堆内内存快照对比是识别缓慢增长型内存泄漏最可靠的方法，需在负载平稳时分阶段拍Baseline、操作后和延时快照，用MAT比对Delta与Retained Heap Delta，并通过引用链分析确认是否因static引用、ThreadLocal或未注销监听器等导致本该回收的对象持续存活。
堆内内存快照对比是识别缓慢增长型内存泄漏最可靠的方法之一。这类泄漏往往不触发明显OOM或频繁Full GC，但会随时间推移持续占用更多堆空间，最终导致服务不稳定。关键不在于单次快照里谁占得多，而在于多次快照之间哪些对象在“悄悄变多”。
选对时机拍快照：避开噪音，聚焦可疑窗口
不要等OOM才行动。应在系统负载平稳、业务逻辑可复现的前提下，分阶段拍摄：
- 初始快照（Baseline）：应用启动完成、空闲5分钟后拍摄，作为参照基准
- 操作后快照：执行一次典型业务流程（如用户登录→下单→退出），等待GC稳定（建议手动触发
jcmd <pid> VM.runFinalization并等10秒）再拍 - 延时快照：间隔10–30分钟再拍一次，观察是否出现“缓慢但持续”的对象增长
用MAT做差异对比：盯住Delta和Retained Heap双指标
MAT的Compare Basket功能能清晰呈现两次快照间的变化。重点看两列：
-
# Delta：正数代表新增实例数。持续为正且数值递增的类（如
com.example.OrderCacheEntry、java.util.concurrent.ConcurrentHashMap$Node）需优先排查 - Retained Heap Delta：该类所有新增实例合计能释放的独占内存。若某类Delta小但Retained Heap Delta很大（例如新增10个对象却占了80MB），说明每个实例都拖着大量子对象，极可能是泄漏源头
顺藤摸瓜查引用链：从“谁多了”到“为什么活下来”
找到高Delta类后，不能只看数量——要确认它们是否本该被回收：
- 右键类名 → “List objects” → “with outgoing references”，查看这些新增实例具体持有哪些对象
- 任选一个实例 → “Merge shortest paths to GC roots”，观察其存活路径
- 重点关注以下不合理路径：
• 被static final Map或static List直接持有
• 被ThreadLocal中的Map.Entry引用（尤其在线程池中长期复用线程时）
• 被未注销的监听器、回调、定时器闭包间接持有
排除缓存与正常增长：验证是否真泄漏
不是所有增长都是泄漏。需结合业务逻辑交叉验证：
- 检查该类是否属于有明确生命周期的对象（如请求上下文、临时DTO），若它在请求结束后仍被强引用，就是泄漏
- 对比缓存类的size()与实际entry数量，若size()稳定但实例数持续上涨，说明缓存未淘汰旧项或存在重复put
- 用
jstat -gc <pid> 5s同步观察老年代使用率趋势，若与快照中某类增长曲线高度吻合，佐证关联性
