直接看gc日志中“谁涨得快、谁降不下去、谁卡在最后”可定位堆内存溢出源头，重点分析各代内存变化异常及oom报错类型，结合堆转储验证泄漏对象。
直接看 GC 日志里“谁涨得快、谁降不下去、谁卡在最后”，就能定位堆内存溢出的源头。关键不是有没有 GC，而是各代内存变化是否异常，以及是否伴随明确的 OOM 报错。
先确认日志末尾是否有明确 OOM 提示
翻到日志最底部，找类似下面的报错：
- java.lang.OutOfMemoryError: Java heap space → 堆空间耗尽，重点查老年代持续高位；
- GC overhead limit exceeded → 不是内存绝对不足，而是 GC 效率崩溃（98% 时间只回收不到 2%），说明对象长期存活或老年代严重碎片化；
- 没有明显报错但 Full GC 频繁且耗时增长 → 很可能是泄漏初期，还没触发最终 OOM，需立即干预。
有报错后，往上回溯几行，找到最后一次 Full GC 前后的内存快照，比对各代 used 值变化。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
盯紧三组数字：Eden、Survivor、Old 的使用趋势
每条 GC 日志中都包含类似 [PSYoungGen: 8192K->1024K(9216K)] [ParOldGen: 5120K->9216K(9216K)] 的结构，重点关注：
- 年轻代长期 >95%，Minor GC 每秒多次，但每次只回收一点点 → 可能 Survivor 区太小、对象存活率高，或大对象直接进老年代；
- 老年代占用缓慢但持续上升，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” 查看 Retained Heap 占比最大的对象类型，再右键 → Path to GC Roots（排除弱/软/虚引用），追溯强引用链。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
