JVM调优思路

JVM运行情况预估

   主要依靠jstat gc -pid 命令统计GC运行情况。如年轻代对象增长速率、Young GC的触发频率和每次耗时、每次Young GC后有多少对象存活和进入老年代、Full GC的触发频率和每次耗时 等。在此信息基础上对jvm参数做出调整。

年轻代对象增长的速率

可以执行命令 jstat -gc pid 1000 10 (每隔1秒执行1次命令，共执行10次)，通过观察EU(eden区的使用)来估算每秒eden大概新增多少对象，如果系统负载不高，可以把频率1秒换成1分钟，甚至10分钟来观察整体情况。注意，一般系统可能有高峰期和日常期，所以需要在不同的时间分别估算不同情况下对象增长速率。

Young GC的触发频率和每次耗时

知道年轻代对象增长速率我们就能推根据eden区的大小推算出Young GC大概多久触发一次，Young GC的平均耗时可以通过 YGCT/YGC公式算出，根据结果我们大概就能知道系统大概多久会因为Young GC的执行而卡顿多久。

每次Young GC后有多少对象存活和进入老年代

这个因为之前已经大概知道Young GC的频率，假设是每5分钟一次，那么可以执行命令 jstat -gc pid 300000 10 ，观察每次结果eden，survivor和老年代使用的变化情况，在每次gc后eden区使用一般会大幅减少，survivor和老年代都有可能增长，这些增长的对象就是每次 Young GC后存活的对象，同时还可以看出每次Young GC后进去老年代大概多少对象，从而可以推算出老年代对象增长速率。

Full GC的触发频率和每次耗时

知道了老年代对象的增长速率就可以推算出Full GC的触发频率了，Full GC的每次耗时可以用公式 FGCT/FGC 计算得出。

优化的理论依据

    其实简单来说就是：

•    对象能在年轻代就被淘汰掉的尽量不让他进入老年代
•    尽量不要触发full GC

  触发young GC的条件：

•    eden区空间不足

  触发full GC的条件：

•   老年代空间不足
•   永久代空间不足
•   young GC时 触发了老年代空间分配担保机制。

 对象进入老年代的条件(即影响老年代对象增长速率)：

•   大对象直接进入老年代
•   大年龄对象进入老年代
•   young GC时根据动态年龄判断机制，一次放入Survivor的对象大于Survivor区的50%，则多余的对象会放入老年代

full gc比minor gc还多的原因

• 元空间不够导致的多余full gc
• 显示调用System.gc()造成多余的full gc，这种一般线上尽量通过­XX:+DisableExplicitGC参数禁用，如果加上了这个JVM启动参数，那么代码中调用System.gc()没有任何效果
• 老年代空间分配担保机制

分析思路

1. 首先，根据老年代的对象增长速率，得出理论上发生full GC的频率。用理论频率与实际频率去对比。
2. 如果实际频率远比理论频率高，那么根据full gc比minor gc还多的原因分析可能是哪一种原因。如尝试增大元空间大小、禁用System.gc()及避免触发老年代空间分配担保机制。
3. 如果实例频率与理论频率相差不多，则说明问题出在老年代对象增长速率上。此时有两种分析思路：

         3.1  考虑降低对象进入老年代的速率。用线程分析确定是否有大量的大对象产生，是否在年轻代young GC时触发了动态年龄判断机制使对象进入了老年代。

         3.2  考虑增大堆大小，以此降低full GC频率。