支配树是识别内存泄漏根因最有力的结构，通过逆向收缩支配路径聚焦高支配开销节点，结合MAT工具分析Retained Heap、过滤框架噪声、交叉验证引用链与业务逻辑，并依据Dominator Depth优先处理深度≤3且保留堆>100MB的节点。
支配树（Dominator Tree）是分析堆转储文件时识别内存泄漏根因最有力的结构之一，尤其适用于大型复杂系统——它不依赖人工猜断，而是基于对象可达性关系，用数学方式定义“谁真正控制着谁的生命周期”。要层层递进圈定首要泄漏源，关键不是画出整棵树，而是沿着支配路径逆向收缩、聚焦“高支配开销节点”。
从堆转储中提取支配树并识别支配根
使用Eclipse MAT（Memory Analyzer Tool）打开heap.hprof后，直接选择 “Histogram” → 右键任意类 → “Merge Shortest Paths to GC Roots” → 勾选 “with all references”，再切换到 “Dominator Tree” 视图。此时列表按“被支配对象总保留大小（Retained Heap）”倒序排列。首位不一定是泄漏源，但它是当前堆中“保留内存最多”的支配节点——也就是所有被它支配的对象加起来占用了最多堆空间。先盯住它。
过滤噪声，锁定可疑支配链
大型系统中，常见干扰项包括：java.lang.Class、java.util.concurrent.ThreadPoolExecutor、org.springframework.context.support.GenericApplicationContext 等框架级长期存活对象。它们本身合法，但可能成为泄漏的“中转站”。需做三步过滤：
- 排除 java.* 和 sun.* 包下的原生类（除非你明确在定制JVM）
- 检查该支配节点的“Immediate Dominators”（直接支配者）：若其上层是某个静态集合（如 com.example.cache.GlobalCache）、未注销的监听器（如 com.example.event.UserLoginListener），就极可能是泄漏入口
- 右键该节点 → “Path to GC Roots” → 勾选 “exclude weak/soft/phantom references”：只看强引用链，弱引用不会阻止GC，排除干扰
交叉验证支配路径与业务逻辑时间线
支配树给出的是静态快照关系，但泄漏是动态累积过程。需结合两个动作确认是否为“首要”泄漏源：
- 对比两次 jmap -histo 的差异：若某类实例数在1小时内增长5倍，且该类恰好位于高Retained Heap支配节点下方，可信度陡增
- 检查该支配路径中最早出现的**业务包名类**（如 com.yourcompany.order.OrderProcessor），它大概率就是泄漏源头代码所在位置；再顺藤摸瓜查其静态字段、单例缓存、注册回调等典型泄漏模式
用“支配深度”辅助判断泄漏严重性
MAT中可右键支配节点 → “Show in Overview” → 查看 “Dominator Depth”。深度越小（如 depth=2），说明它离GC Root越近，越可能是全局性泄漏点（例如一个静态Map）；深度越大（如 depth=8），更可能是局部模块内循环引用或临时堆积。优先处理 depth ≤ 3 且 Retained Heap > 100MB 的节点——这类往往是压垮系统的“第一块多米诺骨牌”。
