java fgc_记一次频繁FGC的简单排查

简书 占小狼

转载请注明原创出处，谢谢！

如果读完觉得有收获的话，欢迎点赞加关注

周末愉快，今天有时间记录一下上周遇到的一个问题，学习的脚步不能放慢，也不敢放慢。

存在问题

在线上环境进行服务压测，压测完成后，cpu使用率居高不下，很是费解，按理说已经没有压测请求了，这时消耗cpu资源的只有GC线程了，可以通过jstat命令查看一下JVM的GC情况，然后就碰到了诡异的GC问题。

jstat命令

jstat [ generalOption | outputOptions vmid [interval[s|ms] [count]] ]

参数：

generalOption: 一般使用-gcutil查看GC情况

vmid: 虚拟机进程号，即当前运行的java进程号

interval: 间隔时间，单位为秒或毫秒

count: 打印次数，如果缺省则打印无数次

执行jstat -gcutil 9132 1000命令，线上服务器的GC情况如下：

参数说明如下：

S0: 新生代中Survivor space 0区已使用空间的百分比

S1: 新生代中Survivor space 1区已使用空间的百分比

E: 新生代已使用空间的百分比

O: 老年代已使用空间的百分比

P: 永久带已使用空间的百分比

YGC: 从应用程序启动到当前，发生Yang GC 的次数

YGCT: 从应用程序启动到当前，Yang GC所用的时间【单位秒】

FGC: 从应用程序启动到当前，发生Full GC的次数

FGCT: 从应用程序启动到当前，Full GC所用的时间

GCT: 从应用程序启动到当前，用于垃圾回收的总时间【单位秒】

问题分析

通过打印的GC数据可以看出，JVM一直在进行FGC(cms gc)，不过老年代的使用率反而没有下降，一直稳定在60.16%，对这一情况很疑惑，几乎每次都重现，后来去仔细查看了JVM的启动参数，发现其中CMSInitiatingOcupancyFraction参数，被设置成60，意味着当老年代的使用率达到阈值60%时会触发FGC，但是FGC之后，老年代的使用率还是大于60%，所以会不断的进行FGC，建议这个值不要设置的这么小。

至于为什么FGC之后，老年代的使用率没有下降，可以通过dump查看到底是哪些存活对象在作怪，在进行FGC时，通常会伴随着一次YGC，但这也不是一定的，如果执行YGC之后没有明显效果的话，会设置一个变量，表明下次不用进行YGC，所以如果老年代如果存在大量对象的GC ROOT在新生代的话，这些对象就不会被回收，这种情况必须强制执行一次YGC之后，才有可能回收这些老年代的对象，比如添加参数-XX:+CMSScavengeBeforeRemark，就可以解这个问题。

昨天正好笨神也遇到类似的问题，并写一篇文章《又抓了一个导致频繁GC的鬼–数组动态扩容》进行分析，可以参考一下。