支配树是MAT中定位内存泄漏根因的核心视图，它按Retained Heap降序排列，顶部节点为真正控制内存生命周期的支配者，如全局单例、静态集合或未注销监听器；右键可疑对象查Path to GC Roots可精确定位强引用链，结合Leak Suspects报告与分组筛选能高效缩小分析范围。
支配树（Dominator Tree）是 MAT 中定位内存泄漏和高内存占用对象路径的核心视图之一。它不展示所有引用链，而是聚焦“谁真正控制着对象的生命周期”——即：如果某个对象被回收，其所有支配对象（dominator）也必须先被回收。因此，支配树顶部的节点，往往是内存占用的“根因”。
支配树怎么看：关键节点识别
打开 MAT 的 Dominator Tree 视图后，默认按“Retained Heap”降序排列。这个值表示：若该对象被回收，能释放多少内存（含其支配子树中所有对象）。重点关注前三到五项：
- 排在最上面的对象，通常是全局单例、静态集合（如
static Map、缓存容器）、未注销的监听器或线程局部变量（ThreadLocal） - 若看到大量相同类名（如
byte[]、char[]、HashMap$Node），不要直接点进去——先看它们的支配者是谁，往往上层一个业务对象就持有全部 - 注意“[Synthetic]”标记的节点，这是 MAT 自动生成的虚拟节点（如代表整个线程栈或 ClassLoader），可能隐藏真实泄漏源头
结合支配路径（Path to GC Roots）精确定位
在支配树中右键任一可疑对象 → Path to GC Roots → 勾选 exclude weak/soft/phantom references。这能过滤掉正常可回收的引用，只保留强引用链：
- 常见泄漏路径模式：
ThreadLocalMap → ThreadLocal → 业务对象 → byte[]；或StaticCache → HashMap → Key → Value → 大对象数组 - 若路径中出现
java.lang.ref.Finalizer或java.lang.ref.ReferenceQueue，说明对象已进入终结队列但尚未执行 finalize，可能阻塞回收（尤其在频繁创建/销毁资源时） - 路径过长？尝试点击中间某层对象，再查它的支配树——有时“真正的根”藏在第二层
避免误判：支配树的局限性
支配树反映的是“控制关系”，不是“业务逻辑关系”。以下情况容易误导判断：
- 多个独立模块共用一个全局容器（如 Spring 的
ApplicationContext），它的 Retained Heap 很大，但未必是泄漏——需确认其中是否堆积了本该被清理的临时对象 - 对象本身很小（如
String），但被大量其他对象引用，它在支配树中可能排名靠后，而实际占用内存的是它引用的底层char[]——此时应切换到 Immediate Dominators 查看谁直接支配该数组 - 使用了 Off-Heap 内存（如 DirectByteBuffer、Netty 的 PooledByteBuf），支配树无法体现这部分开销，需结合 JVM 参数（
-XX:MaxDirectMemorySize）和 Native Memory Tracking 分析
实用技巧：快速缩小范围
面对数 GB 的堆转储，别从头扫支配树：
- 先用 Leak Suspects 报告（首页自动运行）——它已基于支配树+启发式规则标出最可能的泄漏点
- 在支配树顶部右键 → Group By > Package 或 Group By > Class Loader，快速识别是哪个模块或类加载器导致内存聚集
- 对怀疑的类，右键 → List objects > with incoming references，查看哪些地方还在持有着它——比盲目翻引用链更高效
