Node.js 内存泄漏排查实战：从现象到定位的完整流程

# Node.js 内存泄漏排查实战：从现象到定位的完整流程 ## 一、问题背景 线上一个基于 Node.js 编写的数据采集服务，启动时内存占用约 300MB，运行 24 小时后内存涨到 1.5GB，随后被容器以 OOMKilled 方式杀掉重启。监控平台显示内存曲线呈阶梯式上涨，每次重启后恢复正常，说明服务存在内存泄漏。 ## 二、确认泄漏方向 先用 process.memoryUsage() 打印内存明细，重点关注 heapUsed、external、arrayBuffers 三个指标。如果 heapUsed 持续增长且手动触发 global.gc() 后无法回落，说明堆内存存在泄漏；如果 external 和 arrayBuffers 增长明显，则要优先排查 Buffer 和流的释放问题。本次现象是 heapUsed 持续增长，确定是堆内存泄漏。 ## 三、抓取堆快照定位 给服务加上 --inspect 参数启动，用 Chrome DevTools 的 Memory 面板连续抓取两个 Heap Snapshot，间隔半小时。对比两张快照中 Retained Size 增量最大的对象，重点看构造函数、引用链和分配栈。本次发现大量 Promise 对象堆积，引用链指向数据库查询模块。 ## 四、根因分析 查看代码后发现，业务逻辑里有一个循环批量处理任务，循环内部调用异步查询接口时没有 await，也没有收集返回的 Promise，导致查询结果长期不被释放，Promise 对象越积越多。改为 await 串行或 Promise.all 并发控制后，内存曲线恢复平稳。 ## 五、常见泄漏场景汇总 1. 全局缓存不清理：用 Map 做缓存却没有过期策略，数据量大会持续占内存。 2. 事件监听器泄漏：EventEmitter 或 addEventListener 绑定后忘记移除，重复订阅导致对象无法回收。 3. 定时器未清理：setInterval 回调引用了大对象，定时器不停止则对象永不释放。 4. 闭包误用：长生命周期函数持有大对象引用，比如把整个请求对象存进全局数组。 5. 流未销毁：读取文件或网络流之后没有调用 destroy，底层缓冲一直保留。 6. 日志记录大对象：把请求体、响应体整包打进日志，日志缓冲也会成为内存黑洞。 ## 六、避坑指南 1. 生产环境设置 --max-old-space-size，并用 PM2 的 max-memory-restart 做兜底，避免服务彻底卡死。 2. 引入 heapdump 模块，内存达到阈值时自动抓取堆快照，方便事后复盘。 3. 发布前做压测，观察内存曲线是否平稳，把问题挡在上线之前。 4. 代码评审时重点检查全局变量、缓存、定时器和事件监听的生命周期。 5. 监控面板加上内存使用率告警，阈值建议 70%，提前预警而不是等 OOM。 ## 七、总结 内存泄漏排查的核心思路是：确认泄漏方向、抓取对比快照、定位堆积对象、修复引用链。掌握 heap snapshot 分析工具，配合监控告警和压测流程，绝大多数 Node.js 内存问题都能在影响用户之前解决。