javascript - JavaScript 闭包中的内存泄漏风险

Question

已解决
关于这个主题，网络上有很多相互矛盾的信息。感谢@John，我设法确定闭包(如下文所用)不是内存泄漏的原因，而且——即使在 IE8 中——它们并不像人们声称的那样普遍。事实上，我的代码中只发生了 1 个泄漏，这证明修复并不难。
从现在开始，我对这个问题的回答将是:
AFAIK，IE8 泄漏的唯一时间是在全局对象上附加事件/处理程序时。 ( window.onload 、 window.onbeforeunload 、...)。要解决这个问题，请参阅下面的答案。

重大更新:
我现在完全迷失了......经过一段时间的文章和新旧文章的挖掘后，我至少留下了一个巨大的矛盾。虽然其中一位 JavaScript Guru (Douglas Crockford) 说:

Since IE is unable to do its job and reclaim the cycles, it falls on us to do it. If we explicitly break the cycles, then IE will be able to reclaim the memory. According to Microsoft, closures are the cause of memory leaks. This is of course deeply wrong, but it leads to Microsoft giving very bad advice to programmers on how to cope with Microsoft's bugs. It turns out that it is easy to break the cycles on the DOM side. It is virtually impossible to break them on the JScript side.

正如@freakish 指出的，我下面的代码片段类似于 jQuery 的内部工作方式，我对我的解决方案感到非常安全，不会导致内存泄漏。同时我找到了 this MSDN page ，其中的部分 Circular References with Closures我特别感兴趣。下图几乎是我的代码如何工作的示意图，不是吗:

唯一的区别是我没有将我的事件监听器附加到元素本身的常识。尽管如此，Douggie 非常明确:闭包不是 IE 中内存泄漏的根源。这种矛盾让我不知道谁是对的。
我还发现泄漏问题在 IE9 中也没有完全解决(找不到链接 ATM)。
最后一件事:我还了解到 IE 在 JScript 引擎之外管理 DOM，这让我在更改 <select> 的 child 时遇到麻烦。元素，基于 ajax 请求:

function changeSeason(e)
{
    var xhr,sendVal,targetID;
    e = e || window.event;//(IE...
    targetID = this.id.replace(/commonSourceFragment/,'commonTargetFragment');//fooHomeSelect -> barHomeSelect
    sendVal = this.options[this.selectedIndex].innerHTML.trim().substring(0,1);
    xhr = prepareAjax(false,(function(t)
    {
        return function()
        {
            reusableCallback.apply(this,[t]);
        }
    })(document.getElementById(targetID)),'/index/ajax');
    xhr({data:{newSelect:sendVal}});
}

function reusableCallback(elem)
{
    if (this.readyState === 4 && this.status === 200)
    {
        var data = JSON.parse(this.responseText);
        elem.innerHTML = '<option>' + data.theArray.join('</option><option>') + '</option>';
    }
}

如果 IE 确实像没有 JScript 引擎一样管理 DOM，那么使用此代码不释放选项元素的几率有多大？我特意添加了这个片段作为示例，因为在这种情况下，我将作为闭包作用域一部分的变量作为参数传递给全局函数。我找不到关于这种做法的任何文档，但根据 Miscrosoft 提供的文档，它应该会打破任何可能发生的循环引用，不是吗？

警告 : 冗长的问题...(抱歉)
我已经编写了几个相当大的 JavaScript 来在我的 Web 应用程序中进行 Ajax 调用。为了避免大量回调和事件，我充分利用了事件委托(delegate)和关闭。现在我写了一个函数，让我想知道可能的内存泄漏。虽然我知道 IE > 8 比它的前辈更好地处理闭包，但公司政策仍然支持 IE 8。
下面我提供了一个例子，说明我在做什么， here你可以找到一个类似的例子，虽然它不使用ajax，但是使用setTimeout，结果几乎相同。 (当然，您可以跳过下面的代码，直接看问题本身)
我想到的代码是这样的:

function prepareAjax(callback,method,url)
{
    method = method || 'POST';
    callback = callback || success;//a default CB, just logs/alerts the response
    url = url || getUrl();//makes default url /currentController/ajax
    var xhr = createXHRObject();//try{}catch etc...
    xhr.open(method,url,true);
    xhr.setRequestMethod('X-Requested-with','XMLHttpRequest');
    xhr.setRequestHeader('Content-type','application/x-www-form-urlencoded');
    xhr.setRequestHeader('Accept','*/*');
    xhr.onreadystatechange = function()
    {
        callback.apply(xhr);
    }
    return function(data)
    {
        //do some checks on data before sending: data.hasOwnProperty('user') etc...
        xhr.send(data);
    }
}

所有非常简单的东西，除了 onreadystatechange打回来。我在直接绑定(bind)处理程序时注意到 IE 的一些问题: xhr.onreadystatechange = callback; ，因此匿名函数。不知道为什么，但我发现这是使其工作的最简单方法。
正如我所说，我使用了很多事件委托(delegate)，因此您可以想象，访问触发 ajax 调用的实际元素/事件可能会很有用。所以我有一些看起来像这样的事件处理程序:

