前言

大多数 Node.js 服务上线后都会经历一样的痛点：QPS 稳定、接口 P99 也没波动，但监控上却能看到容器内存像心电图一样一路攀升。从 180 MB 涨到 400 MB，再涨到 900 MB，直到某个凌晨触发 OOM Killer，Pod 被重启，监控上出现一个断崖，接下来新的一轮爬坡开始。

很多团队把内存 limit 从 1 G 调到 2 G，再加上“每天凌晨滚动重启”的定时任务。这能让告警安静下来却把根本问题推迟。话说回来，这篇文章不讨论 V8 GC 原理。而是给出一条可以照着做的排查方法：先确认到底是不是泄漏 → 抓取并对比堆快照 → 定位具体那一行代码。所有命令和代码都可以直接跑。

一、第一步先：先确认这真的是泄漏

这一步经常被跳过但它能省掉整整一天无用功。内存一直增加不等于内存泄漏。其实，

有三种情况长得很像，但处理方式完全不同：

现象	本质	处理方向
内存涨到某个值后稳定高水位	不用管，调 limit 即可	调整 limit 或缓存策略
内存锯齿上涨。GC 后能回落一部分，但底线在抬高
RSS 涨但 heapUsed 不涨 Buffer / 原生模块 / 内存碎片 查 external 和 arrayBuffers

至于打点，把内存曲线记下来

不要凭感觉，先埋一个最简单的采样点：

// memory-probe.js
const v8 = require;const MB = 1024 * 1024;const fmt = => .toFixed + 'MB';function startMemoryProbe {
const timer = setInterval => {
const m = process.memoryUsage;const h = v8.getHeapStatistics;按理说，console.log(JSON.stringify({
说到ts，new Date.toISOString,rss: fmt,// 进程实际占用的物理内存
heapTotal: fmt,// V8 申请到的堆大小
heapUsed: fmt。// V8 堆中实际使用的部分
external: fmt,// 绑定到 JS 对象的 C++ 内存
arrayBuffers: fmt,// Buffer / TypedArray 占用
heapLimit: fmt,// 堆上限，超过就 OOM
}));},intervalMs);timer.unref，// 关键：不要因为这个定时器阻止进程退出
return => clearInterval;}
module.exports = { startMemoryProbe };

`timer.unref` 别漏掉。监控代码本身把进程钉住不退出，是个很尴尬的翻车方式。

读懂这几个数字

• `heapUsed` 持续抬高 → JS 对象泄漏，这篇文章后面的堆快照流程适用。
• `heapUsed` 平稳但 `rss` 涨 → 堆外内存。 主要查 `external` 和 `arrayBuffers`，常见于 Buffer 拼接、`sharp`/`canvas` 等原生模块、还有 glibc 的内存碎片。
• `heapUsed` 接近 `heapLimit` → 准备迎接 `FATAL ERROR: JavaScript heap out of memory`。

手动触发一次 GC 做验证

判断“回落线”最可靠的方法是强制 GC 后再看：

node --expose-gc app.js
// 在排查期间开启，不要留在生产代码里
if {
setInterval => {
const before = process.memoryUsage.heapUsed;global.gc，说起来，const after = process.memoryUsage.heapUsed;console.log.toFixed}MB -> ${.toFixed}MB`);},60_000).unref;}
}

If each GC cycle still leaves a growing “after” value。you can confirm a leak—objects are being kept alive.

二、抓堆快照：三种方式按场景选

堆快照是定位泄漏主要武器，它是某一时刻 V8 堆里所有对象完整拓扑图。

从环境来看，--inspect + Chrome DevTools

node --inspect app.js
// 接下来浏览器打开 chrome://inspect，点击 inspect 并进入 DevTools 的 Memory 面板。/* 切到 Heap snapshot 并点击 Take snapshot */

生产环境这方面，代码内主动写盘

// v8.writeHeapSnapshot
const v8 = require;const path = require;function dumpHeapSnapshot {
const file = path.join}.heapsnapshot`);const written = v8.writeHeapSnapshot;// 同步阻塞操作
console.log;return written;其实，}

