[[416172]]

很多開(kāi)發(fā)者可能平時(shí)并不關(guān)心自己維護(hù)的頁(yè)面是否存在內(nèi)存泄漏，原因可能是剛開(kāi)始簡(jiǎn)單的頁(yè)面內(nèi)存泄漏的速度很緩慢，在造成嚴(yán)重卡頓之前可能就被用戶刷新了，問(wèn)題也就被隱藏了，但是隨著頁(yè)面越來(lái)越復(fù)雜，尤其當(dāng)你的頁(yè)面是 SAP 方式交互時(shí)，內(nèi)存泄漏的隱患便越來(lái)越嚴(yán)重，直到突然有一天用戶反饋說(shuō)：“操作一會(huì)兒頁(yè)面就卡住不動(dòng)了，也不知道為什么，以前不這樣的呀”。

這篇文章通過(guò)一些簡(jiǎn)單的例子介紹內(nèi)存泄漏的調(diào)查方法、總結(jié)內(nèi)存泄漏出現(xiàn)的原因和常見(jiàn)情況，并針對(duì)每種情況總結(jié)如何避免內(nèi)存泄漏。希望能對(duì)大家有所幫助。

一 一個(gè)簡(jiǎn)單的例子

先看一個(gè)簡(jiǎn)單的例子，下面是這個(gè)例子對(duì)應(yīng)的代碼：

代碼 1

代碼 1 的邏輯很簡(jiǎn)單：點(diǎn)擊“add date”按鈕時(shí)會(huì)向 dateAry 數(shù)組中 push 3000 個(gè) new Date 對(duì)象，點(diǎn)擊“clear”按鈕時(shí)將 dateAry 清空。很明顯，“add date”操作會(huì)造成內(nèi)存占用不斷增長(zhǎng)，如果將這個(gè)邏輯用在實(shí)際應(yīng)用中便會(huì)造成內(nèi)存泄漏（不考慮故意將代碼邏輯設(shè)計(jì)成這樣的情況），下面我們看一下如何調(diào)查這種內(nèi)存增長(zhǎng)出現(xiàn)的原因以及如何找出內(nèi)存泄漏點(diǎn)。

1 heap snapshot

為了避免瀏覽器插件的干擾，我們?cè)?chrome 中新建一個(gè)無(wú)痕窗口打開(kāi)上述代碼。然后在 chrome 的 devtools 中的 Memory 工具中找到 “Heap Snapshot”工具，點(diǎn)擊左上角的錄制按鈕錄制一個(gè) Snapshot，然后點(diǎn)擊“add date”按鈕，在手動(dòng)觸發(fā) GC（Garbage Collect）之后，再次錄制一個(gè) Snapshot，反復(fù)執(zhí)行上述操作若干次，像圖 1 中操作的那樣，得到一系列的 Snapshot。

 圖 2 錄制的 Snapshot 組

參考【代碼 1】我們可以知道，“add date”按鈕在被點(diǎn)擊時(shí)，會(huì)向 dateAry 數(shù)組中 push 3000 個(gè)新的 Date 對(duì)象，而在圖 2 中的 Date 構(gòu)造器的右側(cè)可以看到這 3000 個(gè) Date 對(duì)象（Date x 3000），它對(duì)應(yīng)的正式我們的循環(huán)創(chuàng)建的那 3000 個(gè) Date 對(duì)象。綜合上面的操作我們可以知道，chorome devtools 中的 Memroy 的 Heap Snapshot 工具可以錄制某一個(gè)時(shí)刻的所有內(nèi)存對(duì)象，也就是一個(gè)“快照”，快照中按“構(gòu)造器”分組，展示了所有被記錄下來(lái)的 JS 對(duì)象。

