Javascript內存泄漏

時間  2021-01-08 標籤 內存泄漏 javascript 阮一峯

最近在面試的過程中，面試官問到關於javascript中的內存泄漏問題。我當時只能想到「垃圾回收機制」和ES6中新增的weakSet等，至於內存泄漏一些的原理性問題沒能很好的回答，原因當然是我自己本人對這塊的知識也不是很清楚。回去的路上一直在百度和查文檔，發現阮一峯大牛對javascript內存泄漏這塊講的很詳細。所以站在巨人的肩膀上，在這裏轉載了阮大牛的技術文章，以供大家和自己學習。
原文地址：http://www.ruanyifeng.com/blog/2017/04/memory-leak.html

一、什麼是內存泄漏？

程序的運行需要內存。只要程序提出要求，操作系統或者運行時（runtime）就必須供給內存。
對於持續運行的服務進程（daemon），必須及時釋放不再用到的內存。否則，內存佔用越來越高，輕則影響系統性能，重則導致進程崩潰。
這裏寫圖片描述
不再用到的內存，沒有及時釋放，就叫做內存泄漏（memory leak）。
有些語言（比如 C 語言）必須手動釋放內存，程序員負責內存管理。

char * buffer;
buffer = (char*) malloc(42);

// Do something with buffer

free(buffer);
上面是 C 語言代碼，malloc方法用來申請內存，使用完畢之後，必須自己用free方法釋放內存。
這很麻煩，所以大多數語言提供自動內存管理，減輕程序員的負擔，這被稱爲」垃圾回收機制」（garbage collector）。

二、垃圾回收機制

垃圾回收機制怎麼知道，哪些內存不再需要呢？
最常使用的方法叫做」引用計數」（reference counting）：語言引擎有一張」引用表」，保存了內存裏面所有的資源（通常是各種值）的引用次數。如果一個值的引用次數是0，就表示這個值不再用到了，因此可以將這塊內存釋放。
這裏寫圖片描述
上圖中，左下角的兩個值，沒有任何引用，所以可以釋放。
如果一個值不再需要了，引用數卻不爲0，垃圾回收機制無法釋放這塊內存，從而導致內存泄漏。

const arr = [1, 2, 3, 4];
console.log(‘hello world’);
上面代碼中，數組[1, 2, 3, 4]是一個值，會佔用內存。變量arr是僅有的對這個值的引用，因此引用次數爲1。儘管後面的代碼沒有用到arr，它還是會持續佔用內存。
如果增加一行代碼，解除arr對[1, 2, 3, 4]引用，這塊內存就可以被垃圾回收機制釋放了。

let arr = [1, 2, 3, 4];
console.log(‘hello world’);
arr = null;
上面代碼中，arr重置爲null，就解除了對[1, 2, 3, 4]的引用，引用次數變成了0，內存就可以釋放出來了。
因此，並不是說有了垃圾回收機制，程序員就輕鬆了。你還是需要關注內存佔用：那些很佔空間的值，一旦不再用到，你必須檢查是否還存在對它們的引用。如果是的話，就必須手動解除引用。

三、內存泄漏的識別方法

怎樣可以觀察到內存泄漏呢？
經驗法則是，如果連續五次垃圾回收之後，內存佔用一次比一次大，就有內存泄漏。這就要求實時查看內存佔用。
3.1 瀏覽器
Chrome 瀏覽器查看內存佔用，按照以下步驟操作。
這裏寫圖片描述
打開開發者工具，選擇 Timeline 面板
在頂部的Capture字段裏面勾選 Memory
點擊左上角的錄製按鈕。
在頁面上進行各種操作，模擬用戶的使用情況。
一段時間後，點擊對話框的 stop 按鈕，面板上就會顯示這段時間的內存佔用情況。
如果內存佔用基本平穩，接近水平，就說明不存在內存泄漏。
這裏寫圖片描述
反之，就是內存泄漏了。
這裏寫圖片描述
3.2 命令行
命令行可以使用 Node 提供的process.memoryUsage方法。

console.log(process.memoryUsage());
// { rss: 27709440,
// heapTotal: 5685248,
// heapUsed: 3449392,
// external: 8772 }
process.memoryUsage返回一個對象，包含了 Node 進程的內存佔用信息。該對象包含四個字段，單位是字節，含義如下。
這裏寫圖片描述
rss（resident set size）：所有內存佔用，包括指令區和堆棧。
heapTotal：」堆」佔用的內存，包括用到的和沒用到的。
heapUsed：用到的堆的部分。
external： V8 引擎內部的 C++ 對象佔用的內存。
判斷內存泄漏，以heapUsed字段爲準。

