使用Chrome DevTools排查NODEJS内存泄漏：定位导致应用崩溃的变量

1. 分阶段采集对比快照 #

• 放弃只采集最终快照的做法，按时间节点分别抓取3份内存快照：
  • 第5秒：内存首次上涨前的基线快照，作为对照基准
  • 第7秒：第6秒内存上涨完成后的快照
  • 第13秒：第12秒内存上涨完成后的快照
• 打开Chrome DevTools Memory面板，切换到Comparison对比视图，将后两份快照分别与基线快照对比，筛选出两次上涨阶段新增且未被销毁的对象，按内存占用降序排序，优先排查大对象的引用持有链路。

2. 开启堆分配采样追踪调用栈 #

• 启动Node应用时添加--inspect参数启用调试模式，打开Chrome DevTools Memory面板，选择Allocation sampling采样模式，点击开始录制后完整复现内存上涨流程
• 采样结果会直接关联对应代码的调用栈，可直接定位到第6、12、14秒三个时间点的新增内存分配分别对应哪段业务代码，大幅缩小排查范围。

3. 针对阶梯式上涨特征定向排查 #

你遇到的这种阶梯式内存上涨，90%以上属于三类问题，可优先排查：

• 全局对象（如global、框架挂载的全局上下文）是否存在动态新增属性、但无过期清理逻辑的场景
• 是否存在反复给EventEmitter绑定on事件监听器、但从未调用removeListener解绑的逻辑
• setInterval等常驻定时器的回调是否持有外部大对象，定时器未被销毁导致关联对象一直无法被GC回收
• 数据库查询、HTTP请求的回调是否通过闭包持有了外部超大上下文对象，回调未释放导致上下文一直存活。

4. 快照离线分析 #

如果DevTools在线分析检索效率低，可将导出的.heapsnapshot快照文件用开源heap分析工具做离线分析，支持按对象类型筛选、引用链一键追溯，比原生DevTools的检索效率更高。

内容的提问来源于stack exchange，提问作者JAN