gc日志是反映内存行为节奏的“心跳图”，关键在于识别eden/survivor/heap空间变化、暂停原因及real停顿时间等异常信号，而非统计full gc次数。
GC 日志不是用来数 Full GC 次数的，而是用来读取内存行为节奏的“心跳图”。真正影响服务稳定性的，往往不是 GC 发生了多少次，而是某次 Minor GC 后 Eden 区几乎没释放空间、某次 Full 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)]
- 暂停类型与原因：不要只认“GC”或“Full GC”，重点看括号内内容。“Allocation Failure”说明是 Eden 满了触发；“G1 Evacuation Pause (young)”表示这是 G1 的年轻代回收；“Metadata GC Threshold”则指向元空间压力。
- 各代空间变化：Eden 从 1024M→0B，说明对象基本被清空；Survivor 保持 128M 不变，意味着大量对象晋升失败或直接进入老年代；Heap 整体从 1840M→820M，回收了约 1GB，但若后续几轮中 Heap 使用量持续回升且 Survivor 占用不降，就提示对象存活率高或晋升阈值不合理。
- 真实停顿时间：注意 real=0.123ms 这个值，它是 STW（Stop-The-World）实际耗时。user/sys 时间反映 CPU 开销，但 real 才决定请求延迟。如果 real 值频繁超过 10ms（尤其在低延迟服务中），就要检查是否发生并发失败（concurrent mode failure）或 Mixed GC 耗时突增。
识别异常模式比统计次数更重要
高频 Full GC 只是表象，背后原因各异。日志中真正值得警觉的信号包括：
- 年轻代刚填满就触发 Minor GC，且每次回收后 Eden 几乎归零但 Survivor 区持续高位 → 可能 Survivor 空间过小或对象年龄阈值（MaxTenuringThreshold）设得太低，导致提前晋升。
- Full GC 后老年代使用量未明显下降，甚至略升 → 存在内存泄漏（如静态 Map 持有业务对象）、缓存未清理，或大对象（Humongous Object）长期驻留。
- 日志中反复出现 “to-space exhausted” 或 “evacuation failed” → G1 Region 不足或 Humongous 分配失败，需检查 -XX:G1HeapRegionSize 是否合理，或是否存在超大数组/ByteBuffer。
- 同一时间段内 Minor GC 频率陡增（如从每 5 秒一次变为每 200ms 一次），而业务 QPS 并未显著上升 → 很可能代码中突发创建大量短生命周期对象（如循环内 new 对象、JSON 序列化临时结构），应优先优化分配逻辑而非加堆。
日志必须和上下文对齐才有意义
孤立看一行 GC 日志，就像只听一句台词猜整部剧。有效分析必须绑定时间窗口和业务动作：
- 启动参数中务必加入
-Xlog:gc*:file=gc.log:time,uptime,level,tags（JDK 11+），确保每条日志带绝对时间、运行时长、级别和标签，方便与监控系统（如 Prometheus + Grafana）或业务日志对齐。 - 发生告警时，先定位时间点，再查该时刻前后 30 秒内的 GC 日志，同时比对应用线程栈（jstack）、堆直方图（jmap -histo）和内存分配热点（JFR 或 Async Profiler），确认是 GC 导致延迟，还是 GC 是其他问题（如锁竞争、IO 阻塞）的结果。
- 避免用
System.gc()辅助排查：它只是建议，不保证执行，且日志中若出现Full GC (System.gc())，说明已触发全停顿，属于线上禁用行为。真正可观测的是自动 GC 的规律性与响应性。
选对回收器，日志解读逻辑完全不同
不同 GC 器的日志结构和关键指标差异很大，不能套用同一套经验：
- G1：关注 Mixed GC 触发频率、老年代区域回收比例、Remembered Set 更新耗时（update RS 阶段）。日志中 “Mixed GC” 表示开始清理部分老年代 Region，若 Mixed GC 耗时波动大或失败，需调优 -XX:G1MixedGCCountTarget 和 -XX:G1OldCSetRegionThresholdPercent。
- ZGC/Shenandoah：日志中极少出现 STW 暂停，主要看 “Pause” 类型是否为 “Relocate” 或 “Mark”；real 时间通常低于 1ms，若某次 Pause real > 5ms，大概率是并发阶段被打断（如 CPU 资源争抢）或堆外内存压力大。
-
Parallel GC：日志简洁，但需紧盯吞吐量。若
[Times: user=2.12 sys=0.03, real=1.89]中 real 远小于 user，说明并行线程效率高；若 real 接近 user，可能存在 CPU 瓶颈或 GC 线程数（-XX:ParallelGCThreads）设置不当。
