保留大小是定位内存泄漏最核心指标，指对象被回收时能释放的独占内存总量；它比浅层大小更精准、比深层大小更真实，MAT中按Retained Heap排序可快速定位泄漏源头。

保留大小（Retained Size）是定位内存问题最核心的指标之一。它代表：如果当前对象被回收，连带能一并释放的所有对象总内存。换句话说，这个数字越大的对象，越可能是“内存持有者”——不是它自己占得多，而是它拖着一堆其他对象无法被 GC。

为什么优先看保留大小，而不是浅层或深层大小

浅层大小（Shallow Size）只算对象头和字段本身，对排查泄漏几乎没用；深层大小（Deep Size）把所有引用对象都加进来，容易高估（比如一个全局缓存 Map 的深层大小会包含全部 value，但其中很多可能还能被其他路径访问）。而保留大小聚焦于“真正由它独占”的内存，更贴近实际可释放量。

• 一个单例对象的保留大小小，说明它没拖住多少东西
• 一个 ArrayList 实例的保留大小异常大，往往意味着它存了大量未清理的数据，或者被某个长生命周期对象强引用着
• 线程局部变量（ThreadLocal）对应的 Map.Entry，常表现出高保留大小——这是典型的内存泄漏信号

在 MAT 中快速筛选高保留大小对象

打开堆快照后，直接进入 “Histogram”（直方图）视图，点击表头的 “Retained Heap” 列进行降序排序。顶部几行就是保留内存最多的类。

• 重点关注 java.util.ArrayList、java.util.HashMap、byte[]、char[] 和你项目中的核心业务类（如 OrderService、CacheManager）
• 右键某一行 → “List objects” → “with outgoing references”，查看这些实例具体持有哪些对象
• 再右键任一实例 → “Merge shortest paths to GC roots”，立刻看到它为什么活下来——是被静态字段引用？还是被线程栈持有？

结合引用链判断是否真有问题

高保留大小不等于 bug，关键看引用路径是否合理。常见可疑路径包括：

• static 字段直接引用集合或大数组（例如：private static Map<String, byte[]> cache = new HashMap<>();）
• ThreadLocal 变量未 remove()，尤其在线程池场景下，导致旧请求的上下文一直残留
• 监听器/回调注册后未反注册，比如 Swing 或 Android 中的 Activity 引用被后台线程长期持有
• 缓存未设上限或未启用 LRU，ArrayList 或 ConcurrentHashMap 持续增长且无淘汰机制

对比多个快照确认增长趋势

单个快照只能看到“此刻谁占得多”，要确认泄漏，必须比对两个以上时间点的快照：

• 用 MAT 打开第一个快照 → 导出 “Top Consumers” 报告（含 Retained Heap 排序）
• 过几分钟（或触发一次业务操作后）再 dump 一个 → 同样导出报告
• 用 Excel 或文本工具对比两份报告中同一类的保留大小变化，增长 >20% 且持续上升，基本可锁定为泄漏源头