核心是盯住ygc频率与耗时、fgc次数、stw总暂停占比、老年代增长趋势四项指标；结合三类日志特征快速定位问题；按jdk版本配置标准gc日志参数；用jstat、jmap三步完成初步诊断。
直接上手就能用的 GC 日志排错手册，核心是“看什么、怎么看、怎么动”，不堆概念，只留关键动作。
一、先盯住这四个数字，别被日志绕晕
不管日志多长、收集器是 G1 还是 ZGC，只盯以下四项：
- YGC 频率和单次耗时：每分钟超过 10 次，或单次 >20ms，说明年轻代太小或对象存活时间过长；
- FGC 次数：线上出现 1 次就该查，一天超 3 次必须干预；
-
STW 总暂停占比：用
jstat -gcutil算出FGCT / (运行总时间)，>2% 就影响稳定性； -
老年代增长趋势：不是看某次大小，而是连续几小时观察
Old Used是否匀速爬升（正常）或突刺式上涨（泄漏/大对象/缓存失控）。
二、快速定位问题的三类日志特征
不用逐行读，扫一眼就知道大概方向：
- 频繁 YGC + Eden 几乎清空后立刻又满 → 对象生成太快，或 Survivor 区太小导致提前晋升；
- Full GC 前老年代已近 95% + Metaspace 使用持续上涨 → 元空间不足或动态类加载泄漏（如反复热部署、Groovy 脚本）；
- 某次 GC 后老年代反而比 GC 前还大 → 大对象直接进老年代（如 new byte[8MB]），或 Survivor 区无法容纳，批量晋升。
三、生产环境 GC 日志标准配置（直接复制）
避免漏关键字段，不同 JDK 版本按需选用：
-
JDK 8 及以前：
-XX:+PrintGCDetails -XX:+PrintGCDateStamps -XX:+PrintTenuringDistribution -XX:+PrintGCApplicationStoppedTime -Xloggc:/data/logs/gc.log -XX:+UseGCLogFileRotation -XX:NumberOfGCLogFiles=5 -XX:GCLogFileSize=100M； -
JDK 11+：
-Xlog:gc*,gc+heap,gc+age,gc+metaspace=info:file=/data/logs/gc.log:time,level,tags:filecount=5,filesize=100M。
四、三步完成初步诊断（不装工具也能做）
没时间搭平台？用系统命令快速过一遍：
- 查当前 GC 状态：
jstat -gcutil <pid> 2s 5</pid>，重点看 FGC、FGCT 和 O（Old）列变化； - 查堆结构是否合理：
jmap -heap <pid></pid>，确认新生代/老年代比例是否匹配业务（如短生命周期服务建议 1:2）； - 查大对象线索：
jmap -histo <pid> | head -20</pid>，关注[B（byte[]）、HashMap、ArrayList占比是否异常高。
