JavaScirpt 的垃圾(garbage collection)回收機制

1、垃圾回收機制—GCjavascript

Javascript具備自動垃圾回收機制(GC:Garbage Collecation),也就是說,執行環境會負責管理代碼執行過程當中使用的內存。java

原理:垃圾收集器會按期(週期性)找出那些不在繼續使用的變量,而後釋放其內存。瀏覽器

JavaScript垃圾回收的機制很簡單:找出再也不使用的變量,而後釋放掉其佔用的內存,可是這個過程不是實時的,由於其開銷比較大,因此垃圾回收器會按照固定的時間間隔週期性的執行安全

再也不使用的變量也就是生命週期結束的變量,固然只多是局部變量,全局變量的生命週期直至瀏覽器卸載頁面纔會結束。局部變量只在函數的執行過程當中存在,而在這個過程當中會爲局部變量在棧或堆上分配相應的空間,以存儲它們的值,而後在函數中使用這些變量,直至函數結束,而閉包中因爲內部函數的緣由,外部函數並不能算是結束。閉包

仍是上代碼說明吧:函數

?
1
2
3
4
5
6
7
8
9
10
11
function fn1() {
  var obj = {name: 'hanzichi' , age: 10};
}
 
function fn2() {
  var obj = {name: 'hanzichi' , age: 10};
  return obj;
}
 
var a = fn1();
var b = fn2();

咱們來看代碼是如何執行的。首先定義了兩個function,分別叫作fn1和fn2,當fn1被調用時,進入fn1的環境,會開闢一塊內存存放對象{name: 'hanzichi', age: 10},而當調用結束後,出了fn1的環境,那麼該塊內存會被js引擎中的垃圾回收器自動釋放;在fn2被調用的過程當中,返回的對象被全局變量b所指向,因此該塊內存並不會被釋放。優化

這裏問題就出現了:到底哪一個變量是沒有用的?因此垃圾收集器必須跟蹤到底哪一個變量沒用,對於再也不有用的變量打上標記,以備未來收回其內存。用於標記的無用變量的策略可能因實現而有所區別,一般狀況下有兩種實現方式:標記清除和引用計數。引用計數不太經常使用,標記清除較爲經常使用。動畫

2、標記清除spa

js中最經常使用的垃圾回收方式就是標記清除。當變量進入環境時,例如,在函數中聲明一個變量,就將這個變量標記爲「進入環境」。從邏輯上講,永遠不能釋放進入環境的變量所佔用的內存,由於只要執行流進入相應的環境,就可能會用到它們。而當變量離開環境時,則將其標記爲「離開環境」。.net

?
1
2
3
4
5
function test(){
  var a = 10 ; //被標記 ,進入環境
  var b = 20 ; //被標記 ,進入環境
}
test(); //執行完畢 以後 a、b又被標離開環境,被回收。

  垃圾回收器在運行的時候會給存儲在內存中的全部變量都加上標記(固然,可使用任何標記方式)。而後,它會去掉環境中的變量以及被環境中的變量引用的變量的標記(閉包)。而在此以後再被加上標記的變量將被視爲準備刪除的變量,緣由是環境中的變量已經沒法訪問到這些變量了。最後,垃圾回收器完成內存清除工做,銷燬那些帶標記的值並回收它們所佔用的內存空間。

  到目前爲止,IE、Firefox、Opera、Chrome、Safari的js實現使用的都是標記清除的垃圾回收策略或相似的策略,只不過垃圾收集的時間間隔互不相同。

3、引用計數

  引用計數的含義是跟蹤記錄每一個值被引用的次數。當聲明瞭一個變量並將一個引用類型值賦給該變量時,則這個值的引用次數就是1。若是同一個值又被賦給另外一個變量,則該值的引用次數加1。相反,若是包含對這個值引用的變量又取得了另一個值,則這個值的引用次數減1。當這個值的引用次數變成0時,則說明沒有辦法再訪問這個值了,於是就能夠將其佔用的內存空間回收回來。這樣,當垃圾回收器下次再運行時,它就會釋放那些引用次數爲0的值所佔用的內存。

?
1
2
3
4
5
6
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的引用。

 