如果這個(gè)頁(yè)面是一個(gè)實(shí)際服務(wù)于用戶的網(wǎng)站的某個(gè)頁(yè)面話（用戶可能非常頻繁的點(diǎn)擊“add date”按鈕，作者可能想記錄用戶點(diǎn)擊的次數(shù)？也許吧，雖然我也不知道他什么要這么做）隨著用戶使用時(shí)間的增長(zhǎng)，“add date”按鈕的反應(yīng)就會(huì)越來(lái)越慢，整體頁(yè)面也隨之越來(lái)越卡，原因除了系統(tǒng)的內(nèi)存資源被占用之外，還有 GC 的頻率和時(shí)長(zhǎng)增長(zhǎng)，如圖 3 所示，因?yàn)?GC 執(zhí)行的過(guò)程中 JS 的執(zhí)行是被暫停的，所以頁(yè)面就會(huì)呈現(xiàn)出越來(lái)越卡的樣子。

圖 3 Performance 錄制的 GC 占比

圖 4 chrome 的任務(wù)管理器

最終：

圖 5 內(nèi)存占用過(guò)高導(dǎo)致瀏覽器崩潰

那么，在這個(gè)“實(shí)際”的場(chǎng)景下，如何找出那“作祟”的 3000 個(gè) Date 對(duì)象呢？我們首先想到的應(yīng)該是就是：之前不是錄制了好多個(gè) Snapshot 嗎？可不可以把它們做對(duì)比找到“差異”呢，從差異中找到增長(zhǎng)的地方不就行了？思路非常正確，在此之前我們?cè)俜治鲆幌逻@幾個(gè) Snapshot：每次點(diǎn)擊“add date”按鈕、手動(dòng)觸發(fā) GC、得到的 Snapshot 的大小相比上一次都有所增加，如果這種內(nèi)存的增長(zhǎng)現(xiàn)象不符合“預(yù)期”的話（顯然在這個(gè)“實(shí)際”的例子中是不符合預(yù)期的），那么這里就有很大的嫌疑存在內(nèi)存泄漏。

這個(gè)時(shí)候我們選中 Snapshot 2，在圖 2 所示的 " Summary" 處選擇“Comparison”，在右側(cè)的 "All objects" 處選擇 Snapshot 1，這樣一來(lái)，Constructor 里展示便是 Snapshot 1 和 Snapshot 2 的對(duì)比，通過(guò)觀察不難發(fā)現(xiàn)，圖中的 +144KB 最值得懷疑，于是我們選中它的構(gòu)造器 Date，展開(kāi)選中任意子項(xiàng)看詳情，發(fā)現(xiàn)其是被 Array 構(gòu)造器構(gòu)造出來(lái)的 dateAry 持有的（即 dateAry 中的一員）,并且 dateAry 被三個(gè)地方持有，其中系統(tǒng)內(nèi)部的 array 我們不用理會(huì)，圖 6 中寫(xiě)有 "context in ()" 地方給了我們持有 dateAry 的 context 所在的位置，點(diǎn)擊便可以跳到代碼所在的位置了，整個(gè)操作如圖 6 所示：

圖 6 定位代碼位置

這里有一個(gè)值得注意的地方，圖 6 中的 “context in () @449305” 中的 "()"，這里之所以展示為了 "()" 是因?yàn)榇a中用了“匿名函數(shù)”（代碼 2 中第 2 行的箭頭函數(shù)）：

// 【寫(xiě)入 date】pushDate.addEventListener("click", () => {    dateCount.innerHTML = `${++dateNum}`;    for (let j = 0; j < 3000; ++j) {        dateAry.push(new Date());    }}); 

代碼 2 匿名函數(shù)

但是如果我們給函數(shù)起一個(gè)名字，如下面的代碼所示，也就是如果我們使用具名函數(shù)（代碼3 第 2 行函數(shù) add）或者將函數(shù)賦值給一個(gè)變量并使用這個(gè)變量（第 10 和 18 行的行為）的時(shí)候，devtools 中都可以看到相應(yīng)的函數(shù)的名字，這也就可以幫助我們更好的定位代碼，如圖 7 所示。

// 【寫(xiě)入 date】pushDate.addEventListener("click", function add() {    dateCount.innerHTML = `${++dateNum}`;    for (let j = 0; j < 3000; ++j) {        dateAry.push(new Date());    }});const clear = document.querySelector(".clear");const doClear = function () {    dateAry = [];    dateCount.innerHTML = "0";};// 【回收內(nèi)存】clear.addEventListener("click", doClear); 

