JS 垃圾回收机制：V8 分代回收、内存泄漏排查（闭包 / DOM 引用 / 定时器）

Hi，我是前端人类学！

今天我们不写业务代码，来聊聊 JavaScript 的“清洁工”——垃圾回收机制。理解它，你才能写出真正高性能、无内存泄漏的应用。

一、为什么需要垃圾回收？

JavaScript 在创建变量（对象、字符串、函数等）时会自动分配内存，当这些变量不再被使用时，需要释放内存以便复用。C 语言中开发者需要手动free，而 JavaScript 则提供了**自动垃圾回收（Garbage Collection）**机制。

但“自动”不等于“完美”。如果对回收机制理解不足，内存泄漏仍然会悄无声息地发生，最终导致页面卡顿甚至崩溃。

二、V8 的分代回收策略

V8 引擎将内存堆划分为两个主要区域，针对不同“代龄”的对象采用不同的回收策略：

2.1 新生代（Young Generation / New Space）

• 存放内容：新创建的对象、短期存活的对象。
• 特点：空间小（通常 1~8MB），存活时间短，回收频率高。
• 回收算法：Scavenge 算法（具体实现为 Cheney 算法）。

Scavenge 将新生代空间一分为二：From 空间和To 空间。分配内存时只在 From 空间进行，回收时，将 From 中存活的对象复制到 To 空间，然后清空 From，最后交换两个空间的角色。

这个过程非常快，但代价是需要额外占用一半空间作为“预留”。

2.2 老生代（Old Generation / Old Space）

• 存放内容：经过多次新生代回收仍存活的对象，以及大对象（如大型数组、字符串）。
• 特点：空间大，存活时间长，回收频率低。
• 回收算法：标记-清除（Mark-Sweep）和标记-整理（Mark-Compact）结合。

标记-清除分为两个阶段：

• 标记：从根对象（如全局对象globalThis）出发，递归遍历所有可达对象，打上标记。
• 清除：遍历堆内存，回收未被标记的对象。

但标记-清除会产生内存碎片，导致大对象无法分配。因此 V8 在适当时候会触发标记-整理，在清除后将存活对象向一端移动，压缩内存。

2.3 为什么分代？

分代假说认为：绝大多数对象“朝生暮死”。新生代使用 Copying 算法速度快，但空间浪费；老生代使用标记-清除，适合大空间但速度稍慢。分代回收兼顾了吞吐量和延迟的平衡。

三、V8 的并发 / 并行 / 增量回收

现代 V8 在回收时不再是“全停顿”（Stop-The-World）：

• 增量标记：将一次完整的标记过程拆分为多个小步骤，穿插在 JS 执行间隙，减少卡顿。
• 并发标记：在 JS 线程运行时，后台线程同时进行标记。
• 并行回收：使用多个辅助线程同时进行清除和整理，加速回收。

这些技术让 GC 的停顿时间从几百毫秒降低到几毫秒，对用户体验影响微乎其微。

四、内存泄漏的三大元凶

即使 GC 再强大，以下几种场景下内存仍然会“泄漏”——即对象不再被需要，但仍然被引用，无法被回收。

4.1 闭包（Closure）引用

闭包是 JS 中最常见的内存泄漏来源之一。当内部函数持有外部函数的变量引用，且内部函数被长期保留时，外部函数的整个作用域链都无法释放。

functioncreateLeak(){lethugeData=newArray(1000000).fill('*');returnfunction(){// 虽然内部函数只用到了 tinyData，但它持有整个作用域lettinyData=1;returntinyData;};}constleakyFn=createLeak();// hugeData 无法被回收，因为 leakyFn 仍在引用它

解决方案：在闭包中只保留必要的变量，或主动将大对象置为null。

functionfixLeak(){lethugeData=newArray(1000000).fill('*');letresult=hugeData.length;hugeData=null;// 主动解除引用returnfunction(){returnresult;};}

4.2 DOM 引用（分离的 DOM 节点）

当 DOM 元素被移除后，如果 JavaScript 中仍有变量指向它，该 DOM 节点及其关联的事件监听器都无法被回收。

letelement=document.getElementById('leak');document.body.removeChild(element);// element 变量仍然指向已移除的 DOM，造成泄漏

解决方案：移除 DOM 时，同时清理所有引用。

letelement=document.getElementById('leak');document.body.removeChild(element);element=null;// 解除引用

4.3 未清理的定时器（setInterval / setTimeout）

setInterval会持续执行回调，如果回调函数中引用了外部变量，该变量将一直存活。

letdata=newArray(1000000).fill('leak');setInterval(()=>{console.log(data.length);// data 一直被引用},1000);

即使想停止定时器，如果忘记clearInterval，data 永远不会被释放。

解决方案：在组件卸载或不再需要定时器时，务必调用clearInterval/clearTimeout。

五、内存泄漏排查实战

5.1 Chrome DevTools Memory 面板

• Heap Snapshot（堆快照）：拍摄当前内存快照，对比两次操作前后的对象变化，找到“保留对象”的路径。
• Allocation Timeline（分配时间线）：记录内存分配随时间的变化，定位频繁分配内存的代码位置。
• Detached DOM Tree：在快照中搜索 “Detached”，可以找到已被移除但未释放的 DOM 节点。

5.2 Performance 面板 + GC 按钮

在 Performance 面板录制时，可以手动点击垃圾桶图标强制执行垃圾回收，观察内存曲线是否回落。

5.3 使用--trace-gc标志

在 Node.js 环境中，启动时添加--trace-gc可以打印每次 GC 的耗时和回收的内存大小，帮助定位 GC 频繁触发的问题。

六、最佳实践总结

垃圾回收是 JavaScript 引擎的“隐形守护者”，但它不是万能的。理解 V8 的分代回收策略，识别闭包、DOM 引用、定时器这三大泄漏源，掌握 Chrome DevTools 的排查技巧，是每一位前端开发者从“会用”走向“精通”的必经之路。

内存管理不是引擎的事，而是你的事。只有真正理解 GC 的运作方式，才能写出既优雅又健壮的 JavaScript 代码。