JavaScript · V8 内存与垃圾回收

场景 1 · SPA 用 8 小时内存翻 3 倍: 快照对比破案

客服后台开一天卡死。快照对比锁定 UserRow 组件增量 5000 份, Retainers 指向一个全局数组:

// 泄漏点: 全局注册表只进不出
const mounted = [];
export function mountUser(row) { mounted.push(row); }
// 修复: 组件卸载时注销
export function unmountUser(row) {
  const i = mounted.indexOf(row);
  if (i >= 0) mounted.splice(i, 1);   // 引用链断掉
}

回归方法: 路由切换 ×10 后快照对比, UserRow #Delta 应为 0。

场景 2 · 全局缓存无上限 → LRU 化

商品详情缓存 Map 一天 40 万 key。加容量上限 + 淘汰最旧:

const cache = new Map();          // Map 有序: 便于 LRU
const MAX = 2000;
function put(k, v) {
  if (cache.has(k)) cache.delete(k);   // 重插置新
  cache.set(k, v);
  if (cache.size > MAX) cache.delete(cache.keys().next().value);
}
// 或直接用 lru-cache 库, 带 TTL 更稳

场景 3 · 第三方图表组件的监听器泄漏

每页挂 4 个 chart, resize 监听闭包拽着整个 chart 实例与数据, 切换 20 次后 1.2GB:

useEffect(() => {
  const chart = initChart(el, data);
  const onResize = () => chart.resize();
  window.addEventListener('resize', onResize);
  return () => {                            // 关键: 成对清理
    window.removeEventListener('resize', onResize);
    chart.dispose();                        // 组件内部监听一并释放
  };
}, [data]);

场景 4 · 一次性事件用 AbortSignal 自动清理

组件里挂 3 个 window 监听器, 漏解绑一个就泄漏。用 AbortController 一键全摘:

useEffect(() => {
  const ac = new AbortController();
  window.addEventListener('resize', h1, { signal: ac.signal });
  window.addEventListener('scroll', h2, { signal: ac.signal });
  document.addEventListener('click', h3, { signal: ac.signal });
  return () => ac.abort();   // 关键: 一行摘掉全部
}, []);

场景 5 · Detached DOM: 虚拟列表的快照残留

无限滚动把每个离开视口的行缓存在 rowCache 便于回滚, 1 万行后 Detached 节点吃掉 800MB:

// 泄漏: 缓存的是 DOM 节点本身
rowCache.set(id, li);
// 修复 1: 缓存"重建所需的数据"而不是节点
rowCache.set(id, { name, avatar, onClickId });
// 修复 2: 上限 + 淘汰, 只留视口附近的行
if (rowCache.size > 200) rowCache.delete(rowCache.keys().next().value);

场景 6 · Node: rss 涨 heapUsed 不涨 = Buffer 的锅

图片代理服务 RSS 3GB 但 heapUsed 300MB。Buffer 分配在 V8 堆外, 走 8KB 池:

const m = process.memoryUsage();
// rss 3000MB, heapUsed 300MB, external 2600MB ← Buffer 在这
log(m.rss, m.heapUsed, m.external, m.arrayBuffers);
// 治理: 大文件用流(pipe)不整读; 限制并发下载量
await pipeline(fs.createReadStream(p), res);

场景 7 · Worker 计算大数组: transferable 零拷贝

主线程把 500MB 数组 postMessage 给 Worker, 结构化克隆直接内存翻倍。转移所有权避免拷贝:

// 错: 克隆一份 → 内存 ×2
worker.postMessage(bigBuffer);
// 对: 转移所有权, 零拷贝, 原线程立即失去访问权
worker.postMessage(bigBuffer, [bigBuffer.buffer]);

场景 8 · K8s 里 Node 被 OOMKill: 堆上限错配

容器 limit 1Gi, V8 按宿主机 128G 内存把堆上限估到 32G, 满负荷时 RSS 冲破 limit 被杀:

// Dockerfile / deployment args:
ENV NODE_OPTIONS="--max-old-space-size=768"
# 关键: limit 1Gi → 堆 768MB, 留 25% 给 Buffer/栈/元数据
# 验证: 压测到满载, 观察 rss 稳定在 limit 的 85% 以下

场景 9 · WeakMap 做对象元数据: 天然不泄漏

给每个请求挂调试上下文, 用 Map 会拽住请求对象, 换 WeakMap 跟随生命周期:

const traceCtx = new WeakMap();
traceCtx.set(req, { start: performance.now(), id: genId() });
// 响应结束 req 被回收时, 元数据自动跟着回收
// Map 版本: 必须 finally 里 traceCtx.delete(req) 否则泄漏

场景 10 · 分配速率过高: 新生代频繁 GC 的治理

动画帧循环里每帧 new 大数组, Scavenge 每秒触发几十次, 掉帧+CPU 高:

// 错: 每帧分配
function frame() { const pts = new Float32Array(1e4); compute(pts); }
// 对: 复用同一块内存(对象池思想)
const pts = new Float32Array(1e4);
function frame() { pts.fill(0); compute(pts); requestAnimationFrame(frame); }

分配速率降为 0 后, 新生代 GC 几乎消失, P99 帧时间从 24ms → 8ms。