瀏覽器中的垃圾回收與內存泄漏

時間 2019-11-07

原文原文鏈接

1. 介紹

瀏覽器的 Javascript 具備自動垃圾回收機制(GC:Garbage Collecation)，也就是說，執行環境會負責管理代碼執行過程當中使用的內存。其原理是：垃圾收集器會按期（週期性）找出那些不在繼續使用的變量，而後釋放其內存。可是這個過程不是實時的，由於其開銷比較大而且GC時中止響應其餘操做，因此垃圾回收器會按照固定的時間間隔週期性的執行。javascript

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

仍是上代碼說明吧：前端

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所指向，因此該塊內存並不會被釋放。vue

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

2. 標記清除

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

function test(){
var a = 10 ;             //被標記 ，進入環境 
var b = 20 ;             //被標記 ，進入環境
}
test();                     //執行完畢 以後 a、b又被標離開環境，被回收。
複製代碼

垃圾回收器在運行的時候會給存儲在內存中的全部變量都加上標記（固然，可使用任何標記方式）。而後，它會去掉環境中的變量以及被環境中的變量引用的變量的標記（閉包）。而在此以後再被加上標記的變量將被視爲準備刪除的變量，緣由是環境中的變量已經沒法訪問到這些變量了。最後，垃圾回收器完成內存清除工做，銷燬那些帶標記的值並回收它們所佔用的內存空間。到目前爲止，IE9+、Firefox、Opera、Chrome、Safari的js實現使用的都是標記清除的垃圾回收策略或相似的策略，只不過垃圾收集的時間間隔互不相同。chrome

3. 引用計數

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

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有一個屬性e指向element對象；而變量element也有一個屬性o回指myObject。因爲存在這個循環引用，即便例子中的DOM從頁面中移除，它也永遠不會被回收。

舉個栗子：

黃色是指直接被 js變量所引用，在內存裏
紅色是指間接被 js變量所引用，如上圖，refB 被 refA 間接引用，致使即便 refB 變量被清空，也是不會被回收的
子元素 refB 因爲 parentNode 的間接引用，只要它不被刪除，它全部的父元素（圖中紅色部分）都不會被刪除

另外一個例子：

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

這段代碼看起來沒什麼問題，可是obj引用了document.getElementById('element')，而document.getElementById('element')的onclick方法會引用外部環境中的變量，天然也包括obj，是否是很隱蔽啊。(在比較新的瀏覽器中在移除Node的時候已經會移除其上的event了，可是在老的瀏覽器，特別是ie上會有這個bug)

解決辦法：

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

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的回收方式已經改變

4. 內存管理

4.1 何時觸發垃圾回收？

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

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

4.2 合理的GC方案

1. 基礎方案

Javascript引擎基礎GC方案是（simple GC）：mark and sweep（標記清除），即：

遍歷全部可訪問的對象。
回收已不可訪問的對象。

2. GC的缺陷

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

3. GC優化策略

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

分代回收（Generation GC）這個和Java回收策略思想是一致的，也是V8所主要採用的。目的是經過區分「臨時」與「持久」對象；多回收「臨時對象」區（young generation），少回收「持久對象」區（tenured generation），減小每次需遍歷的對象，從而減小每次GC的耗時。如圖：

這裏須要補充的是：對於tenured generation對象，有額外的開銷：把它從young generation遷移到tenured generation，另外，若是被引用了，那引用的指向也須要修改。這裏主要內容能夠參考深刻淺出Node中關於內存的介紹，很詳細~
增量GC 這個方案的思想很簡單，就是「每次處理一點，下次再處理一點，如此類推」。如圖：

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

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

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

5. vue中的內存泄漏問題

JS程序的內存溢出後，會使某一段函數體永遠失效（取決於當時的JS代碼運行到哪個函數），一般表現爲程序忽然卡死或程序出現異常。

這時咱們就要對該JS程序進行內存泄漏的排查，找出哪些對象所佔用的內存沒有釋放。這些對象一般都是開發者覺得釋放掉了，但事實上仍被某個閉包引用着，或者放在某個數組裏面。

5.1 泄漏點

DOM/BOM 對象泄漏
script 中存在對DOM/BOM 對象的引用致使
js 對象泄漏
一般由閉包致使，好比事件處理回調，致使DOM對象和腳本中對象雙向引用，這個時常見的泄漏緣由

5.2 代碼關注點

DOM中的 addEventLisner 函數及派生的事件監聽，好比 Jquery 中的 on 函數， vue 組件實例的 $on 函數，第三方庫中的初始化函數
其它BOM對象的事件監聽，好比websocket 實例的on 函數
避免沒必要要的函數引用
若是使用 render 函數，避免在html標籤中綁定DOM/BOM 事件

5.3 如何處理

若是在mounted/created 鉤子中綁定了 DOM/BOM 對象中的事件，須要在 beforeDestroy 中作對應解綁處理
若是在mounted/created 鉤子中使用了第三方庫初始化，須要在beforeDestroy 中作對應銷燬處理
若是組件中使用了定時器，須要在beforeDestroy中作對應銷燬處理
模板中不要使用表達式來綁定到特定的處理函數，這個邏輯應該放在處理函數中？
若是在mounted/created 鉤子中使用了$on，須要在beforeDestroy 中作對應解綁$off處理
某些組件在模板中使用事件綁定可能會出現泄漏，使用$on 替換模板中的綁定

5.4 在vue組件中處理addEventListener

created/mounted 生命期鉤子函數中定義事件響應函數爲對象實例的方法，使用 => 函數來綁定做用域調用 addEventListener 添加事件監聽後在 beforeDestroy 中調用 removeEventListener 移除對應的事件監聽，注意前面定義的響應函數方法須要做爲第二個參數傳入而後用 delete 從對象實例移除定義的響應方法，或者將屬性設置爲 null/undefined 爲了準確移除監聽，不要使用匿名函數或者已有的函數的綁定來直接做爲事件監聽函數

mounted() {
    const box = document.getElementById('time-line')
    this.width = box.offsetWidth
    this.resizefun = () => {
      this.width = box.offsetWidth
    }
    window.addEventListener('resize', this.resizefun)
  },
  beforeDestroy() {
    window.removeEventListener('resize', this.resizefun)
    this.resizefun = null
  }
複製代碼

5.5 觀察者模式引發的內存泄漏

在spa應用中使用觀察者模式的時候若是給觀察者註冊了被觀察的方法，而沒有在離開組件的時候及時移除，可能形成重複註冊而內存泄漏；

舉個栗子：進入組件的時候ob.addListener("enter", _func)，若是離開組件beforeDestroy的時候沒有ob.removeListener("enter", _func)，就會致使內存泄漏

更詳細的栗子參考：德州撲克栗子

5.6 上下文綁定引發的內存泄漏

有時候使用 bind/apply/call 上下文綁定方法的時候，會有內存泄漏的隱患。

var ClassA = function(name) {
  this.name = name
  this.func = null
}

var a = new ClassA("a")
var b = new ClassA("b")

b.func = bind(function() {
  console.log("I am " + this.name)
}, a)

b.func()    // 輸出: I am a

a = null        // 釋放a
//b = null; // 釋放b
//b.func = null; // 釋放b.func

function bind(func, self) {        //模擬上下文綁定
  return function() {
    return func.apply(self)
  }
}
複製代碼