JavaScript 垃圾回收机制深度解析：标记清除、引用计数与内存管理

JavaScript垃圾回收机制概述

在技术团队中，资深工程师常会讨论内存泄漏等底层问题，这往往令人印象深刻。近期我将工作重心转向Web开发，通过研读《JavaScript高级程序设计》——一本由浅入深、质量极高的经典著作——系统学习了JavaScript的垃圾回收机制，从而对内存泄漏有了更为清晰的认识。

与C#和Java类似，JavaScript具备自动垃圾回收机制。执行环境会自动管理代码执行期间使用的内存，开发者无需手动处理内存分配或无用内存的回收。其核心逻辑是识别并释放不再使用的变量所占用的内存。由于该过程开销较大，垃圾回收器并非实时运行，而是以固定的时间间隔周期性执行。

变量生命周期与垃圾回收基础

变量生命周期

读者可能会问，何为“不再使用的变量”？这指的是生命周期结束的变量，通常仅涉及局部变量。全局变量的生命周期直至浏览器卸载页面才会终止。局部变量仅在函数执行期间存在，系统会在栈或堆上为其分配空间以存储值。当函数执行结束时，局部变量便不再需要。需要注意的是，在闭包场景下，由于内部函数引用了外部函数的变量，外部函数实际上并未真正结束（关于闭包与作用域链的深入理解，可参考相关JavaScript作用域文章）。

函数结束后释放局部变量看似简单，但实际开销巨大，这仅是垃圾回收机制的冰山一角。以闭包为例，函数虽已结束，但变量仍被引用。垃圾回收器必须区分哪些变量仍在使用、哪些已无用，并对无用变量打上标记以便后续回收。常见的标记策略主要有两种。

标记清除算法详解

标记清除（mark and sweep）

这是JavaScript中最常见的垃圾回收方式。当变量进入执行环境（如在函数中声明变量）时，垃圾回收器将其标记为“进入环境”；当变量离开环境（函数执行结束）时，则标记为“离开环境”。具体的标记方式（如特殊位反转或维护列表）并不关键，核心在于策略：原则上，进入环境的变量所占内存不能被释放，因为它们随时可能被调用。

垃圾回收器在运行时会给内存中所有变量加上标记，随后移除环境中的变量以及被这些变量引用的变量（包括闭包）。完成后，仍保留标记的变量即为待删除对象，因为环境中的变量已无法访问它们。最后，垃圾回收器会清除这些带有标记的变量及其占用的空间。

大多数浏览器均采用此方式进行垃圾回收，区别仅在于标记方式和回收间隔。值得注意的是，低版本的Internet Explorer（IE）浏览器并未采用此策略，这再次印证了IE在早期标准兼容性和性能优化上的不足。

引用计数算法与循环引用问题

引用计数(reference counting)

低版本IE中频繁出现的内存泄漏问题，很大程度上归因于其采用的引用计数垃圾回收机制。该策略通过跟踪记录每个值被引用的次数来工作：当声明一个变量并将引用类型赋值给它时，该值的引用次数加1；若该变量的值被另一个引用取代，则原值的引用次数减1。当引用次数变为0时，说明没有变量再使用它，该值无法被访问，其占用的空间即可被回收。垃圾回收器会在运行过程中清理引用次数为0的值所占空间。

这种策略看似合理，但为何鲜有浏览器采用且易导致内存泄漏？主要原因在于它无法解决循环引用问题。例如，对象A有一个属性指向对象B，而对象B也有一个属性指向对象A，形成相互引用。

function test(){
var a={};
var b={};
a.prop=b;
b.prop=a;
        }

在此示例中，a和b的引用次数均为2。即使在test()执行完成后，两个对象已离开作用域，在标记清除策略下这并非问题，因为离开环境的变量会被清除。但在引用计数策略下，由于两个对象的引用次数仍为2，不会归零，因此其占用空间不会被清理。若该函数被多次调用，未回收的空间将不断累积，最终导致内存泄漏。

在IE浏览器中，虽然JavaScript对象通过标记清除方式进行垃圾回收，但BOM（浏览器对象模型）与DOM（文档对象模型）对象却是通过引用计数回收垃圾的。这意味着只要涉及BOM及DOM操作，就可能出现循环引用问题。上述例子看似荒谬，但在实际开发中并不少见。

window.onload=function outerFunction(){
var obj = document.getElementById("element");
obj.onclick=function innerFunction(){};
    };

这段代码表面看似无误，但存在隐蔽的循环引用：obj引用了document.getElementById("element")返回的元素，而该元素的onclick方法又引用了外部环境的变量，自然包括obj。这种引用关系非常隐蔽。

解决循环引用的方法

解决办法

最简单的解决方式是手动解除循环引用。例如，针对上述函数，可以修改如下：

window.onload=function outerFunction(){
var obj = document.getElementById("element");
obj.onclick=function innerFunction(){};
obj=null;
    };

垃圾回收触发机制的演进

什么时候触发垃圾回收

垃圾回收器周期性运行，若分配的内存非常多，回收工作将非常艰巨。确定垃圾回收的时间间隔是一个值得深思的问题。IE6的垃圾回收基于内存分配量触发：当环境中存在256个变量、4096个对象或64k的字符串中任意一种情况时，垃圾回收器即开始工作。这种按需触发的机制看似科学，避免了固定时间调用的不必要的开销。然而，如果环境中一直存在大量变量（在现代复杂脚本中很常见），垃圾回收器将持续工作，导致浏览器性能严重下降。

微软在IE7中对此进行了调整，触发条件变为动态修改。初始值与IE6相同；如果垃圾回收器回收的内存量低于程序占用内存的15%，说明大部分内存不可被回收，触发条件过于敏感，此时将触发条件翻倍；如果回收的内存高于85%，说明大部分内存早该清理，此时将触发条件重置。这种动态调整使垃圾回收工作更加智能。

与C#和Java类似，我们可以手动调用垃圾回收程序。但由于其消耗大量资源，且手动调用的准确性未必优于浏览器自身的判断，因此不推荐手动调用垃圾回收。