掌握JVM GC日志分析的关键在于建立“行为—数字—问题”直觉映射：盯住暂停类型与原因、各代空间变化、真实停顿时间三类字段，识别异常模式（如Survivor不降、老年代反升、to-space exhausted）比统计次数更重要，并结合jmap/jstat/Arthas等工具交叉验证，将日志视为时间序列看趋势。
掌握 JVM GC 日志分析进阶技巧，核心不在记住所有参数，而在于建立“行为—数字—问题”的直觉映射。真正卡住线上服务的，往往不是 Full GC 出现了几次，而是某次 Minor GC 后 Eden 几乎清空、Survivor 却纹丝不动，或某次 Mixed GC 耗时突然翻倍却没触发报警——这些信号就藏在每行日志的字段组合里。
盯住三类关键字段，别被括号绕晕
一行典型 G1 日志：
2024-03-15T14:23:01.123+0800: 34567.890: [GC pause (G1 Evacuation Pause) (young), 0.123ms] [Eden: 1024M(1024M)->0B, Survivors: 128M->128M, Heap: 1840M(4096M)->820M(4096M)]
- 暂停类型与原因：括号里写的是“谁干的”和“为什么干”。Allocation Failure 是 Eden 满了；G1 Evacuation Pause (young) 是年轻代回收；Metadata GC Threshold 则指向元空间快爆了——别只扫一眼“GC”，要读括号里的动因。
- 各代空间变化：看箭头（→）前后数字差值。Eden 从 1024M→0B，说明对象基本被清掉；Survivor 保持 128M→128M，意味着大量对象没地方去，只能晋升或卡在 Survivor；Heap 整体下降 1GB，但若后续几轮中老年代持续上涨，就是存活率高或晋升阈值不合理。
- 真实停顿时间：结尾的 0.123ms 是 real 时间，即 STW 实际挂起应用的时间。user/sys 是 CPU 开销，real 才决定接口延迟。超过 10ms 就该警惕，尤其在低延迟服务中，它可能暗示并发失败或 Mixed GC 异常。
识别异常模式，比统计次数重要十倍
高频 Full GC 是症状，不是病根。真正值得立刻干预的信号有：
- Minor GC 后 Eden 归零，但 Survivor 占用长期高位 → Survivor 区太小，或 -XX:MaxTenuringThreshold 设得太低，对象被迫提前进老年代。
- Full GC 后老年代使用量不降反升 → 内存泄漏（比如静态 Map 持有业务对象）、缓存未清理，或大对象（Humongous Object）长期驻留。
- 日志反复出现 to-space exhausted 或 evacuation failed → G1 Region 不足，或 -XX:G1HeapRegionSize 设置不合理，常见于超大数组、DirectByteBuffer 分配失败。
- Minor GC 频率陡增（如从每 5 秒一次变成每 200ms 一次），而 QPS 没变 → 代码里突发创建大量短生命周期对象，比如循环内 new 对象、JSON 反序列化未复用 ObjectMapper。
结合工具链验证猜想，别单靠日志猜
GC 日志告诉你“发生了什么”，但未必说清“谁干的”。需要配合其他工具交叉印证：
- 看到老年代持续增长，立刻执行 jmap -histo <pid> | head -20，查前 20 名对象类型，确认是不是某个 Map 或 List 在疯长。
- 怀疑大对象导致晋升异常，用 jstat -gc <pid> 观察 EC（Eden 容量）、EU（Eden 使用）、OC（老年代容量）、OU（老年代使用），再配合 -XX:+PrintTenuringDistribution 看年龄分布直方图。
- 发现频繁 System.gc()，检查日志里是否有 Full GC (System.gc())，再用 Arthas 的 trace java.lang.System gc 定位调用点。
- 想确认是否元空间压力，运行 jstat -gcmetacapacity <pid>，观察 MCMN/MCMX（元空间最小/最大容量）和 MC/MU（当前容量/已用）是否逼近。
把日志当时间序列看，趋势比单点更关键
单条日志只是快照，连续几十分钟的日志才能看出节奏。重点关注：
- Eden 填满到触发 Minor GC 的间隔是否越来越短？说明分配速率在上升，或新生代偏小。
- 每次 Minor GC 后老年代增量是否稳定？如果某次突增 200MB，就要查那段时间做了什么操作（比如批量导入、报表导出）。
- GC 总耗时（GCT）占应用运行时间的比例是否持续超过 5%？超过这个线，用户大概率感知到卡顿。
- 同一台机器上不同服务的 GC 日志对比：如果 A 服务 GC 频繁而 B 服务平稳，且堆配置相近，问题大概率在 A 的代码分配行为，而非 JVM 参数本身。
