记一次fullgc问题排查

背景

线上一个数据同步集群偶现延迟，该应用对于数据的实时性要求较高，所以加上了针对延迟监控的业务告警。为了尽快解决延迟的问题，开始通过现有的监控分析出造成问题的原因

蛛丝马迹

通过排查发现同步的机器在一天内出现了多次fullgc。通过对比发现fullgc的时间和告警的时间相吻合，这应该就是导致数据同步延迟的罪魁祸首。

那么问题又来了，是什么原因导致的fullgc呢？继续向下挖掘信息。

这是发生fullgc时间的jvm内存描述信息，精确到5.30的时间点上，可以看到fullgc前老年代已使用的空间大概1.25G，而老年代总共也就不到1.5G的大小，所以老年代使用过高。但是老年代空间不足就一定会导致fullgc吗？不一定，这要看我们使用的是那种jvm垃圾收集器。jvm在进化的过程中垃圾收收集器也在不断的优化，关于垃圾收集器的介绍这里不做具体介绍，可以参考《深入理解Java虚拟机——JVM高级特性与最佳实践(第2版)》，里面有详细的介绍。


上面两张图是将时间轴拉长后得到的，通过对比发现每一次老年代已用空间的下降都伴随着一次fullgc。并且在两次fullgc之间老年代的使用空间一直都在增长，没有任何回落的趋势，这个是什么原因呢？到了这里我需要知道jvm使用的是哪一种收集器。通过命令：

java -XX:+PrintCommandLineFlags -version

-XX:UserParallelOldGC 这个参数说明当前jvm使用的是Parallel Scavenge + Serial Old 组合。意思就是老年代用的是Serial Old 收集器。而这种收集器年老代的对象不会被并行回收，只有等到达到空间阈值时触发fullgc才能回收老年代的无效对象。期间stop the world。业务线程被暂停，导致数据同步停顿。问题找到了如何去解决呢？

解决问题

通过对比常用的垃圾收集器，发现G1通过全新的jvm内存空间划分规则，引入mixgc，能够做到低停顿的前提下回收老年代的无效对象。避免老年代的空间持续扩张。至于G1的优缺点这里也不做详细介绍，可以参考《深入理解Java虚拟机——JVM高级特性与最佳实践(第2版)》。下图是使用了G1后的效果：

通过监控发现，G1下的老年代并没有持续增长，主要是因为G1的mixgc能够回收部分无用的老年代对象，控制老年代的空间。

思考

在jvm垃圾收集器选择的时候要结合自己的业务特点，对于gc停顿是否敏感。对应的选取合适的收集器。G1最为sun公司推出的新一代解决方案，在前几代的基础上做了多方面的优化，在降低停顿时间方面有很好的效果。