深入理解JavaScript垃圾回收机制：从内存分配到内存泄漏排查

1. 先搞懂JS的内存分配方式，才能理解回收的逻辑

很多前端同学写了好几年业务代码，从来没主动关心过JS内存是怎么分配的。直到某一天线上页面越跑越卡，内存占用一路飙升，最后浏览器标签页直接崩溃，这才发现自己对垃圾回收机制一无所知。我之前就是这样踩过大坑的，所以这篇记录我就从内存分配的最底层说起。

1.1 栈内存与堆内存，到底谁在管数据

JS中的数据分成两大类：基本类型（string、number、boolean、null、undefined、symbol、bigint）和引用类型（object、array、function等）。这两类数据的存放方式完全不同。基本类型的值直接存放在栈内存中，每个变量占用固定大小的空间，进栈出栈非常快。引用类型则比较特殊，变量名存在栈上，但实际的数据存放在堆内存中，栈里存的只是指向堆内存地址的引用。

这里我用一个生活例子帮你理解。栈就像你去咖啡馆存包，柜子大小固定，存进去取出来都是O(1)的操作，效率极高。而堆就像仓库，你可以随意往里面放大件物品，但你需要记录每件物品放在哪个货架、哪个位置，这个记录就存在你的手机备忘录里（变量名——栈上的引用）。

这样一个结构就决定了垃圾回收的焦点。基本类型用完就释放，栈指针一移动就没了，根本不需要回收。真正的内存压力全部来自堆内存——当你new一个对象、创建一个数组、定义一个闭包时，这些数据都会跑到堆上，如果不及时回收，堆内存就会被越占越满。

1.2 可达性分析：垃圾回收的判断标准

既然堆内存是回收的重点，那怎么判断一个对象是否该被回收？这里有一个核心概念叫"可达性"（reachability）。JS引擎会从一组根对象（root）出发，沿着引用链去遍历，凡是能被根对象直接或间接访问到的对象，就认为是"活的"，需要保留；凡是遍历不到的对象，就是"死的"，可以回收。

根对象包括哪些？主要有：全局对象（window或global）、当前正在执行的函数调用栈上的局部变量和参数、以及一些内置对象（如Math、JSON等）。你可以把根对象想象成一棵大树的树根，从树根出发能连接到的枝叶都是存活的，断掉的枝叶就会被清理掉。

这个机制其实很好理解。举个例子：

let person = { name: '张三', friend: { name: '李四' } }; // 此时person、person.friend都是可达的 person = null; // 整个对象失去引用，包括friend变成不可达，等待回收

关键点在于：只要没有根指向这个对象，哪怕对象内部互相引用得再紧密，它也是死数据。这一点恰恰是引用计数算法的致命伤，后面我详细说。

1.3 为什么V8要自己管内存

C和C++需要开发者手动调用malloc/free来分配和释放内存，这给程序带来了极强的控制力，但也带来了大量内存泄漏和悬垂指针问题。JS选择了一条相反的路——垃圾回收全自动执行，开发者无需（也无法）手动释放内存。V8引擎作为Chrome和Node.js的JS执行引擎，它内部实现了一套完整的内存管理机制，包括内存分配、垃圾回收、堆整理等。

自动化的代价是性能。GC（Garbage Collection，垃圾回收）执行时会暂停JS脚本的执行，这个暂停时间如果太长，用户就会感知到页面卡顿。所以现代引擎都在想尽办法缩短停顿时间，这也是后面要讲的分代回收、增量标记等技术的核心动机。

我必须提醒一点：自动回收不等于一劳永逸。如果你代码写得不对，对象明明还在被引用，GC根本不敢回收它，内存就会持续上涨。这就是典型的内存泄漏——不是GC不干活，而是你的引用把对象"钉死"了。所以理解GC机制，核心目的之一就是写出不阻碍GC的代码。

2. 两种经典回收算法：引用计数与标记清除

垃圾回收领域有两套最基础的算法：引用计数和标记清除。前者简单直观但缺陷明显，后者是当今主流引擎实际采用的核心方案。这两套思路都要吃透，因为很多面试题和性能问题都围绕它们展开。

2.1 引用计数：原理简单，但有一个致命缺陷

引用计数的思路非常朴素：给每个对象维护一个引用计数器，当有一个新引用指向它时，计数器加1；当这个引用被销毁时，计数器减1；当计数器的值变成0时，说明没有任何地方引用它，立即回收。

