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()没有任何效果
- 老年代空间分配担保机制
分析思路
- 首先,根据老年代的对象增长速率,得出理论上发生full GC的频率。用理论频率与实际频率去对比。
- 如果实际频率远比理论频率高,那么根据full gc比minor gc还多的原因分析可能是哪一种原因。如尝试增大元空间大小、禁用System.gc()及避免触发老年代空间分配担保机制。
- 如果实例频率与理论频率相差不多,则说明问题出在老年代对象增长速率上。此时有两种分析思路:
3.1 考虑降低对象进入老年代的速率。用线程分析确定是否有大量的大对象产生,是否在年轻代young GC时触发了动态年龄判断机制使对象进入了老年代。
3.2 考虑增大堆大小,以此降低full GC频率。