你如果线上遇到过 OOM，会发现两种人：

• 一种人：把 -Xmx 调大，先让服务活着
• 另一种人：拿到 heapdump，定位是哪条引用链不该存在

前者能止血，后者才能治本。

这篇给你一套“从 OOM 到根因”的可执行流程。

---

1. 先判断：你要的 dump 是“堆 OOM”还是“元空间 OOM”

常见 OOM 信息：

• 堆：OutOfMemoryError: Java heap space
• 元空间：OutOfMemoryError: Metaspace

注意：

• heapdump（.hprof）主要用于分析堆对象
• 元空间问题更常见要看“类数量、类加载器是否泄露”

---

2. 线上生成 heapdump（务必谨慎）

2.1 自动：OOM 时自动 dump

你可以在启动参数中加入：

• -XX:+HeapDumpOnOutOfMemoryError
• -XX:HeapDumpPath=/path/to/dumps

优点：

• 不需要你手动触发

风险：

• dump 文件可能非常大
• 可能对 IO/磁盘造成压力

2.2 手动：通过 jmap 生成

• jmap -dump:format=b,file=heap.hprof <pid>

建议：

• 大堆生产环境慎用，必要时先在低峰期或从副本实例做

---

3. 在分析之前，你要先做的“快照判断”

heapdump 是静态快照，它告诉你：

• 谁占内存最大
• 谁在引用谁

但它不能直接告诉你：

• “增长趋势”

所以最好配合：

• jcmd <pid> GC.class_histogram（当前对象大户）
• 业务监控（堆使用随时间变化）

---

4. MAT 打开 dump 后，先看这三个地方

4.1 Histogram：谁是“大户”

• 实例数最多的类
• 总占用最大的类

注意：

• 大户不一定是“泄露者”
• 泄露者往往是“持有引用的链路”

4.2 Dominator Tree：谁在“支配”内存

Dominator Tree 是定位泄露最关键的一页：

• “如果这个对象被回收，能释放多少内存？”

你要找：

• Retained Size 异常大的对象

4.3 GC Roots：从根到可疑对象的引用链

MAT 最终要给你一个结论：

• 这个对象为什么没被回收？

通常根因会落在：

• 静态集合缓存
• 线程栈引用
• ThreadLocal
• 监听器/回调未注销

---

5. 一个典型案例：静态 Map 缓存导致泄露

你在 Dominator Tree 里看到：

• java.util.HashMap retained size 巨大

顺着引用链你发现：

• 某个 static Map 持有所有对象

这类问题常见解法：

• 增加淘汰策略（LRU/TTL）
• 改成弱引用/软引用（要评估）
• 缩小缓存粒度

---

6. 另一个典型案例：ThreadLocal 没 remove

现象：

• 线程池线程长期存活
• ThreadLocalMap 持有大对象

排查：

• 在 GC Roots 里经常能看到从 Thread 走到 ThreadLocalMap

解法：

• try/finally 里 remove()
• 避免 ThreadLocal 持有大对象

---

7. 你真正该形成的“从 OOM 到根因”的闭环

• 先确认 OOM 类型（堆/元空间/线程/直接内存）
• 通过 class_histogram 快速抓大户
• 生成 heapdump
• MAT：Histogram -> Dominator Tree -> GC Roots 引用链
• 回到代码：找到“为什么引用没释放”，再改

---

8. 总结

• heapdump 是定位“为什么没回收”的证据
• MAT 的关键是 Dominator Tree 与 GC Roots
• 常见根因：静态缓存、ThreadLocal、监听器未注销、容器热部署类加载器泄露