四、WeakMap

前面說過，及時清除引用非常重要。但是，你不可能記得那麼多，有時候一疏忽就忘了，所以纔有那麼多內存泄漏。
最好能有一種方法，在新建引用的時候就聲明，哪些引用必須手動清除，哪些引用可以忽略不計，當其他引用消失以後，垃圾回收機制就可以釋放內存。這樣就能大大減輕程序員的負擔，你只要清除主要引用就可以了。
ES6 考慮到了這一點，推出了兩種新的數據結構：WeakSet 和 WeakMap。它們對於值的引用都是不計入垃圾回收機制的，所以名字裏面纔會有一個」Weak」，表示這是弱引用。
這裏寫圖片描述
下面以 WeakMap 爲例，看看它是怎麼解決內存泄漏的。

const wm = new WeakMap();

const element = document.getElementById(‘example’);

wm.set(element, ‘some information’);
wm.get(element) // 「some information」
上面代碼中，先新建一個 Weakmap 實例。然後，將一個 DOM 節點作爲鍵名存入該實例，並將一些附加信息作爲鍵值，一起存放在 WeakMap 裏面。這時，WeakMap 裏面對element的引用就是弱引用，不會被計入垃圾回收機制。
也就是說，DOM 節點對象的引用計數是1，而不是2。這時，一旦消除對該節點的引用，它佔用的內存就會被垃圾回收機制釋放。Weakmap 保存的這個鍵值對，也會自動消失。
基本上，如果你要往對象上添加數據，又不想幹擾垃圾回收機制，就可以使用 WeakMap。

五、WeakMap 示例

WeakMap 的例子很難演示，因爲無法觀察它裏面的引用會自動消失。此時，其他引用都解除了，已經沒有引用指向 WeakMap 的鍵名了，導致無法證實那個鍵名是不是存在。
我一直想不出辦法，直到有一天賀師俊老師提示，如果引用所指向的值佔用特別多的內存，就可以通過process.memoryUsage方法看出來。
根據這個思路，網友 vtxf 補充了下面的例子。
首先，打開 Node 命令行。

$ node –expose-gc
上面代碼中，–expose-gc參數表示允許手動執行垃圾回收機制。
然後，執行下面的代碼。

// 手動執行一次垃圾回收，保證獲取的內存使用狀態準確
> global.gc(); 
undefined

// 查看內存佔用的初始狀態，heapUsed 爲 4M 左右
> process.memoryUsage(); 
{ rss: 21106688,
  heapTotal: 7376896,
  heapUsed: 4153936,
  external: 9059 }

> let wm = new WeakMap();
undefined

> let b = new Object();
undefined

> global.gc();
undefined

// 此時，heapUsed 仍然爲 4M 左右
> process.memoryUsage(); 
{ rss: 20537344,
  heapTotal: 9474048,
  heapUsed: 3967272,
  external: 8993 }

// 在 WeakMap 中添加一個鍵值對，
// 鍵名爲對象 b，鍵值爲一個 5*1024*1024 的數組  
> wm.set(b, new Array(5*1024*1024));
WeakMap {}

// 手動執行一次垃圾回收
> global.gc();
undefined

// 此時，heapUsed 爲 45M 左右
> process.memoryUsage(); 
{ rss: 62652416,
  heapTotal: 51437568,
  heapUsed: 45911664,
  external: 8951 }

// 解除對象 b 的引用  
> b = null;
null

// 再次執行垃圾回收
> global.gc();
undefined

// 解除 b 的引用以後，heapUsed 變回 4M 左右
// 說明 WeakMap 中的那個長度爲 5*1024*1024 的數組被銷燬了
> process.memoryUsage(); 
{ rss: 20639744,
  heapTotal: 8425472,
  heapUsed: 3979792,
  external: 8956 }

上面代碼中，只要外部的引用消失，WeakMap 內部的引用，就會自動被垃圾回收清除。由此可見，有了它的幫助，解決內存泄漏就會簡單很多。

六、3種常見的JavaScript泄漏

1.意外的全局變量

