問題描述
我記錄了以下 .
我希望使用最少的內存得到一個包含 500 個 function() {} 的數組.
不幸的是，事實并非如此.每個空函數都持有一個(永遠無法訪問，但不是 GC'ed)一百萬個數字的數組.
Chrome 最終停止并死掉，Firefox 在使用了近 4GB 的 RAM 后完成了整個過程，而 IE 逐漸變慢，直到它顯示內存不足".
刪除任一注釋行可以解決所有問題.
似乎所有這三種瀏覽器(Chrome、Firefox 和 IE)都按上下文而不是按閉包保留環境記錄.Boris 假設這個決定背后的原因是性能，這似乎是可能的，盡管我不確定根據上述實驗可以調用它的性能如何.
如果需要一個引用 some 的閉包(當然我在這里沒有使用它，但想象一下我用過)，如果不是
函數 g() { 一些;}我用
var g = (function(some) { return function() { some; }; )(some);它將通過將閉包移動到與我的其他函數不同的上下文來解決內存問題.
這會讓我的生活更加乏味.
附:出于好奇，我在 Java 中嘗試了這個(利用它在函數內部定義類的能力).GC 就像我最初希望 Javascript 一樣工作.
I've logged the following Chrome bug, which has led to many serious and non-obvious memory leaks in my code:
(These results use Chrome Dev Tools' memory profiler, which runs the GC, and then takes a heap snapshot of everything not garbaged collected.)
In the code below, the someClass instance is garbage collected (good):
var someClass = function() {};
function f() {
var some = new someClass();
return function() {};
}
window.f_ = f();
But it won't be garbage collected in this case (bad):
var someClass = function() {};
function f() {
var some = new someClass();
function unreachable() { some; }
return function() {};
}
window.f_ = f();
And the corresponding screenshot:
It seems that a closure (in this case, function() {}) keeps all objects "alive" if the object is referenced by any other closure in the same context, whether or not if that closure itself is even reachable.
My question is about garbage collection of closure in other browsers (IE 9+ and Firefox). I am quite familiar with webkit's tools, such as the JavaScript heap profiler, but I know little of other browsers' tools, so I haven't been able to test this.
In which of these three cases will IE9+ and Firefox garbage collect the someClass instance?
I tested this in IE9+ and Firefox.
function f() {
var some = [];
while(some.length < 1e6) {
some.push(some.length);
}
function g() { some; } //removing this fixes a massive memory leak
return function() {}; //or removing this
}
var a = [];
var interval = setInterval(function() {
var len = a.push(f());
if(len >= 500) {
clearInterval(interval);
}
}, 10);
Live site here.
I hoped to wind up with an array of 500 function() {}'s, using minimal memory.
Unfortunately, that was not the case. Each empty function holds on to an (forever unreachable, but not GC'ed) array of a million numbers.
Chrome eventually halts and dies, Firefox finishes the whole thing after using nearly 4GB of RAM, and IE grows asymptotically slower until it shows "Out of memory".
Removing either one of the commented lines fixes everything.
It seems that all three of these browsers (Chrome, Firefox, and IE) keep an environment record per context, not per closure. Boris hypothesizes the reason behind this decision is performance, and that seems likely, though I'm not sure how performant it can be called in light of the above experiment.
If a need a closure referencing some (granted I didn't use it here, but imagine I did), if instead of
function g() { some; }
I use
var g = (function(some) { return function() { some; }; )(some);
it will fix the memory problems by moving the closure to a different context than my other function.
This will make my life much more tedious.
P.S. Out of curiousity, I tried this in Java (using its ability to define classes inside of functions). GC works as I had originally hoped for Javascript.
這篇關于JavaScript 閉包是如何被垃圾回收的的文章就介紹到這了，希望我們推薦的答案對大家有所幫助，也希望大家多多支持html5模板網！