摘要：分配這些變量的空間稱為堆棧空間，因?yàn)殡S著函數(shù)的調(diào)用，它們的內(nèi)存將被添加到現(xiàn)有內(nèi)存之上。當(dāng)函數(shù)調(diào)用其他函數(shù)時(shí)，每個(gè)函數(shù)在調(diào)用時(shí)都會(huì)獲得自己的堆棧塊。

該系列的第一篇文章重點(diǎn)介紹了引擎，運(yùn)行時(shí)和調(diào)用堆棧的概述。第二篇文章深入剖析了Google的V8 JavaScript引擎，并提供了關(guān)于如何編寫更好的JavaScript代碼的一些提示。

在第三篇文章中，我們將討論另一個(gè)越來(lái)越被開發(fā)人員忽視的關(guān)鍵主題，因?yàn)槿粘Ｊ褂玫木幊陶Z(yǔ)言（內(nèi)存管理）越來(lái)越成熟和復(fù)雜。我們還會(huì)提供一些關(guān)于如何處理內(nèi)存泄漏的技巧。

像C這樣的編程語(yǔ)言，提供從底層上管理內(nèi)存的方法，如malloc()和free()。開發(fā)人員使用這些方法，用來(lái)從操作系統(tǒng)分配內(nèi)存，或釋放內(nèi)存到操作系統(tǒng)中。

當(dāng)對(duì)象或字符串等被創(chuàng)建時(shí)，JavaScript會(huì)申請(qǐng)和分配內(nèi)存；當(dāng)對(duì)象或字符不在被使用時(shí)，它們就會(huì)被自動(dòng)釋放，這也被稱為垃圾處理。這種釋放資源的看似是“自動(dòng)”的，這恰恰是誤解的來(lái)源，給JavaScript（以及其他高級(jí)語(yǔ)言）開發(fā)人員造成了他們可能選擇不關(guān)心內(nèi)存管理的錯(cuò)誤印象。這是一個(gè)大錯(cuò)誤。

即使使用高級(jí)語(yǔ)言，開發(fā)人員也應(yīng)該理解內(nèi)存管理。有時(shí)自動(dòng)內(nèi)存管理也會(huì)出現(xiàn)問題（如bugs或者垃圾回收限制等），開發(fā)人員不得不先了解它們，然后才能妥善處理。

無(wú)論您使用什么編程語(yǔ)言，內(nèi)存生命周期幾乎都是一樣的：

以下簡(jiǎn)單描述了在該周期的每個(gè)步驟中發(fā)生的情況：

分配內(nèi)存 - 內(nèi)存由操作系統(tǒng)分配，允許程序使用它。在底層語(yǔ)言（如C）中，這是一個(gè)顯式操作，您作為開發(fā)人員應(yīng)該處理。然而，在高級(jí)語(yǔ)言中，這個(gè)操作被隱藏了。

使用內(nèi)存 - 這是您的程序?qū)嶋H使用之前分配的內(nèi)存。讀取和寫入操作發(fā)生在您在代碼中使用分配的變量時(shí)。

釋放內(nèi)存 - 現(xiàn)在是釋放您不需要的整個(gè)內(nèi)存的時(shí)間，以便它可以變?yōu)榭臻e并再次可用。 與分配內(nèi)存操作一樣，這個(gè)操作在底層語(yǔ)言中是可以直接調(diào)用的。

有關(guān)調(diào)用堆棧和內(nèi)存堆的概念的概述，您可以閱讀本系列第一篇文章。

在開始討論JavaScript的內(nèi)存之前，我們將簡(jiǎn)要討論一般內(nèi)存概念以及它如何工作。

在硬件級(jí)別上，計(jì)算機(jī)內(nèi)存由大量的觸發(fā)器。每個(gè)觸發(fā)器都包含一些晶體管并且能夠存儲(chǔ)一個(gè)bit。單個(gè)觸發(fā)器可通過(guò)唯一標(biāo)識(shí)符進(jìn)行尋址，因此我們可以讀取并覆蓋它們。因此，從概念上講，我們可以將整個(gè)計(jì)算機(jī)內(nèi)存看作是我們可以讀寫的bit數(shù)組。

從人類角度來(lái)說(shuō)，我們不擅長(zhǎng)用bit來(lái)完成我們現(xiàn)實(shí)中思想和算法，我們把它們組織成更大的部分，它們一起可以用來(lái)表示數(shù)字。 8位（比特位）稱為1個(gè)字節(jié)（byte）。除字節(jié)外，還有單詞（word）（有時(shí)是16，有時(shí)是32位）。

