JavaScript中的垃圾回收机制详解

JavaScript垃圾回收机制是引擎自动管理内存的策略，通过标记-清除算法识别并回收不可达对象，避免内存泄漏；现代引擎结合分代回收、增量与并发回收优化性能，减少“Stop-the-World”停顿；开发者需理解GC原理以规避意外全局变量、未清理定时器、闭包过度引用等常见内存泄漏场景，并善用浏览器DevTools或Node.js工具监控内存使用，提升应用性能与稳定性。

JavaScript的垃圾回收机制，简而言之，就是引擎自动管理内存的一种策略。我们写代码时创建的各种变量、对象，用完之后总得有个地方去清理它们，否则内存就会被耗尽。在C++这类语言里，这事儿得程序员亲自动手，申请了内存就得记得释放。但JavaScript不一样，它把这个脏活累活自己揽了过去，目的就是让我们开发者能更专注于业务逻辑，而不是底层内存管理。说白了，它就是幕后的“清洁工”，默默地识别并回收那些程序不再需要的内存，确保我们的应用能够持续、高效地运行。

解决方案

我们都知道，JavaScript是一门高级语言，它抽象掉了底层的内存管理细节，这无疑极大地提升了开发效率。但这种“看不见”的自动管理，并不意味着我们可以对内存问题掉以轻心。理解垃圾回收（Garbage Collection, GC）机制，就像是了解汽车引擎的工作原理，即便你不用自己修车，也能更好地驾驶和保养它。

什么是“垃圾”？

在JS的语境里，“垃圾”并非指那些被错误创建或无用的数据，而是指那些程序不再能访问到的对象。想象一下，你创建了一个对象，然后所有指向它的引用都消失了，那么这个对象就变得不可达了，GC就会认为它是一块可以回收的内存。

立即学习“Java免费学习笔记（深入）”；

核心算法：从引用计数到标记-清除

早期的垃圾回收机制，比如引用计数（Reference Counting），思路非常直观：每个对象都有一个引用计数器，当有变量引用它时，计数器加一；当引用被解除时，计数器减一。一旦计数器归零，这个对象就被认为是垃圾，可以回收了。听起来完美无缺，对吧？但它有个致命的缺陷——循环引用。

比如：

let obj1 = {};
let obj2 = {};
obj1.a = obj2;
obj2.a = obj1;
// 此时obj1和obj2互相引用，它们的引用计数都是1。
// 即使我们之后把obj1和obj2设为null，
// 它们之间的引用计数仍然是1，导致它们都无法被回收，这就是内存泄漏。
obj1 = null;
obj2 = null;

这种情况下，引用计数就无能为力了。这也是为什么现代JS引擎（比如V8）都放弃了引用计数，转而采用更高级的算法——标记-清除（Mark-and-Sweep）。

标记-清除算法的核心思想是：

1. 标记阶段（Mark Phase）：垃圾回收器从一组“根”（比如全局对象

   window

   登录后复制
   或

   global

   登录后复制
   ，以及当前执行栈中的局部变量）开始，遍历所有能从根访问到的对象，并给它们打上“活的”标记。
2. 清除阶段（Sweep Phase）：遍历整个堆内存，将那些没有被标记的对象（也就是不可达的对象）进行回收，释放它们所占用的内存空间。

标记-清除完美解决了循环引用的问题，因为它只关心对象是否可达，而不是引用计数。即使

obj1

obj2

优化：分代回收与增量/并发回收

标记-清除虽然强大，但它有一个潜在问题：在执行GC时，JS应用会暂停（所谓的“Stop-the-World”），如果堆内存很大，暂停时间就会很长，导致页面卡顿。为了解决这个问题，现代JS引擎引入了许多优化策略：

• 分代回收（Generational Collection）：这个理论基于一个经验观察：大多数对象“生得快，死得也快”，而那些能活下来的对象往往会活得更久。于是，内存被分成了“新生代”（Young Generation）和“老生代”（Old Generation）。
  • 新生代：存放新创建的对象。这里会频繁进行“Scavenge”算法的回收，它是一种高效的复制算法，将存活的对象从一个区域复制到另一个区域，然后清空整个旧区域。多次存活的对象会被“晋升”到老生代。
  • 老生代：存放那些在新生代中存活下来的对象。这里的GC频率较低，但会采用标记-清除（可能还会配合标记-整理，避免内存碎片）算法。
