Dominator Tree 能定位集合类泄漏，因其揭示对象支配关系：若集合的 dominator（如静态缓存、未注销监听器）未被回收，则整个 elementData/table 子树持续存活，导致 Retained Heap 异常偏高。
为什么 Dominator Tree 比普通对象引用链更能定位集合类泄漏
因为集合类（比如 ArrayList、HashMap）本身不占多少内存，但它的 elementData 或 table 字段可能持有一大片对象——这些对象是否“真正被释放”，取决于谁在支配它们。Dominator Tree 显示的是：如果某个对象被回收，它直接或间接支配的所有对象也会被回收。对集合来说，一旦它的持有者没被 GC，整个子树都活下来，Retained Heap 就会异常高。
常见错误现象：HashMap 实例的 Retained Heap 占比突然飙升，但看它的直接引用只有一处；点开 Dominator Tree 发现上层有个静态缓存类或监听器没注销。
- 别只盯着集合对象本身，重点看它的 dominator 是谁（右键 →
Go to Dominator） - 静态字段、单例、ThreadLocal、未注销的 Observer/Listener 是高频 dominator 来源
-
Retained Heap值大 ≠ 泄漏，要结合生命周期判断：这个集合本该在 Activity 销毁后清空，但它还活着 → 才是问题
怎么从 Retained Heap 排序快速筛出可疑集合实例
MAT 默认按 Shallow Heap 排序，这对集合类完全无效——ArrayList 的 Shallow Heap 只有几十字节。必须切到 Retained Heap 列，降序排列，再加过滤条件。
- 打开
Histogram视图 → 点击列头Retained Heap两次（第二次为降序） - 右键 →
List objects→with outgoing references，避免漏掉被其他对象引用但自身 retain 大的集合 - 在筛选框输入
java.util.ArrayList或java.util.HashMap，注意大小写和包名完整 - 重点关注
Retained Heap > 1MB且Objects count > 1000的条目（小项目阈值可调低）
Path to GC Roots 里哪些路径意味着真实泄漏
不是所有不可达路径都算泄漏。MAT 的 Path to GC Roots 会列出所有强引用链，但只有那些本不该长期存在的引用才危险。
- 出现
ThreadLocal→ 检查线程是否已结束，ThreadLocal是否remove()了 - 出现
static字段 → 查源码确认该静态变量是否设计为长期持有，还是忘了清理（比如public static List<Object> cache = new ArrayList<>();） - 出现
android.app.Activity或android.view.View作为 GC Root → 很可能 Activity 已 finish，但集合还被某处静态引用着 - 出现
java.lang.ref.Finalizer或java.lang.ref.ReferenceQueue→ 不代表泄漏，只是 finalize 尚未执行，需结合时间判断
用 OQL 快速验证集合内容是否合理
光看大小和引用链不够，得确认集合里存的到底是什么。MAT 的 OQL（Object Query Language）能直接查内容，比手动展开快得多。
- 打开
Query Browser→OQL Console - 查
ArrayList元素数量：SELECT COUNT(*) FROM java.util.ArrayList WHERE @length > 10000 - 查某集合里是否包含已销毁的 Activity：
SELECT * FROM java.util.ArrayList x WHERE x.elementData[0] instanceof android.app.Activity（注意索引越界风险） - 查
HashMap的 key 类型分布：SELECT DISTINCT classof(x.key) FROM java.util.HashMap x
容易被忽略的一点：elementData 数组常有大量 null 占位，size 字段才反映真实元素数。OQL 里不能直接读 size（它是 private），得用 x.size（MAT 会自动解析）或转成 ArrayList 子类再查。