很多東西都存儲(chǔ)在這個(gè)內(nèi)存中：

所有程序使用的所有變量和其他數(shù)據(jù)。

程序的代碼，包括操作系統(tǒng)的代碼。

編譯器和操作系統(tǒng)一起工作，為您處理大部分內(nèi)存管理，但我們建議您看看底下發(fā)生了什么。

編譯代碼時(shí)，編譯器可以檢查原始數(shù)據(jù)類型并提前計(jì)算它們需要多少內(nèi)存。然后將所需的內(nèi)存分配給調(diào)用堆棧空間中的程序。分配這些變量的空間稱為堆?？臻g，因?yàn)殡S著函數(shù)的調(diào)用，它們的內(nèi)存將被添加到現(xiàn)有內(nèi)存之上。當(dāng)它們終止時(shí)，它們以LIFO（后進(jìn)先出）順序被移除。例如，請(qǐng)考慮以下聲明：

int n; // 4字節(jié)
int x [4]; // 4個(gè)元素的數(shù)組，每個(gè)4個(gè)字節(jié)
double m; // 8個(gè)字節(jié)

編譯器可以立即看到代碼需要
4 + 4×4 + 8 = 28個(gè)字節(jié)。

這就是它如何處理整數(shù)和雙精度的當(dāng)前大小。大約20年前，整數(shù)通常是2個(gè)字節(jié)，并且是雙4字節(jié)。您的代碼不應(yīng)該依賴于此時(shí)基本數(shù)據(jù)類型的大小。

編譯器將插入與操作系統(tǒng)進(jìn)行交互的代碼，以在堆棧中請(qǐng)求必要的字節(jié)數(shù)，以便存儲(chǔ)變量。

在上面的例子中，編譯器知道每個(gè)變量的確切內(nèi)存地址。事實(shí)上，只要我們寫入變量n，就會(huì)在內(nèi)部翻譯成類似“內(nèi)存地址4127963”的內(nèi)容。

注意，如果我們?cè)噲D在這里訪問x[4]，我們將訪問與m關(guān)聯(lián)的數(shù)據(jù)。這是因?yàn)槲覀冋谠L問數(shù)組中不存在的元素 - 它比數(shù)組中最后一個(gè)實(shí)際分配的元素x [3]更遠(yuǎn)了4個(gè)字節(jié)，并且可能最終讀?。ɑ蚋采w）m個(gè)位中的一些位。這對(duì)方案的其余部分幾乎肯定會(huì)有非常不希望的后果。

當(dāng)函數(shù)調(diào)用其他函數(shù)時(shí)，每個(gè)函數(shù)在調(diào)用時(shí)都會(huì)獲得自己的堆棧塊。它保留了它所有的局部變量，同時(shí)還有一個(gè)程序計(jì)數(shù)器，記錄它在執(zhí)行時(shí)的位置。當(dāng)功能完成時(shí)，其存儲(chǔ)器塊再次可用于其他目的。

不幸的是，當(dāng)我們?cè)诰幾g時(shí)有時(shí)不知道變量需要多少內(nèi)存時(shí)，假設(shè)我們想要做如下的事情：

int n = readInput(); //用戶輸入
...
//常見一個(gè)長(zhǎng)度為n的數(shù)組

在編譯時(shí)，編譯器不知道數(shù)組需要多少內(nèi)存，因?yàn)樗捎脩籼峁┑闹禌Q定。

因此，它不能為堆棧上的變量分配空間。 相反，我們的程序需要在運(yùn)行時(shí)明確要求操作系統(tǒng)提供適當(dāng)?shù)目臻g。 該內(nèi)存是從堆空間分配的。 下表總結(jié)了靜態(tài)和動(dòng)態(tài)內(nèi)存分配之間的區(qū)別：

為了充分理解動(dòng)態(tài)內(nèi)存分配是如何工作的，我們需要在指針上花費(fèi)更多時(shí)間，這可能與本文的主題偏離太多。 如果您有興趣了解更多信息，請(qǐng)?jiān)谠u(píng)論中告訴我們，我們可以在以后的文章中詳細(xì)介紹指針。

現(xiàn)在我們將解釋第一步（分配內(nèi)存），以及它如何在JavaScript中工作。

JavaScript減輕了開發(fā)人員處理內(nèi)存分配的責(zé)任 - JavaScript自身聲明的時(shí)候就分配內(nèi)存，然后賦值。

