WEBKT

Node.js 内存泄漏排查实战：heapdump 深度分析与三大典型案例

4 0 0 0

在 Node.js 服务端开发中，最让开发者头疼的莫过于“内存泄漏”。它不像代码报错那样瞬间崩溃，而是像一个隐形的杀手，一点点吞噬服务器资源，直到触发 OOM (Out of Memory) 导致服务频繁重启。

虽然 V8 引擎拥有高效的垃圾回收（GC）机制，但如果代码逻辑中持有了本该释放的引用，GC 也无能为力。本文将带你通过 heapdump 工具进入“内存微观世界”，实战分析如何准确定位并修复这些问题。

一、 核心武器：heapdump

在排查内存泄漏时，仅仅看 process.memoryUsage() 的曲线是不够的，我们需要看到堆内存里到底装了什么。

heapdump 是一个强大的 Node.js 扩展，它可以将当前的堆内存状态拍摄成一个快照（.heapsnapshot 文件）。这个文件可以用 Chrome 浏览器的 DevTools 直接打开分析。

1. 安装与基础使用

npm install heapdump

在代码中引入：

const heapdump = require('heapdump');

// 可以在代码中手动触发
// heapdump.writeSnapshot('./' + Date.now() + '.heapsnapshot');

更专业的做法： 在生产环境下，通常不建议在代码逻辑里写死生成快照，而是通过发送信号的方式触发，避免影响正常业务：

// 默认情况下，heapdump 监听 USR2 信号
// 在 Linux 环境下执行：kill -USR2 <pid>

二、 排查方法论：两快照对比法

单看一个快照很难确定谁在增长。最科学的方法是：

  1. 快照 A（基准）：服务启动且完成预热后，抓取一个快照。
  2. 快照 B（问题态）：在负载升高或内存明显上涨后，抓取第二个快照。
  3. 对比分析：在 Chrome DevTools -> Memory 面板中 Load 这两个文件，选择 Comparison（对比）模式。

关注点： New（新增对象）、Deleted（删除对象）以及 Delta（净增量）。如果某个构造函数（Constructor）下的 Delta 一直是正数且居高不下，那就是嫌疑犯。

三、 三大经典案例分析

案例 1：隐蔽的闭包（The Sneaky Closure）

代码复现：

let theThing = null;
const replaceThing = function () {
  let originalThing = theThing;
  // 这里的闭包引用了 unused，而 unused 引用了 originalThing
  let unused = function () {
    if (originalThing) console.log("hi");
  };
  theThing = {
    longStr: new Array(1000000).join('*'),
    someMethod: function () {
      console.log("doing something");
    }
  };
};
setInterval(replaceThing, 100);

排查结论：
在 heapdump 中，你会发现 someMethod 共享了闭包作用域。即便 unused 从未被调用，它对 originalThing 的引用也会迫使 originalThing 留在内存中。随着 setInterval 的运行，这种引用链条会形成一种“俄罗斯套娃”，导致旧的 theThing 永远无法被回收。
修复： 在 replaceThing 函数末尾显式将 originalThing = null。

案例 2：失控的本地缓存（Unbounded Cache）

很多同学喜欢用一个 Object 或 Map 做本地缓存，提升查询性能。

const userCache = {};

function getUser(id) {
  if (userCache[id]) return userCache[id];
  const user = fetchUserFromDB(id); // 假设这是个耗时操作
  userCache[id] = user; // 没设置过期时间，没限制大小
  return user;
}

排查结论：
在 heapdump 的对比中，你会看到 Object 或 Map 的数量并没有异常，但其占用的 Retained Size（保留空间）极其庞大。点开详情可以看到里面堆积了成千上万个用户对象。
修复： 永远不要使用无限增长的对象做缓存。推荐使用 lru-cache 等库，设置 max 数量或 ttl 过期时间。

3. 忘记解绑的事件监听器（Forgotten Listeners）

在 Node.js 中，EventEmitter 如果只绑定不解绑，是极易造成泄漏的，尤其是在短生命周期的请求处理中。

server.on('request', (req, res) => {
  const onData = (chunk) => { /* 处理数据 */ };
  process.on('SIGUSR2', onData); // 错误：把请求级别的逻辑挂载到了全局对象上
  
  res.on('finish', () => {
    // 忘记 process.removeListener('SIGUSR2', onData);
  });
});

排查结论：
在 heapdump 中搜索 EventEmitters 或特定的函数名（如 onData），你会发现 process 对象的 _events 属性下挂载了数以万计的监听器。
修复： 确保在请求结束或对象销毁时，成对地使用 removeListener；或者考虑使用 once()。

四、 避坑小贴士

  1. 小心 Distance： 在 DevTools 中，Distance 表示对象距离根节点（GC Root）的距离。距离越短，说明被引用的层级越浅。
  2. Shallow Size vs Retained Size：
    • Shallow Size：对象自身占用的大小。
    • Retained Size：如果删除该对象，GC 能释放的总大小。我们通常要找 Retained Size 特别大的对象。
  3. 快照生成的开销： 生成 heapdump 会导致 Node.js 主线程短时间卡死（Stop-the-world）。在千万级 QPS 的生产环境下，建议先从负载均衡中摘除节点，再抓取快照。

总结

内存泄漏并不可怕，可怕的是“盲目猜想”。借助 heapdump 提供的客观数据，通过对比快照并观察引用树（Retainers），你可以精准地找到那个未被释放的变量。

记住排查三部曲：抓基准、抓增量、看对比。 希望这篇文章能帮你解决掉那个顽固的 OOM 问题！

架构师老余 Nodejs内存泄漏heapdump

评论点评