• 增量回收（Incremental GC）和并发回收（Concurrent GC）：为了进一步减少“Stop-the-World”的时间，GC过程不再一次性完成。
  • 增量回收：将标记阶段分解成小块，穿插在JS代码执行之间，每次只处理一小部分，减少单次暂停时间。
  • 并发回收：让GC线程与JS主线程同时运行，GC在后台进行标记，只在必要时才暂停JS主线程进行清除。

这些复杂的优化，都是为了让JavaScript的自动内存管理在不影响用户体验的前提下，高效地完成任务。作为开发者，我们虽然不必深入到V8引擎的每一个细节，但理解这些基本原理，能帮助我们更好地编写高性能、无内存泄漏的代码。

为什么理解垃圾回收机制对前端开发者很重要？

说实话，很多人觉得前端开发嘛，不就是写写页面、调调API，内存这种底层的东西跟我们关系不大。这种想法，我个人觉得是有点偏颇的。我们每天都在和数据打交道，创建对象、操作DOM，这些都涉及到内存。如果不了解GC，就很容易在不经意间埋下“内存泄漏”的地雷，最终导致应用卡顿、崩溃，甚至影响用户体验。

首先，最直接的影响就是内存泄漏。内存泄漏不是说内存真的“漏”出去了，而是指那些本该被回收的内存，因为某种原因（通常是无意中保留了对它们的引用）而没有被GC回收，长期占用着系统资源。一个长期运行的单页应用（SPA）或者Node.js服务，如果存在内存泄漏，内存占用会持续增长，最终拖垮整个系统。

其次，它直接关系到应用性能。GC虽然是自动的，但它不是免费的。每次GC都需要消耗CPU时间，如果GC过于频繁，或者单次GC暂停时间过长（特别是那些没有很好优化过的老旧GC算法），就会导致应用出现明显的卡顿，用户体验直线下降。我们常说的“页面掉帧”、“UI卡顿”，除了渲染性能问题，GC停顿也可能是罪魁祸首之一。

再者，理解GC能帮助我们更好地调试和优化代码。当你发现应用内存占用异常，或者有性能瓶颈时，如果你知道GC的工作方式，就能更快地定位问题：是不是某个地方创建了大量短生命周期的对象导致GC频繁？是不是有循环引用或者未清理的事件监听器导致内存泄漏？这些问题，在懂GC原理的人眼中，会变得清晰很多。

最后，这其实也是专业素养的一部分。作为一名“真实人类作者”，我深知代码不仅仅是实现功能，更是对资源的一种管理。写出高效、健壮、无内存泄漏的代码，是每个专业开发者的追求。理解GC，就是我们迈向这个目标的重要一步。

常见的内存泄漏场景及其避免策略

在实际开发中，内存泄漏往往不是我们故意造成的，而是不经意间的疏忽。我见过不少项目，因为对内存管理缺乏认知，导致应用上线后出现各种性能问题。下面我总结了一些常见的内存泄漏场景和相应的避免策略：

1. 意外的全局变量

   • 场景描述：在函数内部，如果没有使用

     var

     登录后复制
     、

     let

     登录后复制
     或

     const

     登录后复制
     声明变量，那么这个变量就会自动成为全局对象（浏览器环境是

     window

     登录后复制
     ，Node.js环境是

     global

     登录后复制
     ）的属性。一旦成为全局变量，它就永远不会被GC回收，除非显式地将其设置为

     null

     登录后复制
     。
   • 代码示例：

     function createLeak() {
         leakVar = '我是一个意外的全局变量'; // 没有声明关键字
     }
     createLeak();
     // 此时 window.leakVar 存在，永远不会被回收

     登录后复制
   • 避免策略：
     • 始终使用

       var

       登录后复制
       、

       let

       登录后复制
       或

       const

       登录后复制
       声明变量。
     • 开启严格模式（

       'use strict';

       登录后复制
       ），它会阻止这种隐式全局变量的创建。
     • 如果确实需要全局变量，确保在不再需要时将其设置为

       null

       登录后复制
       。

