如何利用分析工具评估GC带来的影响

直接看 GC 对应用的影响，说白了，核心就三件事：停顿、频率、内存变化。工具只是辅助，关键是用对指标、读准信号。先把这三个维度量化出来，后续的分析才有意义。

盯住真实停顿时间，别被 System.gc() 干扰

System.gc() 触发的 Full GC 往往会造成秒级卡顿，但这种停顿和业务压力无关，纯粹是代码误调用。它会拉高 P99 延迟，甚至导致 K8s 探针失败，却掩盖了真实瓶颈。所以，必须先把 System.gc() 的影响剥离出来，剩下的 Full GC 才值得深挖。

• 先加 -XX:+DisableExplicitGC 启动参数，让 System.gc() 静默失效
• 禁用后，再观察 jstat -gc 输出里的 FGC 列是否停止异常增长
• GC 日志中不再出现 “(System.gc())” 字样，剩下的 Full GC 才值得深挖

用 GCViewer 看趋势，不是只看单次日志

GCViewer 把文本日志转成图表，一眼就能识别异常模式——比如堆不回落、停顿毛刺、Full GC 规律性爆发。这些趋势比单次日志更能说明问题。

• 重点看 Heap Usage Over Time：老年代持续爬升不回落，暗示内存泄漏或缓存失控
• 关注 Pause Time Distribution：出现 >200ms 的尖峰，检查是否 G1 fallback 或 CMS concurrent mode failure
• 对比 Young GC 间隔：从几分钟缩到几十秒，可能对象分配过快，或 Survivor 区太小导致提前晋升

结合 jstat 和 GC 日志交叉验证

jstat 提供实时快照，GC 日志记录历史行为，两者对照才能排除偶然抖动。单看任何一个都可能误判。

• 运行 jstat -gc 1000 5，看 YGC/YGCT/FGC/FGCT 是否稳定增长
• 若 FGC 次数上升但 FGCT 单次耗时很短，可能是元空间耗尽触发的轻量级 Full GC
• 若 E、O 区使用率同步缓慢上涨，老年代填满的前兆，需查长期存活对象（用 jmap -histo）

让 GCeasy 帮你定位根因，不止于现象

GCeasy 是带机器学习分析能力的在线工具，上传 gc.log 后自动标出风险项，比如“过早晋升”“DirectByteBuffer 泄漏”“Metaspace 接近上限”。它比手动翻日志更高效。

• 它会直接指出哪类对象占老年代最多，比手动翻 jmap -histo 更快定位静态 Map 或 ThreadLocal 持有
• 对 G1 收集器，能识别并发标记失败次数及原因（如 Evacuation Failure 或 Mixed GC 太少）
• 输出报告里带修复建议，比如“建议增大 -XX:MaxMetaspaceSize=512m”或“检查 Netty 的 PooledByteBufAllocator 使用方式”