这套算法在小范围内用起来很爽，没有暂停，实时回收。但它有一个绕不过去的致命伤——循环引用。看这个例子：

function createCircular() { const objA = {}; const objB = {}; objA.b = objB; objB.a = objA; return; } createCircular();

函数执行完，objA和objB理论上已经没人用了，但它们互相引用对方，各自的应用计数都是1，永远不会变成0，GC也就永远不会回收它们。这两个死对象会一直躺在堆里，造成泄漏。

以前老版本的IE浏览器（IE8及更早）对DOM对象采用引用计数管理，经常出现JS对象和DOM元素之间互相引用导致的内存泄漏。后来引用计数逐渐被主流引擎抛弃，取而代之的是标记清除。

2.2 标记清除：现代引擎的核心算法

标记清除分两个阶段。标记阶段：从根对象出发，递归遍历所有可达对象，给它们打上"存活"标记。清除阶段：遍历堆中所有对象，把没有被标记的对象视为垃圾直接清除，同时把存活对象的标记抹掉，为下一次GC做准备。

这套算法解决了循环引用问题，因为判断依据不是"有没有人引用我"，而是"从根出发能不能遍历到我"。即使两个对象互相引用，只要从根出发访问不到，它们依然会被标记为垃圾。

标记清除的代价是遍历开销。最直接的实现需要从根出发完整扫描一遍对象图，标记所有存活对象，再扫一遍堆来清除垃圾。堆越大，这两次遍历的时间越长。V8在实现上做了大量优化，比如使用三色标记法配合增量标记来降低单次GC的停顿时间，这一点后面单独展开。

2.3 标记整理：顺手解决内存碎片问题

标记清除还有一个副作用——内存碎片化。因为回收的内存块是不连续的，大量对象被清除后，堆上会留下很多细小的空闲空间。下一次要分配一个大对象时，即使总空闲内存足够，也找不到一块连续的区域，被迫触发一次Full GC甚至直接内存不足。

标记整理算法就是为了解决碎片问题。它在标记之后增加了一个"整理"阶段：把所有存活对象向内存空间的一端移动，紧挨着排列，然后直接清掉边界之外的所有空间。这样腾出来的是一整块连续内存，后续分配效率更高。

听起来很完美，但整理阶段需要移动对象，移动意味着需要更新所有指向这些对象的引用，这个开销不小。所以V8并不是每次GC都做完整整理，而是在空间碎片积累到一定程度，或者分配大对象遇到困难时，才执行带整理的GC。

这里给个小结论：标记清除适合大多数情况，标记整理是它的增强版，主要为了解决碎片。引用计数已基本退出历史舞台，但理解它能帮你更深刻地理解循环引用的坑。

3. V8的分代回收到底怎么运作的

实际生产环境中，引擎不会只用一套算法解决所有问题。V8的核心策略是"分代回收"——把堆分成新生代和老生代两个区域，对不同区域采用不同的GC策略。这是典型的因地制宜，因为研究统计表明：大部分对象在创建后很快就变成垃圾（比如函数内部的临时对象），活下来的对象往往能活很久。

3.1 新生代与老生代的划分逻辑

V8把堆分为新生代（new space）和老生代（old space）。新生代通常有1~8MB的容量（小内存设备会更小），里面的对象寿命短，GC频率高。老生代容量大，对象寿命长，GC频率低。

对象怎么从新生代进入老生代？两个条件：一是对象经历了一次Scavenge回收后依然存活（相当于扛过了一轮"筛选"），二是对象在新生代中总大小超过一定阈值（比如大数组、大缓存会被直接分配到老生代）。这个过程有个专业术语叫"晋升"（promotion）。晋升逻辑本质上是对对象"生命预期"的判断——你都熬过一两次GC了，大概率还会活很久，放在频繁回收的新生代反而是浪费，不如挪到老生代，用低频GC来照看。

3.2 新生代的Scavenge算法

新生代采用Scavenge算法，具体实现叫Cheney算法，也叫"半空间复制"。它的做法是把新生代空间一分为二：一个处于使用状态（from space），一个处于空闲状态（to space）。分配对象都在from space进行；触发GC时，先把from space中还存活的对象复制到to space，然后把from space全部清空，最后交换from和to的角色。

这个算法的精妙之处在于：复制是顺序的，存活对象在to space中紧密排列，天然解决了碎片问题。而且新生代空间小、存活对象少，复制成本很低。代价是空间利用率减半，因此新生代空间不能设计得太大。

