IE内存泄露与无法回收研究小结

Posted 2020-07-13 有梦就能实现

IE内存泄露与无法回收研究小结

一、内存泄露 
   之前确实看了很多资料，但这位大哥的话可谓画龙点睛，不是奉承他，一下子就打通了我的任督二脉，请看： 

trarck 写道

   IE下的内存泄露原因就是循环引用，IE的垃圾回收器不能很好处理这种引用。 
会产生泄露的循环引用，只有孤立的DOM对象(脱离DOM树)。 
孤立的DOM对象间的循环引用，孤立的DOM对象与JS对象的循环引用。 
为什么是孤立的DOM对象呢？在离开页面时（刷新，跳转）会删除整个DOM树，在DOM树上的对象也会被删除，就算有循环引用，此时被打断。 
孤立的DOM对象有：一、用JS创建但未加入DOM树。二、从DOM树中删除的。 
所以避免泄露，就尽量不要让这样的DOM对象产生。 
有时候这样对象又不可避免，那就不要让这样对像产生循环引用。 
最常见的循环引用是由闭包产生，其执行环境中的变量(包括参数)引用了DOM对象。 

   看完了这段话，只会战战兢兢模仿示例的我立即就自创了一个新的例子。 
示例1： 

1. <input type="button" value="leak" id="leak" onclick="location.reload();"/>  
2.   
3. <script type="text/javascript"><!--  
4. (function(){  
5.         var test=$(\'<div />\')[0];  
6.         test.onclick=function(){};  
7.         var s=[];  
8.         for(var i=0;i<10000;i++){  
9.             s.push(\'aaaa\');  
10.         }  
11.         test.expan=s.join(\'\');   
12.         //$(\'body\').append(test);  
13.         //孤立的DOM元素才会泄露  
14. })();         
15. //--></script>  

特殊情况：iframe 
测试工具为：sIEve-0.0.8 
在iframe中刷新页面，页面中有很多泄露，每刷一次增加一倍；但最后刷新其父页面时所有的泄露都消失了。 
而将iframe提出来单独测试（刷新），没有泄露。 

二、内存回收 
1、清除全局引用。道理很简单，只要全局引用存在浏览器不能释放对应的对象，因为在引用的生命周期内，对象随时可能被调用。 

1. <input type="button" value="TO GC" onclick="toGC()" />  
2. <script type="text/javascript"><!--  
3. function toGC(){  
4.     g.s=null;  
5. }  
6.   
7. var g={};  
8. g.s=[];  
9. for ( var i=0;i<100;i++){  
10.     g.s.push($(\'<div  />\')[0]);  
11. }  
12. //--></script>  

如果不点击TO GC按钮，所创建的div永远都不会释放，直至页面unload。 
2、各浏览器不同的内存释放机制 
   一个正常（无泄漏）的页面，当它unload（比如href指向about:blank）时，在不同的浏览器中内存释放情况并不相同。做了测试，使用某著名电子商务网站作测试对象。 
   IE7:不会出现显著释放，即使等1个小时也一样，内存依然很高；最小化窗口才会释放到几M的水准。 
   FireFox3:无论如何都不释放，目前还没找到方法(当然，关闭窗口除外)。 
   Chrome6:立即释放。