MAT查内存泄漏三步：先用Histogram找异常多或大的类；再用Dominator Tree锁定内存源头；最后通过Path to GC Roots定位强引用链，结合Leak Suspects Report和对比分析验证。
直接用 Eclipse Memory Analyzer（MAT）查内存泄漏，核心是三步：看谁占得多、看谁不该活、看谁拽着它不放。重点不在堆里有多少对象，而在于哪些对象本该被回收却一直被强引用链拴在 GC Roots 上。
看 Histogram 找出“异常多”或“异常大”的类
Histogram 是你打开堆转储后最先该点开的视图。它按类名统计所有实例数量和总占用内存（retained size）。重点关注：
- 实例数远高于业务预期的类（比如本该只存 10 个的缓存对象，实际有 50 万）
- retained size 排名靠前的类（尤其是非基础类，如自定义 DTO、Handler、Listener、Adapter 等）
- 明显带业务标识的类名（如 UserSession、OrderProcessor、ImageLoader）
右键某一行 → “List objects → with incoming references”，就能看到所有该类的实例；再选一个典型实例，为下一步路径分析做准备。
用 Dominator Tree 快速锁定“内存大户”的源头
Dominator Tree 按 retained size 降序列出能“支配”其他对象的对象——也就是删掉它，一大片内存才能被释放。这个视图帮你跳过中间层，直击关键持有者。
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
立即学习“Java免费学习笔记（深入）”；
- 顶部几个节点如果属于你的业务类或框架扩展类（如 Spring 的 AspectJExpressionPointcut、自定义的 CallbackRegistry），高度可疑
- 注意看 classloader 列：若某个类由 LaunchedURLClassLoader 或自定义 ClassLoader 加载，且其 retained size 巨大，常指向类加载器泄漏
- 展开节点后，留意字段名是否暗示长期持有（如 cache、listeners、handlers、staticMap）
追 Path to GC Roots 定位“不该存在的引用链”
选中可疑对象 → 右键 → “Path to GC Roots → exclude all phantom/weak/soft references”。这一步只保留强引用路径，结果就是 GC 不敢动它的真正原因。
- 常见泄漏路径包括：ThreadLocal（线程未结束，值没清理）、静态集合（如 static Map 缓存未 remove）、内部类持外部类引用（尤其 AsyncTask、Runnable 在 Activity 销毁后仍存活）、监听器未反注册（如 addListener 后没 remove）
- 路径中若出现 java.lang.Thread → threadLocals → 你的类，基本可断定 ThreadLocal 泄漏
- 路径终点若是 system class loader 或 static field，说明引用来自全局静态上下文，需检查初始化逻辑和生命周期管理
用 Leak Suspects Report 和 Compare Basket 辅助验证
首次打开 dump 时，MAT 会自动生成 Leak Suspects Report，汇总前几大嫌疑对象及引用链摘要，适合快速初筛。
- 若问题偶发，建议在疑似泄漏前后分别 dump（如内存使用率上升前/后），用 Compare Basket 对比两个 Histogram，聚焦“新增大量实例”的类
- 对比时勾选 “Use percentage” 和 “Sort by difference”，差异一目了然
- OQL 也可辅助验证，例如输入 SELECT * FROM java.util.ArrayList WHERE @retainedHeapSize > 1000000 直接找大集合
