MAT (Memory Analyzer)：利用支配树（Dominator Tree）寻找占用内存最多的变量路径-java教程-PHP中文网

支配树是mat中定位内存泄漏根因的核心视图，它按retained heap降序排列，顶部节点为真正控制内存生命周期的支配者，如全局单例、静态集合或未注销监听器；右键可疑对象查path to gc roots可精确定位强引用链，结合leak suspects报告与分组筛选能高效缩小分析范围。

mat (memory analyzer)：利用支配树（dominator tree）寻找占用内存最多的变量路径

支配树（Dominator Tree）是 MAT 中定位内存泄漏和高内存占用对象路径的核心视图之一。它不展示所有引用链，而是聚焦“谁真正控制着对象的生命周期”——即：如果某个对象被回收，其所有支配对象（dominator）也必须先被回收。因此，支配树顶部的节点，往往是内存占用的“根因”。

打开 MAT 的 Dominator Tree 视图后，默认按“Retained Heap”降序排列。这个值表示：若该对象被回收，能释放多少内存（含其支配子树中所有对象）。重点关注前三到五项：

排在最上面的对象，通常是全局单例、静态集合（如 static Map、缓存容器）、未注销的监听器或线程局部变量（ThreadLocal）
若看到大量相同类名（如 byte[]、char[]、HashMap$Node），不要直接点进去——先看它们的支配者是谁，往往上层一个业务对象就持有全部
注意“[Synthetic]”标记的节点，这是 MAT 自动生成的虚拟节点（如代表整个线程栈或 ClassLoader），可能隐藏真实泄漏源头

在支配树中右键任一可疑对象 → 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，查看哪些地方还在持有着它——比盲目翻引用链更高效