• * 写快照会 STW。堆越大停顿越久，怎么说呢，务必先把实例从负载均衡摘掉再操作。
• * 快照文件大小约等于堆大小；1GB 堆会产出近1GB 文件，请留意磁盘和下载耗时。
• * 推荐在压力测试或观察期间才写。不要频繁写桩子，否则可能影响业务性能。话说回来，
• * 可以把目录映射成挂载卷。以便离线分析，或者通过 SFTP 下载到本地机器分析。
• * 如果想避免同步阻塞，可以改为异步实现——虽然官方 API 没有异步版本。但可用 child_process spawn 调用 node -e 'require.writeHeapSnapshot' 来实现非阻塞调用。还是会触发 STW，因为 V8 本身是同步写文件。其实，但可以将其放在低峰期执行，以减少业务影响。
• * 在 Kubernetes 环境下如果想让 Pod 内部产生更小、更易转移的数据。可以考虑压缩生成后的文件，例如使用 gzip 或 zip；或者直接上传至云对象存储后再下载，以节省磁盘 I/O 带宽和空间成本。

如果你对这些细节感兴趣，可进一步 V8 的内部实现文档。

从更优雅的方式来看。信号触发

Node 提供了信号触发能力，无需改业务代码即可按需产生快照。bash node --heapsnapshot-signal=SIGUSR2 app.js

kill -USR2 此方案最适合“线上偶发、复现困难”的场景——提前挂上，在出现异常时随手打一发。

提醒nodemon 默认用 SIGUSR2 做重启信号，本地开发时换成 SIGUSR1 或者干脆别用这个方式。

---

三、对比快照：真正定位问题的一步

单张快照几乎没用。你会看到几十万个对象，无从下手。有价值的是两张快照差集**。

标准流程这方面，1️⃣ 服务启动预热完成后 → 抓 基线 Snapshot

1️⃣ 压测或等待业务跑一段时间。让泄漏累积至肉眼可见 → 抓 变化 Snapshot

1️⃣ 在 DevTools Memory 面板加载两张快照，并切换视图至 Comparison Base 为 Snapshot A

此时按 Size Delta 倒序排列；排在最上的构造函数就是嫌疑人。

三个必须分清指标

指标 含义与何时查看？	Shallow Size 对象自身占用判断单个对象是否异常大 #Retained Size #Distance #Address #Type #Size #Children ...?						Retained Size 该对象被回收后能释放的总内存 *定位泄漏主要看这个*	Distance 到 GC Root 的最短距离 辅助判断引用层级-->

**新手容易犯错盯 Shallow Size**——一个 Map 实例可能只有几十字节，却 Retain 着800MB 数据——Retained Size 才是真相。

看 Retainers：谁在拿着引用不放

选中可疑对象后看下方 **Retainers** 面板。它会展示一条从 GC Root 到该对象引用链。例如： Object @ └── in system / Context @ └── in cacheMap @ └── in exports @ └── in GC roots 这条链即答案——该对象被模块级 cacheMap 引用，所以永远无法回收。顺着链往上找到对应模块，在代码里搜 cacheMap，即可定位问题。

---

四、五种最常见泄漏模式

排查多了发现，大多数 Node.js 内存泄露逃不出以下五类：

模块级缓存没有淘汰策略

javascript // ❌ 无限增长缓存示例： const userCache = new Map;async function getUser { if ) return userCache.get;const user = await db.users.findById;userCache.set;// 只进不出 → 无限增长 return user;} 只要 ID 范围足够大，该 Map 就会一直涨。再看*修复*，给任何缓存设置上限。例如 LRU + TTL： javascript const { LRUCache } = require;const userCache=new LRUCache;async function getUser{ if) return userCache.get;const u=await db.users.findById;userCache.set;return u，} 若 key 是对象且想让它随 key GC 自动消失，用 WeakMap： javascript const metaCache=new WeakMap;metaCache.set });