代碼 3 具名函數(shù)

圖 7 具名函數(shù)方便定位

這樣我們便找到了代碼可疑的地方，只需要將代碼的作者抓過(guò)來(lái)對(duì)著他一頓“分析”這個(gè)內(nèi)存泄漏的問(wèn)題基本就水落石出了。

其實(shí)，Snapshot 除了“Comparison”之外還有一個(gè)更便捷的用于對(duì)比的入口，在這里直接可以看到在錄制 Snapshot 1 和 Snapshot 2 兩個(gè)時(shí)間點(diǎn)之間被分配出來(lái)的內(nèi)存，用這種方式也可以定位到那個(gè)可疑的 Date x 3000：

圖 8 Snapshot 比較器

上文件介紹的是用 Heap Snapshot 尋找內(nèi)存泄漏點(diǎn)的方法，這個(gè)方法的優(yōu)點(diǎn)：可以錄制多個(gè) Snapshot，然后方便的兩兩比較，并且能看到 Snapshot 中的全量?jī)?nèi)存，這一點(diǎn)是下文要講的“Allocation instrumentation on timeline”方法不具備的，并且這種方法可以更加方便地查找后面會(huì)講的因 Detached Dom 導(dǎo)致的內(nèi)存泄漏。

2 Allocation instrumentation on timeline

但是，不知道你有沒(méi)有覺(jué)得，這種高頻率地錄制 Snapshot、對(duì)比、再對(duì)比的方式有點(diǎn)兒麻煩？我需要不斷的去點(diǎn)擊“add date”，然后鼠標(biāo)又要跑過(guò)去點(diǎn)擊手動(dòng) GC、錄制 Snapshot、等待錄制完畢，再去操作，再去錄制。有沒(méi)有簡(jiǎn)單一些的方式來(lái)查找內(nèi)存泄漏？這個(gè)時(shí)候我們回到 Memory 最初始的界面，你突然發(fā)現(xiàn) “Heap snapshot”下面還有一個(gè) radio：“Allocation instrumentation on timeline”，并且這個(gè) radio 下面的介紹文案的最后寫(xiě)著：“Use this profile type to isolate memory leaks”，原來(lái)這是一個(gè)專(zhuān)門(mén)用于調(diào)查內(nèi)存泄漏的工具！于是，我們選中這個(gè) radio，點(diǎn)擊開(kāi)始錄制按鈕，然后將注意力放在頁(yè)面上，然后你發(fā)現(xiàn)當(dāng)點(diǎn)擊“add date”按鈕時(shí)，右面錄制的 timeline 便會(huì)多出一個(gè)心跳：

圖 9 Allocation instrumentation on timeline

如圖 9 所示，每當(dāng)我們點(diǎn)擊“add date”按鈕時(shí)，右面都有一個(gè)對(duì)應(yīng)的心跳，當(dāng)我們點(diǎn)擊“clear”按鈕時(shí)，剛才出現(xiàn)的所有心跳便全都“縮回”去了，于是我們得出結(jié)論：每一個(gè)“心跳”都是一次內(nèi)存分配，其高度代表內(nèi)存分配的量，在之后的時(shí)間推移過(guò)程中，如果剛才心跳對(duì)應(yīng)的被分配的內(nèi)存被 GC 回收了，“心跳”便會(huì)跟著變化為回收之后的高度。于是，我們便擺脫了在 Snapshot 中來(lái)回操作、錄制的窘境，只需要將注意力集中在頁(yè)面的操作上，并觀察哪個(gè)操作在右邊的時(shí)間線變化中是可疑的。

經(jīng)過(guò)一系列操作，我們發(fā)現(xiàn)“add date”這個(gè)按鈕的點(diǎn)擊行為很可疑，因?yàn)樗峙涞膬?nèi)存不會(huì)自動(dòng)被回收，也就是只要點(diǎn)擊一次，內(nèi)存就會(huì)增長(zhǎng)一點(diǎn)，我們停止錄制，得到了一個(gè) timeline 的 Snapshot，這個(gè)時(shí)候如果我們點(diǎn)擊某個(gè)心跳的話：

