要看懂Java GC日志，关键是建立“日志→内存行为→系统状态”映射逻辑：紧盯时间戳、GC类型、回收前后堆占用、总耗时及失败信号（如promotion failed），分阶段分析Minor GC（关注Eden/Survivor变动）、Full/Mixed GC（聚焦触发原因与老年代回收效率），并结合jstat、JFR、MAT等工具交叉验证，避免仅依赖日志做判断。
要看懂 Java 虚拟机 GC 日志，关键不是逐行翻译，而是建立「日志 → 内存行为 → 系统状态」的映射逻辑。它本质上是一份 JVM 垃圾回收的“行车记录仪”，记录了每次 GC 的时间、区域、对象流动和资源消耗。
先抓核心字段，别被细节淹没
GC 日志里真正需要盯住的只有几个字段：
- 时间戳（如 2026-10-09T03:45:22.112+0800）——定位问题发生时刻
- GC 类型（GC 表 Minor GC，Full GC 或 Allocation Failure 触发的混合回收）
- 回收前/后堆内存占用（如 [PSYoungGen: 892M->124M(920M)]）——看 Eden/Survivor 是否频繁打满、对象是否过早晋升
- 总耗时（[Times: user=0.08 sys=0.01, real=0.09 secs]）——real 时间超过 100ms 就值得警惕
- 是否出现 promotion failed 或 concurrent mode failure ——这是老年代压力过载的明确信号
分阶段看：Minor GC 日志怎么看
重点关注年轻代三块区域（Eden + S0 + S1）的变动：
- 如果每次 Minor GC 后 Eden 都清空，但 Survivor 区持续堆积、使用率逼近 100%，说明对象存活率高，可能该调大 SurvivorRatio 或检查是否有缓存滥用
- 如果 Eden 没满就频繁触发 GC（比如每秒好几次），大概率是年轻代太小（-Xmn 设置过低）或有大量短生命周期大对象（如 MB 级 byte[]）
- 出现 Desired survivor size 1048576 bytes, new threshold 1 (max 15) 且很快晋升，说明动态年龄判断已启动，对象正在加速进入老年代
Full GC / Mixed GC 日志重点看什么
这不是“偶尔一次”的事，而是系统承压的体现：
- 先看触发原因：Ergonomics（JVM 自适应触发）、Metadata GC Threshold（元空间满了）、Allocation Failure（老年代没空间容纳晋升对象）
- 对比老年代回收前后大小：[ParOldGen: 2145M->2140M(2560M)]——只回收了 5MB 却花了 300ms？那基本是 CMS 失败或 G1 的 evacuation failure，得查碎片或停顿目标是否设得太激进
- 注意是否伴随 to-space overflow（G1）或 concurrent cycle abandoned（ZGC/Shenandoah）——说明并发回收跟不上分配速度
结合工具交叉验证，别只信日志
GC 日志是线索，不是结论：
- 把日志时间点和 JFR（Java Flight Recorder）或 Prometheus + Grafana 的堆内存曲线对齐，确认是否真有内存缓慢泄漏
- 用 jstat -gc
实时观察各代容量与使用率变化节奏，验证日志中“为什么这时候 GC” - 若发现频繁 Full GC，立刻用 jmap -histo
看类实例数量，再配合 MAT 分析 dump，大概率会看到 HashMap、ArrayList 或 ThreadLocal 持有大量对象
不复杂但容易忽略
