理解并解决IE的内存泄漏方式

用和闭包的引用存在于同一个对象域中，于是我们可以借助它来释放事件引用，从而完成引用移除。为了简单起见我们将闭包的引用暂存在一个expando属性中，下面的示例将向你演示释放事件引用和清除expando属性。＜html＞＜head＞＜script language="JScript"＞function AttachEvents(element){　// In order to remove this we need to put　// it somewhere. Creates another ref　element.expandoClick = ClickEventHandler;　// This structure causes element to ref ClickEventHandler　element.attachEvent("onclick", element.expandoClick);　function ClickEventHandler()　{　　// This closure refs element　}}function SetupLeak(){　// The leak happens all at once　AttachEvents(document.getElementById("LeakedDiv"));}function BreakLeak(){　document.getElementById("LeakedDiv").detachEvent("onclick",　document.getElementById("LeakedDiv").expandoClick);　document.getElementById("LeakedDiv").expandoClick = null;}＜/script＞＜/head＞＜body onload="SetupLeak()" onunload="BreakLeak()"＞＜div id="LeakedDiv"＞＜/div＞＜/body＞＜/html＞　　在这篇文章中，实际上建议我们除非迫不得已尽量不要创建使用闭包。文章中的示例，给我们演示了非闭包的事件引用方式，即把闭包函数放到页面的全局作用域中。当闭包函数成为普通函数后，它将不再继承其父函数的参数和局部变量，所以我们也就不用担心基于闭包的循环引用了。在非必要的时候不使用闭包这样的编程方式可以尽量使我们的代码避免这样的问题。　　最后，脚本引擎开发组的Eric Lippert，给我们带来了一篇关于闭包使用通俗易懂的好文章。他的最终建议也是希望在真正必要的时候才使用闭包函数。虽然他的文章没有提及闭包会使用的真正场景，但是这儿已有的大量示例非常有助于大家起步。 　　不得不说Eric Lippert同志疾呼的：Don''t use closures unless you really need closure semantics. In most cases, non-nested functions are the right way to go. 是非常消极的应付之辞。今天关于IE内存泄漏的文章已有很多，而且很大部分就是微软的自己人在解释，甚至象Eric Lippert这样引擎开发组的成员。但是他们的文章始终没有正面承认其实这就是IE的bug，而且是非常严重的bug，这事情其实完全不关脚本引擎对象和DOM对象的事。就是微软对产品不负责任的表现，不说IE4，1997那个春天那是太遥远了点，但是IE6也是2001年随xp发布的。使用COM可以给他们的开发带来很多便利，当然也利用很多现成的东西，可是居然在带来这样的严重问题后，他们却把大部分责任归咎于不合理和不正确的使用Closures技术！对于循环引用产生Memory Leak我根本就是不好意思提了，那样的问题是应该发生的吗？那就让我们拭目以待看IE7怎么解决这堆shit问题吧，当然我希望不要再看到类似：Do not use closures unless they are necessary. 这样的扯淡建议！