本文將探索常見的客戶端 JavaScript 內存泄漏,以及如何使用 Chrome 開發工具發現問題。
簡介
內存泄漏是每個開發者最終都要面對的問題,它是許多問題的根源:反應遲緩,崩潰,高延遲,以及其他應用問題。
什麼是內存泄漏?
本質上,內存泄漏可以定義爲:應用程序不再需要佔用內存的時候,由於某些原因,內存沒有被操作系統或可用內存池回收。編程語言管理內存的方式各不相同。只有開發者最清楚哪些內存不需要了,操作系統可以回收。一些編程語言提供了語言特性,可以幫助開發者做此類事情。另一些則寄希望於開發者對內存是否需要清晰明瞭。
JavaScript 內存管理
JavaScript 是一種垃圾回收語言。垃圾回收語言通過週期性地檢查先前分配的內存是否可達,幫助開發者管理內存。換言之,垃圾回收語言減輕了“內存仍可用”及“內存仍可達”的問題。兩者的區別是微妙而重要的:僅有開發者瞭解哪些內存在將來仍會使用,而不可達內存通過算法確定和標記,適時被操作系統回收。
JavaScript 內存泄漏
垃圾回收語言的內存泄漏主因是不需要的引用。理解它之前,還需瞭解垃圾回收語言如何辨別內存的可達與不可達。
Mark-and-sweep
大部分垃圾回收語言用的算法稱之爲 Mark-and-sweep 。算法由以下幾步組成:
- 垃圾回收器創建了一個“roots”列表。Roots 通常是代碼中全局變量的引用。JavaScript 中,“window” 對象是一個全局變量,被當作 root 。window 對象總是存在,因此垃圾回收器可以檢查它和它的所有子對象是否存在(即不是垃圾);
- 所有的 roots 被檢查和標記爲激活(即不是垃圾)。所有的子對象也被遞歸地檢查。從 root 開始的所有對象如果是可達的,它就不被當作垃圾。
- 所有未被標記的內存會被當做垃圾,收集器現在可以釋放內存,歸還給操作系統了。
現代的垃圾回收器改良了算法,但是本質是相同的:可達內存被標記,其餘的被當作垃圾回收。
不需要的引用是指開發者明知內存引用不再需要,卻由於某些原因,它仍被留在激活的 root 樹中。在 JavaScript 中,不需要的引用是保留在代碼中的變量,它不再需要,卻指向一塊本該被釋放的內存。有些人認爲這是開發者的錯誤。
爲了理解 JavaScript 中最常見的內存泄漏,我們需要了解哪種方式的引用容易被遺忘。
三種類型的常見 JavaScript 內存泄漏
1:意外的全局變量
JavaScript 處理未定義變量的方式比較寬鬆:未定義的變量會在全局對象創建一個新變量。在瀏覽器中,全局對象是 window 。
1 2 3 | function foo(arg) { bar = "this is a hidden global variable"; } |
真相是:
1
2
3
|
function
foo(arg)
{
window.bar
=
"this is an explicit global
variable";
}
|
函數 foo 內部忘記使用 var ,意外創建了一個全局變量。此例泄漏了一個簡單的字符串,無傷大雅,但是有更糟的情況。
另一種意外的全局變量可能由 this 創建:
1 2 3 4 5 6 7 | function foo() { this.variable = "potential accidental global"; } // Foo 調用自己,this 指向了全局對象(window) // 而不是 undefined foo(); |
在 JavaScript 文件頭部加上 ‘use strict’,可以避免此類錯誤發生。啓用嚴格模式解析 JavaScript ,避免意外的全局變量。
全局變量注意事項
儘管我們討論了一些意外的全局變量,但是仍有一些明確的全局變量產生的垃圾。它們被定義爲不可回收(除非定義爲空或重新分配)。尤其當全局變量用於臨時存儲和處理大量信息時,需要多加小心。如果必須使用全局變量存儲大量數據時,確保用完以後把它設置爲 null 或者重新定義。與全局變量相關的增加內存消耗的一個主因是緩存。緩存數據是爲了重用,緩存必須有一個大小上限纔有用。高內存消耗導致緩存突破上限,因爲緩存內容無法被回收。
2:被遺忘的計時器或回調函數
在 JavaScript 中使用 setInterval 非常平常。一段常見的代碼:
1
2
3
4
5
6
7
8
|
var
someResource
=
getData();
setInterval(function()
{
var
node
=
document.getElementById('Node');
if(node)
{
//
處理 node 和 someResource
node.innerHTML
=
JSON.stringify(someResource));
}
},
1000);
|
此例說明了什麼:與節點或數據關聯的計時器不再需要,node 對象可以刪除,整個回調函數也不需要了。可是,計時器回調函數仍然沒被回收(計時器停止纔會被回收)。同時,someResource 如果存儲了大量的數據,也是無法被回收的。
對於觀察者的例子,一旦它們不再需要(或者關聯的對象變成不可達),明確地移除它們非常重要。老的 IE 6 是無法處理循環引用的。如今,即使沒有明確移除它們,一旦觀察者對象變成不可達,大部分瀏覽器是可以回收觀察者處理函數的。
觀察者代碼示例:
1 2 3 4 5 6 | var element = document.getElementById('button'); function onClick(event) { element.innerHTML = 'text'; } element.addEventListener('click', onClick); |
對象觀察者和循環引用注意事項
老版本的 IE 是無法檢測 DOM 節點與 JavaScript 代碼之間的循環引用,會導致內存泄漏。如今,現代的瀏覽器(包括 IE 和 Microsoft Edge)使用了更先進的垃圾回收算法,已經可以正確檢測和處理循環引用了。換言之,回收節點內存時,不必非要調用 removeEventListener 了。
3:脫離 DOM 的引用
有時,保存 DOM 節點內部數據結構很有用。假如你想快速更新表格的幾行內容,把每一行 DOM 存成字典(JSON 鍵值對)或者數組很有意義。此時,同樣的 DOM 元素存在兩個引用:一個在 DOM 樹中,另一個在字典中。將來你決定刪除這些行時,需要把兩個引用都清除。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
|
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);
//
更多邏輯
}
function
removeButton()
{
//
按鈕是 body 的後代元素
document.body.removeChild(document.getElementById('button'));
//
此時,仍舊存在一個全局的 #button 的引用
//
elements 字典。button 元素仍舊在內存中,不能被 GC 回收。
}
|
此外還要考慮 DOM 樹內部或子節點的引用問題。假如你的 JavaScript 代碼中保存了表格某一個 <td> 的引用。將來決定刪除整個表格的時候,直覺認爲 GC 會回收除了已保存的 <td> 以外的其它節點。實際情況並非如此:此<td> 是表格的子節點,子元素與父元素是引用關係。由於代碼保留了 <td> 的引用,導致整個表格仍待在內存中。保存 DOM 元素引用的時候,要小心謹慎。
4:閉包
閉包是 JavaScript 開發的一個關鍵方面:匿名函數可以訪問父級作用域的變量。
代碼示例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 | 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 得到一個包含一個大數組和一個新閉包(someMethod)的新對象。同時,變量 unused 是一個引用 originalThing 的閉包(先前的 replaceThing 又調用了 theThing )。思緒混亂了嗎?最重要的事情是,閉包的作用域一旦創建,它們有同樣的父級作用域,作用域是共享的。someMethod 可以通過 theThing 使用,someMethod 與 unused 分享閉包作用域,儘管 unused 從未使用,它引用的 originalThing 迫使它保留在內存中(防止被回收)。當這段代碼反覆運行,就會看到內存佔用不斷上升,垃圾回收器(GC)並無法降低內存佔用。本質上,閉包的鏈表已經創建,每一個閉包作用域攜帶一個指向大數組的間接的引用,造成嚴重的內存泄漏。
Meteor 的博文 解釋瞭如何修復此種問題。在 replaceThing 的最後添加 originalThing = null 。
Chrome 內存剖析工具概覽
Chrome 提供了一套很棒的檢測 JavaScript 內存佔用的工具。與內存相關的兩個重要的工具:timeline 和 profiles。
Timeline
timeline 可以檢測代碼中不需要的內存。在此截圖中,我們可以看到潛在的泄漏對象穩定的增長,數據採集快結束時,內存佔用明顯高於採集初期,Node(節點)的總量也很高。種種跡象表明,代碼中存在 DOM 節點泄漏的情況。
Profiles
Profiles 是你可以花費大量時間關注的工具,它可以保存快照,對比 JavaScript 代碼內存使用的不同快照,也可以記錄時間分配。每一次結果包含不同類型的列表,與內存泄漏相關的有 summary(概要) 列表和 comparison(對照) 列表。
summary(概要) 列表展示了不同類型對象的分配及合計大小:shallow size(特定類型的所有對象的總大小),retained size(shallow size 加上其它與此關聯的對象大小)。它還提供了一個概念,一個對象與關聯的 GC root 的距離。
對比不同的快照的 comparison list 可以發現內存泄漏。
實例:使用 Chrome 發現內存泄漏
實質上有兩種類型的泄漏:週期性的內存增長導致的泄漏,以及偶現的內存泄漏。顯而易見,週期性的內存泄漏很容易發現;偶現的泄漏比較棘手,一般容易被忽視,偶爾發生一次可能被認爲是優化問題,週期性發生的則被認爲是必須解決的 bug。
以 Chrome 文檔中的代碼爲例:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
var
x
=
[];
function
createSomeNodes()
{
var
div,
i
=
100,
frag
=
document.createDocumentFragment();
for
(;i
>
0;
i--)
{
div
=
document.createElement("div");
div.appendChild(document.createTextNode(i
+
" - "+
new
Date().toTimeString()));
frag.appendChild(div);
}
document.getElementById("nodes").appendChild(frag);
}
function
grow()
{
x.push(new
Array(1000000).join('x'));
createSomeNodes();
setTimeout(grow,1000);
}
|
當 grow 執行的時候,開始創建 div 節點並插入到 DOM 中,並且給全局變量分配一個巨大的數組。通過以上提到的工具可以檢測到內存穩定上升。
找出週期性增長的內存
timeline 標籤擅長做這些。在 Chrome 中打開例子,打開 Dev Tools ,切換到 timeline,勾選 memory 並點擊記錄按鈕,然後點擊頁面上的 The Button 按鈕。過一陣停止記錄看結果:
兩種跡象顯示出現了內存泄漏,圖中的 Nodes(綠線)和 JS heap(藍線)。Nodes 穩定增長,並未下降,這是個顯著的信號。
JS heap 的內存佔用也是穩定增長。由於垃圾收集器的影響,並不那麼容易發現。圖中顯示內存佔用忽漲忽跌,實際上每一次下跌之後,JS heap 的大小都比原先大了。換言之,儘管垃圾收集器不斷的收集內存,內存還是週期性的泄漏了。
確定存在內存泄漏之後,我們找找根源所在。
保存兩個快照
切換到 Chrome Dev Tools 的 profiles 標籤,刷新頁面,等頁面刷新完成之後,點擊 Take Heap Snapshot 保存快照作爲基準。而後再次點擊 The Button 按鈕,等數秒以後,保存第二個快照。
篩選菜單選擇 Summary,右側選擇 Objects allocated between Snapshot 1 and Snapshot 2,或者篩選菜單選擇 Comparison ,然後可以看到一個對比列表。
此例很容易找到內存泄漏,看下 (string) 的 Size Delta Constructor,8MB,58個新對象。新對象被分配,但是沒有釋放,佔用了8MB。
如果展開 (string) Constructor,會看到許多單獨的內存分配。選擇某一個單獨的分配,下面的 retainers 會吸引我們的注意。
我們已選擇的分配是數組的一部分,數組關聯到 window 對象的 x 變量。這裏展示了從巨大對象到無法回收的 root(window)的完整路徑。我們已經找到了潛在的泄漏以及它的出處。
我們的例子還算簡單,只泄漏了少量的 DOM 節點,利用以上提到的快照很容易發現。對於更大型的網站,Chrome 還提供了 Record Heap Allocations 功能。
Record heap allocations 找內存泄漏
回到 Chrome Dev Tools 的 profiles 標籤,點擊 Record Heap Allocations。工具運行的時候,注意頂部的藍條,代表了內存分配,每一秒有大量的內存分配。運行幾秒以後停止。
上圖中可以看到工具的殺手鐗:選擇某一條時間線,可以看到這個時間段的內存分配情況。儘可能選擇接近峯值的時間線,下面的列表僅顯示了三種 constructor:其一是泄漏最嚴重的(string),下一個是關聯的 DOM 分配,最後一個是 Text constructor(DOM 葉子節點包含的文本)。
從列表中選擇一個 HTMLDivElement constructor,然後選擇 Allocation stack。
現在知道元素被分配到哪裏了吧(grow -> createSomeNodes),仔細觀察一下圖中的時間線,發現 HTMLDivElement constructor 調用了許多次,意味着內存一直被佔用,無法被 GC 回收,我們知道了這些對象被分配的確切位置(createSomeNodes)。回到代碼本身,探討下如何修復內存泄漏吧。
另一個有用的特性
在 heap allocations 的結果區域,選擇 Allocation。
這個視圖呈現了內存分配相關的功能列表,我們立刻看到了 grow 和 createSomeNodes。當選擇 grow 時,看看相關的 object constructor,清楚地看到 (string), HTMLDivElement 和 Text 泄漏了。
結合以上提到的工具,可以輕鬆找到內存泄漏。
原文地址:http://web.jobbole.com/86244/