支配树通过支配关系界定对象被回收时必然连带回收的对象集合，其Shallow Heap总和即Retained Heap；支配要求所有GC Root到该对象的路径必经此对象，且具传递性。
支配树（Dominator Tree）是 MAT 中理解 Retained Heap 的核心视角。它不直接“计算”数值，而是通过对象间的支配关系，精准界定：当某个对象被回收时，哪些对象会**必然随之被回收**——这部分对象的 Shallow Heap 总和，就是该对象的 Retained Heap。
支配关系决定 Retained Set 的边界
对象 X 支配对象 Y，意味着从任意 GC Root 到 Y 的所有可达路径，都必须经过 X。换句话说，Y 的存活完全依赖于 X 的存在。
一个对象 X 的 Retained Set 就是它所支配的所有对象集合（包括自己）。Retained Heap 就是这个集合里所有对象的 Shallow Heap 之和。
关键点在于：只要 Y 还能通过其他路径（不经过 X）被 GC Root 触达，Y 就不在 X 的 Retained Set 里，也不会计入 X 的 Retained Heap。
- 比如 A → B → C，同时 H → C。那么 C 不被 A 支配，A 的 Retained Heap 就不包含 C
- 再如 A → B，C → B，且 A 和 C 都是 GC Root 直接引用。B 被 A 和 C 共同引用，因此 B 不被 A 支配，也不在 A 的 Retained Set 中
- 支配具有传递性：若 A 支配 B，B 支配 C，则 A 也支配 C；但反之不成立
Retained Heap 不是简单递归引用求和
很多人误以为 Retained Heap = 自身 + 所有直接/间接引用对象的 Shallow Heap。这是错的——它只包含那些“除了你，没人引用它们”的对象。
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
MAT 在计算时，会真实模拟 GC 回收过程：假设 X 被移除，然后检查内存中还有哪些对象因失去全部引用而变得不可达。这些对象才是 X 的 Retained Set。
- Shallow Heap 是静态的：只看类定义、字段类型、数组长度等，可估算
- Retained Heap 是动态的：高度依赖当前堆快照中的实际引用图结构
- 同一个类的两个实例，Retained Heap 可能天差地别，取决于它们各自在引用图中的位置
支配树视图（Dominator Tree）为什么比直方图更有效
Histogram 按类分组统计，告诉你“UserBean 类共占多少 Retained Heap”，但无法区分哪个实例拖累了整体。
Dominator Tree 按实例展开，按 Retained Heap 降序排列，顶部节点就是内存占用的真正“根因”。它天然呈现了支配链：
- 点击某对象 → 查看其 Dominator Tree 子树 → 就等于看到它的完整 Retained Set
- 右键 → “Path to GC Roots”（排除弱/软引用）→ 可确认它为何没被回收，即泄漏路径
- 右键 → “Merge Shortest Paths to GC Roots” → 对多个可疑对象批量分析共同引用源头
实战中如何验证 Retained Heap 数值是否合理
不要只信面板数字。打开对象详情，切换到 “References” 标签页，重点看：
- Outgoing References：它引用了谁？这些对象是否也都列在它的 Dominator 子树里？
- Incoming References：谁在引用它？如果有多个非 GC Root 的强引用者，它的 Retained Heap 很可能被严重低估（因为不是唯一支配者）
- 对比 “Retained Heap” 和 “Shallow Heap” 差值：差值巨大，说明它持有大量独占资源（如缓存、大数组、未关闭流）；差值接近，说明它本身是内存大户，但没带“拖家带口”
