mat分析百万级内存泄漏关键在“找得准”：先用jstat确认old gen持续增长，再通过histogram按包/类加载器筛选异常高数量对象，接着查incoming references锁定持有者，最后用path to gc roots验证其可达性。
用 MAT 分析百万级对象内存泄漏，核心不是“找得快”，而是“找得准”——关键在缩小范围、识别可疑对象、验证引用链。盲目点开 dominator tree 或 histogram 容易陷入噪声。
一、先抓快照，避开干扰
生产环境不能随便 dump 全堆——耗时长、影响服务、文件太大（常超 4GB）。建议：
- 用 jmap -dump:format=b,file=heap.hprof
前，先用 jstat -gc 确认是否真有持续增长的 old gen / metaspace； - 若应用使用 G1 GC，优先加参数 -XX:+HeapDumpBeforeFullGC，让 Full GC 触发时自动 dump，更贴近泄漏发生时刻；
- 避免在高峰期 dump；可结合 JVM 启动参数 -XX:+UseG1GC -XX:MaxGCPauseMillis=200 降低 dump 时卡顿风险。
二、MAT 中三步快速定位百万级泄漏源
打开 heap.hprof 后，不急着看 dominator tree：
- 第一步：直奔 Histogram → Group by Package 或 Group by Class Loader，按对象数量降序排，重点关注你 own 的包（如 com.example.cache）下数量异常高（比如 >50 万）的类；
- 第二步：选中可疑类 → 右键 “List objects → with incoming references”，看这些对象被谁持有着——如果发现大量被 ConcurrentHashMap、static final Map 或某个 Singleton 实例强引用，基本就是泄漏点；
- 第三步：对那个持有者右键 “Path to GC Roots → exclude weak/soft/phantom references”，确认它本身是否可达（即没被正确释放），常见模式是：监听器注册后未反注册、ThreadLocal 没 remove、缓存未设置过期策略或 size 限制。
三、应对“对象太多，MAT 卡死”的实操技巧
MAT 默认加载全部对象，百万级容易 OOM 或假死。解决方法：
- 启动 MAT 前修改 MemoryAnalyzer.ini：把 -Xmx 调到至少 4G（如 -Xmx4g），并加 -XX:+UseG1GC；
- 导入时勾选 “Keep unreachable objects” = false（默认 true），跳过已不可达对象，提速 3–5 倍；
- 用 “Parse Heap Dump in Background” 模式导入，边加载边分析，Histogram 几秒就能出结果；
- 若仍卡顿，可用 jhat 或 jcmd
VM.native_memory summary 辅助判断是否 native 内存泄漏（MAT 查不到）。
四、验证与收尾：别只看 MAT，要闭环
找到疑似泄漏点后，必须验证，否则容易误判：
- 写单元测试模拟相同操作路径（如反复调用某接口 1000 次），用 VisualVM + Visual GC 观察 old gen 是否阶梯式上涨；
- 修复后重新部署，用 arthas watch 监控关键集合 size 变化： watch com.example.service.CacheService cacheMap 'size()' -n 5；
- 上线后开启 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps，观察 Full GC 频率是否下降、old gen 使用量是否平稳。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
