Java内存泄漏排查：jmap与MAT分析教程

本文深入剖析了Java内存泄漏的精准识别与高效排查全流程：从通过jstat观察老年代“只涨不跌”、FGC频次激增且无效、OOM反复发生、特定类实例持续增长等本质现象确认泄漏存在，到强调使用jmap -dump:live导出纯净堆快照以规避临时对象干扰，再到借助MAT中Path to GC Roots聚焦强引用链定位泄漏源头（如静态缓存、未清理ThreadLocal、Spring监听器残留），并指出Dominator Tree比Histogram更能直击要害——它揭示真正“拖垮内存”的支配者及其背后缺失的remove()、close()或shutdown()调用，帮你绕过表象噪音，快速锁定并修复代码中那些隐匿的生命周期管理漏洞。

怎么确认真有内存泄漏，而不是GC波动？

别急着 jmap，先看现象是否符合泄漏本质：老年代内存「只涨不跌」。比如 jstat -gcutil 1000 5 连续采样，发现 O（Old space 使用率）从 70% → 85% → 92% → 96% → 98%，且每次 FGC 后几乎没回落，这就不是正常业务高峰，是泄漏信号。

• Full GC 频次越来越高（比如从每小时 1 次变成每分钟 2 次），单次耗时超 1s，同时 FGCT 累计值快速上升
• 应用日志里反复出现 java.lang.OutOfMemoryError: Java heap space，重启后几小时内复现
• 用 jmap -histo:live 隔 5 分钟跑两次，对比发现某类实例数（如 com.example.UserCacheEntry）持续增长、不减

用 jmap 导出 dump 时，为什么加 live 很关键？

jmap -dump:format=b,file=heap.hprof 会触发一次全局 Stop-The-World，导出所有对象（包括已标记待回收但还没清理的）。而生产环境更推荐 jmap -dump:live,format=b,file=heap.hprof —— 它强制先做一次 Full GC，再 dump 剩下的「活对象」，数据更干净，避免把临时对象噪音带进分析。

• 不加 live：dump 文件大、MAT 分析慢、容易被短生命周期对象干扰判断
• 加 live：文件小 30%~50%，Leak Suspects 报告更准，但会短暂卡顿（STW 时间取决于老年代大小）
• 线上慎用：若服务敏感，优先依赖启动参数 -XX:+HeapDumpOnOutOfMemoryError 自动捕获，而非手动触发

MAT 中怎么看懂「Path to GC Roots」里的引用链？

打开 dump 后点 Leak Suspects Report，它标出的嫌疑对象只是起点；真正要动手改代码，得点进去看 Path to GC Roots —— 这里显示的是「谁在强持有这个对象，让它没法被回收」。

• 看到 static 字段（如 com.example.CacheManager.cache）→ 典型静态集合泄漏，检查是否漏清理或没设过期
• 看到 java.lang.Thread 持有 → 查线程栈，可能是线程池任务中缓存了大对象或未关闭 ThreadLocal
• 看到 org.springframework.context.support.AbstractApplicationContext → Spring Bean 生命周期异常，比如监听器注册后没注销
• 注意过滤：勾选 exclude all phantom/weak/soft references，只看强引用链，否则会看到大量无意义路径

为什么用 Dominator Tree 比 Histogram 更快定位根因？

Histogram 只告诉你「哪个类实例最多」，比如 byte[] 占内存第一——但这没用，因为几乎所有大对象底层都是 byte[]。Dominator Tree 才是关键：它按「支配关系」排序，排第一的，是那些「自己占内存多 + 它活着就拖着一堆其他对象也活不了」的对象。

• 找 Retained Heap 最大的几行，比如 com.example.OrderService 实例占 1.2GB → 直接去查这个类的静态字段或单例状态
• 右键 → Path to GC Roots → 看是不是被某个 static Map 或未 shutdown 的 ScheduledExecutorService 持有
• 如果 Dominator Tree 顶部全是第三方库类（如 io.netty.buffer.PooledByteBuf），别急着改自己代码，先查 Netty 是否漏调 release()

真正难的不是找到那个大对象，而是看懂它为什么不该活那么久——引用链里每个箭头，都对应一行可能漏掉的 remove()、close() 或 shutdown()。

理论要掌握，实操不能落！以上关于《Java内存泄漏排查：jmap与MAT分析教程》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！