直接看 Full GC 日志的 reason 字段并结合前后内存趋势即可准确定位根源：Allocation Failure 表示老年代将满或 Survivor 过小；Metaspace 相关说明类加载过多；System.gc() 提示代码误调用；concurrent mode failure 暴露 CMS 碎片化问题；Ergonomics 反映 JVM 自适应失败；O 列持续高位或缓慢上升指向内存泄漏，快速升降则倾向流量突增或新生代配置不当；G1/ZGC 中的 Full GC 需警惕严重异常；辅以 jstat、jmap 和 MAT 交叉验证。
直接看 Full GC 日志里的 reason 字段，再结合前后几行内存变化趋势，就能准确定位根源。不用等 OOM，也不用先 dump 堆——GC 日志本身已经给出关键线索。
看日志开头的触发原因关键词
每条 Full GC 日志通常在括号内标注触发 reason，这是最直接的判断依据：
- Allocation Failure：新生代满、对象晋升失败，老年代没空间接收 → 老年代确实快满了，或 Survivor 区太小导致对象提前晋升
- Metadata GC Threshold 或 Metaspace allocation failure：元空间耗尽 → 类加载过多，比如热部署、动态代理、大量反射、自定义 ClassLoader 泄漏
- System.gc()：代码或第三方库显式调用了 System.gc() → 检查监控埋点、测试代码、旧版 Druid/Quartz 等框架
- concurrent mode failure（CMS 收集器）：CMS 并发清理未完成，老年代就撑不住了 → 老年代碎片化严重，或 -XX:CMSInitiatingOccupancyFraction 设置过高
- Ergonomics：JVM 自适应策略主动触发 → 多见于开启 -XX:+UseAdaptiveSizePolicy 后，各区域比例反复调整失败
结合上下文看内存变化趋势
单看一行 reason 不够，要拉出前后 3～5 次 GC 记录，重点观察老年代使用量（O 列）：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- Full GC 后老年代占用率从 85% → 70% → 82% → 75% → 86%，缓慢爬升 → 很可能是内存泄漏（对象被意外强引用）
- Full GC 后老年代瞬间降到 10% 以下，几分钟后又冲到 95% 触发下一次 → 更可能是业务流量突增 + 新生代配置不合理，对象批量晋升
- 用 jstat -gcutil PID 2000 实时观察，若 O 持续 >80% 且不回落，基本可确认是老年代瓶颈
注意区分“真 Full GC”和“伪 Full GC”
有些日志写着 Full GC，实际不是整堆回收：
立即学习“Java免费学习笔记（深入）”；
- G1 下出现 Full GC (Ergonomics) 或 Full GC (G1 Evacuation Pause)：其实是 G1 回退到单线程串行收集，根源常在大对象分配失败或并发标记失败
- ZGC / Shenandoah 日志里几乎不会出现 Full GC 字样：它们设计目标就是消除 STW 全堆回收；若看到 Full GC，说明已严重异常，需立即排查
- 日志末尾有 java.lang.OutOfMemoryError: Java heap space → 堆耗尽，重点查老年代持续高位；有 GC overhead limit exceeded → 回收效率极低，可能已进入泄漏晚期
辅助验证手段不能少
光靠日志还不够，需要交叉验证：
- 用 jmap -dump:live,format=b,file=heap.hprof PID 抓取 Full GC 前后的堆转储，用 MAT 分析大对象和强引用链
- 用 jstat -gc PID 1000 观察对象晋升速率，若每次 Young GC 后有 30%+ 对象直接进老年代，说明 Survivor 区过小或 MaxTenuringThreshold 设置不当
- 检查是否有静态 Map 缓存未设 TTL、未淘汰，或线程局部变量（ThreadLocal）持有大对象未清理