2. 被遗忘的定时器和事件监听器

   • 场景描述：

     setInterval

     登录后复制
     、

     setTimeout

     登录后复制
     以及

     addEventListener

     登录后复制
     是前端开发中非常常用的API。但如果它们的回调函数引用了外部变量，并且定时器或事件监听器本身没有被清除，那么回调函数及其引用的外部变量就无法被回收。
     

     关于Objective

     本文档主要讲述的是关于Objective-C手动内存管理的规则；在ios开发中Objective-C 增加了一些新的东西，包括属性和垃圾回收。那么，我们在学习Objective-C之前，最好应该先了解，从前是什么样的，为什么Objective-C 要增加这些支持。有需要的朋友可以下载看看

     0

     查看详情

   • 代码示例：

     let someData = { value: 'important' };
     let timer = setInterval(() => {
         console.log(someData.value); // 闭包引用了 someData
     }, 1000);
     
     // 假设某个组件被销毁了，但 timer 还在运行
     // someData 永远不会被回收
     // function destroyComponent() {
     //   // ...
     //   clearInterval(timer); // 这一步经常被忘记
     // }

     登录后复制

   • 避免策略：

     • 对于

       setInterval

       登录后复制
       和

       setTimeout

       登录后复制
       ，在不再需要时务必调用

       clearInterval

       登录后复制
       和

       clearTimeout

       登录后复制
       。
     • 对于

       addEventListener

       登录后复制
       ，在组件销毁或不再需要时，务必调用

       removeEventListener

       登录后复制
       ，且传入的函数引用必须是同一个。
     • 使用

       AbortController

       登录后复制
       可以更优雅地管理事件监听器。

3. 脱离DOM树的引用

   • 场景描述：当我们从DOM树中移除一个元素时，如果JavaScript代码中仍然持有对这个元素的引用（比如在一个数组或对象中），那么这个元素及其子元素就无法被GC回收。

   • 代码示例：

     let elements = [];
     const ul = document.getElementById('myList');
     for (let i = 0; i < 10; i++) {
         const li = document.createElement('li');
         li.textContent = `Item ${i}`;
         ul.appendChild(li);
         elements.push(li); // 强引用了 li 元素
     }
     
     // 假设某个操作移除了 ul 元素
     ul.remove(); // DOM树上移除了，但 elements 数组还持有引用
     // elements 数组中的 li 元素及其内部数据无法被回收

     登录后复制

   • 避免策略：

     • 当DOM元素从页面中移除时，确保JS代码中所有对它的引用也被清除（设置为

       null

       登录后复制
       或从数组中删除）。
     • 如果需要缓存DOM元素，考虑使用

       WeakMap

       登录后复制
       ，它对键是弱引用，键对象没有其他引用时GC可以回收它。

4. 闭包引起的过度引用

   • 场景描述：闭包是JS中一个强大但有时也容易“惹麻烦”的特性。当一个内部函数引用了外部函数的变量，并且这个内部函数被外部持有（比如作为事件回调、定时器回调或返回值），那么即使外部函数执行完毕，其作用域中的变量也不会被回收，因为闭包还在引用它们。

   • 代码示例：

     function outer() {
         let largeArray = new Array(1000000).fill('some data'); // 很大的数组
         return function inner() {
             console.log(largeArray.length); // inner 闭包引用了 largeArray
         };
     }
     
     let keepAlive = outer(); // outer 执行完毕，但 largeArray 仍被 inner 引用
     // 只要 keepAlive 存在，largeArray 就不会被回收
     // 如果 keepAlive 长期不被释放，就会造成内存泄漏

     登录后复制

   • 避免策略：

     • 谨慎使用闭包，尤其是在处理大型数据结构时。
     • 确保不再需要的闭包及时解除引用（例如，将

       keepAlive = null

       登录后复制
       ）。
     • 如果闭包只引用了外部作用域中一小部分变量，可以考虑将这些变量作为参数传递，而不是直接引用整个外部作用域。

5. Map

   登录后复制
   、

   Set

   登录后复制
   与

   WeakMap

   登录后复制
   、

   WeakSet

   登录后复制
   的选择

   • 场景描述：

     Map

     登录后复制
     和

     Set

     登录后复制
     会强引用它们存储的键和值。这意味着，即使键对象或值对象在其他地方不再被引用，只要它们还在

     Map

     登录后复制
     或

     Set

     登录后复制
     中，GC就无法回收它们。

   • 代码示例：

     let cache = new Map();
     let keyObject = {};
     let valueObject = { data: 'some cached data' };
     
     cache.set(keyObject, valueObject);
     keyObject = null; // 此时 keyObject 仍然被 cache 强引用
     // valueObject 也被 cache 强引用
     // 它们都不会被回收

     登录后复制

   • 避免策略：

     • 当你的键是对象，且你希望这些键在没有其他引用时能被GC回收，那么应该使用

       WeakMap

       登录后复制
       或

       WeakSet

       登录后复制
       。它们对键是弱引用，不会阻止GC回收键对象。

     • WeakMap

       登录后复制
       的键必须是对象，

       WeakSet

       登录后复制
       的成员也必须是对象。

