在编写代码高亮脚本的时候，问了瓶子一个问题，就是在循环里处理删除DOM元素的时候，会动态改变NodeList的length，所以测试许久， 最后发现是这个问题，狂晕。但是期间谈到了一个关于removeChild的时候在IE下无法回收内存的泄漏问题，他展示了一个EXT里针对IE使用的方 法：
var div=document.getElementById("div"); var first=div.firstChild,next=first; while(next){ var d=document.createElement("div"); d.appendChild(next); d.innerHTML=""; next=div.firstChild; } /////////////////////////////////////////////////// //简单的removeChild方式： var div=document.getElementById("div"); var first=div.firstChild,next=first; while(next){ next.parentNode.removeChild(next); next=div.firstChild; } |
但是经过使用Drip工具（测试IE是否内存泄漏的工具，download），测试还是存在内存泄漏的问题，但是使用IE JS Leaks Detector却啥也检测不出来（全部的测试都检测不出来，就连网上都吹捧的内存泄漏的方式也检测不出来），还有使用了话说是Drip的增强版的sIEve(download)，也测试不出来。既然这样，那就暂且信任Drip吧。下面几种传说中的内存泄漏的方式都是在Drip下测试的。
在开始讲述之前，先大概了解一下javascript的GC机制：
垃圾回收进程尝试推断何时可以安全地回收不再使用的变量，通常是通过判定程序是否能够通过变量之间形成的引用网络到达该变量。当确信变量是不可达的，就在它上面标上可以回收的记号，并且在回收器的下一次清理中（可能在未来的任意时刻)释放相关的内存。
也就是说，垃圾回收机制会定时的检查程序中的对象，查看它是否跟别的对象之间已经完全断开了引用链而“孤单一人”，这时，垃圾回收机制就会回收这个 对象的内存，否则，将不会回收。所以说，对象在使用完了之后，就应该被回收内存，而不是一直占用着内存不放，导致浏览器的内存使用量节节飙升。
第一种：既然上面谈到了关于removeChild，那就从它开始吧，通过Drip测试，简单的使用 removeChild删除子节点的方式确实存在内存泄漏，但是使用了上面EXT使用的方式，也还是存在。经过一番搜索，有文章说需要清除节点的全部属性 来实现内存的正确回收，那就进行了下面的测试。结果通过将节点的属性都delete掉之后，Drip显示没有内存泄漏了。
var div=document.getElementById("div"); var first=div.firstChild,next=first; while(next){ div.removeChild(next); for(var k in next){ delete next[k]; } next=div.firstChild; } |