圖 10 點(diǎn)擊某個(gè)心跳

熟悉的 Date x 3000 又出現(xiàn)了（圖 11），點(diǎn)擊一個(gè) Date 對(duì)象看持有鏈，接下來(lái)便跟上文 Snapshot 的持有鏈分析一樣了：

圖 11 通過(guò) timeline 找到泄漏點(diǎn)

這個(gè)方法的優(yōu)點(diǎn)上文已經(jīng)說(shuō)明，可以非常直觀、方便的觀察內(nèi)存隨可疑操作的分配與回收過(guò)程，可以方便的觀察每次分配的內(nèi)存。它的缺點(diǎn)：錄制時(shí)間較長(zhǎng)時(shí) devtools 收集錄制結(jié)果的時(shí)間會(huì)很長(zhǎng)，甚至有時(shí)候會(huì)卡死瀏覽器；下文會(huì)講到 detached DOM，這個(gè)工具不能比較出 detached DOM，而 heap snapshot 可以。

3 performance

devtools 中的 Performance 面版中也有一個(gè) Memory 功能，下面看一下它如何使用。我們把 Memory 勾選上，并錄制一個(gè) performance 結(jié)果：

圖 12 Performance 的錄制過(guò)程

在圖 12 中可以看到，在錄制的過(guò)程中我們連續(xù)點(diǎn)擊“add date”按鈕 10 次，然后點(diǎn)擊一次“clear”按鈕，然后再次點(diǎn)擊“add date” 10 次，得到的最終結(jié)果如圖 13 所示：

圖 13 Performance 的錄制結(jié)果

在圖 13 中我們可以得到下面的信息：

整個(gè)操作過(guò)程中內(nèi)存的走勢(shì)：參見(jiàn)圖 13 下方的位置，第一輪點(diǎn)擊 10 次的過(guò)程中內(nèi)存不斷增長(zhǎng)，點(diǎn) clear 之后內(nèi)存斷崖式下跌，第二輪點(diǎn)擊 10 次內(nèi)存又不斷增長(zhǎng)。這也是這個(gè)工具的主要作用：得到可疑操作的內(nèi)存走勢(shì)圖，如果內(nèi)存持續(xù)走高則有理由懷疑此操作由內(nèi)存泄漏的可能。
內(nèi)存的增長(zhǎng)量：參見(jiàn) JS Heap 位置，鼠標(biāo)放上去可以看見(jiàn)每個(gè)階梯上下位置的內(nèi)存增長(zhǎng)/下跌的量
通過(guò)在 timeline 中定位某個(gè)“階梯”，我們也能找到可疑的代碼，如圖 14 所示：

圖 14 通過(guò) Performance 定位問(wèn)題代碼

這種方法的優(yōu)點(diǎn)：可以直觀得看到內(nèi)存的總體走勢(shì)，并且同時(shí)得到所有操作過(guò)程中的函數(shù)調(diào)用棧和時(shí)間等信息。缺點(diǎn)：沒(méi)有具體的內(nèi)存分配的細(xì)節(jié)，錄制的過(guò)程不能實(shí)時(shí)看到內(nèi)存分配的過(guò)程。

二 內(nèi)存泄漏出現(xiàn)的場(chǎng)景

1 全局

JS 采用標(biāo)記清掃法去回收無(wú)法訪問(wèn)的內(nèi)存對(duì)象，被掛載在全局對(duì)象（在瀏覽器中即指的是 window 對(duì)象，在垃圾回收的角度上稱(chēng)其為根節(jié)點(diǎn)，也叫 GC root）上的屬性所占用內(nèi)存是不會(huì)被回收的，因?yàn)槠涫鞘冀K可以訪問(wèn)的，這也符合“全局”的命名含義。

解決方案就是避免用全局對(duì)象存儲(chǔ)大量的數(shù)據(jù)。

2 閉包（closure）

我們把【代碼 1】稍加改動(dòng)便可以得到一個(gè)閉包導(dǎo)致內(nèi)存泄漏的版本：

代碼 3 閉包導(dǎo)致內(nèi)存泄漏

