必须加live参数：jmap -dump:live,format=b,file=heap.hprof ，否则默认导出所有对象（含临时对象），干扰分析；生产环境务必使用live过滤存活对象，避免误判内存泄漏。
怎么用 jmap 生成有效 heap dump 文件
直接用 jmap -dump:format=b,file=heap.hprof <pid></pid> 很容易拿到“假现场”——它默认 dump 所有对象，包括大量刚分配还没来得及 GC 的临时对象，干扰分析。生产环境必须加 live 参数，只保留存活对象：jmap -dump:live,format=b,file=heap.hprof <pid></pid>。
常见错误现象：
- 没加
live，MAT 中看到大量短生命周期对象（如String、char[]），误判为泄露 - 目标进程无权限写入指定路径，命令静默失败（检查
ls -l目录权限） - 磁盘空间不足，dump 中断但不报错，生成的
.hprof文件大小异常小（比如只有几 MB）
建议步骤：
- 先用
jps -l确认 PID，避免杀错进程 - 执行前用
df -h检查目标路径所在分区剩余空间，至少预留比堆内存大 20% 的空间 - 如果进程响应慢，加
-F强制模式：jmap -F -dump:live,format=b,file=heap.hprof <pid></pid>（但可能造成短暂 STW）
MAT 启动时为什么总卡住或崩溃
MAT 不是“开箱即用”，它的 MemoryAnalyzer.ini 里默认 -Xmx 值太小（通常是 1g 或 2g），而实际 dump 文件往往 2–8GB。启动时卡在“Loading…”，或者直接闪退，基本就是这个原因。
关键操作：
- 打开
MemoryAnalyzer.ini，找到-Xmx行，改成至少为 dump 文件大小的 1.5 倍。例如分析 4GB 的heap.hprof，设为-Xmx6g - 确保运行 MAT 的 JDK 版本 ≥ 11（MAT 1.14+ 已不兼容 JDK 8）
- 不要用 Eclipse 插件版做主分析工具——插件受限于 Eclipse 自身 JVM 配置，极易 OOM
性能影响：Xmx 设太高不会提升分析速度，反而拖慢启动；设太低则解析中途崩溃，且无法恢复，必须重开。
在 MAT 里该盯哪几个视图才不跑偏
新手常陷入“全量展开引用链”的陷阱，浪费数小时却找不到根因。真正高效的路径很窄：先看 Leak Suspects Report → 再核对 Histogram → 最后用 Dominator Tree 定位支配者。
各视图作用差异：
-
Leak Suspects Report：MAT 自动生成的嫌疑摘要，通常第一项就是最大泄露点（比如 “One instance of ‘org.apache.commons.pool2.impl.GenericObjectPool’ is holding 2.1 GB”）。这是最省力的入口 -
Histogram：按类统计实例数和 retained heap。重点关注 retained heap 排名靠前、且实例数明显异常增长的类（比如某CacheEntry类有 50 万实例，而正常应 ≤ 1000） -
Dominator Tree：显示谁真正“占着内存不放”。右键某个可疑类 →List objects → with outgoing references，一层层往下钻，直到看到业务代码里的静态字段、未注销监听器或 ThreadLocal
容易踩的坑：
- 只看 shallow heap（对象自身大小），忽略 retained heap（它支配的所有对象总大小）——泄露根源往往 shallow 很小，retained 极大
- 在
Histogram里双击某个类后，直接看 “Merge Shortest Paths to GC Roots”，结果被一堆系统线程/ClassLoader 引用绕晕——应先勾选 “exclude weak/soft/phantom references”，再过滤 “java.lang.Thread” 和 “org.springframework” 等无关路径
怎么确认是代码问题而不是框架或中间件锅
MAT 报告里出现 Spring、Netty、Druid 等框架类名，不代表它们有 bug。绝大多数情况是业务代码误用导致的引用滞留。
判断依据：
- 看 GC Roots 路径终点：如果最终停在你的某个
static Map<string object></string>、未remove()的ThreadLocal、或注册了但没unregister()的监听器，就是你的代码问题 - 对比多个 dump：同一应用在不同时间点 dump，若某类实例数持续增长（比如每小时 +5000），而业务流量稳定，基本可锁定泄露点
- 检查 finalize 队列：Histogram 中搜
java.lang.ref.Finalizer，如果数量 > 1000，说明大量对象在等待 finalize，往往是资源未 close 导致（如FileInputStream、Connection）
复杂点在于：有些泄露是间接的。比如一个 Runnable 被线程池长期持有，它又持有一个大缓存对象 —— 这时候 Dominator Tree 里看不到你写的类名，要顺着 java.util.concurrent.ThreadPoolExecutor$Worker 往下翻两层才能看到你的 RefreshCmsOrganizationStruts。
