Node.js 服务内存泄漏怎么排查？

详细解析#

服务端常见的泄漏#

浏览器中的通用场景见 常见的内存泄漏，服务端最常见的是这几类：

// bus 是全局的 EventEmitter。每个 SSE 连接都在上面加一个监听，
// 断开后如果不移除，监听函数和它闭包里的 res 都无法回收
app.get('/events', (req, res) => {
  res.setHeader('Content-Type', 'text/event-stream')
  const onUpdate = (data) => res.write(`data: ${JSON.stringify(data)}\n\n`)
  bus.on('update', onUpdate)
  req.on('close', () => bus.off('update', onUpdate)) // 连接关闭时移除
})

同一个事件的监听器超过 10 个时，Node.js 会打印 MaxListenersExceededWarning，这往往就是重复添加监听的信号，见 EventEmitter 的原理。

第一步：确认是不是泄漏#

const toMB = (n) => (n / 1024 / 1024).toFixed(1)
setInterval(() => {
  const { rss, heapUsed, external } = process.memoryUsage()
  console.log(`rss=${toMB(rss)}MB heapUsed=${toMB(heapUsed)}MB external=${toMB(external)}MB`)
}, 60_000).unref()

生产环境一般接入监控看趋势，比如 Prometheus 的 prom-client 默认指标里就有这些数据。判断依据是 GC 后的低点：heapUsed 的曲线呈锯齿状，每次 GC 后回落到差不多的水平是正常的；如果每次回落的低点都比上次高，停止压测后也降不回去，就很可能有泄漏。heapUsed 平稳、rss 却持续上涨时，要看 external 和 arrayBuffers，问题可能出在 Buffer 或原生模块。

第二步：对比堆快照#

1. 在测试环境用 node --inspect server.mjs 启动，Chrome 打开 chrome://inspect，点 Open dedicated DevTools for Node，进入 Memory 面板
2. 预热后拍第一张堆快照（Heap snapshot），拍摄前会先执行一次 GC
3. 用压测工具（如 autocannon）对可疑接口发几千个请求，拍第二张快照
4. 在第二张快照中切换到 Comparison 视图，按净增数量（# Delta）排序，找出数量随请求数一起增长的对象
5. 选中这类对象，在下方的 Retainers 面板看引用链，一路往上找到源头，比如某个模块里的 cache 变量、某个 EventEmitter 的监听器数组

不方便连接调试器时，可以在代码里调用 v8.writeHeapSnapshot() 生成 .heapsnapshot 文件；或者启动时加 --heapsnapshot-signal=SIGUSR2，之后执行 kill -USR2 <pid> 写出快照；加 --heapsnapshot-near-heap-limit=2 则会在堆快要用满时自动写出快照，保留崩溃前的现场。快照文件下载到本地，在 DevTools 的 Memory 面板加载分析。

生成快照是同步操作，会阻塞事件循环，堆越大耗时越长；还需要大约堆大小两倍的内存，可能直接触发 OOM。线上抓快照前，先把这个实例从负载均衡中摘掉。

--max-old-space-size#

它设置 V8 老生代内存的上限，单位是 MB。堆用满后进程会以 JavaScript heap out of memory 错误崩溃。调大它只能推迟崩溃，解决不了泄漏。在容器里还要给堆外内存留出空间：设置得比容器的内存限制还大，进程会先被系统的 OOM Killer 杀掉，而不是由 V8 报错退出，排查时连错误信息都没有。

面试官可能追问#

易错点#

• 调大 --max-old-space-size 只是推迟崩溃，不能解决泄漏
• 只看 rss 判断 JS 对象泄漏不准确，要看 heapUsed 在 GC 后的低点
• 抓堆快照会阻塞进程、需要大量额外内存，线上要先摘掉流量
• --inspect 默认只监听 127.0.0.1，不要绑定 0.0.0.0 暴露到公网：能连上调试端口就能在进程里执行任意代码