理解这些场景并养成良好的编码习惯，能大大减少内存泄漏的发生。这不仅仅是技术问题，更是一种对代码负责的态度。

如何在实际项目中监控和优化内存使用？

光知道原理和常见场景还不够，我们还得学会怎么在实际项目中“捉虫”和“防虫”。我个人觉得，工具的使用和日常的习惯养成同样重要。

1. 浏览器开发者工具：你的内存侦探

Chrome DevTools（或其他浏览器类似工具）是前端开发者排查内存问题的利器。

• Performance 面板：在录制性能时，你会看到一个绿色的条纹，那就是GC活动。如果GC条纹过于频繁或持续时间过长，就说明你的应用可能存在内存压力。这能给你一个初步的信号。
• Memory 面板：这才是真正进行内存分析的主战场。
  • Heap Snapshot (堆快照)：这是最常用的功能。它会捕获当前时刻JS堆内存的详细快照。你可以：
    • 直接分析：看看哪些对象占用了大量内存，特别是那些你觉得不应该存在的对象。
    • 对比快照：这是发现内存泄漏的关键。
      1. 在应用正常状态下，拍一张快照A。
      2. 执行一些可能导致泄漏的操作（比如打开/关闭一个弹窗10次，或者重复加载/卸载一个组件）。
      3. 回到初始状态，再拍一张快照B。
      4. 选择快照B，在顶部下拉菜单中选择“Comparison”模式，与快照A进行对比。
      5. 重点关注“Delta”列，它会显示对象数量的变化。如果某个对象类型的数量在重复操作后持续增加，且没有减少，那么很可能就是内存泄漏了。
      • 小技巧：在对象列表中，可以按“Size”或“Count”排序，找出异常增长的对象。展开对象，查看其“Retainers”视图，能看到是谁在持有这个对象的引用，从而定位到代码。
  • Allocation instrumentation on timeline (分配时间线)：这个功能可以实时记录内存分配情况。当你怀疑某个操作导致大量内存分配时，可以开启它，执行操作，然后观察内存曲线。它能帮助你识别频繁创建临时对象的代码模式。

2. Node.js 环境下的内存监控

如果你在开发Node.js应用，也有类似的工具和方法：

• process.memoryUsage()

  登录后复制
  ：这是Node.js内置的一个简单API，可以快速获取当前进程的内存使用情况，包括RSS（常驻内存）、HeapTotal（堆总大小）、HeapUsed（堆已使用大小）等。

  console.log(process.memoryUsage());
  // {
  //   rss: 49356800,
  //   heapTotal: 7372800,
  //   heapUsed: 4948840,
  //   external: 87272,
  //   arrayBuffers: 13916
  // }

  登录后复制

• heapdump

  登录后复制
  或

  v8-profiler

  登录后复制
  ：这些第三方库可以帮助你在Node.js应用中生成堆快照，然后你可以将这些快照导入Chrome DevTools进行分析，方法和浏览器环境类似。
• PM2/Docker等部署工具：这些工具通常提供内存监控功能，可以设置内存阈值，当内存使用超过限制时发出警告或自动重启服务。

3. 优化策略：从习惯到架构

了解了如何监控，接下来就是如何优化了。这不仅仅是技术细节，更是一种编码习惯和架构考量。

• 减少不必要的对象创建：尤其是在循环或高频事件处理函数中。避免在每次迭代或每次事件触发时都创建新的对象，可以考虑复用。
• 及时解除引用：这是避免内存泄漏的核心。无论是变量、事件监听器、定时器还是DOM引用，在不再需要时，务必将其设置为

  null

  登录后复制
  或调用相应的清除函数。
• **使用`WeakMap

以上就是JavaScript中的垃圾回收机制详解的详细内容，更多请关注php中文网其它相关文章！