核心是盯住YGC频率与耗时、FGC次数、STW总暂停占比、老年代增长趋势四项指标；结合三类日志特征快速定位问题；按JDK版本配置标准GC日志参数；用jstat、jmap三步完成初步诊断。

直接上手就能用的 GC 日志排错手册，核心是“看什么、怎么看、怎么动”，不堆概念，只留关键动作。

一、先盯住这四个数字，别被日志绕晕

不管日志多长、收集器是 G1 还是 ZGC，只盯以下四项：

• YGC 频率和单次耗时：每分钟超过 10 次，或单次 >20ms，说明年轻代太小或对象存活时间过长；
• FGC 次数：线上出现 1 次就该查，一天超 3 次必须干预；
• STW 总暂停占比：用 jstat -gcutil 算出 FGCT / (运行总时间)，>2% 就影响稳定性；
• 老年代增长趋势：不是看某次大小，而是连续几小时观察 Old Used 是否匀速爬升（正常）或突刺式上涨（泄漏/大对象/缓存失控）。

二、快速定位问题的三类日志特征

不用逐行读，扫一眼就知道大概方向：

Java调试

通过 JDWP 实现 Java 远程调试：连接远程 JVM、设置断点、单步执行代码、查看变量值、获取调用栈。适用于需要调试远程 Java 应用、排查运行时状态、追踪代码执行流程的场景。 术语注解 JDWP：Java Debug Wire Protocol，Java 调试有线协议（Java 远程调试底层通信协议） remote JVM：远程 Java 虚拟机 step through code：代码单步调试（步入 / 步过 / 步出调试） inspect variables：变量查看 / 变量检视 stac

下载

• 频繁 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 2s 5，重点看 FGC、FGCT 和 O（Old）列变化；
• 查堆结构是否合理：jmap -heap ，确认新生代/老年代比例是否匹配业务（如短生命周期服务建议 1:2）；
• 查大对象线索：jmap -histo | head -20，关注 [B（byte[]）、HashMap、ArrayList 占比是否异常高。