学Java垃圾回收日志关键在于建立“日志即内存行为快照”思维，需用JDK 11+的-Xlog参数正确开启，聚焦暂停原因、空间变化与真实STW时间，并借助GCEasy等工具识别内存泄漏、晋升异常等真问题。
学Java垃圾回收日志，关键不是背参数，而是建立“日志即内存行为快照”的思维——每行日志都在告诉你对象怎么分配、在哪存活、为何晋升、何时卡住。掌握它不靠死记，靠拆解真实场景中的信号。
从开日志开始：JDK 11+ 必须用 -Xlog，旧参数已失效
别再写 -XX:+PrintGCDetails -Xloggc:gc.log，JDK 11 起这些参数静默失效。正确写法是：
-
-Xlog:gc*:file=gc.log:time,uptime,pid,tags—— 最常用组合，覆盖所有GC事件，带时间戳和进程标识 - 轻量监控可选：
-Xlog:gc=info，只输出基础信息，减少IO压力 - 查晋升年龄必须加：
gc,age标签，否则看不到对象在Survivor里活了几轮 - 生产环境务必加滚动：
:filecount=5,filesize=20M，防止单个日志撑爆磁盘
看懂一行日志：盯住三类核心信息
以 G1 日志为例：2026-10-08T11:23:45.678+0800: 12345.789: [GC pause (G1 Evacuation Pause) (young), 0.042ms][Eden: 1024M(1024M)->0B, Survivors: 128M->128M, Heap: 2100M(4096M)->980M(4096M)][Times: user=0.03s, sys=0.00s, real=0.042s]
- 暂停类型与原因：括号里内容比“GC”二字重要。“Allocation Failure”= Eden填满；“Metadata GC Threshold”= 元空间快爆了；“Ergonomics”= JVM自动调优失败，已失控
- 各代空间变化：Eden→0B 是正常；但 Survivor 保持高位不变，说明大量对象没被回收又没晋升，可能 Survivor 空间太小或 MaxTenuringThreshold 设得太低
-
真实停顿时间：看
real=0.042s，这才是 STW 时间，直接决定请求延迟。user/sys 是CPU总耗时，多核下可能比 real 还大
识别真问题：别数 Full GC 次数，要抓异常节奏
高频 Full GC 是结果，不是根因。真正该警觉的是这些信号：
- Minor GC 后 Eden 归零，但老年代使用率逐轮上升 → 对象存活率高，或有缓存未清理、静态集合持续add
- Full GC 后老年代占用不降反升 → 极大概率内存泄漏（如 ThreadLocal 持有对象、未关闭的流、监听器未反注册）
- 日志反复出现
to-space exhausted或evacuation failed→ G1 Region 不足，需检查-XX:G1HeapRegionSize是否合理，或存在超大数组 - 某次 Young GC real 时间突然从 20ms 跳到 200ms → 可能触发了并发失败（concurrent mode failure），说明老年代增长太快，CMS/G1 来不及回收
分析工具：别硬啃原始日志，用 GCEasy 做结构化解读
GC 日志字段随 JDK 小版本、GC 算法（G1/ZGC/Shenandoah）差异极大，自己写脚本 grep 容易漏判。推荐：
立即学习“Java免费学习笔记（深入）”；
- GCEasy：上传日志自动生成吞吐量趋势图、STW 分布直方图、内存升降热力图，并自动标出异常点（如某次 GC 晋升速率突增300%）
-
jstat 实时辅助：运行中执行
jstat -gc <pid> 1s，观察 S0/S1/E/O 使用率变化节奏，验证日志推断 -
动态开启（不重启）：生产紧急排查可用 JMX，调用
VM.log命令实时开启日志输出到文件或控制台，无需改启动参数
