深入理解 JavaScript 垃圾回收机制：从原理到性能优化

2026-02-09 11:45:59 0条评论 2次阅读 0人点赞

作为一名前端开发者，你是否曾经好奇过，为什么我们在 JavaScript 中创建了无数的对象、变量和函数，却很少像在 C 或 C++ 中那样担心内存释放的问题？当我们在代码中写下 INLINECODEf23c344b 时，内存被分配了；但当我们不再使用 INLINECODEdad87faf 时，谁来负责清理这部分内存？这就是 JavaScript 引擎中一项被称为“垃圾回收”的神奇技术在背后默默工作。

在本文中，我们将深入探讨 JavaScript 的内存管理机制。我们将一起学习什么是垃圾回收，它是如何自动检测并清理那些“不再可达”的对象的，以及引用计数和标记-清除等核心算法是如何运作的。无论你是想避免常见的内存泄漏陷阱，还是仅仅想对这门语言的底层运行机制有更透彻的理解，这篇文章都将为你提供实用的知识和见解。

1 什么是垃圾回收？
2 JavaScript 垃圾回收的核心概念：可达性
3 垃圾回收背后的算法：标记-清除
4 垃圾回收在实际开发中的体现
5 为什么垃圾回收对性能至关重要？
6 进阶：现代引擎的优化策略 (分代回收与 V8)
7 常见的内存泄漏陷阱与最佳实践
8 总结与关键要点

什么是垃圾回收？

在计算机科学中，垃圾回收是一种自动内存管理形式。简单来说，垃圾回收器就像一位勤劳的清洁工，它会定期检查我们的内存（通常被称为“堆” Heap），找出那些不再被程序任何部分引用或访问的数据，并将它们清理掉，从而释放出宝贵的内存资源供后续使用。

在像 C 或 C++ 这样的低级语言中，我们需要手动调用 INLINECODE55df0101 来分配内存，并在使用完毕后调用 INLINECODE1312cdda 来释放内存。如果忘记释放，就会导致内存泄漏；如果过早释放，则会导致程序崩溃。然而，JavaScript 是一种高级语言，它被设计为安全且易于使用。因此，JavaScript 引擎（如 Chrome 的 V8 或 Firefox 的 SpiderMonkey）内置了垃圾回收机制，当我们创建对象时自动分配内存，并在这些对象不再被使用时自动释放内存。

这个过程是自动发生的，我们作为开发者通常不需要干预，但理解它对于编写高性能的代码至关重要。

JavaScript 垃圾回收的核心概念：可达性

在探讨具体的算法之前，我们需要理解垃圾回收器判断一个对象是否“该死”的基本标准，那就是“可达性”。

你可以将内存中的对象想象成一张巨大的蜘蛛网：

根：这张网有一些固定的起点，被称为“根”。这通常是全局变量（在浏览器中是 INLINECODE76a2b1e9，在 Node.js 中是 INLINECODEc388f223）或者当前执行栈中被当前函数使用的参数和局部变量。
引用：如果一个对象可以通过引用链从根节点追溯到，那么它就是“可达的”。
垃圾：如果一个对象无法从根节点追溯到了，也就是说程序没有任何办法再访问到它了，那么它就是“不可达的”。不可达的对象被认为是垃圾，将被回收器清理。

垃圾回收背后的算法：标记-清除

虽然不同的 JavaScript 引擎实现细节不同，但最基础且广泛使用的算法思想是“标记-清除”。这个算法主要分为两个阶段：

标记：垃圾回收器从“根”开始，遍历所有引用。对于每一个访问到的对象，都会被打上一个“活跃”或“可达”的标记。这就像是在寻宝游戏中给每个找到的宝藏贴上标签。
清除：在这个阶段，回收器遍历整个堆内存。那些在标记阶段没有被贴上标签的对象，即“不可达”的对象，将被执行内存释放操作。

为了让你更直观地理解这个过程，让我们用 JavaScript 代码来模拟一个简化的垃圾回收器：

/**
 * 模拟垃圾回收算法的类
 * 用于演示标记-清除的基本逻辑
 */
