JavaScript 之記憶體回收和記憶體管理

標籤：正是   移除   ase   creat   ons   區分   最佳化   sdn   rip   

JavaScript 具有自動垃圾收集機制（GC：Garbage Collecation），也就是說，執行環境會負責管理代碼執行過程中使用的記憶體。而在 C 和 C++ 之類的語言中，開發人員的一項基本任務就是手工跟蹤記憶體的使用方式，這是造成許多問題的一個根源。

在編寫 JavaScript 程式時，開發人員不用再關心記憶體使用量問題，所需記憶體的分配以及無用記憶體的回收完全實現了自動管理。這種垃圾收集機制的原理其實很簡單：找出那些不再繼續使用的變數，然後釋放其佔用的記憶體。為此，垃圾收集器會按照固定的時間間隔（或代碼執行中預定的收集時間），周期性地執行這一操作。

正因為記憶體回收行程的存在，許多人認為 JavaScript 不用太關心記憶體管理的問題，但如果不瞭解 JavaScript 的記憶體管理機制，我們同樣非常容易成記憶體流失（記憶體無法被回收）的情況。

// 1.對象new Object(); new MyConstructor(); { a: 4, b: 5 } Object.create(); 

// 2.數組 new Array(); [ 1, 2, 3, 4 ]; 

// 3.字串，JavaScript 的字串和 .NET 一樣，使用資源集區和 copy on write 方式管理字串。new String("hello hyddd"); "<p>" + e.innerHTML + "</p>" 

// 4.函數var x = function () { ... } new Function(code)

// 5.閉包 function outer(name) {     var x = name;      return function inner() {         return "Hi, " + name;      }  }

記憶體的生命週期

下面我們來分析一下函數中局部變數的正常生命週期。

• 記憶體配置：局部變數只在函數執行的過程中存在。而在這個過程中，會為局部變數在棧（或堆）記憶體上分配相應的空間，以便儲存它們的值。
• 記憶體使用量：然後在函數中使用這些變數，直至函數執行結束。
• 記憶體回收：此時，局部變數就沒有存在的必要了，因此可以釋放它們的記憶體以供將來使用。

通常，很容易判斷變數是否還有存在的必要，但並非所有情況下都這麼容易就能得出結論（例如：使用閉包的時）。垃圾收集器必須跟蹤哪個變數有用哪個變數沒用，對於不再有用的變數打上標記，以備將來收回其佔用的記憶體。用於標識無用變數的策略可能會因實現而異，但具體到瀏覽器中的實現，則通常有兩個策略：標記清除 和 引用計數。

標記清除

JavaScript 中最常用的垃圾收集方式是 標記清除（mark-and-sweep）。當變數進入環境（例如，在函數中聲明一個變數）時，就將這個變數標記為“進入環境”。從邏輯上講，永遠不能釋放進入環境的變數所佔用的記憶體，因為只要執行流進入相應的環境，就可能會用到它們。而當變數離開環境時，則將其標記為“離開環境”。

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

記憶體回收行程在啟動並執行時候會給儲存在記憶體中的所有變數都加上標記（當然，可以使用任何標記方式）。然後，它會去掉環境中的變數以及被環境中的變數引用的變數的標記（例如，閉包）。而在此之後再被加上標記的變數將被視為準備刪除的變數，原因是環境中的變數已經無法訪問到這些變數了。最後，記憶體回收行程完成記憶體清除工作，銷毀那些帶標記的值並回收它們所佔用的記憶體空間。

這種方式的主要缺點就是如果某些對象被清理後，記憶體是不連續的，那麼就算記憶體佔用率不高，例如只有50%，但是由於記憶體空隙太多，後來的大對象甚至無法儲存到記憶體之中。一般的處理方式都是在記憶體回收後進行整理操作，這種方法也叫 標記整理，整理的過程就是將不連續的記憶體向一端複製，使不連續的記憶體連續起來。

目前，IE9+、Firefox、Opera、Chrome 和 Safari 的 JavaScript 實現使用的都是 標記清除 式的垃圾收集策略（或類似的策略），只不過垃圾收集的時間間隔互有不同。

引用計數

另一種不太常見的垃圾收集策略叫做 引用計數（reference counting）。引用計數的含義是追蹤記錄每個值被引用的次數。當聲明了一個變數並將一個參考型別值賦給該變數時，則這個值的引用次數就是1。如果同一個值又被賦給另一個變數，則該值的引用次數加1。相反，如果包含對這個值引用的變數又取得了另外一個值，則這個值的引用次數減1。當這個值的引用次數變成0時，則說明沒有辦法再訪問這個值了，因而就可以將其佔用的記憶體空間回收回來。這樣，當垃圾收集器下次再運行時，它就會釋放那些引用次數為零的值所佔用的記憶體

