在IE下的JS编程中，以下的编程方式都会造成即使关闭IE也无法释放内存的问题，下面分类给出：

var MyObject = {}; document.getElementById('myDiv').myProp = MyObject;

解决方法：

在window.onunload事件中写上: document.getElementById('myDiv').myProp = null;

2、DOM对象与JS对象相互引用。范例：

function Encapsulator(element) {         this.elementReference = element;         element.myProp = this; } new Encapsulator(document.getElementById('myDiv'));

解决方法：

在onunload事件中写上: document.getElementById('myDiv').myProp = null;

3、给DOM对象用attachEvent绑定事件。范例：

function doClick() {} element.attachEvent("onclick", doClick);

解决方法：

在onunload事件中写上: element.detachEvent('onclick', doClick);

4、从外到内执行appendChild。这时即使调用removeChild也无法释放。范例：

var parentDiv = document.createElement("div"); var childDiv = document.createElement("div"); document.body.appendChild(parentDiv); parentDiv.appendChild(childDiv); 解决方法： 从内到外执行appendChild: var parentDiv = document.createElement("div"); var childDiv = document.createElement("div"); parentDiv.appendChild(childDiv); document.body.appendChild(parentDiv);

5、反复重写同一个属性会造成内存大量占用(但关闭IE后内存会被释放)。范例：

for(i = 0; i < 5000; i++) {         hostElement.text = "asdfasdfasdf"; }

这种方式相当于定义了5000个属性！
解决方法：
其实没什么解决方法:P~就是编程的时候尽量避免出现这种情况咯
说明：
1、以上资料均来源于微软官方的MSDN站点，链接地址：
http://msdn.microsoft.com/librar … e_leak_patterns.asp
大家可以到上面这个地址中看到详细的说明，包括范例和图例都有。只是我英文不太好，看不太懂，如果我上述有失误或有需要补充的地方请大家指出。

2、对于第一条，事实上包括 element.onclick = funcRef 这种写法也算在其中，因为这也是一个对对象的引用。在页面onunload时应该释放掉。

3、对于第三条，在MSDN的英文说明中好像是说即使调用detachEvent也无法释放内存，因为在attachEvent的时候就已经造成内存“LEAK”了，不过detachEvent后情况还是会好一点。不知道是不是这样，请英文好的亲能够指出。

4、在实际编程中，这些内存问题的实际影响并不大，尤其是给客户使用时，客户对此绝不会有察觉，然而这些问题对于程序员来说却始终是个心病 — 有这样的BUG心里总会觉得不舒服吧？能解决则给与解决，这样是最好的。事实上我在webfx.eae.net这样顶级的JS源码站点中，在它们的源码里都会看到采用上述解决方式进行内存的释放管理。

理解并解决IE的内存泄漏方式
Web开发的发展

在过去一些的时候，Web开发人员并没有太多的去关注内存泄露问题。那时的页面间联系大都比较简单，并主要使用不同的连接地址在同一

个站点中导航，这样的设计方式是非常有利于浏览器释放资源的。即使Web页面运行中真的出现了资源泄漏，那它的影响也是非常有限而且常常

是不会被人在意的。

今天人们对Web应用有了高更的要求。一个页面很可能数小时不会发生URL跳转，并同时通过Web服务动态的更新页面内容。复杂的事件关联

设计、基于对象的JScript和DHTML技术的广泛采用，使得代码的能力达到了其承受的极限。在这样的情况和改变下，弄清楚内存泄露方式变得

非常的急迫，特别是过去这些问题都被传统的页面导航方法给屏蔽了。

还算好的事情是，当你明确了希望寻找什么时，内存泄露方式是比较容易被确定的。大多数你能遇到的泄露问题我们都已经知道，你只需

要少量额外的工作就会给你带来好处。虽然在一些页面中少量的小泄漏问题仍会发生，但是主要的问题还是很容易解决的。

