JavaScript垃圾回收通过“可达性”判断对象是否为垃圾，以标记-清除为主流算法，从根对象出发标记可达对象，清除未标记的不可达对象；现代引擎如V8采用分代回收、增量回收等优化策略减少性能影响；内存泄漏常因未清理定时器、事件监听器、意外全局变量或闭包导致，需通过及时解除引用、避免强引用滞留等方式预防；合理使用性能工具分析内存使用，配合垃圾回收机制可有效提升程序性能。
JavaScript的垃圾回收机制，说白了，就是一套自动管理内存的系统。它负责找出那些程序不再需要的内存空间，然后把它们清理掉，好让新的数据能有地方住。这对于我们开发者来说，简直是福音，省去了手动分配和释放内存的繁琐和易错。
解决方案
当我们在JavaScript中创建对象、变量、函数时，它们都会占用内存。但这些东西并非永生不灭，总有它们完成使命，不再被任何地方引用的那一刻。这时，如果任由它们占据着内存，系统就会越来越慢，直到崩溃。垃圾回收机制就是来解决这个问题的。
它的核心思想是“可达性”（Reachability）。一个对象，只要能从根（Root）对象（比如全局对象
window
或
global
，当前执行栈中的局部变量，以及活动函数的参数等）通过引用链条访问到，它就是“可达的”，也就是“活着的”。反之，如果一个对象从任何根都无法访问到，那它就是“不可达的”，也就是“垃圾”，可以被回收了。
目前最主流的垃圾回收算法是“标记-清除”（Mark-and-Sweep）。我总觉得这个过程，就像是系统在玩一场大型的“寻宝游戏”：
标记阶段（Mark Phase）：垃圾回收器会从一系列“根”对象（比如全局对象、当前执行上下文中的变量等）开始，遍历所有能从这些根访问到的对象，给它们打上一个“活着的”标记。这个过程会沿着对象的引用链条一层层地往下找，凡是能被找到的，都算“活着的”。那些没有被标记到的，自然就是“死的”——也就是垃圾。清除阶段（Sweep Phase）：在标记阶段结束后，垃圾回收器会遍历堆内存，把所有没有被标记的对象，也就是那些“死掉的”对象，从内存中清除掉，释放它们占据的空间。
当然，早期的浏览器也用过“引用计数”（Reference Counting），但那玩意儿有个致命的弱点：循环引用。两个对象互相指着对方，谁也走不掉，结果就是内存泄漏。这就像两个人互相锁着对方的门，谁也出不去，最后都饿死在屋里。所以，标记-清除就成了主流。现代的V8引擎（Chrome和Node.js都在用）在此基础上做了很多优化，比如“分代回收”（Generational Collection）和“增量回收”（Incremental Collection），以减少垃圾回收对程序性能的影响，让用户几乎感受不到它的存在。
JavaScript垃圾回收是如何判断哪些对象是“垃圾”的？
判断一个对象是否是“垃圾”，关键在于它是否“可达”。这可不是简单地看它有没有被引用，而是要看它是否能从一组特定的“根”对象那里，通过一系列的引用链条被访问到。
想象一下，内存空间就像一个巨大的网络，每个对象都是网络中的一个节点。而“根”对象，就是这个网络的入口。这些根通常包括：
全局对象（Global Object）：在浏览器环境中是
window
，在Node.js中是
global
。任何直接挂载在它们下面的变量和函数，都是可达的。执行栈（Execution Stack）：当前正在执行的函数中声明的局部变量、函数参数等。当前执行上下文中的其他活动对象：比如闭包捕获的外部变量等。
垃圾回收器会从这些根出发，沿着所有的引用关系，像“病毒传播”一样，把所有能“感染”到的对象都标记为“活着的”。那些无论如何都无法被“感染”到的对象，就意味着它们已经彻底失去了与程序运行的联系，无法再被访问和使用了。这些就是真正的“垃圾”，可以被无情地清理掉。所以，一个对象即使还有引用指向它，但如果这个引用链条的源头已经不可达了，那么这个对象最终还是会被回收的。
内存泄漏与JavaScript垃圾回收机制有何关联，我们该如何避免？
内存泄漏，简单来说，就是那些本应被垃圾回收机制清理掉的内存，因为某种原因没有被清理，导致内存占用持续增长，最终影响程序性能甚至崩溃。垃圾回收机制的初衷就是防止内存泄漏，但它并非万能，很多时候，内存泄漏是由于我们代码编写不当，制造了“假性可达”而引起的。
我个人在开发中，最常遇到的内存泄漏场景包括：
未清除的定时器（Timers）或事件监听器（Event Listeners）：
如果你设置了一个
setInterval
或
setTimeout
，但没有在合适的时机调用
clearInterval
或
clearTimeout
，那么即使定时器内部引用的对象在逻辑上已经“用不着”了，但只要定时器还在运行，那些被引用的对象就仍然是可达的。同样，给DOM元素添加了事件监听器，但在元素被移除或组件销毁时没有调用
removeEventListener
，那么即使DOM元素从页面上消失了，事件监听器及其闭包捕获的变量仍然会存在，导致内存泄漏。避免方法：务必在组件卸载、页面切换等生命周期结束时，清理掉所有定时器和事件监听器。
意外的全局变量：
在函数内部不使用
var
、
let
或
const
声明变量，直接赋值，例如
foo = "bar"
，这会在全局对象上创建一个属性。全局变量在页面关闭前都不会被回收。避免方法：始终使用
var
、
let
或
const
声明变量，避免污染全局作用域。开启严格模式
'use strict'
也能有效防止这类问题。
闭包（Closures）的不当使用：
闭包本身是JavaScript非常强大的特性，但如果一个闭包捕获了外部作用域中一个非常大的对象，并且这个闭包本身又被长期持有（比如作为某个全局对象的属性，或者作为未清除的事件回调），那么被捕获的大对象就无法被回收。避免方法：审慎使用闭包，尤其是在处理大量数据时。如果闭包只为了访问外部作用域中的一小部分数据，可以考虑将这部分数据作为参数传入，或者在不需要时显式地解除引用。
脱离DOM的引用：
当你从DOM树中移除了一个元素，但你的JavaScript代码中仍然持有对这个元素的引用（比如在一个数组或对象中），那么这个元素及其子元素，以及它们关联的数据，都无法被垃圾回收。避免方法：在移除DOM元素后，及时将JavaScript中对应的引用设置为
null
，解除对它们的强引用。
解决内存泄漏的关键在于理解“可达性”的本质，并养成良好的编程习惯，主动在不再需要时解除引用，而不是盲目依赖垃圾回收器。
JavaScript垃圾回收会影响程序性能吗？我们能优化吗？
答案是肯定的，JavaScript的垃圾回收机制确实会影响程序性能。虽然它在后台默默工作，替我们省去了大量麻烦，但这个“打扫卫生”的过程，有时会占用CPU时间，甚至可能导致程序出现短暂的卡顿，也就是所谓的“暂停”（Pause）或“停顿”（Stop-the-world）。
这是因为在传统的标记-清除过程中，为了确保内存状态的一致性，垃圾回收器在执行时需要暂停JavaScript应用程序的执行。如果堆内存很大，需要回收的垃圾很多，那么这个暂停时间就会变长，用户就会感觉到明显的卡顿。
不过，现代的JavaScript引擎（如V8）已经对垃圾回收进行了大量优化，以最大程度地减少这种影响：
分代回收（Generational Collection）：V8将堆内存分为“新生代”（New Space）和“老生代”（Old Space）。新生代：用于存放生命周期较短的对象。新生代中的对象会频繁地进行小范围的回收，速度很快，因为大部分对象很快就会“死亡”。老生代：用于存放生命周期较长的对象（经过多次新生代回收后仍然存活的对象）。老生代的回收频率较低，但由于对象数量和大小都更大，回收时间相对较长。这种策略基于“弱代假说”：大部分对象生命周期很短，少数对象生命周期很长。增量回收（Incremental Collection）：将垃圾回收任务分解成多个小块，分批执行。在每个小块执行之间，JavaScript应用程序可以继续运行，从而减少了单次暂停的时间，使得用户体验更流畅。并发回收（Concurrent Collection）和并行回收（Parallel Collection）：并发回收：垃圾回收器的一部分工作可以与JavaScript应用程序同时进行，不阻塞主线程。并行回收：垃圾回收器利用多核CPU的优势，同时使用多个线程来执行回收任务，从而缩短回收时间。
我们能做的优化：
尽管引擎已经很智能，但我们作为开发者，仍然可以通过一些策略来帮助垃圾回收器，间接优化程序性能：
减少不必要的对象创建：尤其是在循环或频繁调用的函数中，避免创建大量临时对象。尽可能重用对象，或者使用对象池（虽然这在JS中通常是过度优化）。及时解除引用：当一个对象不再需要时，显式地将其引用设置为
null
。这会帮助垃圾回收器更快地识别出它为垃圾。避免内存泄漏：这是最重要的。如前所述，清理定时器、事件监听器，避免全局变量和不当的闭包使用，是减少垃圾回收压力的关键。注意大型数据结构：如果你的应用程序需要处理大量数据，考虑如何高效地存储和访问它们，避免一次性加载所有数据到内存。使用性能分析工具：Chrome DevTools里的Memory面板，简直是排查这类问题的利器。它能帮助你监控内存使用情况，发现内存泄漏点，甚至记录堆快照，分析哪些对象占据了大部分内存，哪些对象迟迟不被回收。没有它，我们很多时候就像在黑暗中摸索。
总而言之，我们不应该去“对抗”垃圾回收，而是要“配合”它。通过编写更内存友好的代码，我们可以让垃圾回收器的工作更轻松、更高效，从而提升整个应用程序的性能和响应速度。
以上就是什么是JS的垃圾回收机制？的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1518404.html
微信扫一扫 
支付宝扫一扫 
