JavaScript垃圾回收机制与常见内存泄漏场景分析

一、JavaScript 内存生命周期与垃圾回收基本模型

在任何编程语言中，内存的生命周期都可以分为三个阶段：内存分配（声明变量、函数、对象时由运行时提供）、内存使用（读取或写入对象属性）以及内存释放（数据闲置后归还给系统）。

在 JavaScript 执行环境中，基础原始类型（如 Number、Boolean、String、null、undefined、Symbol）通常分配在执行栈（Stack）中，由执行上下文的弹栈过程直接清理；而引用类型（Object、Array、Function、Map 等）则分配在堆内存（Heap）中。栈内存中仅保存指向堆中具体地址的指针。垃圾回收器（Garbage Collector，简称 GC）监控和管理的核心战场正是这块动态增长的堆内存。

图 1：基于根节点可达性判断的 JavaScript 内存状态模型

二、核心垃圾回收算法：从引用计数到标记清除

评估一块内存是否能够被释放，垃圾回收算法主要经历了两个发展阶段：早期简单的引用计数法与当今主流的标记清除法。

1. 引用计数法及其致命缺陷

早期浏览器的垃圾回收策略通过跟踪记录每个值被引用的次数。当声明一个变量并将一个引用类型值赋给该变量时，引用次数为 1；如果该值又被赋给另一个变量，次数加 1；当变量脱离作用域或被赋予新值时，次数减 1。一旦引用计数归零，内存即可被安全回收。

致命缺陷：循环引用（Circular Reference）。如果两个对象相互包含对彼此的属性引用，即使这两个对象在业务上已经彻底废弃，它们的引用计数永远不会小于 1，造成永久无法被释放。

function testCycle() {
  const objA = {};
  const objB = {};
  objA.sibling = objB; // objB 计数 +1
  objB.sibling = objA; // objA 计数 +1
  // 函数执行结束，objA 和 objB 局部指针出栈
  // 但在引用计数机制下，两者的计数均为 1，导致内存泄漏！
}
testCycle();

2. 现代标记清除法（Mark-and-Sweep）

从 2012 年起，所有现代浏览器均全面转向标记清除法（及其演进的根节点可达性算法）。

垃圾回收器从一组“根节点”（Roots，包括全局对象 window / globalThis、当前正在调用的函数作用域局部变量、闭包作用域等）出发，沿着属性引用向下遍历：

• 标记阶段（Mark）：凡是从根节点能够直接或间接访问到的对象，都被打上“活动/可达”标记。
• 清除阶段（Sweep）：遍历整块堆内存，未被打上标记的对象均被判定为“死亡对象”，其所占用的内存空间被直接回收或加入空闲列表。

图 2：引用计数机制与标记清除可达性分析的区别

3. V8 引擎的分代式垃圾回收策略（Generational Collection）

现代高性能引擎（如 Chrome 的 V8）在此基础上提出了“代际假说”（The Generational Hypothesis）：大部分对象在诞生不久后就会死亡，而存活时间越长的对象，未来继续存活的概率越高。基于此，V8 将堆划分为：

• 新生代内存区（New Space）：容量较小（通常 1MB~64MB），存放生命周期短的对象。采用 Scavenge 算法配合 Cheney 双半区复制（From 空间与 To 空间交换），执行频率高、速度极快。
• 老生代内存区（Old Space）：存放经历过多次新生代 GC 仍存活的对象（晋升机制），以及体积庞大的大对象。采用标记-清除（Mark-Sweep）与标记-整理（Mark-Compact），结合增量标记（Incremental Marking）、并发标记（Concurrent Marking）避免主线程长时间卡顿（Stop-The-World）。

三、前端开发中高发的 5 大内存泄漏场景

由于现代引擎采用“可达性”判断，所谓的内存泄漏，本质上就是：业务上已经无用的对象，由于编码疏忽仍然挂载在某个可达的 GC Root 之上。以下是实践中最常见的场景：

场景 1：意外生成的全局变量

在非严格模式下，对未声明的变量进行赋值，或者在全局函数中错误使用 this，都会将变量隐式绑定在全局 window 上。全局对象作为常驻 GC Root，其所引用的所有数据在页面关闭前都不会被回收。

// 错误示例：未用 let/const 声明，泄漏至 window
function processCache() {
  leakData = new Array(1000000).fill("data"); // 隐式挂载至 window.leakData
}

// 错误示例：全局普通函数内的 this 指向 window
function setupInstance() {
  this.sessionPayload = { token: "abc", buffer: new Array(500000) };
}
setupInstance(); // 此时 window.sessionPayload 被污染

// 修复方案：
// 1. 在脚本或构建工具中启用严格模式 "use strict";
// 2. 规范变量作用域，始终显式使用 const / let；
// 3. 确实需要全局共享的数据，在页面跳转或销毁时手动解绑：window.leakData = null;

场景 2：被遗忘的定时器与未解绑的事件监听器

使用 setInterval 或 setTimeout 时，如果定时器回调内部引用了外部变量，只要定时器没有被明确调用 clearInterval 清除，定时器回调及其闭包上下文就会常驻内存。类似地，在 DOM 元素或全局总线上注册的事件监听器若未在组件销毁时注销，回调函数和作用域引用同样无法释放。

// 错误示例：在单页应用组件中启动定时器但未清除
let heavyBuffer = new Array(2000000).fill("heavy_payload");