JavaScript的目標是開發一種看起來像Java但足夠自由的被初學者使用的語言。JavaScript自由的其中一種方式是它可以處理沒有聲明的變量：一個未聲明的變量的引用在全局對象中創建了一個新變量。在瀏覽器的環境中，全局對象是window。也就是說：

function foo(arg) {
bar = 「this is a hidden global variable」;
}
實際上是：

function foo(arg) {
window.bar = 「this is an explicit global variable」;
}
如果bar是僅在foo函數作用域內承載引用，並且你忘記用var來聲明的變量，一個意外的全局變量就被創建了。在這個例子中，泄漏一個單一字符串不會有太大害處，但這的確是不好的。
另一種意外全局變量被創建的方式是通過this：

function foo() {
this.variable = 「potential accidental global」;
}
// Foo called on its own, this points to the global object (window)
// rather than being undefined.
foo();
爲了阻止這種錯誤發生，在你的Javascript文件最前面添加’use strict;’。這開啓瞭解析JavaScript的阻止意外全局的更嚴格的模式。

全局變量的一個注意事項：

即使我們談了不明的全局變量，仍然存在很多代碼被顯式的全局變量填充的情況。這是通過定義不可收集的情況（除非清零或重新賦值）。特別的，用來臨時存儲和處理大量信息的全局變量會引起關注。如果必須用全局變量來存儲很多數據，在處理完之後，確保對其清零或重新賦值。 一個在與全局連接上增加內存消耗常見的原因是緩存)。 緩存存儲重複被使用的數據。爲此，爲了有效，緩存必須有其大小的上限。飆出限制的緩存可能會因爲內容不可被回收，導致高內存消耗。

2.被遺忘的計時器或回調

在JavaScript中setInterval的使用相當常見。其他庫提供觀察者和其他工具以回調。這些庫中大多數，在引用的實例變成不可訪問之後，負責讓回調的任何引用也不可訪問。在setInterval的情況下，這樣的代碼很常見：

var someResource = getData();
setInterval(function() {
var node = document.getElementById(‘Node’);
if(node) {
// Do stuff with node and someResource.
node.innerHTML = JSON.stringify(someResource));
}
}, 1000);
這個例子表明了跳動的計時器可能發生什麼：計時器使得節點或數據的引用不再被需要了。代表node的對象將來可能被移除，使得整個塊在間隔中的處理不必要。然而，處理函數，由於間隔仍然是活躍的，不能被回收（間隔需要被停掉才能回收）。如果間隔處理不能被回收，它的依賴也不能被回收。那意味着可能存儲着大量數據的someResource，也不能被回收。
觀察者情況下，一旦不被需要（或相關的對象快要訪問不到）就創建明確移除他們的函數很重要。在過去，這由於特定瀏覽器（IE6）不能很好的管理循環引用（下面有更多相關信息），曾經尤爲重要。現如今，一旦觀察對象變成不可訪問的，即使收聽者沒有明確的被移除，多數瀏覽器可以並會回收觀察者處理函數。然而，它保持了在對象被處理前明確的移除這些觀察者的好實踐。例如：

var element = document.getElementById(‘button’);
function onClick(event) {
element.innerHtml = ‘text’;
}
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.
一條關於對象觀察者及循環引用的筆記

觀察者和循環引用曾經是JavaScript開發者的禍患。這是由於IE垃圾回收的一個bug(或者設計決議)出現的情況。IE的老版本不能檢測到DOM節點和JavaScript代碼間的循環引用。 這是一個通常爲觀察到的保留引用（如同上面的例子）的觀察者的典型。 也就是說，每次在IE中對一個節點添加觀察者的時候，會導致泄漏。這是開發者在節點或空引用之前開始明確的移除處理函數的原因。 現在，現代瀏覽器（包括IE和MS Edge）使用可以剪裁這些循環和正確處理的現代垃圾回收算法。換言之，在使一個節點不可訪問前，調用removeEventLister不是嚴格意義上必須的。

像Jquery一樣的框架和庫做了在處置一個節點前（當爲其使用特定的API的時候）移除監聽者的工作。這被在庫內部處理，即使在像老版本IE一樣有問題的瀏覽器裏面跑，也會確保沒有泄漏產生。

3. 超出DOM引用

有時存儲DOM節點到數據結構中可能有用。假設你想要迅速的更新一個表格幾行內容。存儲每個DOM行節點的引用到一個字典或數組會起作用。當這發生是，兩個對於同個DOM元素的引用被留存：一個在DOM樹中，另外一個在字典中。如果在將來的某些點你決定要移除這些行，需要讓兩個引用都不可用。