class GarbageCollector {
    constructor() {
        // 我们在内存中维护一个对象列表来模拟堆
        this.heap = [];
    }

    /**
     * 创建一个新对象并加入模拟的堆内存
     * @param {string} name 对象名称
     * @returns {object} 新创建的对象
     */
    createObject(name) {
        // refCount 模拟引用计数，初始为 1（被当前变量引用）
        const obj = { name: name, refCount: 1, marked: false };
        this.heap.push(obj);
        return obj;
    }

    /**
     * 模拟标记阶段
     * 遍历堆中的对象，如果被引用则标记为 true
     */
    mark() {
        this.heap.forEach(obj => {
            // 简单的逻辑：只要有引用计数大于 0，就被视为“可达”
            if (obj.refCount > 0) {
                obj.marked = true;
            }
        });
        console.log("[标记阶段] 已扫描所有对象并标记活跃项。");
    }

    /**
     * 模拟清除阶段
     * 移除所有未被标记的对象，并重置标记状态
     */
    sweep() {
        // 过滤掉未标记的对象
        const initialLength = this.heap.length;
        this.heap = this.heap.filter(obj => obj.marked);
        const removedCount = initialLength - this.heap.length;
        
        // 清除标记状态，为下一轮 GC 做准备
        this.heap.forEach(obj => obj.marked = false);
        
        console.log(`[清除阶段] 已清理 ${removedCount} 个不再使用的对象。`);
    }

    /**
     * 执行完整的垃圾回收流程
     */
    collectGarbage() {
        console.log("--- 开始垃圾回收 ---");
        this.mark();
        this.sweep();
        console.log("--- 垃圾回收结束 ---");
    }

    /**
     * 查看当前堆内存状态
     */
    printStatus() {
        console.log("当前堆中的对象:", this.heap);
    }
}

// --- 使用示例 ---
const gc = new GarbageCollector();

// 1. 创建两个对象
const user1 = gc.createObject("用户 A");
const user2 = gc.createObject("用户 B");

gc.printStatus(); 
// 输出: 两个对象都在内存中

// 2. 模拟不再引用 user2 (例如 user2 离开了作用域或被设为 null)
// 在我们的模拟器中，手动将引用计数设为 0
user2.refCount = 0;