function handleClick(e)
{
    var target,parent,data,i;
    e = e || window.event;
    target = e.target || e.srcElement;
    if (target.tagName.toLowerCase() !== 'input' && target.className !== 'delegateMe')
    {
        return true;
    }
    parent = target;
    while(parent.tagName.toLowerCase() !== 'tr')
    {
        parent = parent.parentNode;
    }
    data = {};
    for(i=0;i<parent.cells;i++)
    {
        data[parent.cells[i].className] = parent.cells[i].innerHTML;
    }
    //data looks something like {name:'Bar',firstName:'Foo',title:'Mr.'}
    i = prepareAjax((function(t)
    {
        return function()
        {
            if (this.readyState === 4 && this.status === 200)
            {
                //check responseText and, if ok:
                t.setAttribute('disabled','disabled');
            }
        }
    })(target));
    i(data);
}

如您所见， onreadystatechange callback 是函数的返回值，提供对 target 的引用。调用回调时的元素。感谢事件委托(delegate)，当我决定从 DOM 中删除它时(我有时会这样做)，我不再需要担心可能绑定(bind)到该元素的事件。
然而，在我看来，回调函数的调用对象对于 IE 的 JScript 引擎及其垃圾收集器来说可能太过分了:

Event ==> handler ==> prepareAjax is a pretty normal call sequence, but the callback argument:

[anon. func (argument t = target) returns anon. F (has access to t which in turn refs back to target)]
   ===> passed to a anon callback function, called using .apply method to the xhr object, in turn a private variable to the prepareAjax function

我已经在 FF 和 chrome 中测试了这种“结构”。它在那里工作得很好，但是这种在关闭后关闭时的调用堆栈，每次传递对 DOM 元素的引用都会在 IE 中成为问题(尤其是 IE9 之前的版本)？

不，我不会使用 jQuery 或其他库。我喜欢纯 JS，并且想尽可能多地了解这种被严重低估的语言。代码片段不是实际的复制粘贴示例，但提供了 IMO，很好地表示了我如何在整个脚本中使用委托(delegate)、闭包和回调。因此，如果某些语法不太正确，请随时纠正它，但这当然不是这个问题的内容。

Answer 1

我曾经在一个非浏览器的 EcmaScript (err.. JScr ... JavaScript) 项目中与 Microsoft 内部的 JavaScript 前程序经理一起工作。我们对关闭进行了一些冗长的讨论。最后，重点是它们更难 GC，并非不可能。我必须阅读 DC 关于关闭导致内存泄漏的 MS 是如何“错误的”的讨论——因为在 IE 的旧实现中，关闭肯定有问题，因为它们很难被垃圾收集 与 MS 实现 .我觉得奇怪的是，一个雅虎人会试图告诉 MS 架构师，他们的代码的一个已知问题在其他地方。尽管我很欣赏他的工作，但我看不出他有什么依据。

请记住，您在上面引用的文章指的是 IE6，因为在撰写本文时 IE7 仍在大力开发中。

顺便说一句——谢天谢地，IE6 已经死了(不要让我挖掘葬礼图片)。尽管如此，不要忘记它的遗产......我还没有看到有人在发布的第一天就它不是世界上最好的浏览器提出可信的论点——问题是他们赢得了浏览器 war .因此，这相当于他们历史上最大的错误之一——他们事后解雇了这支球队，并且该球队停滞了近 5 年。多年来，IE 团队只有 4 或 5 个人在做错误修复，造成了巨大的人才流失并大大落后于曲线。当他们重新雇用团队并意识到他们所处的位置时，他们已经落后了好几年，因为处理一个没有人真正理解的单一代码库的额外工作。这是我作为公司内部人员的观点，但与该团队没有直接关系。

还要记住，IE 从来没有针对闭包进行过优化，因为没有 ProtoypeJS(见鬼，没有 Rails)，而且 jQuery 在 Resig 的脑海中几乎没有闪光。

在撰写本文时，他们还在瞄准具有 256 兆 RAM 的机器，这些机器也没有报废。

在让我读完你的整本书后，我认为给你上这堂历史课是公平的。

最后，我的观点是你引用的 Material 已经过时了。是的，避免在 IE6 中使用闭包，因为它们会导致内存泄漏——但是在 IE6 中什么没有？

归根结底，这是 MS 已经解决并将继续解决的问题。您将进行某种程度的关闭，即使在当时也是如此。

我知道他们围绕 IE8 在这方面做了大量工作(因为我的不起眼的项目使用了非当时的标准 JavaScript 引擎)，并且这项工作一直持续到 IE9/10。 StatCounter (http://gs.statcounter.com/) 表明 IE7 的市场份额从一年前的 6% 下降到 1.5%，并且在开发"new"站点时，IE7 变得越来越不相关。您还可以针对引入 JavaScript 支持的 NetScape 2.0 进行开发，但这只是稍微不那么愚蠢。

真的......不要为了一个不再存在的引擎而试图过度优化。