JVM查看gc情况

jvm gc查看

jstat -gcutil pid interval(ms)

举例：

jstat -gcutil 332 1000

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

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-edqWvTZF-1649055476173)(https://blog.csdn.net/zkq_1986/article/details/79325552)]参数说明如下：

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，就可以解这个问题。

。