console.log("
user2 的引用已断开...");

// 3. 执行垃圾回收
gc.collectGarbage();

// 4. 再次检查内存状态
gc.printStatus(); 
// 预期输出: 只有 "用户 A" 还在，"用户 B" 被回收了

代码解析：

createObject: 当我们创建对象时，它们被加入到一个模拟的 INLINECODE60fc5af8 数组中。每个对象都有一个 INLINECODE7f96e0ae 来模拟当前的引用情况。
mark: 在这个模拟中，我们简单地遍历数组。如果 INLINECODEe4b753b9 大于 0，说明还有东西在引用它，我们把 INLINECODEf44a6498 设为 true。在真实的引擎中，这一步会递归遍历对象的所有属性引用。
sweep: 这是清理环节。我们使用 INLINECODEa750d695 保留那些 INLINECODE68ea99f6 为 INLINECODE083c0c45 的对象。那些没被标记的（比如我们手动把 INLINECODE5aa6122e 设为 0 的 user2）就被从数组中移除了，模拟了内存的释放。
collectGarbage: 这是组合拳，它按顺序调用标记和清除，还原了真实的 GC 周期。

通过这个模拟，你可以看到垃圾回收的核心逻辑：找到活着的，剩下的就是垃圾，清理掉。

垃圾回收在实际开发中的体现

理解了算法原理后，让我们看看在日常编码中，哪些操作会直接触发垃圾回收机制。

场景 1：基础引用的丢失

这是最直观的场景。当一个变量被赋值为 null 或者被重新赋值时，原本指向的对象就失去了引用。

// 创建一个对象，内存地址假设为 0x001
let project = { name: "Super Project", id: 101 };

// 此时，变量 project 引用着 0x001
// 0x001 是可达的，不会被回收
console.log(project); // { name: ‘Super Project‘, id: 101 }

// --- 上下文变更 ---
// 我们不再需要这个项目了，手动移除引用
project = null;

// 现在，project 指向 null。
// 原来的对象 { name: "Super Project", id: 101 } 变成了不可达对象。
// 垃圾回收器会在下一次运行时识别到这一点，并清理这块内存。
console.log(project); // null

为什么这很重要？

在构建单页应用（SPA）时，我们经常会有大量的状态对象。当用户切换页面或组件卸载时，如果不将这些大对象置为 null，它们会一直占用内存，导致应用随着时间推移变得越来越卡。

场景 2：脱离作用域的局部变量

函数内的局部变量在函数执行完毕后，通常会成为垃圾回收的目标。

function processUserData() {
    // 局部变量 user，仅在函数内部有效
    const user = { name: "Alice", role: "Admin" };
    let processedData = user.name + " is processed.";
    
    console.log(processedData);
    
    // 函数结束
    // 此时，user 和 processedData 都不再被外部需要。
    // 它们是函数作用域内的局部变量，函数返回后，它们就变成了“不可达”的。
    // GC 会自动回收这些局部变量占用的内存。
}

processUserData();
// 函数执行完毕，user 对象所在的内存可以被回收

这里有一个微妙的点：闭包。如果内部函数引用了外部函数的变量，那么即使外部函数执行完毕，被引用的变量也不会被回收。这也是闭包会占用更多内存的原因。

场景 3：数组元素的删除

当我们在处理列表数据时，删除数组元素不仅仅是逻辑上的移除，也会影响内存引用。

let employees = [
    { id: 1, name: "Tom" },
    { id: 2, name: "Jerry" },
    { id: 3, name: "Spike" }
];

// 假设我们需要开除 Spike (id: 3)
// 使用 splice 移除
const removedEmployee = employees.pop(); 
// 或者 splice(2, 1)

console.log(employees); // 只剩 Tom 和 Jerry

// 关键点：
// removedEmployee 变量现在引用着原本数组中的第三个对象。
// 如果你不需要处理这个离职员工的数据，最好不要创建 removedEmployee，
// 或者在使用完 removedEmployee 后将其置为 null。
// 否则，那个对象依然存在于内存中！

如果你只是使用 employees.splice(index, 1) 而不接收返回值，那么被切出来的那个对象瞬间就失去了引用，立即变成了可回收垃圾。这是处理大量数据列表时的一种优化手段。

为什么垃圾回收对性能至关重要？

你可能会想，现在的电脑内存这么大，为什么还要这么在意垃圾回收？

防止内存泄漏：这是最直接的后果。如果你保留了对不再使用的对象的引用（比如在全局对象中缓存了所有用户的会话数据），内存占用会持续上升。最终，浏览器会杀掉标签页，或者移动端 App 会崩溃。
提升应用响应速度：垃圾回收器本身运行也是需要消耗 CPU 资源的。如果内存中充满了垃圾，回收器就需要更频繁地运行，甚至可能导致页面出现短暂的卡顿。良好的内存管理可以减少 GC 的触发频率，让动画和交互更流畅。
资源优化：在移动设备或低功耗设备上，内存是非常宝贵的资源。高效的内存使用意味着你的应用可以在更多设备上流畅运行。

进阶：现代引擎的优化策略 (分代回收与 V8)

现代 JavaScript 引擎（特别是 Chrome 的 V8）并不是简单地全盘扫描整个堆。全盘扫描非常慢。它们使用了更聪明的策略，其中最著名的是分代假说。

分代假说认为：大部分对象存活时间很短（比如函数内的临时变量），只有少部分对象会长期存活（比如全局配置）。

基于此，V8 将堆分为两代：新生代 和 老生代。

新生代：

* 空间小：通常只有 1MB 到 8MB。

* 存活率低：这里存放刚创建的对象。

* 算法：Scavenge 算法（Cheney 算法）。这是一种“复制”算法。它将内存分为两块，一块叫 From，一块叫 To。新对象在 From 中分配。当 GC 开始，它检查 From 中的存活对象，将它们复制到 To 中（这自然完成了内存整理，消除了碎片）。复制完成后，From 和 To 角色互换。From 中剩下的（也就是垃圾）直接被清空。

* 优势：非常适合存活率低的情况，速度极快。

老生代：

* 空间大：存放从新生代熬过来的“老”对象，或者直接分配的大对象。

* 存活率高：这里的对象不容易死。

* 算法：标记-清除 + 标记-整理。如果这里也用复制算法，那要浪费一半内存去复制，太奢侈了。所以还是用传统的标记清除。为了避免内存碎片，V8 会定期进行“标记-整理”，将存活的对象向一端移动。

实用见解： 当你在优化性能时，尽量避免在老生代中产生过多的垃圾，或者尽量避免让临时对象意外晋升到老生代（例如，不要在闭包里无限制地持有大对象引用）。

常见的内存泄漏陷阱与最佳实践

即使有 GC，不良的编码习惯也会导致“本该被回收的对象”被意外保留，这就是内存泄漏。

1. 意外的全局变量

function foo() {
    // 忘记写 let/const/var！
    leakyVariable = "I am global now!"; 
}

foo();
// 现在 leakyVariable 挂在了 window 上。
// 除非页面关闭或手动删除，否则这个字符串永远不会被回收。

解决方案：始终使用 ‘use strict‘ 严格模式，这会阻止创建意外的全局变量。

2. 被遗忘的定时器

function startPolling() {
    const data = new Array(1000000).fill("Big Data");
    
    setInterval(() => {
        // 这里的回调闭包捕获了 data 变量
        console.log("Checking data...");
    }, 1000);
}

startPolling();
// 即使 startPolling 执行完毕，setInterval 的回调函数依然被浏览器引用。
// 回调引用了 data，data 就永远不会被回收。

解决方案：当你不需要定时器时，务必调用 clearInterval(intervalId)。

3. 未清理的 DOM 引用

let button = document.getElementById(‘myButton‘);

const data = { /* 巨大的图表数据 */ };

button.addEventListener(‘click‘, () => {
    // 使用 data
});

// 后来，我们通过 JS 移除了 button
button.remove();

// 问题：虽然 DOM 树中没有 button 了，但变量 button 还在内存中。
// 且变量 button 引用了 DOM 元素，DOM 元素的事件回调引用了 data。
// 整个链条都在内存中。

解决方案：当移除 DOM 节点时，同时也将对应的 JavaScript 变量置为 null。

总结与关键要点

在这篇文章中，我们一起探索了 JavaScript 垃圾回收的奥秘。从基本的概念到核心的“标记-清除”算法，再到现代引擎的优化策略，我们看到了 JavaScript 引擎是如何在后台默默地保障我们的程序健康运行的。

让我们回顾一下最关键的几点：

自动化：JavaScript 通过垃圾回收机制自动管理内存，我们通常不需要手动分配或释放内存。
核心逻辑：垃圾回收主要基于“可达性”概念。如果一个对象无法从根节点被访问到，它就会被标记为垃圾并清理。
主要算法：虽然现代引擎很复杂，但基础是标记-清除。V8 引擎使用分代回收策略（新生代用复制，老生代用标记清除/整理）来优化性能。
开发者责任：虽然有 GC，但我们并不是高枕无忧的。我们需要小心处理全局变量、定时器和闭包，避免内存泄漏。
最佳实践：当对象不再使用时，主动解除引用（设为 null）；及时清理定时器和事件监听器。

掌握这些知识，不仅能帮助你写出更稳定的代码，还能在遇到内存问题时，让你能够像侦探一样迅速定位并解决问题。现在，当你写下 const obj = ... 时，你知道它将经历怎样的生命周期了。祝编码愉快！

投稿给我们	如何建站？
vps是什么？	如何安装宝塔？
如何通过博客赚钱？	便宜wordpress托管方案
免费wordpress主题	这些都是免费方案

豆丁博客