將上述代碼加載到 chrome 中，并用 timeline 的方式錄制一個(gè) Snapshot，得到的結(jié)果如圖 15 所示：

圖 15 閉包的錄制結(jié)果

我們選中 index = 2 的心跳，可以看到 Constructor 里面出現(xiàn)了一個(gè) "(closure)"，我們展開(kāi)這個(gè) closure，可以看到里面的 "inner()"，inner() 后面的 "()" 表示 inner 是一個(gè)函數(shù)，這時(shí)候你可能會(huì)問(wèn)：“圖中的 Constructor 的 Retained Size 大小都差不多，為什么你要選 (closure)？”，正是因?yàn)闆](méi)有明顯占比較高的 Retained Size 我們才隨便選一個(gè)調(diào)查，后面你會(huì)發(fā)現(xiàn)不管你選了哪一個(gè)最后的調(diào)查鏈路都是殊途同歸的。

我們?cè)谙旅娴?Retainers 中看下 inner() 的持有細(xì)節(jié)：從下面的 Retainers 中可以看出 inner() 這個(gè) closure 是某個(gè) Array 的第 2 項(xiàng)（index 從 0 開(kāi)始），而這個(gè)數(shù)組的持有者是 system/Context（即全局） 中的 ary，通過(guò)觀察可以看到 ary 的持有大小（Retained Size）是 961KB 大約等于 192KB 的 5 倍，5 即是我們點(diǎn)擊“add date”按鈕的次數(shù)，而下面的 5 個(gè) "previous in system/Context" 每個(gè)大小都是 192KB，而它們最終都是被某個(gè) inner() 閉包持有，至此我們便可以得出結(jié)論：全局中有一個(gè) ary 數(shù)組，它的主要內(nèi)存是被 inner() 填充的，通過(guò)藍(lán)色的 index.html:xx 處的代碼入口定位到代碼所在地看一下一切就都了然了，原來(lái)是 inner() 閉包內(nèi)部持有了一個(gè)大對(duì)象，并且所有的 inner() 閉包及其持有的大對(duì)象都被 ary 對(duì)象持有，而 ary 對(duì)象是全局的不會(huì)被回收，導(dǎo)致了內(nèi)存泄漏（如果這種行為不符合預(yù)期的話）。返回去，如果這個(gè)時(shí)候你選擇上面提到的 system/Context 構(gòu)造器，你會(huì)看到（見(jiàn)圖 16，熟悉吧）：

圖 16 system/Context

也就是你選擇的 system/Context 其實(shí)是 inner() 閉包的上下文對(duì)象（context），而此上下文持有了 192KB 內(nèi)存，通過(guò)藍(lán)色的 index.html:xx 又可以定位到問(wèn)題代碼了。如果你像圖 17 一樣選擇了 Date 構(gòu)造器進(jìn)行查看的話也可以最終定位到問(wèn)題，此處將分析過(guò)程留給讀者自己進(jìn)行：

圖 17 選中 Date 構(gòu)造器

3 Detached DOM

我們先看一下下面的代碼，并用 chrome 載入它：

代碼 4 Detached Dom

然后我們采用 Heap Snapshot 的方式將點(diǎn)擊“del”按鈕前后的兩個(gè) snapshot 錄制下來(lái)，得到的結(jié)果如圖 6 所示。我們選用和 snapshot 1 對(duì)比的方式并在 snapshot 2 的過(guò)濾器中輸入 "detached"。我們觀察得到的篩選結(jié)果的 "Delta" 列，其中不為 0 的列如下：

要解釋上述表格需要先介紹一個(gè)知識(shí)點(diǎn)：DOM 對(duì)象被回收需要同時(shí)滿足兩個(gè)條件，1、DOM 在 DOM 樹(shù)中被刪掉；2、DOM 沒(méi)有被 JS 對(duì)象引用。其中第二點(diǎn)還是比較容易被忽視的。正如上面的例子所示，Detached HTMLButtonElement +1 代表有一個(gè) button DOM 被從組件樹(shù)中刪掉了，但是仍有 JS 引用之（我們不考慮有意為之的情況）。

