简书 占小狼
转载请注明原创出处，谢谢！
如果读完觉得有收获的话，欢迎点赞加关注
周末愉快，今天有时间记录一下上周遇到的一个问题，学习的脚步不能放慢，也不敢放慢。
存在问题
在线上环境进行服务压测，压测完成后，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的鬼--数组动态扩容》进行分析，可以参考一下。
