JavaScript 中的垃圾收集是如何工作的? [英] How does garbage collection work in JavaScript?

问题描述

垃圾收集在 JavaScript 中是如何工作的?它类似于 .NET 垃圾收集吗?是不是因为 VBScript 中垃圾收集的实现很糟糕，人们避免了它并建立了首选 JavaScript 作为他们的标准客户端语言?

解决方案

垃圾收集是如何工作的?

简短的回答是:当一块内存(比如一个对象)不再可达时，它就有资格被回收.何时、如何或是否回收完全取决于实现，不同的实现以不同的方式进行.但在语言层面，它是自动的.

例如:

function foo() {无功吧；bar = new RealMassiveObject();bar.someCall();}

当 foo 返回时，bar 指向的对象自动可用于垃圾回收，因为没有任何东西可以引用它.

对比:

function foo() {无功吧；bar = new RealMassiveObject();bar.someCall();返回栏；}//别处var b = foo();

...现在对对象的引用在调用中仍然存在，并且一直持续到/除非调用者将其他内容分配给 b 或 b 超出范围.

也对比:

function foo() {无功吧；bar = new RealMassiveObject();bar.someCall();设置超时(功能(){alert("已经过了三秒");}, 3000);}

这里，即使在 foo 返回之后，定时器机制也有对定时器回调的引用，以及定时器回调  —闭包 —具有对创建它的上下文的引用，该上下文又包含 bar 变量.因此，理论上，当 foo 返回时，bar 所指的内容不能立即用于垃圾收集.相反，它会一直保留到计时器触发并释放对回调的引用，从而使回调及其引用的上下文符合 GC 条件.(在实践中，现代 JavaScript 引擎可以并且确实会尽可能优化闭包.例如，在上面，静态分析显示回调不引用 bar，并且不包含任何 eval 或 new Function 可能在运行时动态引用它的代码，因此 JavaScript 引擎可以安全地将 bar 排除在函数引用的上下文之外，从而使其所指的内容符合 GC   和现代人所做的).(在这篇文章中有更多关于闭包的信息.)>

JavaScript 处理清理循环引用没有问题，顺便说一句，例如:

function foo() {变量 a, b;a = {};b = {};b.refa = a;a.refb = b;}

当 foo 返回时，a 指的是 b，反之亦然，这不是问题.由于没有其他内容涉及它们中的任何一个，因此它们都可以得到清理.在 IE 上，如果对象之一是主机提供的对象(例如 DOM 元素或通过 new ActiveXObject 创建的东西)而不是 JavaScript 对象，则这不为真.(例如，如果您将 JavaScript 对象引用放在 DOM 元素上，并且 JavaScript 对象引用回 DOM 元素，即使没有人引用它们中的任何一个，它们也会将彼此保留在内存中.)但这是一个 IE bug问题，不是 JavaScript 问题.

回复:

<块引用>

是不是因为 vbscript GC 不好，人们恢复使用 javascript 作为他们的标准客户端 api?

JavaScript 是原始客户端 Web 脚本语言.VBScript 是在微软推出浏览器之后才出现的，并且只在微软浏览器中得到支持.如果您想使用最广泛的浏览器，JavaScript 曾经并且现在是城里唯一的客户端脚本游戏.<subjective>它也是经典 VBScript 语言的八倍左右.;-) </主观的>

How does garbage collection work in JavaScript? Is it similar to .NET garbage collection? And is it because the implementation of garbage collection in VBScript is bad that people avoided it and established a preference for JavaScript as their standard client-side language?

解决方案

How does garbage collection work?

The short answer is: When a block of memory (an object, say) is no longer reachable, it is eligible to be reclaimed. When, how, or whether it is reclaimed is entirely up to the implementation, and different implementations do it differently. But at a language level, it's automatic.

For example:

function foo() {
    var bar;

    bar = new ReallyMassiveObject();
    bar.someCall();
}

When foo returns, the object bar points to is automatically available for garbage collection because there is nothing left that has a reference to it.

Contrast with:

function foo() {
    var bar;

    bar = new ReallyMassiveObject();
    bar.someCall();
    return bar;
}
// elsewhere
var b = foo();

...now a reference to the object survives the call, and persists until/unless the caller assigns something else to b or b goes out of scope.

Also contrast with:

function foo() {
    var bar;

    bar = new ReallyMassiveObject();
    bar.someCall();
    setTimeout(function() {
        alert("Three seconds have passed");
    }, 3000);
}

Here, even after foo returns, the timer mechanism has a reference to the timer callback, and the timer callback — a closure — has a reference to the context where it was created, which in turn contains the bar variable. As a result, in theory, what bar refers to isn't available for garbage collection immediately when foo returns. Instead, it's kept around until the timer fires and releases its reference to the callback, making the callback and the context it refers to eligible for GC. (In practice, modern JavaScript engines can and do optimize closures where they can. For instance, in the above, static analysis shows the callback doesn't refer to bar, and doesn't contain any eval or new Function code that might refer to it dynamically at runtime, so the JavaScript engine can safely leave bar out of the context the function refers to, thus making what it refers to eligible for GC — and modern ones do). (More about closures in this article.)

JavaScript has no problem handling cleaning up circular references, btw, so for instance:

function foo() {
    var a, b;

    a = {};
    b = {};
    b.refa = a;
    a.refb = b;
}

When foo returns, the fact that a is referring to b and vice-versa isn't a problem. Since nothing else refers to either of them, they can both get cleaned up. On IE, this is not true if one of the objects is a host-provided object (such as a DOM element or something created via new ActiveXObject) instead of a JavaScript object. (So for instance, if you put a JavaScript object reference on a DOM element and the JavaScript object refers back to the DOM element, they keep each other in memory even when no one is referencing either of them.) But that's an IE bugissue, not a JavaScript thing.

Re:

is it because the vbscript GC is bad that people reverted to javascript as their standard client side api?

JavaScript was the original client-side web scripting language. VBScript only came later, when Microsoft came out with a browser, and was only ever supported in Microsoft browsers. JavaScript was and is the only client-side scripting game in town if you want to work with the broadest range of browsers. <subjective>It's also about eight times the language classic VBScript ever was. ;-) </subjective>

这篇关于JavaScript 中的垃圾收集是如何工作的?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！