定位内存泄漏关键在于找出“本该释放却长期持有对象”的源头，需聚焦Retained Heap、用Dominator Tree分析支配关系、结合Path to GC Roots验证静态集合、ThreadLocal等典型泄漏模式。
定位海量变量（尤其是 String、Map、List 等）长期持有对象的问题，关键不在“看谁占得多”，而在于“谁本该释放却一直挂着”。MAT 不是统计工具，是侦探工具——要顺着引用链，找到那个“不该活却牢牢 hold 住一堆对象”的源头。
聚焦 Retained Heap，避开 Shallow Heap 干扰
Shallow Heap（对象自身大小）对排查泄漏意义有限。比如一个空 ArrayList 只占几十字节，但若它持有一百万个 String，其 Retained Heap 可达几百 MB。MAT 的真正价值在 Retained Heap 列——代表“删掉它，能释放多少内存”。
- 打开 Histogram 视图，按 Retained Heap 降序排列
- 筛选 java.lang.String、java.util.HashMap、com.yourpackage.* 等高嫌疑类
- 重点关注“单个实例 Retained Heap 异常高”（如 >100MB），而非“总实例数多”
用 Dominator Tree 锁定支配者，再查 Path to GC Roots
Dominator Tree 展示的是“谁控制着谁的生死”。一个高 Retained Heap 的 String 实例，往往被某个容器对象（如 static Map、ThreadLocalMap、缓存单例）直接或间接支配。
- 在 Dominator Tree 中定位高 Retained Heap 的可疑对象（如 com.example.cache.DataCache）
- 右键 → “Path to GC Roots” → 勾选 exclude all weak/soft/phantom references
- 观察路径终点：若停在 java.lang.ThreadLocal$ThreadLocalMap 或 static final HashMap，基本确认泄漏点
结合 Leak Suspects 报告 + 手动验证，防误判
Leak Suspects 报告会提示“某 ArrayList 占据堆的 82%”，但它不区分这是合理缓存还是真实泄漏。必须人工交叉验证：
- 点击报告中的 Details，查看该 ArrayList 的内容（右键 → List Objects → with incoming references）
- 检查其中 String 内容是否与业务生命周期匹配（例如：订单已关闭 7 天，但缓存里仍有对应字符串）
- 对比多个时间点 dump：若某 Map 的 size 持续增长且无清理逻辑，就是强证据
识别典型持有模式，直击常见根因
海量变量被持有，往往不是代码写错了 new，而是“引用挂得太久”。以下模式出现即需重点审查：
- 静态集合类：static Map/ConcurrentHashMap/List，只 put 不 remove，尤其用业务 ID 作 key 却无过期机制
- ThreadLocal 泄漏：线程池复用下，未调用 remove()，导致 ThreadLocalMap 持有大量 String 或 DTO 对象
- 监听器/回调注册未注销：GUI 组件、事件总线、Spring ApplicationListener 注册后未解绑
- 未关闭的资源包装类：如 StringBuilder、StringBuffer 在循环中反复 append 但未 reset，底层 char[] 被持续持有