晋升时机也很讲究。当一个对象经历第一次Scavenge还存活时，就会被移动到老生代。但要注意，如果to space的空间已经被占用了大约25%，那么后续存活对象也会直接晋升到老生代，避免to space空间不足导致频繁GC。这个细节很多资料不会讲，但你在调优时可以留意。

3.3 老生代的标记清除与增量标记

老生代里的对象通常是大块头或者"长寿老人"，用Scavenge那种复制方式不划算——复制大对象的开销太高。所以老生代采用标记清除为主、标记整理为辅的策略。

老生代的GC有个核心痛点：完整遍历整个堆做标记需要暂停JS执行，如果堆很大，这个暂停可能长达几百毫秒，用户会感觉到明显的卡顿。为了降低停顿，V8引入了增量标记（Incremental Marking）——把一次完整的标记过程拆成很多小步，穿插在JS脚本执行的间隙中完成。每次执行一小段标记，然后让出主线程继续跑业务代码，循环往复，最终完成整轮标记。

和增量标记配套的还有惰性清除（Lazy Sweeping）与并发清除（Concurrent Sweeping）。前者把清除阶段延迟到必要时才做，后者把清除操作分配到后台线程。到了后来的V8版本，连标记阶段都可以并发执行了（并发标记），GC停顿时间被压缩到极低的水平，这也是现代大型前端应用能保持流畅的关键保障。

再补充一个概念：老生代还有一种叫"增量整理"的机制，但整理本身比标记更耗时，所以V8对整理非常谨慎，一般只在碎片化严重时触发。日常开发中，你可能感知不到整理的存在，但理解它的触发逻辑，有助于解释为什么某些时刻内存占用会出现"先涨后降再涨"的锯齿形曲线。

4. 实战：排查和定位JS内存泄漏的完整过程

讲完原理，下面进入实操环节。这部分是我踩坑最多的地方。说实话，光知道GC怎么工作，不能帮你线上问题；真正有价值的是知道怎么用工具定位泄漏，以及知道哪些编码习惯最容易把对象"钉死"在堆上。这一大节我围绕真实场景展开。

4.1 十个常见内存泄漏场景，先对照自查

我把日常开发中最容易造成内存泄漏的写法整理成一张速查表，你可以直接对照项目代码自查。

这里最坑的是事件监听器。假设你开发一个单页应用，每次路由切换都往window上绑一个scroll监听，而回调里引用了当前页面的DOM和大对象。页面切走了，DOM已销毁，但window还在，监听器还在，回调引用的对象全都还"活着"。我见过一个后台管理系统，用户切了几十个页面后，页面就开始卡顿，最后直接白屏。排查下来，就是因为每个页面都添加了全局监听事件且不清理。

4.2 用Performance面板录制GC活动，找到停顿元凶

定位内存问题第一步，先确认是不是GC导致的卡顿。打开Chrome DevTools的Performance面板，点击录制按钮，然后在页面上执行一些操作（比如翻页、打开弹窗、拉取列表），录制约5到10秒后停止。在录制结果的Timeline中，你会看到一条叫"Minor GC"或"Major GC"的彩色短横线。

• Minor GC：新生代回收，频率高、耗时短，通常只有几毫秒。
• Major GC：老生代回收，频率低、耗时长，如果横线很长，或者颜色特别深，说明一次GC停顿时间异常。

我实际遇到过一种典型情况：页面上连续打开十几个大弹窗，每次弹窗都渲染几百行表格数据，关闭弹窗时只隐藏不销毁。结果Performance录制显示Major GC横线不断拉长，最长的一次接近800毫秒，页面直接卡死。顺着GC停顿点去查业务代码，发现弹窗数据用了全局缓存数组，只push不pop，数组长度飙到上万条，每次Major GC光扫描这个数组就耗费大量时间。

这里要强调一个观念：GC停顿长，不一定只因为"对象太多"，更可能是因为"被引用的对象太多"。即使对象不大，只要引用链深、对象图复杂，标记阶段就要遍历很长时间。所以优化手段不只是少创建对象，还要及时切断不必要的引用链。

4.3 用Memory面板做堆快照对比，精确定位泄漏对象

定位了GC停顿还只是第一步，要找到具体是哪个对象泄漏，需要用Memory面板做堆快照（Heap Snapshot）对比。操作步骤很简单：

