摘要：內存回收此時，局部變量就沒有存在的必要了，因此可以釋放它們的內存以供將來使用。局部變量會在它們離開執(zhí)行環(huán)境時自動被解除引用，如下面這個例子所示手工解除的引用由于局部變量在函數執(zhí)行完畢后就離開了其執(zhí)行環(huán)境，因此無需我們顯式地去為它解除引用。

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

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

正因為垃圾回收器的存在，許多人認為 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 hyffffd"); 
"
" + e.innerHTML + "
" 

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

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

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

內存分配：局部變量只在函數執(zhí)行的過程中存在。而在這個過程中，會為局部變量在棧（或堆）內存上分配相應的空間，以便存儲它們的值。

內存使用：然后在函數中使用這些變量，直至函數執(zhí)行結束。

內存回收：此時，局部變量就沒有存在的必要了，因此可以釋放它們的內存以供將來使用。

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

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

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

垃圾回收器在運行的時候會給存儲在內存中的所有變量都加上標記（當然，可以使用任何標記方式）。然后，它會去掉環(huán)境中的變量以及被環(huán)境中的變量引用的變量的標記（例如，閉包）。而在此之后再被加上標記的變量將被視為準備刪除的變量，原因是環(huán)境中的變量已經無法訪問到這些變量了。最后，垃圾回收器完成內存清除工作，銷毀那些帶標記的值并回收它們所占用的內存空間。

這種方式的主要缺點就是如果某些對象被清理后，內存是不連續(xù)的，那么就算內存占用率不高，例如只有50%，但是由于內存空隙太多，后來的大對象甚至無法存儲到內存之中。一般的處理方式都是在垃圾回收后進行整理操作，這種方法也叫 標記整理，整理的過程就是將不連續(xù)的內存向一端復制，使不連續(xù)的內存連續(xù)起來。

目前，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 
}

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

function problem(){
    var objectA = new Object();
    var objectB = new Object();

    objectA.someOtherObject = objectB;
    objectB.anotherObject = objectA;
}

在這個例子中，objectA 和 objectB 通過各自的屬性相互引用；也就是說，這兩個對象的引用次數都是2。在采用 標記清除 策略的實現中，由于函數執(zhí)行之后，這兩個對象都離開了作用域，因此這種相互引用不是個問題。但在采用 引用計數 策略的實現中，當函數執(zhí)行完畢后，objectA 和 objectB 還將繼續(xù)存在，因為它們的引用次數永遠不會是0。假如這個函數被重復多次調用，就會導致大量內存得不到回收。為此，新一代瀏覽器都放棄了引用計數方式，轉而采用標記清除來實現其垃圾收集機制?？墒牵糜嫈祵е碌穆闊┎⑽淳痛私K結。

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

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

這個例子在一個 DOM 元素（element）與一個原生 JavaScript 對象（myObject）之間創(chuàng)建了循環(huán)引用。其中，變量 myObject 有一個名為 element 的屬性指向 element 對象；而變量 element 也有一個屬性名叫 someObject 回指 myObject。由于存在這個循環(huán)引用，即使將例子中的 DOM 從頁面中移除，它也永遠不會被回收。

為了避免類似這樣的循環(huán)引用問題，最好是在不使用它們的時候手工斷開原生 JavaScript 對象與 DOM 元素之間的連接。例如，可以使用下面的代碼消除前面例子創(chuàng)建的循環(huán)引用：

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

將變量設置為 null 意味著切斷變量與它此前引用的值之間的連接。當垃圾收集器下次運行時，就會刪除這些值并回收它們占用的內存。

為了解決上述問題，IE9 把 BOM 和 DOM 對象都轉換成了真正的 JavaScript 對象。這樣，就避免了兩種垃圾收集算法并存導致的問題，也消除了常見的內存泄漏現象。

IE6 的垃圾回收是根據內存分配量運行的，當環(huán)境中存在256個變量、4096個對象、64k的字符串任意一種情況的時候就會觸發(fā)垃圾回收器工作，看起來很科學，不用按一段時間就調用一次，有時候會沒必要，這樣按需調用不是很好嗎？但是如果環(huán)境中就是有這么多變量等一直存在，現在腳本如此復雜，那么垃圾回收器會一直工作，這樣瀏覽器就沒法兒玩兒了。

微軟在 IE7 中做了調整，觸發(fā)條件不再是固定的，而是動態(tài)修改的，初始值和 IE6 相同，如果垃圾回收器回收的內存分配量低于程序占用內存的15%，說明大部分內存不可被回收，設的垃圾回收觸發(fā)條件過于敏感，這時候把臨界條件翻倍，如果回收的內存高于85%，說明大部分內存早就該清理了，這時候則將各種臨界值重置回默認值。這一看似簡單的調整，極大地提升了 IE7 在運行包含大量 JavaScript 的頁面時的性能。

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

因此，確保占用最少的內存可以讓頁面獲得更好的性能。而優(yōu)化內存占用的最佳方式，就是為執(zhí)行中的代碼只保存必要的數據。一旦數據不再有用，最好通過將其值設置為 null 來釋放其引用——這個做法叫做 解除引用（dereferencing）。這一做法適用于大多數全局變量和全局對象的屬性。局部變量會在它們離開執(zhí)行環(huán)境時自動被解除引用，如下面這個例子所示：

function createPerson(name){
    var localPerson = new Object();
    localPerson.name = name;
    return localPerson;
}

var globalPerson = createPerson("Nicholas");

// 手工解除globalPerson的引用
globalPerson = null;

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

不過，解除一個值的引用并不意味著自動回收該值所占用的內存。解除引用的真正作用是讓值脫離執(zhí)行環(huán)境，以便垃圾收集器下次運行時將其回收。

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

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

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

這個方案的思想很簡單，就是「每次處理一點，下次再處理一點，如此類推」。這種方案，雖然耗時短，但中斷較多，帶來了上下文切換頻繁的問題。Firefox 瀏覽器所使用的 JavaScript 引擎就是采用的增量回收策略。如圖：

因為每種方案都其適用場景和缺點，因此在實際應用中，會根據實際情況選擇方案。例如：如果大量對象都是長期「存活」，則分代處理優(yōu)勢也不大。

原文鏈接：Know Your Engines: How to Make Your JavaScript Fast  
http://t.cn/RIROY1W

使用快捷鍵 F12 或者 Ctrl+Shift+J 打開 Chrome 瀏覽器的「開發(fā)者工具」。

選擇 Timeline 選項卡，在 Capture 選項中，只勾選 Memory。

設置完成后，點擊最左邊的 Record 按鈕，然后就可以訪問網頁了。

打開一個網站，例如：http://www.taobao.com，當網頁加載完成后，點擊 Stop，等待分析結果。

然后在 Chart View 上尋找內存急速下降的部分，查看對應的 Event Log，可以從中找到 GC 的日志。

具體過程如下圖所示：

挑戰(zhàn)一，嘗試寫一段小程序，觸發(fā) IE6 的無限 CG。

挑戰(zhàn)二，參考「查看 Chrome 瀏覽器下的 CG 過程」，嘗試查看 Firefox 瀏覽器下的 CG 過程。

關注微信公眾號「劼哥舍」回復「答案」，獲取關卡詳解。  
關注 https://github.com/stone0090/javascript-lessons，獲取最新動態(tài)。