内存泄漏可通过增量比对两次快照识别：baseline在启动轻载gc后抓取，target在相同业务路径运行数分钟后获取；用mat/chrome devtools/dotmemory做delta排序，聚焦新增实例与retained heap增幅大的类；再抓第三次快照验证增长趋势；最后通过引用链分析定位静态字段、未注销监听器或隐式强引用等泄漏源头。
核心思路很直接：内存泄漏的本质是对象该回收却没被回收，而增量比对能过滤掉“合法长生命周期对象”，只聚焦两次快照之间**净新增且未被 GC 清理的对象**。只要泄漏持续发生，这些增量就会稳定增长，形成可识别的模式。
选对时间点，让增量有意义
第一次快照（Baseline）应在系统刚启动、业务轻载、GC 刚完成时抓取；第二次快照（Target）需在相同业务路径下运行数分钟至十几分钟后获取——比如车载 IVI 中连续操作导航+音乐+语音 5 分钟，或 Node.js 服务接收 1000 次请求后。两次间隔不宜过短（否则噪声大），也不宜过长（可能掩盖早期泄漏节奏）。关键不是固定时长，而是确保业务逻辑已稳定复现、内存趋势已开始爬升。
用工具做 Delta 排序，盯紧“涨得最狠”的类
不同语言生态有对应工具：
- Java 用 MAT：加载两个 heapdump → “Compare with Another Heap Dump” → 按 “Objects added” 或 “Retained Heap Delta” 排序 → 重点关注新增实例数多、且 retained heap 增幅大的类（如 MyActivity、CacheManager、EventHandler）
- Node.js 用 Chrome DevTools：Memory 标签 → Load 两个 .heapsnapshot → 选新快照 → Comparison → 按 Delta 列排序 → 关注 Object、Array、Closure 下子类型（如 MyService 实例或闭包中缓存的 Buffer）
- C# 用 dotMemory 或 PerfView：执行 compare 命令 → 查看 “Heap Stacks” 视图中 inc% 最高的调用栈 → 往下钻，定位到具体静态字段（如 MyModule._cache）或事件订阅点（如 SerialPort.DataReceived += handler）
验证是否真泄漏：拉第三次快照交叉确认
仅靠两次对比不能 100% 确定是泄漏，也可能是瞬时缓存高峰。必须再抓第三次快照（比如再跑一轮相同操作），与第二次做同样比对。若某类对象的实例数呈现“+1200 → +2450 → +3780”这种线性或加速增长趋势，且 retained heap 同步扩大，基本可锁定为泄漏点。此时配合 OQL（Java）、console.memoryInfo（Node.js）或堆栈符号（C#）进一步确认对象来源。
顺藤摸瓜，查引用链而非只看对象本身
找到增长类后，别停在类名上。在 MAT 中右键该类 → “Merge Shortest Paths to GC Roots”（排除弱/软引用）；在 Chrome DevTools 中点击对象 → 查看 “Retainers” 面板；在 dotMemory 中展开 “Paths to Root”。重点找三类持有者：
- 静态字段（static final Map / List / EventHandler）
- 未注销的监听器或回调（Listener 注册后没 remove，Timer 没 stop）
- 隐式强引用（非静态内部类、Handler、Lambda 闭包捕获了 Activity/this/大数组）
只要引用链终点落在不该长期存活的上下文里（比如已 finish 的 Activity、已 dispose 的 Form、已 close 的 Socket），就是泄漏铁证。