var n = 374; // 為數(shù)字分配內(nèi)存
var s = "sessionstack"; // 為字符串分配內(nèi)存 
var o = {
  a: 1,
  b: null
}; // 為對(duì)象和它的值分配內(nèi)存
var a = [1, null, "str"];  // (類似對(duì)象) 為數(shù)組和它的值
                           // 分配內(nèi)存
function f(a) {
  return a + 3;
} // 為函數(shù)分配內(nèi)存 (which is a callable object)
// 函數(shù)表達(dá)式也會(huì)分配內(nèi)存
someElement.addEventListener("click", function() {
  someElement.style.backgroundColor = "blue";
}, false);

一些函數(shù)調(diào)用也會(huì)導(dǎo)致對(duì)象分配：

var d = new Date(); // 為日期對(duì)象分配內(nèi)存
var e = document.createElement("div"); // 為DOM元素分配內(nèi)存

方法可以分配新的值或?qū)ο螅?/p>

var s1 = "sessionstack";
var s2 = s1.substr(0, 3); // s2 is a new string
// 由于字符串是不可改變的， 
// JavaScript may decide to not allocate memory, 
// but just store the [0, 3] range.
var a1 = ["str1", "str2"];
var a2 = ["str3", "str4"];
var a3 = a1.concat(a2); 
// new array with 4 elements being
// the concatenation of a1 and a2 elements

基本上在JavaScript中使用分配的內(nèi)存意味著讀取和寫入。

這可以通過(guò)讀取或?qū)懭胱兞炕驅(qū)ο髮傩缘闹担蛘呱踔翆?shù)傳遞給函數(shù)來(lái)完成。

大部分內(nèi)存管理問題都是在這個(gè)階段出現(xiàn)的。

這里最困難的任務(wù)是確定何時(shí)不再需要分配的內(nèi)存。它通常需要開發(fā)人員確定程序中的哪個(gè)地方不再需要這些內(nèi)存，并將其釋放。

高級(jí)語(yǔ)言嵌入了一個(gè)名為垃圾收集器的軟件，其工作是跟蹤內(nèi)存分配和使用情況，以便找到何時(shí)不再需要分配的內(nèi)存，在這種情況下，它會(huì)自動(dòng)釋放它。

不幸的是，這個(gè)過(guò)程是一個(gè)大概，因?yàn)橹朗欠裥枰承﹥?nèi)存的一般問題是不可判定的（不能由算法解決）。

大多數(shù)垃圾收集器通過(guò)收集不能再訪問的內(nèi)存來(lái)工作，例如，指向它的所有變量都超出了范圍。然而，這是可以收集的一組內(nèi)存空間的近似值，因?yàn)樵谌魏螘r(shí)候內(nèi)存位置可能仍然有一個(gè)指向它的變量，但它將不會(huì)再被訪問。

垃圾收集
由于發(fā)現(xiàn)某些內(nèi)存是否“不再需要”的事實(shí)是不可判定的，所以垃圾收集實(shí)現(xiàn)了對(duì)一般問題的解決方案的限制。本節(jié)將解釋理解主要垃圾收集算法及其局限性的必要概念。

垃圾收集算法所依賴的主要概念是參考之一。

在內(nèi)存管理的上下文中，如果一個(gè)對(duì)象可以訪問后者（可以是隱式或顯式的），則稱該對(duì)象引用另一個(gè)對(duì)象。例如，JavaScript對(duì)象具有對(duì)其原型（隱式引用）及其屬性值（顯式引用）的引用。

在這種情況下，“對(duì)象”的概念擴(kuò)展到比常規(guī)JavaScript對(duì)象更廣泛的范圍，并且還包含函數(shù)范圍（或全局詞法范圍）。

詞法范圍定義了如何在嵌套函數(shù)中解析變量名稱：即使父函數(shù)已返回，內(nèi)部函數(shù)也包含父函數(shù)的作用域。

JavaScript以一種有趣的方式處理未聲明的變量：當(dāng)引用未聲明的變量時(shí)，會(huì)在全局對(duì)象中創(chuàng)建一個(gè)新變量。 在瀏覽器中，全局對(duì)象將是window，這意味著

function foo(arg) {
    bar = "some text";
}

等同于

function foo(arg) {
    window.bar = "some text";
}

假設(shè)bar的目的是僅引用foo函數(shù)中的變量。但是，如果您不使用var來(lái)聲明它，將會(huì)創(chuàng)建一個(gè)冗余的全局變量。在上述情況下，這不會(huì)造成太大的傷害。 盡管如此，你一定可以想象一個(gè)更具破壞性的場(chǎng)景。