const timerId = setInterval(() => {
  const node = document.getElementById("status-indicator");
  if (node) {
    node.innerText = "Buffer size: " + heavyBuffer.length;
  }
}, 1000);

// 当 status-indicator 节点从页面移除或用户切换路由时：
// 定时器仍在不断轮询，heavyBuffer 将永久存活在内存中！

// 修复方案：在组件卸载或生命周期结束时手动清理
clearInterval(timerId);
heavyBuffer = null;

场景 3：不经意的闭包驻留与共享作用域捕获

闭包是 JavaScript 强大的特性，但闭包会保留其外层函数词法环境的引用。如果在同一外层作用域中定义了多个闭包函数，V8 引擎会为该作用域生成一个共享闭包上下文（Context）。如果其中一个长期存活的函数引用了该作用域，作用域内所有被任何闭包接触过的大对象都无法释放。

// 经典 Meteor 闭包内存泄漏简化模型
let leakHolder = null;

function runLeak() {
  const original = leakHolder;
  // unused 闭包引用了 original
  const unused = function () {
    if (original) console.log("hi");
  };

  // leakHolder 引用了一个新的大对象与闭包
  leakHolder = {
    longStr: new Array(1000000).join("*"),
    someMethod: function () {
      // 闭包 someMethod 与 unused 共享同一个函数词法环境
    }
  };
}

// 每秒调用一次 runLeak()，堆内存将以线性阶梯持续攀升，迅速崩溃！
setInterval(runLeak, 1000);

// 修复方案：将局部大变量在使用后置空，或解耦不必要的闭包嵌套
function runSafe() {
  let heavyData = getHugeData();
  useData(heavyData);
  heavyData = null; // 解除对大对象的长期强引用
}

场景 4：脱离文档流但仍被 JS 持有的 DOM 节点（Detached DOM）

在操作 UI 时，如果我们通过变量保存了某个 DOM 元素的引用，随后在页面中通过 removeChild 或 innerHTML = '' 将该节点及其子树从 DOM 树中移除，该节点就变成了“游离 DOM”（Detached DOM）。由于 JavaScript 变量仍然指向它，垃圾回收器不能回收该节点以及该节点整棵子树的任何元素。

// 错误示例：保存了被移除 DOM 节点的引用
const elements = {
  button: document.getElementById("confirm-btn"),
  container: document.getElementById("dialog-box")
};

function removeDialog() {
  // 从文档树中移除了 DOM
  document.body.removeChild(elements.container);
  // 但 elements 对象中依然持有 container 及 button 的指针！
  // 整棵 dialog-box 及其所有子节点均成为 Detached DOM 留在内存中
}

// 修复方案：移除 DOM 的同时清空引用
function removeDialogSafely() {
  document.body.removeChild(elements.container);
  elements.button = null;
  elements.container = null;
}

场景 5：集合类滥用强引用（Map / Set 缺少回收机制）

标准 Map 与 Set 对其键和值都是强引用的。将对象存入 Map 后，即使该对象在其他地方已被彻底抛弃，只要 Map 自身依然存在，该对象及其关联数据就无法被垃圾回收。

// 错误示例：普通 Map 作为缓存，键值对象无法自动回收
const userMetadataMap = new Map();

function trackUser(user) {
  userMetadataMap.set(user, { loginTime: Date.now(), accessLevel: "admin" });
}

// 当 user 对象在业务逻辑中被赋值为 null 时，userMetadataMap 依然强引用着它！

// 修复方案：使用 WeakMap 或 WeakSet
// WeakMap 对键对象持有“弱引用”，一旦外部键对象不再被其他地方引用，
// 垃圾回收器会自动清理该键值对，无需手动维护生命周期。
const safeMetadataMap = new WeakMap();

function trackUserSafe(user) {
  safeMetadataMap.set(user, { loginTime: Date.now(), accessLevel: "admin" });
}

四、基于 Chrome DevTools 科学排查与定位内存泄漏

排查内存泄漏不能靠凭空猜测，必须依靠浏览器开发者工具提供的指标与快照进行科学对比。排查通常分为以下四个标准步骤：

图 3：Chrome DevTools 内存排查四步闭环法

1. 两个重要概念：Shallow Size 与 Retained Size

在分析 Heap Snapshot 时，必须准确理解这两个尺寸的含义：

• Shallow Size（浅层大小）：对象自身直接占用的内存大小（不包含它引用的其他对象）。例如，一个普通对象包含两个指针属性，其 Shallow Size 仅为存储这两个指针所需的大小（通常几十字节）。
• Retained Size（保留大小）：将该对象彻底删除后，垃圾回收器能够释放的总内存空间大小。它包含了该对象直接或间接支配引用的所有子对象的体积。排查内存泄漏时，首要关注 Retained Size 最大的节点。

2. 快速排查游离 DOM 节点（Detached Elements）

在拍摄完快照后，在快照顶部的“Class filter”搜索框中直接输入 Detached。如果出现黄色或红色高亮显示的 Detached HTMLDivElement 等节点，说明页面已经将其从渲染树移出，但仍有 JavaScript 变量强引用着它。选中该节点，在下方的 Retainers（保留者）面板中自底向上逐级查看，高亮黄色背景的属性即为持有该引用的“真凶”。

五、内存防御治理与最佳实践总结

预防内存泄漏的成本远低于线上出现卡顿甚至浏览器崩溃崩溃后的排查成本。在日常编码与工程建设中，建议遵循以下防御清单：

图 4：现代前端内存安全与防御治理规范