HeapDump + MAT：从一次 OOM 到根因定位的完整链路
你如果线上遇到过 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.HashMapretained 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、监听器未注销、容器热部署类加载器泄露