直接看gc日志中“谁涨得快、谁降不下去、谁卡在最后”可定位堆内存溢出源头，重点分析各代内存变化异常及oom报错类型，结合full gc前后内存快照与堆转储验证泄漏对象。
直接看 GC 日志里“谁涨得快、谁降不下去、谁卡在最后”，就能定位堆内存溢出的源头。关键不是有没有 GC，而是各代内存变化是否异常，以及是否伴随明确的 OOM 报错。
先确认日志末尾是否有明确 OOM 提示
翻到日志最底部，找类似下面的报错：
- java.lang.OutOfMemoryError: Java heap space → 堆空间耗尽，重点查老年代持续高位；
- GC overhead limit exceeded → GC 花了 98% 时间只回收不到 2% 空间，说明回收效率极低；
- 没有明显报错但 Full GC 频繁且耗时增长 → 可能是泄漏初期，还没触发最终 OOM。
有报错后，往上回溯几行，找到最后一次 Full GC 前后的内存快照，比对各代 used 值变化。
盯紧三组数字：Eden、Survivor、Old 的使用趋势
每条 GC 日志中都包含类似 [PSYoungGen: 8192K->1024K(9216K)] [ParOldGen: 5120K->9216K(9216K)] 的结构，重点关注：
- 年轻代（YoungGen）长期 >95% 且 Minor GC 非常密集（如每秒多次），但每次只回收一点点 → 可能 Survivor 区太小、对象存活率高，或大对象直接进老年代；
- 老年代（OldGen）占用缓慢但持续上升，Full GC 后仅从 98% → 95%，且回收量极少（如只释放几十 KB）→ 典型内存泄漏信号；
- Full GC 耗时越来越长（>1s），同时 OldGen 使用率几乎不变 → 对象无法被回收，引用链未断。
识别典型溢出模式组合
不同问题在日志中有特征性表现，对照判断：
- 堆内存溢出：老年代使用率逐步逼近 100%，多次 Full GC 后仍无法释放，最终报 “Java heap space”；
- GC 开销过大：日志高频出现 “GC pause”，单次耗时高，伴随 “GC overhead limit exceeded” 字样；
- 疑似泄漏但未爆 OOM：jstat -gcutil 显示 OU（Old Used）持续上涨，YGC 频次稳定但 FGC 间隔缩短、回收比下降。
配合堆转储进一步验证
光看日志只能判断“哪里没降”，要确认“为什么没降”，需生成堆快照：
- 启动时加参数：-XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/path/to/dump，OOM 时自动保存；
- 运行中怀疑泄漏，用 jmap -dump:format=b,file=heap.hprof
手动抓取； - 用 Eclipse MAT 或 VisualVM 打开 dump 文件，按“dominator tree” 查看占用最大的对象类型，再追溯其强引用链。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