1. 打开DevTools的Memory面板，选择Heap snapshot，点击"Take snapshot"获取初始状态。
2. 在页面上执行你怀疑泄漏的操作（比如打开一个弹窗然后关闭）。
3. 再次点击"Take snapshot"获取操作后的快照。
4. 在"Comparison"视图下，对比两个快照之间的差异，重点看"New"（新增）和"Delta"（变化量）列。

如果某类对象的数量在操作前后基本不变，但执行了多次操作后数量还在持续增长，那基本可以判定泄漏。比如反复打开关闭弹窗，内容类（如HTMLDivElement）数量却只增不减，说明弹窗关闭时DOM并没有被释放，极有可能是外层容器还保留着它的引用。

还有一种更高效的排查手段：用Allocation instrumentation on timeline（时间线上的分配分析）录制。它会记录每个函数分配的内存量和对象数量，你可以按函数名排序，点开查看具体是哪个函数在持续分配内存、有没有被回收。这种方式比快照对比更直观，特别适合定位那些"高频分配但从不释放"的代码。

4.4 一个真实的线上案例：从卡顿到修复的完整排查

说一个我参与过的实际案例。某个运营管理平台，用户反映打开报表页后，页面内存以肉眼可见的速度上涨，切到别的页面也不回落，半小时后电脑风扇狂转。我接手排查，第一轮先看代码，发现报表页里有个轮询接口，每五秒拉一次实时数据，每次返回的数据处理后塞进一个全局对象里存着，用于页面切换时恢复数据。

数据量其实不大，每次也就几KB，但问题在于这个轮询注册在全局，页面离开时没有clearInterval。而且更隐蔽的是，接口返回后处理数据的函数是一个闭包，闭包引用了报表页的核心DOM节点和数据对象。页面虽然切走了，轮询还在跑，每五秒更新一次数据，把大量中间值包在闭包里，释放不掉。

定位过程我分了三步。第一步用Performance录制，确认每五秒出现一次Minor GC且停顿逐渐变长。第二步用Memory快照对比，发现切走页面后，报表组件对象数量没有减少，并且有一个很大的Array持续膨胀。第三步点开对象详情，顺着引用链条看到了那个轮询回调函数。找到根因后修复很简单：在组件卸载时clearInterval，并把全局缓存改为页面级变量，切换页面时自动清理。修复后同样操作半小时，堆内存曲线非常平稳，GC停顿基本消失。

这个案例给我最大启发是：内存泄漏经常不是华丽的代码难题，而是被忽略的生命周期管理问题。定时器、事件监听器、闭包、缓存，这些都是"隐形的引用链"，写的时候不觉得有问题，跑起来才知道它们把对象锁得死死的。

5. 常见问题答疑与避坑技巧，全是实在经验

这一部分我把平时社群和博客留言里最常见的问题汇总一下，加上一些我个人的判断和实操经验。这些问题如果不讲透，很容易在面试和实战中翻车。

5.1 闭包一定会造成内存泄漏吗

很多人一听到闭包就紧张，觉得闭包等于泄漏。这个认知不准确。闭包本身不是问题，问题在于闭包的生命周期超过了预期，而它引用的外部变量又舍不得放。

举一个最常见的场景：

function createCounter() { let count = 0; return function() { count += 1; return count; }; } const counter = createCounter();

这里的count被闭包函数引用，只要counter还存在，count就不会被回收。这对计数器来说是合理需求，不算泄漏。但如果你在一个大数组上创建了一个闭包，闭包只用到其中一个小字段，引擎也没法做到精准回收，因为闭包会引用整个外部环境（在ES6之前是变量对象，现在V8做了优化，但仍有边界情况），大数组就一直留在内存里。

所以结论是：闭包不是洪水猛兽，使用时盯住它的生命周期。短命闭包（回调、事件处理函数内部）没问题，长命闭包（全局缓存、单例、模块级变量）就得小心，确保它引用的都是必要数据。

5.2 WeakMap和WeakSet到底什么时候用

WeakMap和WeakSet是专门配合垃圾回收设计的容器。它们的键（WeakSet是对象元素）对对象的引用是"弱引用"——不阻止GC回收这个对象。一旦对象没有其他强引用，垃圾回收时就会把它从WeakMap/WeakSet中移除。

看这段代码：

const cache = new Map(); function process(obj) { if (!cache.has(obj)) { cache.set(obj, expensiveCalculation(obj)); } return cache.get(obj); }

如果用Map做缓存，即使外部已经把obj置为null，Map里仍然持有obj的强引用，这个对象永远不会被回收。如果换成WeakMap：