你也可以用這個(gè)意外地創(chuàng)建一個(gè)全局變量：

function foo() {
    this.var1 = "potential accidental global";
}
// Foo called on its own, this points to the global object (window)
// rather than being undefined.
foo();

您可以通過(guò)添加"use strict"來(lái)避免這些問題; 在您的JavaScript文件的開始處，它將切換更嚴(yán)格的解析JavaScript模式，從而防止意外創(chuàng)建全局變量。

意外的全局變量當(dāng)然是一個(gè)問題，然而，更多的時(shí)候，你的代碼會(huì)受到顯式定義的全局變量的影響，這些變量不能被垃圾收集器回收。需要特別注意用于臨時(shí)存儲(chǔ)和處理大量信息的全局變量。如果你必須使用全局變量來(lái)存儲(chǔ)數(shù)據(jù)，用完之后一定要把它賦值為null或者在完成之后重新賦值。

以setInterval為例，因?yàn)樗?jīng)常在JavaScript中使用。

提供觀察者模式或接受回調(diào)的工具庫(kù)，它通常會(huì)確保當(dāng)其實(shí)例無(wú)法訪問時(shí)，其所回調(diào)的引用在變得無(wú)法訪問。下面的代碼并不罕見：

var serverData = loadData();
setInterval(function() {
    var renderer = document.getElementById("renderer");
    if(renderer) {
        renderer.innerHTML = JSON.stringify(serverData);
    }
}, 5000); //This will be executed every ~5 seconds.

上面的代碼片段顯示了使用引用不再需要的節(jié)點(diǎn)或數(shù)據(jù)的定時(shí)器的后果。

renderer對(duì)象可能會(huì)被替換或刪除，這會(huì)使得間隔處理程序封裝的塊變得冗余。如果發(fā)生這種情況，則不需要收集處理程序及其依賴關(guān)系，因?yàn)閕nterval需要先停止（請(qǐng)記住，它仍然處于活動(dòng)狀態(tài)）。這一切歸結(jié)為serverData確實(shí)存儲(chǔ)和處理負(fù)載數(shù)據(jù)的事實(shí)也不會(huì)被收集。

當(dāng)使用observers時(shí)，你需要確保你做了一個(gè)明確的調(diào)用，在完成它們之后將其刪除（不再需要觀察者，否則對(duì)象將無(wú)法訪問）。

幸運(yùn)的是，大多數(shù)現(xiàn)代瀏覽器都會(huì)為您完成這項(xiàng)工作：即使您忘記刪除偵聽器，一旦觀察到的對(duì)象變得無(wú)法訪問，他們會(huì)自動(dòng)收集觀察者處理程序。在過(guò)去，一些瀏覽器無(wú)法處理這些情況（舊版IE6）。

var element = document.getElementById("launch-button");
var counter = 0;
function onClick(event) {
   counter++;
   element.innerHtml = "text " + counter;
}
element.addEventListener("click", onClick);
// Do stuff
element.removeEventListener("click", onClick);
element.parentNode.removeChild(element);
// Now when element goes out of scope,
// both element and onClick will be collected even in old browsers // that don"t handle cycles well.

現(xiàn)在的瀏覽器支持可以檢測(cè)這些周期并適當(dāng)處理它們的垃圾收集器，因此在使節(jié)點(diǎn)無(wú)法訪問之前，不再需要調(diào)用removeEventListener。

如果您利用jQuery API（其他庫(kù)和框架也支持這一點(diǎn)），您也可以在節(jié)點(diǎn)過(guò)時(shí)之前刪除偵聽器。 即使應(yīng)用程序在較舊的瀏覽器版本下運(yùn)行，該庫(kù)也會(huì)確保沒有內(nèi)存泄漏。

JavaScript開發(fā)的一個(gè)關(guān)鍵點(diǎn)是閉包：一個(gè)可以訪問外部函數(shù)的變量的內(nèi)部函數(shù)。由于JavaScript運(yùn)行時(shí)的實(shí)現(xiàn)方式，可能以下列方式泄漏內(nèi)存：

var theThing = null;
var replaceThing = function () {
  var originalThing = theThing;
  var unused = function () {
    if (originalThing) // "originalThing"的引用
      console.log("hi");
  };
  theThing = {
    longStr: new Array(1000000).join("*"),
    someMethod: function () {
      console.log("message");
    }
  };
};
setInterval(replaceThing, 1000);

