memory-leaks

Memory Leaks Skill — 内存泄漏排查

何时使用

• 服务跑久了内存爆 / OOMKilled
• Chrome 页面用一会卡顿 / 标签页崩溃
• 容器 RSS 持续增长不释放
• 单元测试通过但生产泄漏
• 怀疑某个改动引入泄漏

一、判断真泄漏 vs 假象

真泄漏：内存 monotonic 增长，永不下降，最终 OOM
   → 引用链让 GC 无法回收

假象：
  - 工作集大但稳定（cache 满了）→ 不是泄漏
  - 临时峰值（处理大请求）→ 不是泄漏
  - V8 / GC 延迟回收 → 等几分钟看是否下降

最可靠诊断：长时间观察 RSS 曲线。

# 容器
docker stats <container>
kubectl top pod <pod>

# 进程
ps aux | grep app
top -p <pid>

观察 趋势，不是瞬时值。

二、Node.js 内存模型

RSS = Resident Set Size（OS 视角，进程占的物理内存）
     = V8 heap + native heap + libuv buffers + ...

V8 heap = JS 对象（GC 管）
  - new space (young generation)
  - old space (long-lived)
  - large object space

外部缓冲区 = Buffer / ArrayBuffer
原生模块内存 = N-API addon 自管

console.log(process.memoryUsage())
// { rss, heapTotal, heapUsed, external, arrayBuffers }

三、Node 三快照对比法（黄金流程）

1. 服务启动 + 跑一会 → snapshot 1（baseline）
2. 触发可疑操作 N 次
3. 强制 GC → snapshot 2
4. 再触发 N 次 → snapshot 3
5. 对比 snapshot 2 → snapshot 3：净增长就是泄漏

// 启动允许 inspect 和 expose-gc
node --inspect --expose-gc app.js

// 代码或 console:
global.gc()
require('v8').writeHeapSnapshot('./snap-1.heapsnapshot')

Chrome → chrome://inspect → "Memory" → "Load profile" → Comparison view。

Comparison 看什么：

• "Delta" 列正数 = 增加的对象
• 按 retained size 排序
• 点对象看 Retainers（谁持有它，回溯到 GC root）

四、Node 常见泄漏模式

1. 闭包持有大对象

// ❌ 整个 huge 被闭包捕获
function makeHandler(huge) {
  return () => console.log('hi')   // 没用 huge 但仍引用作用域
}

// ✅ 显式提取需要的
function makeHandler(huge) {
  const id = huge.id   // 只引用 id
  return () => console.log(id)
}

2. EventEmitter 监听器累积

// ❌ 每次 add 都加，never remove
emitter.on('data', handler)
// 1000 次 emitter.on 后，1000 个 handler 引用 closure

// ✅ 用 once 或显式 off
emitter.once('data', handler)
emitter.off('data', handler)
emitter.removeAllListeners('data')

// 检测
emitter.setMaxListeners(20)   // 超出告警
emitter.listenerCount('data')

3. setInterval 不清

// ❌
const t = setInterval(() => doStuff(largeObj), 1000)
// largeObj 被 closure 抓住直到 clearInterval

// ✅
const t = setInterval(...)
on('shutdown', () => clearInterval(t))

// Node-specific：让 timer 不阻止退出
t.unref()