JVM调优情况十分复杂，各种情况都可能导致垃圾回收不能够达到预想的效果。对于场景问题，可以从如下几个 大方向进行设计：
- 在大访问压力下，MinorGC 频繁，MinorGC 是针对新生代进行回收的，每次在MGC 存活下来的对象，会移动 到Survivor1区。先到这里为止，大访问压力下，MGC 频繁一些是正常的，只要MGC 延迟不导致停顿时间过长或 者引发FGC ，那可以适当的增大Eden 空间大小，降低频繁程度，同时要保证，空间增大对垃圾回收时间产生的 停顿时间增长也是可以接受的。 继续说，如果MinorGC 频繁，且容易引发 Full GC。需要从如下几个角度进行分析。a：每次MGC存活的对象的 大小，是否能够全部移动到 S1区，如果S1 区大小 < MGC 存活的对象大小，这批对象会直接进入老年代。注意 了，这批对象的年龄才1岁，很有可能再多等1次MGC 就能被回收了，可是却进入了老年代，只能等到Full GC 进 行回收，很可怕。这种情况下，应该在系统压测的情况下，实时监控MGC存活的对象大小，并合理调整eden和s 区的大小以及比例。还有一种情况会导致对象在未达到15岁之前，直接进入老年代，就是S1区的对象，相同年 龄的对象所占总空间大小>s1区空间大小的一半，所以为了应对这种情况，对于S区的大小的调整就要考虑：尽 量保证峰值状态下，S1区的对象所占空间能够在MGC的过程中，相同对象年龄所占空间不大于S1区空间的一半， 因此对于S1空间大小的调整，也是十分重要的。
- 由于大对象创建频繁，导致Full GC 频繁。对于大对象，JVM专门有参数进行控制，-XX： PretenureSizeThreshold。超过这个参数值的对象，会直接进入老年代，只能等到full GC 进行回收，所以在系统 压测过程中，要重点监测大对象的产生。如果能够优化对象大小，则进行代码层面的优化，优化如：根据业务 需求看是否可以将该大对象设置为单例模式下的对象，或者该大对象是否可以进行拆分使用，或者如果大对象 确定使用完成后，将该对象赋值为null，方便垃圾回收。如果代码层面无法优化，则需要考虑：a:调高-XX： PretenureSizeThreshold参数的大小，使对象有机会在eden区创建，有机会经历MGC以被回收。但是这个参数的 调整要结合MGC过程中Eden区的大小是否能够承载，包括S1区的大小承载问题。b：这是最不希望发生的情况， 如果必须要进入老年代，也要尽量保证，该对象确实是长时间使用的对象，放入老年代的总对象创建量不会造 成老年代的内存空间迅速长满发生Full GC，在这种情况下，可以通过定时脚本，在业务系统不繁忙情况下，主 动触发full gc。
- MGC 与 FGC 停顿时间长导致影响用户体验。其实对于停顿时间长的问题无非就两种情况：a：gc 真实回收过 程时间长，即real time时间长。这种时间长大部分是因为内存过大导致，导致从标记到清理的过程中需要对很大 的空间进行操作，导致停顿时间长。b：gc真实回收时间 real time 并不长，但是user time(用户态执行时间) 和 sys time（核心态执行时间）时间长，导致从客户角度来看，停顿时间过长。对于a情况，要考虑减少堆内存大 小，包括新生代和老年代，比如之前使用16G的堆内存，可以考虑将16G 内存拆分为4个4G的内存区域，可以单 台机器部署JVM逻辑集群，也可以为了降低GC回收时间进行4节点的分布式部署，这里的分布式部署是为了降低 GC垃圾回收时间。对于b情况，要考虑线程是否及时达到了安全点，通过
-XX：+PrintSafepointStatistics和-XX： PrintSafepointStatisticsCount=1去查看安全点日志，如果有长时间未达到安全点的线程，再通过参数-XX： +SafepointTimeout和-XX：SafepointTimeoutDelay=2000两个参数来找到大于2000ms到达安全点的线程，这里 的2000ms可以根据情况自己设置，然后对代码进行针对的调整。除了安全点问题，也有可能是操作系统本身负 载比较高，导致处理速度过慢，线程达到安全点时间长，因此需要同时检测操作系统自身的运行情况。 - 内存泄漏导致的MGC和FGC频繁，最终引发oom。内存泄漏的排查参见面试题247. 5. 纯代码级别导致的MGC和FGC频繁。如果是这种情况，那就只能对代码进行大范围的调整，这种情况就非常 多了，而且会很糟糕。如大循环体中的new 对象，未使用合理容器进行对象托管导致对象创建频繁，不合理的 数据结构使用等等。 总之，JVM的调优无非就一个目的，在系统可接受的情况下达到一个合理的MGC和FGC的频率以及可接受的回收 时间