js晉級篇——前端內存泄漏探討

1.IE7/8 DOM對象或者ActiveX對象循環引用致使內存泄漏

　　循環引用分爲兩種：javascript

　　第一種：多個對象循環引用html

var a=new Object; var b=new Object; a.r=b; b.r=a;

　　第二種：循環引用本身java

var a=new Object; a.r=a;

　　對於ECMAScript 對象而言，只要沒有其餘對象引用對象 a、b，也就是說它們只是相互之間的引用，那麼仍然會被垃圾收集系統識別並處理。瀏覽器

　　可是，在 IE七、IE8 中，若是循環引用中的任何對象是 DOM 節點或者 ActiveX 對象，好比var a = document.getElementById("#a")，垃圾收集系統則不會發現它們之間的循環關係,由於IE的DOM回收機制和JS回收機制不是同一個。js回收機制分兩種：標記清除和引用計數，引用計數對循環引用的垃圾回收會出現內存泄漏，而IE的DOM回收機制即是採用引用計數的。IE9+並不存在循環引用致使Dom內存泄露問題，多是微軟作了優化，或者Dom的回收方式已經改變。緩存

下面摘自小蘋果的跟我學習javascript的垃圾回收機制與內存管理閉包

2、標記清除 js中最經常使用的垃圾回收方式就是標記清除。當變量進入環境時，例如，在函數中聲明一個變量，就將這個變量標記爲「進入環境」。從邏輯上講，永遠不能釋放進入環境的變量所佔用的內存，由於只要執行流進入相應的環境，就可能會用到它們。而當變量離開環境時，則將其標記爲「離開環境」。
function test(){ var a = 10 ; //被標記 ，進入環境 
 var b = 20 ; //被標記 ，進入環境
} test(); //執行完畢 以後 a、b又被標離開環境，被回收。
　　垃圾回收器在運行的時候會給存儲在內存中的全部變量都加上標記（固然，可使用任何標記方式）。而後，它會去掉環境中的變量以及被環境中的變量引用的變量的標記（閉包）。而在此以後再被加上標記的變量將被視爲準備刪除的變量，緣由是環境中的變量已經沒法訪問到這些變量了。最後，垃圾回收器完成內存清除工做，銷燬那些帶標記的值並回收它們所佔用的內存空間。 　　到目前爲止，IE、Firefox、Opera、Chrome、Safari的js實現使用的都是標記清除的垃圾回收策略或相似的策略，只不過垃圾收集的時間間隔互不相同。
 3、引用計數 　　引用計數的含義是跟蹤記錄每一個值被引用的次數。當聲明瞭一個變量並將一個引用類型值賦給該變量時，則這個值的引用次數就是1。若是同一個值又被賦給另外一個變量，則該值的引用次數加1。相反，若是包含對這個值引用的變量又取得了另一個值，則這個值的引用次數減1。當這個值的引用次數變成0時，則說明沒有辦法再訪問這個值了，於是就能夠將其佔用的內存空間回收回來。這樣，當垃圾回收器下次再運行時，它就會釋放那些引用次數爲0的值所佔用的內存。
function test(){ var a = {} ; //a的引用次數爲0 
 var b = a ; //a的引用次數加1，爲1 
 var c =a; //a的引用次數再加1，爲2
 var b ={}; //a的引用次數減1，爲1
} 　　Netscape Navigator3是最先使用引用計數策略的瀏覽器，但很快它就遇到一個嚴重的問題：循環引用。循環引用指的是對象A中包含一個指向對象B的指針，而對象B中也包含一個指向對象A的引用。 function fn() { var a = {}; var b = {}; a.pro = b; b.pro = a; } fn(); 　　以上代碼a和b的引用次數都是2，fn()執行完畢後，兩個對象都已經離開環境，在標記清除方式下是沒有問題的，可是在引用計數策略下，由於a和b的引用次數不爲0，因此不會被垃圾回收器回收內存，若是fn函數被大量調用，就會形成內存泄露。在IE7與IE8上，內存直線上升。 　　咱們知道，IE中有一部分對象並非原生js對象。例如，其內存泄露DOM和BOM中的對象就是使用C++以COM對象的形式實現的，而COM對象的垃圾回收機制採用的就是引用計數策略。所以，即便IE的js引擎採用標記清除策略來實現，但js訪問的COM對象依然是基於引用計數策略的。換句話說，只要在IE中涉及COM對象，就會存在循環引用的問題。
var element = document.getElementById("some_element"); var myObject = new Object(); myObject.e = element; element.o = myObject; 　　這個例子在一個DOM元素（element)與一個原生js對象（myObject)之間建立了循環引用。其中，變量myObject有一個名爲element的屬性指向element對象；而變量element也有一個屬性名爲o回指myObject。因爲存在這個循環引用，即便例子中的DOM從頁面中移除，它也永遠不會被回收。 　　看上面的例子，有同窗回以爲太弱了，誰會作這樣無聊的事情，其實咱們是否是就在作 window.onload=function outerFunction(){ var obj = document.getElementById("element"); obj.onclick=function innerFunction(){}; }; 　　這段代碼看起來沒什麼問題，可是obj引用了document.getElementById(「element」)，而document.getElementById(「element」)的onclick方法會引用外部環境中的變量，天然也包括obj，是否是很隱蔽啊。 　　解決辦法 　　最簡單的方式就是本身手工解除循環引用，好比剛纔的函數能夠這樣 myObject.element = null; element.o = null;  window.onload=function outerFunction(){ var obj = document.getElementById("element"); obj.onclick=function innerFunction(){}; obj=null; }; 　　將變量設置爲null意味着切斷變量與它此前引用的值之間的鏈接。當垃圾回收器下次運行時，就會刪除這些值並回收它們佔用的內存。 　　要注意的是，IE9+並不存在循環引用致使Dom內存泄露問題，多是微軟作了優化，或者Dom的回收方式已經改變