function test(){     var a = {} ; // a的引用次數為0     var b = a ; // a的引用次數加1，為1     var c = a; // a的引用次數再加1，為2     var b = {}; // a的引用次數減1，為1 }

早期很多瀏覽器使用引用計數策略，但很快它就遇到了一個嚴重的問題：循環參考。循環參考指的是對象 A 中包含一個指向對象 B 的指標，而對象 B 中也包含一個指向對象 A 的引用。請看下面這個例子：

function problem(){    var objectA = new Object();    var objectB = new Object();    objectA.someOtherObject = objectB;    objectB.anotherObject = objectA;}

在這個例子中，objectA 和 objectB 通過各自的屬性相互引用；也就是說，這兩個對象的引用次數都是2。在採用標記清除 策略的實現中，由於函數執行之後，這兩個對象都離開了範圍，因此這種相互引用不是個問題。但在採用 引用計數 策略的實現中，當函數執行完畢後，objectA 和 objectB 還將繼續存在，因為它們的引用次數永遠不會是0。假如這個函數被重複多次調用，就會導致大量記憶體得不到回收。為此，新一代瀏覽器都放棄了引用計數方式，轉而採用標記清除來實現其垃圾收集機制。可是，引用計數導致的麻煩並未就此終結。

我們知道，IE 中有一部分對象並不是原生 JavaScript 對象。例如，其 BOM 和 DOM 中的對象就是使用 C++ 以 COM（Component Object Model，元件物件模型）對象的形式實現的，而 COM 物件的垃圾收集機制採用的就是引用計數策略。因此，即使 IE 的 JavaScript 引擎是使用標記清除策略來實現的，但 JavaScript 訪問的 COM 物件依然是基於引用計數策略的。換句話說，只要在 IE 中涉及 COM 物件，就會存在循環參考的問題。下面這個簡單的例子，展示了使用 COM 物件導致的循環參考問題：

var element = document.getElementById("some_element");var myObject = new Object();myObject.element = element;element.someObject = myObject;

這個例子在一個 DOM 元素（element）與一個原生 JavaScript 對象（myObject）之間建立了循環參考。其中，變數 myObject 有一個名為 element 的屬性指向 element 對象；而變數 element 也有一個屬性名稱叫 someObject 回指 myObject。由於存在這個循環參考，即使將例子中的 DOM 從頁面中移除，它也永遠不會被回收。

為了避免類似這樣的循環參考問題，最好是在不使用它們的時候手工斷開原生 JavaScript 對象與 DOM 元素之間的串連。例如，可以使用下面的代碼消除前面例子建立的循環參考：

myObject.element = null;element.someObject = null;

將變數設定為 null 意味著切斷變數與它此前引用的值之間的串連。當垃圾收集器下次運行時，就會刪除這些值並回收它們佔用的記憶體。

為瞭解決上述問題，IE9 把 BOM 和 DOM 對象都轉換成了真正的 JavaScript 對象。這樣，就避免了兩種垃圾收集演算法並存導致的問題，也消除了常見的記憶體流失現象。

IE6 的效能問題

IE6 的記憶體回收是根據記憶體配置量啟動並執行，當環境中存在256個變數、4096個對象、64k的字串任意一種情況的時候就會觸發記憶體回收行程工作，看起來很科學，不用按一段時間就調用一次，有時候會沒必要，這樣按需調用不是很好嗎？但是如果環境中就是有這麼多變數等一直存在，現在指令碼如此複雜，那麼記憶體回收行程會一直工作，這樣瀏覽器就沒法兒玩兒了。

微軟在 IE7 中做了調整，觸發條件不再是固定的，而是動態修改的，初始值和 IE6 相同，如果記憶體回收行程回收的記憶體配置量低於程式佔用記憶體的15%，說明大部分記憶體不可被回收，設的記憶體回收觸發條件過于敏感，這時候把臨界條件翻倍，如果回收的記憶體高於85%，說明大部分記憶體早就該清理了，這時候則將各種臨界值重設回預設值。這一看似簡單的調整，極大地提升了 IE7 在運行包含大量 JavaScript 的頁面時的效能。

編碼注意 - 解除引用

使用具備垃圾收集機制的語言編寫程式，開發人員一般不必操心記憶體管理的問題。但是，JavaScript 在進行記憶體管理及垃圾收集時面臨的問題還是有點與眾不同。其中最主要的一個問題，就是分配給 網頁瀏覽器的可用記憶體數量通常要比分配給傳統型應用程式的少。這樣做的目的主要是出於安全方面的考慮，目的是防止運行 JavaScript 的網頁耗盡全部系統記憶體而導致系統崩潰。記憶體限制問題不僅會影響給變數分配記憶體，同時還會影響調用棧以及在一個線程中能夠同時執行的語句數量。

因此，確保佔用最少的記憶體可以讓頁面獲得更好的效能。而最佳化記憶體佔用的最佳方式，就是為執行中的代碼只儲存必要的資料。一旦資料不再有用，最好通過將其值設定為 null 來釋放其引用——這個做法叫做 解除引用（dereferencing）。這一做法適用於大多數全域變數和全域對象的屬性。局部變數會在它們離開執行環境時自動被解除引用，如下面這個例子所示：

function createPerson(name){    var localPerson = new Object();    localPerson.name = name;    return localPerson;}var globalPerson = createPerson("Nicholas");// 手工解除globalPerson的引用globalPerson = null;

由於局部變數 localPerson 在 createPerson() 函數執行完畢後就離開了其執行環境，因此無需我們顯式地去為它解除引用。但是對於全域變數 globalPerson 而言，則需要我們在不使用它的時候手工為它解除引用，這也正是上面例子中最後一行代碼的目的。

不過，解除一個值的引用並不意味著自動回收該值所佔用的記憶體。解除引用的真正作用是讓值脫離執行環境，以便垃圾收集器下次運行時將其回收。

記憶體回收的最佳化策略

和其他語言一樣，JavaScript 的記憶體回收策略也無法避免一個問題：記憶體回收時，會停止回應其他動作，這是為了安全考慮。而 JavaScript 的記憶體回收在 100ms 甚至以上，對一般的應用還好，但對於 JavaScript 遊戲和動畫，這種對連貫性要求比較高的應用，就麻煩了。這就是新引擎需要最佳化的點：避免記憶體回收造成的長時間停止回應。

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

分代回收（Generation GC）

這個和 Java 回收策略思想是一致的。目的是通過區分「臨時」與「持久」對象；多回收「臨時對象區」（young generation），少回收「持久對象區」（tenured generation），減少每次需遍曆的對象，從而減少每次GC的耗時。Chrome 瀏覽器所使用的 V8 引擎就是採用的分代回收策略

 

JavaScript 之記憶體回收和記憶體管理