记一次 CMS GC导致 FULL GC 时间开销很大的排查

背景

1. 服务接入注册中心后，就会有实例健康检查，通过ip+port的方式访问接口，检查实例是否健康，某日有个实例出现了告警。检查发现是当时接口超时异常了，触发告警。
2. 短暂的时间后，服务又正常恢复了，接口正常响应。观察日志没有异常问题。

定位分析过程

1. 这个健康接口是个简单的返回，没有经过DB、缓存等。所以超时问题出现在服务本身。
2. 查看CAT、机器基础监控，检查内存，CPU，GC等监控，发现FULL GC在这个时间点有个很长的耗时，环比其他时间都没有这个现象。
3. 定位是GC 导致 时间很长，服务暂停，导致接口超时。

第一次尝试解决方案

1. 分析：服务的JVM参数是 -xms2g -xmx5g
2. 考虑到FULL GC时间长，那应该是老年代需要回收的垃圾太多了，导致整个GC耗时长了，所以调整-xmx4g，缩小JVM的大小，老年代尽快完成FULl GC.
3. 效果不明显，还是会出现这个FULL GC耗时长，接口超时告警. 进一步分析JVM，服务使用的是CMS GC收集器，考虑这里有个STW的阶段可能是原因。

CMS GC收集器分析

了解CMS收集原理

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虚拟机第一款真正意义上的并发收集器，多线程标记清除算法࿰