在IE下的JS编程中，以下的编程方式都会造成即使关闭IE也无法释放内存的问题，下面分类给出：

var MyObject = {}; document.getElementById('myDiv').myProp = MyObject;

解决方法：

在window.onunload事件中写上: document.getElementById('myDiv').myProp = null;

2、DOM对象与JS对象相互引用。范例：

function Encapsulator(element) {         this.elementReference = element;         element.myProp = this; } new Encapsulator(document.getElementById('myDiv'));

解决方法：

在onunload事件中写上: document.getElementById('myDiv').myProp = null;

3、给DOM对象用attachEvent绑定事件。范例：

function doClick() {} element.attachEvent("onclick", doClick);

解决方法：

在onunload事件中写上: element.detachEvent('onclick', doClick);

4、从外到内执行appendChild。这时即使调用removeChild也无法释放。范例：

var parentDiv = document.createElement("div"); var childDiv = document.createElement("div"); document.body.appendChild(parentDiv); parentDiv.appendChild(childDiv); 解决方法： 从内到外执行appendChild: var parentDiv = document.createElement("div"); var childDiv = document.createElement("div"); parentDiv.appendChild(childDiv); document.body.appendChild(parentDiv);

5、反复重写同一个属性会造成内存大量占用(但关闭IE后内存会被释放)。范例：

for(i = 0; i < 5000; i++) {         hostElement.text = "asdfasdfasdf"; }

这种方式相当于定义了5000个属性！
解决方法：
其实没什么解决方法:P~就是编程的时候尽量避免出现这种情况咯
说明：
1、以上资料均来源于微软官方的MSDN站点，链接地址：
http://msdn.microsoft.com/librar … e_leak_patterns.asp
大家可以到上面这个地址中看到详细的说明，包括范例和图例都有。只是我英文不太好，看不太懂，如果我上述有失误或有需要补充的地方请大家指出。

2、对于第一条，事实上包括 element.onclick = funcRef 这种写法也算在其中，因为这也是一个对对象的引用。在页面onunload时应该释放掉。

3、对于第三条，在MSDN的英文说明中好像是说即使调用detachEvent也无法释放内存，因为在attachEvent的时候就已经造成内存“LEAK”了，不过detachEvent后情况还是会好一点。不知道是不是这样，请英文好的亲能够指出。

4、在实际编程中，这些内存问题的实际影响并不大，尤其是给客户使用时，客户对此绝不会有察觉，然而这些问题对于程序员来说却始终是个心病 — 有这样的BUG心里总会觉得不舒服吧？能解决则给与解决，这样是最好的。事实上我在webfx.eae.net这样顶级的JS源码站点中，在它们的源码里都会看到采用上述解决方式进行内存的释放管理。

理解并解决IE的内存泄漏方式
Web开发的发展

在过去一些的时候，Web开发人员并没有太多的去关注内存泄露问题。那时的页面间联系大都比较简单，并主要使用不同的连接地址在同一

个站点中导航，这样的设计方式是非常有利于浏览器释放资源的。即使Web页面运行中真的出现了资源泄漏，那它的影响也是非常有限而且常常

是不会被人在意的。

今天人们对Web应用有了高更的要求。一个页面很可能数小时不会发生URL跳转，并同时通过Web服务动态的更新页面内容。复杂的事件关联

设计、基于对象的JScript和DHTML技术的广泛采用，使得代码的能力达到了其承受的极限。在这样的情况和改变下，弄清楚内存泄露方式变得

非常的急迫，特别是过去这些问题都被传统的页面导航方法给屏蔽了。

还算好的事情是，当你明确了希望寻找什么时，内存泄露方式是比较容易被确定的。大多数你能遇到的泄露问题我们都已经知道，你只需

要少量额外的工作就会给你带来好处。虽然在一些页面中少量的小泄漏问题仍会发生，但是主要的问题还是很容易解决的。