　　在上面描述的循環引用例子函數

window.onload=function outerFunction(){ var obj = document.getElementById("element"); obj.onclick=function innerFunction(){}; };

　　還能夠理解成閉包循環引用致使的內存泄漏。怎麼理解？工具

　　首先obj是外部的一個對象， obj.onclick定義的這個函數隱式的調用到了obj這個對象（obj.onclick函數中的this就是對象obj）。而後咱們須要知道obj.onclick其實是一個outerFunction外部的函數，爲何？DOM監聽事件不多是局部做用域的，是全局做用域的，明白了吧。因此DOM觸發這個事件至關因而在函數outerFunction外部調用了obj.click()，而事件內部使用了outerFunction的變量obj,這就造成了一個閉包。IE7/IE8 DOM的引用計數永遠沒法回收這個DOM對象。不管如何，這都是DOM循環引用致使的內存泄漏，普通閉包是不會致使內存泄漏的。學習

　　改爲以下結構優化

window.onload=function outerFunction(){ var obj = document.getElementById("element"); $(obj).click(function innerFunction(){}); };

　　jQuery綁定事件最終都沒有直接綁定到DOM對象上，而是使用jQuery緩存來綁定的。詳見jQuery事件體系結構

　　即便此時仍然會建立一個閉包，而且也會致使同前面同樣的循環，但這裏的代碼卻不會使 IE 發生內存泄漏。因爲jQuery考慮到了內存泄漏的潛在危害，因此它會手動釋放本身指定的全部事件處理程序（jQuery源代碼$.fn.remove函數中有對節點的緩存釋放的處理）。只要堅持使用jQuery的事件綁定方法，就無需爲這種特定的常見緣由致使的內存泄漏而擔憂。

　　可是，這並不意味着咱們徹底脫離了險境。當對DOM元素進行其餘操做時，仍然要到處留心。只要是將JavaScript對象指定給DOM元素，就可能在舊版本IE中致使內存泄漏。jQuery只是有助於減小發生這種狀況的可能性。

　　有鑑於此，jQuery爲咱們提供了另外一個避免這種泄漏的工具。用.data()方法，將信息附加到DOM元素。因爲這裏的數據並不是直接保存在擴展屬性中（jQuery使用一個內部對象並經過它建立的ID來保存這裏所說的數據），所以永遠也不會構成引用循環，從而有效迴避了內存泄漏問題。這種方式也就是jQuery事件綁定使用的方式。

2.基礎的DOM泄漏

當原有的DOM被移除時，子結點引用沒有被移除則沒法回收。

var select = document.querySelector; var treeRef = select('#tree'); var leafRef = select('#leaf');   //在COM樹中leafRef是treeFre的一個子結點
 select('body').removeChild(treeRef);//#tree不能被回收入，由於treeRef還在

　　解決方法:

treeRef = null;//tree還不能被回收，由於葉子結果leafRef還在
leafRef = null;//如今#tree能夠被釋放了

DOM 插入順序致使內存泄漏

　　當動態建立的2 個不一樣範圍的 DOM 對象附加到一塊兒的時候，一個臨時的對象會被建立。這個 DOM 對象改變範圍到 document 時，那個臨時對象就沒用了，這個臨時對象沒有被回收將致使內存泄漏。若是咱們一一將這兩個DOM添加到原有的DOM 對象上就不會產生中間臨時對象。詳見理解和解決IE內存泄漏的頁面交叉泄露 Cross-Page Leaks。

3.timer定時器泄漏


var val = 0; for (var i = 0; i < 90000; i++) { var buggyObject = { callAgain: function() { var ref = this; val = setTimeout(function() { ref.callAgain(); }, 90000); } } buggyObject.callAgain();

　　這個時候你沒法回收buggyObject

//雖然你想回收可是timer還在
buggyObject = null;

　　解決辦法，先中止timer而後再回收

//解決方法，先中止定時器
clearTimeout(val); buggyObject = null;

推薦內存泄漏文章：

理解和解決IE內存泄漏（中文翻譯）：http://www.tuicool.com/articles/2AZ3y2

理解和解決IE內存泄漏（英文原版）：https://msdn.microsoft.com/en-us/library/bb250448.aspx

js內存泄露的幾種狀況：http://blog.csdn.net/li2274221/article/details/25217297

　　若是以爲本文不錯，請點擊右下方【推薦】！