EventEmitter监听器只加不减

javascript // ❌ 每请求都挂全局 emitter 上监听器： function handleRequest{ bus.on=>{res.setHeader;})，} 控制台会弹出 MaxListenersExceededWarning。说到*正确做法*，javascript function handleRequest{ const onChange==>res.setHeader;bus.on，res.on=>bus.off);} 或使用 AbortSignal： javascript function handleRequest{ const ac=new AbortController;bus.on，res.on=>ac.abort);} 建议加启动期自检： javascript process.on=>{ if{ console.error;} })，

定时器忘记清理

javascript // ❌ socket断开后定时器仍跑： function startHeartbeat{ setInterval=>socket.ping,1000);} setInterval 返回 Timeout 对象本身被事件循环持有，它闭包里的 socket 永远不会释放。至于*修复*，javascript function startHeartbeat{ const timer=setInterval=>socket.ping,1000);socket.once=>clearInterval);}

未消费 Stream 与背压失控

❌ 一次性读完整个文件导致 Buffer 占满： javascript const data=await fs.promises.readFile;// 大量数据直接堆外占满。✅ 流式处理保持恒定占用： javascript async function processCsv{ const rl=readline.createInterface({ input的观点是。fs.createReadStream,crlfDelay:true,});for await{ await handleLine;} } 关键是 `` 中 `` 会暂停读取。让处理完成，从而避免读得比写慢导致数据积压。

全局数组当日志缓冲区

❌ 用数组缓冲日志，一旦 flush 出错就成炸弹： javascript const pendingLogs=;function log{ pendingLogs.push;} setInterval=>flush,10000);✅ 有界队列+丢弃策略： javascript const MAX_PENDING=10_000;let droppedCount=0;const pendingLogs=;function log{ if{pendingLogs.shift;droppedCount++;} pendingLogs.push;}

---

五、实际案例复盘

再看背景。订单查询服务日均万请求，每小时必 OOM 重启一次。

步骤	操作	描述
Step — 确认泄露	埋点观察	小时间隔 monitor shows heapUsed 从210→690 MB；强制 GC 回落仅30 MB ⇒ 真泄露
Step — 抓快照	LB摘除实例	间隔数小时抓两张 snap；240 MB→610 MB
Step — 对比	Comparison视图按 Delta 排序	第一名 Object +xxx 个 Retained Size 增 +340 MB
Step — 看 Retainers	引用链指向 requestContextMap Map	搜索 code ⇒ 未清理
Step — 修复	删除操作添加至 requestContextMap.delete on res.close

最终连续运行数天heapUsed 稳定230 MB，无 OOM 告警。更进一步，可替换为 AsyncLocalStorage 自动管理生命周期。

六、防止 发生 —— 前移防御措施

加一层内存水位告警

javascript const v8=require;setInterval=>{ let {used_heap_size,heap_size_limit}=v8.getHeapStatistics;let ratio=used_heap_size/heap_size_limit;if{metrics.gauge;} },30000).unref;不过， 阈值建议设 .7-.9。让团队提前介入而不是等 OOM。

显式设置堆上限

容器环境里 V8 不一定识别 cgroup 限制。需要显式指定： bash

node --max-old-space-size=$) app.js

这样即使程序异常增长，也能提前由 OS 中断，而不是让 Node 静默崩溃。

CI 内加一个简单回归检查

在压测环节跑简化版检测脚本，看是否每轮都增加相同量。例如 run N rounds of same operation:

七、排查 Checklist

• 埋点采样 rss / heapUsed / external / arrayBuffers 至少数小时观察
` ... ...

---

写在最终

欢迎在评论区聊聊！

---