?
1
2
3
4
5
6
7
8
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對象,就會存在循環引用的問題。

?
1
2
3
4
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從頁面中移除,它也永遠不會被回收。

看上面的例子,有同窗回以爲太弱了,誰會作這樣無聊的事情,其實咱們是否是就在作

?
1
2
3
4
window.onload= function outerFunction(){
  var obj = document.getElementById( "element" );
  obj.onclick= function innerFunction(){};
};

這段代碼看起來沒什麼問題,可是obj引用了document.getElementById(「element」),而document.getElementById(「element」)的onclick方法會引用外部環境中德變量,天然也包括obj,是否是很隱蔽啊。

解決辦法

最簡單的方式就是本身手工解除循環引用,好比剛纔的函數能夠這樣

?
1
2
myObject.element = null ;
element.o = null ;

 

?
1
2
3
4
5
window.onload= function outerFunction(){
  var obj = document.getElementById( "element" );
  obj.onclick= function innerFunction(){};
  obj= null ;
};

將變量設置爲null意味着切斷變量與它此前引用的值之間的鏈接。當垃圾回收器下次運行時,就會刪除這些值並回收它們佔用的內存。

要注意的是,IE9+並不存在循環引用致使Dom內存泄露問題,多是微軟作了優化,或者Dom的回收方式已經改變

4、內存管理

一、何時觸發垃圾回收?

垃圾回收器週期性運行,若是分配的內存很是多,那麼回收工做也會很艱鉅,肯定垃圾回收時間間隔就變成了一個值得思考的問題。IE6的垃圾回收是根據內存分配量運行的,當環境中存在256個變量、4096個對象、64k的字符串任意一種狀況的時候就會觸發垃圾回收器工做,看起來很科學,不用按一段時間就調用一次,有時候會不必,這樣按需調用不是很好嗎?可是若是環境中就是有這麼多變量等一直存在,如今腳本如此複雜,很正常,那麼結果就是垃圾回收器一直在工做,這樣瀏覽器就無法兒玩兒了。

微軟在IE7中作了調整,觸發條件再也不是固定的,而是動態修改的,初始值和IE6相同,若是垃圾回收器回收的內存分配量低於程序佔用內存的15%,說明大部份內存不可被回收,設的垃圾回收觸發條件過於敏感,這時候把臨街條件翻倍,若是回收的內存高於85%,說明大部份內存早就該清理了,這時候把觸發條件置回。這樣就使垃圾回收工做職能了不少

二、合理的GC方案

1)、Javascript引擎基礎GC方案是(simple GC):mark and sweep(標記清除),即:

  • (1)遍歷全部可訪問的對象。
  • (2)回收已不可訪問的對象。

2)、GC的缺陷

和其餘語言同樣,javascript的GC策略也沒法避免一個問題:GC時,中止響應其餘操做,這是爲了安全考慮。而Javascript的GC在100ms甚至以上,對通常的應用還好,但對於JS遊戲,動畫對連貫性要求比較高的應用,就麻煩了。這就是新引擎須要優化的點:避免GC形成的長時間中止響應。

3)、GC優化策略

David大叔主要介紹了2個優化方案,而這也是最主要的2個優化方案了:

(1)分代回收(Generation GC)
這個和Java回收策略思想是一致的。目的是經過區分「臨時」與「持久」對象;多回收「臨時對象」區(young generation),少回收「持久對象」區(tenured generation),減小每次需遍歷的對象,從而減小每次GC的耗時。如圖:

這裏須要補充的是:對於tenured generation對象,有額外的開銷:把它從young generation遷移到tenured generation,另外,若是被引用了,那引用的指向也須要修改。

(2)增量GC
這個方案的思想很簡單,就是「每次處理一點,下次再處理一點,如此類推」。如圖:

這種方案,雖然耗時短,但中斷較多,帶來了上下文切換頻繁的問題。

由於每種方案都其適用場景和缺點,所以在實際應用中,會根據實際狀況選擇方案。

好比:低 (對象/s) 比率時,中斷執行GC的頻率,simple GC更低些;若是大量對象都是長期「存活」,則分代處理優點也不大。

 

做者:小平果118

相關文章
相關標籤/搜索