27.2 内存泄漏定位与常见诱因

在 Node.js 中，内存泄漏是指进程占用的内存持续增长，即便在垃圾回收（GC）正常工作的情况下仍然无法释放已不再使用的内存。长期运行的服务器发生内存泄漏会导致内存耗尽、进程假死或被 OOM Killer 强制终止，严重影响服务可用性。本节将梳理最常见的泄漏诱因，并给出可操作的定位方案。

一、理解内存泄漏的信号

在平时开发中，并不是所有内存上升都代表泄漏。正常的服务在接收请求时内存会自然上涨，然后随着 GC 回收掉临时对象而回落。真正需要警惕的是 持续、单调上升且 GC 后不回落 的内存曲线。典型表现包括：

进程启动后内存不断攀升，最终逼近容器或系统上限。
process.memoryUsage().heapUsed 呈现单调增长趋势，没有周期性的下降。
GC 频率越来越高，但每次回收释放的空间越来越少。
服务响应逐渐变慢，甚至频繁触发 full GC 导致长时间停顿。

一旦观察到这些现象，就有必要通过工具对内存进行采样分析。

二、常见的内存泄漏诱因

1. 全局变量无节制膨胀

JavaScript 中，全局变量会作为根引用一直存活，如果不断向全局对象或模块作用域中的变量追加数据，内存将持续增长。

// 模块级变量（类似全局）
let cache = {};

app.get('/data', (req, res) => {
  // 模拟将数据无限制存入内存
  cache[req.query.id] = generateLargeObject();
  res.json({ ok: true });
});

上述 cache 永远不会被清理，随着请求量的增加，进程内存将线性上升。类似的情况还包括在定时器中持续向数组 push 数据而没有清理策略。

解决方案：使用具备淘汰策略的缓存（如 lru-cache）替代裸对象，或者为全局容器设置容量上限并配合定时清理。

2. 闭包捕获了意料之外的大对象

闭包会持有其外部函数作用域中的变量引用，如果闭包长时间未被释放，它所引用的整个作用域链上的对象都无法被回收。一个经典的例子是在处理请求时意外保留了整个请求上下文。

function createHandler(largeData) {
  return function (req, res) {
    // 闭包捕获了 largeData，即使这个函数只使用了其中一小部分
    console.log(largeData.summary);
  };
}

如果 largeData 包含大量数据（比如整个文件内容或数据库查询结果），而这个闭包被持续调用或保存在某个全局结构中，这些数据将一直占据内存。

解决方案：尽量只传递实际需要的字段，避免在闭包中直接引用整个大对象。处理请求时，避免将 req 和 res 对象存储在闭包或全局集合中（例如在 WebSocket 连接对象上挂载 req）。

3. 未正确移除事件监听器

Node.js 的核心模块广泛基于 EventEmitter。每增加一个监听器，EventEmitter 内部就会维护一个对该回调函数的引用，从而间接引用了回调所关联的上下文。如果事件源本身是长期存在的（如全局的 process 对象）而监听器没有被移除，那么即使业务逻辑中已经不再需要，被引用的对象仍然无法被 GC。

const EventEmitter = require('events');
const emitter = new EventEmitter();

function setup() {
  const largeData = Buffer.alloc(10 * 1024 * 1024);
  emitter.on('data', () => {
    console.log(largeData.length);
  });
}
setup();
// largeData 会一直存活，因为 emitter 持有了监听器回调的引用

在网络编程中，还常见为每个 socket 注册监听但断开时忘记 removeListener，导致 socket 及关联的缓冲区得不到释放。

解决方案：每个 on 都应该有一个对应的 off 或 removeListener。可以利用 once 代替 on 处理一次性事件。对于生命周期有限的对象，可以在其清理逻辑中手动移除全部监听器，甚至使用 emitter.removeAllListeners()。

4. 定时器未清除

setInterval 和 setTimeout 都会在内部维护对回调函数的引用，直到定时器被清除。如果定时器指向的回调持有大对象，而这些定时器又没有在适当的时候清理，就会导致内存泄漏。

let intervalId = setInterval(() => {
  // 处理一些长期任务
}, 1000);
// 如果忘记 clearInterval(intervalId)，该定时器将持续运行并占用内存

另一个隐晦的例子是递归 setTimeout，如果在某些条件下没有终止递归，也会形成持续的内存占用。

解决方案：在使用定时器时，要规划好清除时机。应用生命周期结束时，也应该集中清理所有定时器。可以使用 unref() 让定时器不再阻止进程退出（但仍需注意泄漏）。

5. 流（Stream）未正确消费或销毁

当使用 fs.createReadStream 或网络流时，如果流没有被完全消费（例如读取了一部分后就不再做任何操作），底层文件描述符或 socket 可能处于悬挂状态，其缓冲区中的数据仍然驻留在内存中。未调用 destroy() 会让流相关的内存持续占用。

const fs = require('fs');

app.get('/file', (req, res) => {
  const stream = fs.createReadStream('/path/to/large/file');
  // 假设发生错误或不完整的读取，流没有被销毁
  // 潜在的内存泄漏
});

解决方案：始终监听流的 error 和 end 事件，并在出现异常或不需要继续读取时调用 stream.destroy()。使用 pipeline 或 `stream.pipe` 时也要注意错误传递，确保所有分支都能清理。

6. Buffer 对象的不当囤积

Buffer 分配在 V8 的堆外内存中，直接由 C++ 管理，因此其大小不会被 process.memoryUsage().heapUsed 完全反映。如果大量 Buffer 被创建后没有得到及时回收，进程的 RSS（驻留集大小）会持续增长，但堆内存指标可能变化不明显。这种现象在处理大文件上传或网络包解析时尤为常见。