相似的，Detached EventListener 也是因?yàn)?DOM 被刪掉了，但是事件沒(méi)有解綁，于是 Detached 了，解決方案也很簡(jiǎn)單：及時(shí)解綁事件即可。

于是解決的方法就很簡(jiǎn)單了：參見(jiàn)代碼 5，回掉函數(shù) del 在執(zhí)行完畢時(shí)臨時(shí)變量會(huì)被回收，于是兩個(gè)條件就都同時(shí)滿足了，DOM 對(duì)象就會(huì)被回收掉，事件解綁了，Detached EventListener 也就沒(méi)有了。值得注意的是 table 元素，如果一個(gè) td 元素發(fā)生了 detached，則由于其自身引用了自己所在的 table，于是整個(gè) table 就也不會(huì)被回收了。

代碼 5 Detached DOM 的解決方法

圖 18 Detached DOM 的 Snapshot

Performance monitor 工具

DOM/event listener 泄漏在編寫(xiě)輪播圖、彈窗、toast 提示這種工具的時(shí)候還是很容易出現(xiàn)的，chrome 的 devtools 中有一個(gè) Performance monitor 工具可以用來(lái)幫助我們調(diào)查內(nèi)存中是否有 DOM/event listener 泄漏。首先看一下代碼 6：

代碼 6 不斷增加 DOM NODE

按照我們圖 19 的方式打開(kāi) Performance monitor 面版：

圖 19 打開(kāi) Performance monitor 工具

DOM Nodes 右側(cè)的數(shù)量是當(dāng)前內(nèi)存中的所有 DOM 節(jié)點(diǎn)的數(shù)量，包括當(dāng)前 document 中存在的和 detached 的以及計(jì)算過(guò)程中臨時(shí)創(chuàng)建的，每當(dāng)我們點(diǎn)擊一次“add date”按鈕，并手動(dòng)觸發(fā) GC 之后 DOM Nodes 的數(shù)量就 + 2，這是因?yàn)槲覀兿?document 中增加了一個(gè) button 節(jié)點(diǎn)和一個(gè) button 的文字節(jié)點(diǎn)，就像圖 20 中所示。如果你寫(xiě)的 toast 組件在臨時(shí)插入到 document 并過(guò)一會(huì)兒執(zhí)行了 remove 之后處于了 detached 狀態(tài)的話，Performance monitor 面版中的 DOM Nodes 數(shù)量就會(huì)不斷增加，結(jié)合 snapshot 工具你便可以定位到問(wèn)題所在了。值得一提的是，有的第三方的庫(kù)的 toast 便存在這個(gè)問(wèn)題，不知道你被坑過(guò)沒(méi)有。

圖 20 不斷增加的 DOM Nodes

4 console

這一點(diǎn)可能有人不會(huì)留意到，控制臺(tái)打印的內(nèi)容是需要始終保持引用的存在的，這一點(diǎn)也是值得注意的，因?yàn)榇蛴∵^(guò)多過(guò)大對(duì)象的話也是會(huì)造成內(nèi)存泄漏的，如圖 21 所示（配合代碼 7）。解決方法便是不要肆意打印對(duì)象到控制臺(tái)中，只打印必要的信息出來(lái)。

代碼 7 console 導(dǎo)致內(nèi)存泄漏

圖 21 console 導(dǎo)致的內(nèi)存泄漏

三 總結(jié)

本文用了幾個(gè)簡(jiǎn)單的小例子介紹了內(nèi)存泄漏出現(xiàn)的時(shí)機(jī)、尋找泄漏點(diǎn)的方法并將各種方法的優(yōu)缺點(diǎn)進(jìn)行了對(duì)比，總結(jié)了避免出現(xiàn)內(nèi)存泄漏的注意點(diǎn)。希望能對(duì)讀者有所幫助。文中如果有本人理解錯(cuò)誤或書(shū)寫(xiě)錯(cuò)誤的地方歡迎留言指正。

參考

https://commandlinefanatic.com/cgi-bin/showarticle.cgi?article=art038
https://developer.chrome.com/docs/devtools/memory-problems/
https://www.bitdegree.org/learn/chrome-memory-tab