一旦replaceThing函數(shù)被調(diào)用，theThing變量將被賦值為一個(gè)由很長(zhǎng)的字符串和一個(gè)新閉包（someMethod）組成的新對(duì)象。originalThing變量被一個(gè)閉包引用，這個(gè)閉包由unused變量保持。需要記住的是，當(dāng)一個(gè)閉包的作用域被創(chuàng)建，同屬父范圍內(nèi)的閉包的作用域會(huì)被共享。

在這種情況下，閉包someMethod創(chuàng)建的作用域?qū)⑴c閉包unused的作用域共享。unused引用了originalThing，盡管代碼中unused從未被調(diào)用過(guò)，但是我們還是可以在replaceThing函數(shù)外通過(guò)theThing來(lái)調(diào)用someMethod。由于someMethod與unused的閉包作用域共享，閉包unused的引用了originalThing，強(qiáng)制它保持活動(dòng)狀態(tài)（兩個(gè)閉包之間的共享作用域）。這阻止了它被垃圾回收。

在上面的例子中，閉包someMethod創(chuàng)建的作用域與閉包unused作用域的共享，而unused的引用originalThing。盡管閉包unused從未被使用，someMethod還是可以通過(guò)theThing，從replaceThing范圍外被調(diào)用。事實(shí)上，閉包unused引用了originalThing要求它保持活動(dòng)，因?yàn)閟omeMethod與unused的作用域共享。

閉包會(huì)保留一個(gè)指向其作用域的指針，作用域就是閉包父函數(shù)，所以閉包unused和someMethod都會(huì)有一個(gè)指針指向replaceThing函數(shù)，這也是為什么閉包可以訪問外部函數(shù)的變量。由于閉包unused引用了originalThing變量，這使得originalThing變量存在于lexical environment，replaceThing函數(shù)里面定義的所有的閉包都會(huì)有一個(gè)對(duì)originalThing的引用，所以閉包someMethod自然會(huì)保持一個(gè)對(duì)originalThing的引用，所以就算theThing替換成其它值，它的上一次值不會(huì)被回收。

所有這些都可能導(dǎo)致相當(dāng)大的內(nèi)存泄漏。當(dāng)上面的代碼片段一遍又一遍地運(yùn)行時(shí)，您可能會(huì)發(fā)現(xiàn)內(nèi)存使用量激增。當(dāng)垃圾收集器運(yùn)行時(shí)，其大小不會(huì)縮小。創(chuàng)建了一個(gè)閉包的鏈表（在這種情況下，它的根就是theThing變量），并且每個(gè)閉包范圍都會(huì)間接引用大數(shù)組。

有些情況下開發(fā)者會(huì)保存DOM節(jié)點(diǎn)的引用。假設(shè)你想快速更新表格中幾行的內(nèi)容，如果使用字典或數(shù)組存儲(chǔ)這幾行的DOM引用，則會(huì)有兩個(gè)對(duì)同一DOM元素的引用：一個(gè)在DOM樹中，另一個(gè)在字典或數(shù)組中。如果你決定刪除并回收這些行，您需要記住要使這個(gè)兩個(gè)引用都無(wú)法訪問。

var elements = {
    button: document.getElementById("button"),
    image: document.getElementById("image")
};
function doStuff() {
    elements.image.src = "http://example.com/image_name.png";
}
function removeImage() {
    // image元素是body的子元素
    document.body.removeChild(document.getElementById("image"));
    // 這時(shí)我們還有一個(gè)對(duì) #image 的引用，這個(gè)引用在elements對(duì)象中
    // 換句話說(shuō)，image元素還在內(nèi)存中，不能被GC回收
}

涉及DOM樹內(nèi)的內(nèi)部節(jié)點(diǎn)或葉節(jié)點(diǎn)時(shí)，還有一個(gè)額外需要考慮的問題。如果在代碼中保留對(duì)表格單元格（標(biāo)記）的引用，并決定從DOM中刪除該表格并保留對(duì)該特定單元格的引用，則可以預(yù)期會(huì)出現(xiàn)嚴(yán)重的內(nèi)存泄漏。你可能會(huì)認(rèn)為垃圾回收器會(huì)釋放該這個(gè)單元格外的所有內(nèi)容。然而，情況并非如此。由于單元格是表格的子節(jié)點(diǎn)，并且子節(jié)點(diǎn)保持對(duì)父節(jié)點(diǎn)的引用，因此對(duì)表格單元格的這種單引用將使整個(gè)表格保留在內(nèi)存中，不能被GC回收。