Java 内存溢出 OOM 怎么排查？如何用 Heap Dump 找到问题对象？

知识点详解：从错误信息走到保留对象的引用链

第一件事，是确认你遇到的真是哪一种 OOM

咱们假设订单服务突然失败，日志里出现 OutOfMemoryError。

先把后面的具体信息读完。Java heap space 通常指 Java 堆无法满足分配；Metaspace 要检查类元数据及类加载；Direct buffer memory 要检查直接内存；unable to create native thread 则要检查线程数量、原生内存和系统限制。

这些问题需要的证据不同。堆快照很适合分析堆对象，但不能包办所有堆外内存问题。容器被操作系统 OOM Kill，也可能没有 Java 异常、没有自动堆快照，应该查看容器退出原因和系统事件。

堆很满，不等于发生了泄漏

假设这个服务每次把全部订单加载到内存中。订单数量增加以后，正常结果集就可能超过堆容量。这属于工作量和容量不匹配，不一定存在一个“忘了释放”的对象。

另一种情况是：每次查询产生的订单对象都被放进全局集合，任务结束后也没有移除。即使 GC 执行完，它们仍然被引用，回收后的内存基线就会逐渐抬高。

因此，要观察相近负载下多次回收后的趋势。单次使用率达到 90%，或者刚好看到一个大数组，都不足以独立证明泄漏。大数组也可能是此刻正在工作的合理数据。

Heap Dump 里，要顺着“保留关系”往回找

继续看那个全局订单集合。集合对象本身可能不大，但它能通过内部数组、节点等结构，连到大量订单对象。

分析工具通常会提供几种视角：

• 对象数量与浅大小：这一类有多少实例，对象自身占多少空间。
• 保留大小：如果某个对象可以被回收，连带有多少只靠它保留的对象也能被回收。
• 支配树与引用路径：谁在保留这片对象，它又通过什么路径仍然可达。

咱们真正想找到的可能是“GC Root → 全局缓存 → 集合 → 订单对象”，而不是只停在“Order 对象很多”。看到引用链以后，再回到代码确认：它为什么加入、什么时候应该移除、有没有容量或过期限制。

保留大小也是基于当前快照和引用关系计算的分析指标，不是“删除这行代码就一定立刻释放这么多内存”的保证。

快照怎样取，取之前要注意什么？

HotSpot 可以提前配置 -XX:+HeapDumpOnOutOfMemoryError，并用 -XX:HeapDumpPath 指定受控位置。也可以在合适时机使用 jcmd。下面是 Shell 命令示意，12345 需要换成已确认的目标 JVM PID：

jcmd 12345 GC.heap_info
jcmd 12345 GC.heap_dump /var/tmp/order-service-oom.hprof

不要不看进程就直接复制执行。堆转储可能暂停应用、占用很大磁盘空间，也可能包含口令、用户数据等敏感内容。需要先确认业务影响、磁盘空间、目录权限和后续保管方式。

如果问题在原生内存，还可以结合 Native Memory Tracking 等工具；它也有启用条件和覆盖范围，不能凭堆快照较小就认定进程没有内存问题。

修复以后，怎样证明判断对了？

假设最后发现缓存没有上限。修复可能包括限制条数、设置过期、改成分页处理，具体取决于这些对象为什么被保存。

然后在相近负载与资源配置下重新观察：GC 后基线是否稳定，错误是否消失，吞吐和尾延迟有没有新的问题。内存曲线仍然会随分配与回收上下变化，不需要追求“一条永不增长的直线”。

本篇按 Oracle 内存泄漏排障指南 和 HotSpot 命令文档核验，未在生产服务执行转储。

面试官继续追问

线上正在失败，是先分析还是先恢复？

先根据故障影响止损，同时尽量保留日志、指标、转储等证据。重启能恢复服务，但可能把重要现场一起清掉，应该区分恢复动作和定位结论。

把堆翻倍，问题是不是就解决了？

正常工作集超过容量时可能有效；持续保留无用对象时，只是延后失败。还要看进程总内存与容器额度，避免堆扩大后挤压堆外空间。

面试速记卡

• 先分类：堆、元空间、直接内存、线程和系统 OOM，不混为一谈。
• 看趋势：GC 后基线持续上升，比单次堆使用率更值得追查。
• 查对象：数量、浅大小、保留大小、支配关系配合使用。
• 找原因：沿引用链确认谁在保留对象、什么时候应该清理。
• 取证风险：转储可能暂停、占磁盘并暴露敏感数据。
• 修复验证：同等负载下检查内存、错误、吞吐和延迟。