var elements = {
button: document.getElementById(‘button’),
image: document.getElementById(‘image’),
text: document.getElementById(‘text’)
};
function doStuff() {
image.src = ‘http://some.url/image‘;
button.click();
console.log(text.innerHTML);
// Much more logic
}
function removeButton() {
// The button is a direct child of body.
document.body.removeChild(document.getElementById(‘button’));
// At this point, we still have a reference to #button in the global
// elements dictionary. In other words, the button element is still in
// memory and cannot be collected by the GC.
}
對此的額外考慮，必須處理DOM樹內的內部節點或葉子節點。假設你在JavaScript代碼中保留了一個對於特定的表格內節點（一個td標籤）的引用。在將來的某個點決定從DOM中移除這個表格，但是保留對於那個節點的引用。直觀的，會假設GC會回收除那個節點之外的每個節點。在實踐中，這不會發生的：這個單節點是那個表格的子節點，子節點保留對父節點引用。換句話說，來自JavaScript代碼的表格元素的引用會引起在內存裏存整個表格。當保留DOM元素的引用的時候，仔細考慮下。

4.閉包

一個JavaScript開發的關鍵點是閉包：從父級作用域捕獲變量的匿名函數。很多開發者發現，由於JavaScript runtime的實現細節，有以一種微妙的方式泄漏的可能，這種特殊的情況：

var theThing = null;
var replaceThing = function () {
var originalThing = theThing;
var unused = function () {
if (originalThing)
console.log(「hi」);
};
theThing = {
longStr: new Array(1000000).join(‘*’),
someMethod: function () {
console.log(someMessage);
}
};
};
setInterval(replaceThing, 1000);
這個代碼片段做了一件事：每次replaceThing被調用的時候，theThing獲取到一個包括一個大數組和新閉包(somMethod)的新對象。同時，變量unused保留了一個有originalThing（theThing從之前的對replaceThing的調用）引用的閉包。已經有點疑惑了，哈？重要的是一旦一個作用域被在同個父作用域下的閉包創建，那個作用域是共享的。這種情況下，爲閉包somMethod創建的作用域被unused共享了。unused有一個對originalThing的引用。即使unused從來沒被用過，someMethod可以通過theTing被使用。由於someMethod和unused共享了閉包作用域，即使unused從來沒被用過，它對originalThing的引用迫使它停留在活躍狀態（不能回收）。當這個代碼片段重複運行的時候，可以看到內存使用穩步的增長。GC運行的時候，這並不會減輕。本質上，一組關聯的閉包被創建（同unused變量在表單中的根節點一起），這些閉包作用域中每個帶了大數組一個非直接的引用，導致了大型的泄漏。

這是一個實現構件。一個可以處理這關係的閉包的不同實現是可以想象的，就如在這篇博客中解釋的一樣。

垃圾回收的直觀行爲
即使垃圾回收很方便，他們有自己的一套權衡方法。其中一個權衡是nondeterminism。也就是說，GC是不可預期的。通常不能確定什麼時候回收器被執行。這意味着在一些情況下，需要比程序正在使用的更多的內存。其他情況下，短的暫停在特別敏感的應用中很明顯。即使不確定性意味着不能確定回收什麼時候執行，大多數GC實現共享在分配期間，普通的回收通行證模式。如果沒有執行分配，大多數CG停留在休息狀態。考慮下面的方案：

1.執行一組大型的分配。

2.多數元素（或所有）被標記爲不可訪問（假設我們置空了一個指向不再需要的緩存的引用）。

3.沒有進一步的分配執行了。

在這個方案中，大多GC不會運行任何進一步的回收通行了。換言之，即使有可用於回收的，不可訪問的引用，回收器不會要求他了。這不是嚴格的泄漏，但是也會導致比平常更高的內存使用率。
Google在 JavaScript Memory Profiling docs, example #2.文章中，提供了一個優秀的例子。
原文地址：http://blog.csdn.net/web_lc/article/details/72920029

七、參考鏈接

  • Simple Guide to Finding a JavaScript Memory Leak in Node.js
  • Understanding Garbage Collection and hunting Memory Leaks in Node.js
  • Debugging Memory Leaks in Node.js Applications
联系我们 沪ICP备13005482号-10