const cache = new WeakMap(); function process(obj) { if (!cache.has(obj)) { cache.set(obj, expensiveCalculation(obj)); } return cache.get(obj); }

当外部不再引用obj时，GC可以随时回收它，WeakMap里的记录也会跟着消失。这天然解决了缓存无限膨胀的问题。但我必须提醒：WeakMap没有size属性，不能遍历，也不能清空，这些限制决定了它只适合做"辅助缓存"，不适合做"主数据存储"。在选择容器前，先想清楚是否需要遍历能力，这是实际项目中很容易踩的坑。

5.3 我能手动触发GC吗，哪些场景需要

Chrome DevTools里你可以通过Memory面板左下角的垃圾桶图标手动触发一次GC，用于调试。线上环境不建议也没必要手动触发GC——引擎的自动调度远比人精细。但有一个场景值得手动触发：你想要干净地测量某个操作的"真实内存占用"时，先点击垃圾箱图标清一波，再录制分配，这样结果更准确。

Node.js环境可以通过global.gc()手动触发，但前提是启动时加了--expose-gc参数。我在做Node服务端内存泄漏排查时经常这么做：在关键接口处理前后打印process.memoryUsage()，结合手动GC来判断哪些对象还留在堆里。

5.4 如何设置V8内存上限，node --max-old-space-size

Node.js默认的老生代内存上限大约是1.4GB（64位系统，具体和系统版本有关），超出后进程直接OOM（Out of Memory）。如果你的应用确实需要处理大量数据，可以通过启动参数调整：

node --max-old-space-size=4096 app.js

单位是MB，上面这行表示把老生代上限调到4GB。强调一下：调大内存上限不是解决泄漏的长久之计，它只是给程序更多空间，但泄漏速度没变，最终还是会OOM。正确做法是先定位泄漏根源再考虑调参。另外调太大也有风险，机器物理内存不够时会使用交换分区，性能断崖式下降，线上服务会表现成"假死"。

5.5 排查再补两刀：DevTools的覆盖率和Lighthouse也可以帮忙

很多同学只知道Performance和Memory，忽略了另外两个辅助面板。Coverage（覆盖率）面板可以录制页面JS的执行覆盖情况，如果一个脚本文件中大量代码没被使用，但文件又被全局加载并留着引用，这本身就是一种潜在的资源泄漏。Lighthouse的Performance审计会检测"JavaScript执行时间"和"主线程工作"，如果得分低且提示"Reduce JavaScript execution time"，可以从侧面反映脚本执行和内存压力偏高。这两个工具不是内存排查的主力，但作为交叉验证很有用，能帮你确认问题到底出在内存还是出在整体脚本执行效率。

5.6 浏览器自动GC的时机，别指望它帮你兜底

最后聊一个经常被误解的点：浏览器确实会在内存压力大时自动触发GC，甚至对后台标签页大幅压缩内存（Chrome的节能模式），但你不能把"自动GC"当成内存管理求助热线。GC只能回收不可达的对象，对你的代码里那些强引用毫无办法。你写了window.xxx = data，页面不关，GC永远不敢动它。

我见过最典型的反面教材是：在全局对象上存了一大堆表单校验结果，美其名曰"方便下次打开恢复"，结果用户打开几百次表单之后，全局对象保存了上万个旧表单的数据快照。这种代码层不会报错，但内存曲线会非常诚实地一路向上。所以核心原则只有一个：管好自己的引用，别让对象活过它的使命期。

写在最后的小体会

回头看，垃圾回收这件事最反直觉的地方在于：你越是想靠直觉"帮"GC，越容易帮倒忙。比如频繁把数据塞进全局变量、用Map缓存所有计算结果、在长生命周期对象里挂大量短生命周期数据……这些做法表面上是在优化性能，实际上是把对象往老生代里"钉"。我自己现在写代码有一个固定习惯：每个存储类数据（缓存、全局状态、模块级变量）都必须回答三个问题——存什么、活多久、谁来清理。回答不清楚，就不写。

另外还想分享一个排查技巧：当你怀疑内存泄漏但找不到头绪时，别急着看代码，先做一个"压力操作 + 堆快照对比"的基线实验。先录一个干净页面的内存基线，再执行一次业务操作，再录一个快照；重复执行十次同样的操作，观察内存增长是线性还是指数级。线性增长一般是有固定对象没释放，指数级增长通常是递归或请求回调嵌套导致的对象爆炸。这个判断能帮你快速缩小排查范围，比拿着代码一行行猜效率高得多。