let chunks = [];
socket.on('data', (chunk) => {
  chunks.push(chunk); // 不断增加 Buffer 数组，没有限制或清理
});

解决方案：对数据流做限流，比如限制累积大小、及时将 Buffer 写入磁盘或流式处理，不要无限制地在内存中堆积。使用 Buffer.concat 前要评估总大小。

7. 模块缓存导致的持续引用

Node.js 的模块加载机制（CommonJS）会永久缓存第一次 require 的结果。如果模块导出的是一个动态增长的大对象，这个对象将永远不被回收，即使没有任何其他代码引用它。

// bigCollection.js
module.exports = [];

// 其他模块每次请求时 push 数据
const arr = require('./bigCollection');
arr.push(largeData);

解决方案：避免模块导出可变的大型容器作为全局单例。如果需要缓存，请使用可控制生命周期的专门方案，并考虑清理策略。

8. 连接池与客户端未关闭

数据库连接、Redis 客户端、HTTP Agent 等通常会维护连接池。如果程序异常退出、未调用 close，连接池中的 socket 和关联缓冲区可能不会释放，导致内存和文件描述符泄漏。

const mysql = require('mysql2');
const pool = mysql.createPool({ ... });
// 忘记在进程退出时调用 pool.end()

解决方案：在应用停止时（如监听 process.on('SIGTERM')）优雅地关闭所有连接池和客户端。使用连接池时注意归还连接，及时处理错误并销毁无效连接。

9. 无限递归或循环中创建大量临时对象

虽然不是“泄漏”，但快速的临时对象分配同样会造成内存压力，甚至导致 GC 跟不上分配速度而引发 OOM。

function recursive(count) {
  const temp = { data: Buffer.alloc(1024) };
  if (count > 0) recursive(count - 1);
}

如果递归深度过大，所有栈帧引用的临时对象都无法被回收，直到递归结束。这可能导致 RSS 瞬间飙升，即使最终会被回收，也可能击穿内存上限。

解决方案：注意递归深度、避免在循环内大量分配大对象。对大数组操作时，尽可能使用流式或分批处理。

三、定位内存泄漏的工具与方法

1. 使用 Chrome DevTools 分析 heap snapshot

Node.js 提供了 --inspect 标志来启动调试器，Chrome DevTools 可以直接连接到该进程并进行内存快照对比。

操作步骤：

启动应用：node --inspect app.js
打开 Chrome 并访问 chrome://inspect
在 Memory 标签页中，拍摄第一次堆快照（Snapshot 1）
触发一段模拟流量（如压测工具发送请求），等待处理完成
拍摄第二次堆快照（Snapshot 2）
对比 Snapshot 2 与 Snapshot 1，按大小和新增对象排序

通过对比视图中的 Delta 值，可以迅速定位哪些对象在两次快照之间增加了最多，进而找到相关构造函数或闭包。

2. 使用 `heapdump` 模块生成快照文件

在无法使用实时调试的生产环境，可以通过安装 heapdump 模块，在代码中或通过信号触发保存内存快照文件（.heapsnapshot），然后将文件下载到本地，再用 Chrome DevTools 离线分析。

const heapdump = require('heapdump');
// 在程序中调用
heapdump.writeSnapshot('/tmp/' + Date.now() + '.heapsnapshot');

实用技巧：在内存占用达到预设阈值时自动生成快照，便于捕获泄漏峰值。

3. 使用 `clinic` 工具链进行堆分析

Clinic.js 提供了 clinic heapprofiler 子命令，可以对 Node.js 进程进行全生命周期的内存分配监控，最终生成火焰图帮助定位高频分配点。

npm install -g clinic
clinic heapprofiler -- node app.js

运行结束后它会生成一个 HTML 报告，显示哪些函数分配了最多内存，并结合时间线展示泄漏趋势。

4. 结合 `node-memwatch` 监控 GC 事件

node-memwatch（或 @airbnb/node-memwatch）可监听 GC 事件并检测可疑的内存增长。当检测到内存持续未回收时，会触发 leak 事件，可配合快照自动生成。

const memwatch = require('@airbnb/node-memwatch');
memwatch.on('leak', (info) => {
  console.error('Potential leak detected:', info);
});

5. 使用 `process.memoryUsage()` 自建监控埋点

在应用的关键位置记录内存使用情况，结合日志或监控系统查看趋势。

setInterval(() => {
  const usage = process.memoryUsage();
  console.log(`HeapUsed: ${Math.round(usage.heapUsed / 1024 / 1024)} MB`);
}, 5000);

注意区分 heapUsed 和 rss：Buffer 等堆外内存主要影响 rss，必要时记录 process.memoryUsage().external。

四、预防与治理的最佳实践

严格管理生命周期：每个需要清理的资源（定时器、监听器、流、连接）都应在不再使用时显式释放。
使用 Linter 规则：ESLint 插件如 no-restricted-globals 可以限制全局变量的使用，eslint-plugin-node 可以提醒调用 EventEmitter 时的风险。
进行专门的泄漏测试：在 CI 中加入压测后的内存对比逻辑，比如启动服务 → 压测 10 万次请求 → 关闭连接 → 等待几次 GC → 检查内存是否回落到初始水平。
设置合理的容器内存上限：为 Docker 容器设置 --memory 限制，并配置 --max-old-space-size 参数让 Node.js 主动在接近容器上限时触发 GC，避免被 OOM Killer 直接杀掉。
代码审查关注点：重点检查全局缓存、闭包捕获、事件绑定与解绑、递归深度，这些是泄漏的高发区。

内存泄漏的定位和修复需要耐心和工具配合，但一旦掌握了快照分析与诱因模式，大多数泄漏都可以在几分钟内定位到原因。在长期运行的服务中，提前做好资源管理和监控布防，远比事后排错来得经济高效。