一文帶你了解如何排查記憶體泄漏導致的頁面卡頓現象-有解無憂

在這里插入圖片描述
不知道在座的各位有沒有被問到過這樣一個問題：如果頁面卡頓，你覺得可能是什么原因造成的？有什么辦法鎖定原因并解決嗎？

這是一個非常寬泛而又有深度的問題，他涉及到很多的頁面性能優化問題，我依稀還記得當初面試被問到這個問題時我是這么回答的：

先會檢查是否是網路請求太多，導致資料回傳較慢，可以適當做一些快取
也有可能是某塊資源的bundle太大，可以考慮拆分一下
然后排查一下js代碼，是不是某處有過多回圈導致占用主執行緒時間過長
瀏覽器某幀渲染的東西太多，導致的卡頓
在頁面渲染程序中，可能有很多重復的重排重繪
emmmmmm…不知道了

后來了解到了，感官上的長時間運行頁面卡頓也有可能是因為記憶體泄漏引起的

記憶體泄漏的定義

那什么是記憶體泄漏呢？借助別的大佬給出的定義，記憶體泄漏就是指由于疏忽或者程式的某些錯誤造成未能釋放已經不再使用的記憶體的情況，簡單來講就是假設某個變數占用100M的記憶體，而你又用不到這個變數，但是這個變數沒有被手動的回識訓自動回收，即仍然占用100M的記憶體空間，這就是一種記憶體的浪費，即記憶體泄漏

JS的資料存盤

JavaScript的記憶體空間分為堆疊記憶體和堆記憶體，前者用來存放一些簡單變數，后者用來存放復雜物件

簡單變數指的是JS的基本資料型別，例如：String、Number、Boolean、null、undefined、Symbol、BigInt
復雜物件指的是JS的參考資料型別，例如：Object、Array、Function…

JS垃圾回識訓制

根據記憶體泄漏的定義，有些變數或資料不再被使用或不需要了，那么它就是垃圾變數或垃圾資料，如果其一直保存在記憶體中，最終可能會導致記憶體占用過多的情況，那么此時就需要對這些垃圾資料進行回收，這里引入了垃圾回識訓制的概念

垃圾回收的機制分為手動和自動兩種

例如C/C++采用的就是手動回收的機制，即先用代碼為某個變數分配一定的記憶體，然后在不需要了后，再用代碼手動釋放掉記憶體

而JavaScript采用的則是自動回收的機制，即我們不需要關心何時為變數分配多大的記憶體，也不需要關心何時去釋放記憶體，因為這一切都是自動的，但這不表示我們不需要關心記憶體的管理！！！！否則也不會有本文討論的記憶體泄露了

接下來就講一下JavaScript的垃圾回識訓制

通常全域狀態(window)下的變數是不會被自動回收的，所以我們來討論一下區域作用域下的記憶體回收情況

function fn1 () {
    let a = {
        name: '零一'
    }

    let b = 3

    function fn2() {
        let c = [1, 2, 3]
    }

    fn2()

    return a
}

let res = fn1()

以上代碼的呼叫堆疊如下圖所示：

圖中左側為堆疊空間，用于存放一些執行背景關系和基本型別資料；右側為堆空間，用于存放一些復雜物件資料

當代碼執行到fn2()時，堆疊空間內的執行背景關系從上往下依次是 fn2函式執行背景關系 => fn1函式執行背景關系 => 全域執行背景關系

待fn2函式內部執行完畢以后，就該退出fn2函式執行背景關系了，即箭頭向下移動，此時fn2函式執行背景關系會被清除并釋放堆疊記憶體空間，如圖所示：

待fn1函式內部執行完畢以后，就該退出fn1函式執行背景關系了，即箭頭再向下移動，此時fn1函式執行背景關系會被清除并釋放相應的堆疊記憶體空間，如圖所示：

此時處于全域的執行背景關系中，JavaScript的垃圾回收器會每隔一段時間遍歷呼叫堆疊，假設此時觸發了垃圾回識訓制，當遍歷呼叫堆疊時發現變數b和變數c沒有被任何變數所參考，所以認定它們是垃圾資料并給它們打上標記，因為fn1函式執行完后將變數a回傳了出去，并存盤在全域變數res中，所以認定其為活動資料并打上相應標記，待空閑時刻就會將標記上垃圾資料的變數給全部清除掉，釋放相應的記憶體，如圖所示：

從這我們得出幾點結論：

JavaScript的垃圾回識訓制是自動執行的，并且會通過標記來識別并清除垃圾資料
在離開區域作用域后，若該作用域內的變數沒有被外部作用域所參考，則在后續會被清除

補充： JavaScript的垃圾回識訓制有著很多的步驟，上述只講到了標記-清除，其實還有其它的程序，這里簡單介紹一下就不展開討論了，例如：標記-整理，在清空部分垃圾資料后釋放了一定的記憶體空間后會可能會留下大面積的不連續記憶體片段，導致后續可能無法為某些物件分配連續記憶體，此時需要整理一下記憶體空間；交替執行，因為JavaScript是運行在主執行緒上的，所以執行垃圾回識訓制時會暫停js的運行，若垃圾回收執行時間過長，則會給用戶帶來明顯的卡頓現象，所以垃圾回識訓制會被分成一個個的小任務，穿插在js任務之中，即交替執行，盡可能得保證不會帶來明顯的卡頓感

Chrome devTools查看記憶體情況

在了解一些常見的記憶體泄漏的場景之前，先簡單介紹一下如何使用Chrome的開發者工具來查看js記憶體情況

首先打開Chrome的無痕模式，這樣做的目的是為了屏蔽掉Chrome插件對我們之后測驗記憶體占用情況的影響

然后打開開發者工具，找到Performance這一欄，可以看到其內部帶著一些功能按鈕，例如：開始錄制按鈕；重繪頁面按鈕；清空記錄按鈕；記錄并可視化js記憶體、節點、事件監聽器按鈕；觸發垃圾回識訓制按鈕等等

簡單錄制一下百度頁面，看看我們能獲得什么，如下動圖所示：

從上圖中我們可以看到，在頁面從零到加載完成這個程序中JS Heap（js堆記憶體）、documents（檔案）、Nodes（DOM節點）、Listeners（監聽器）、GPU memory（GPU記憶體）的最低值、最高值以及隨時間的走勢曲線，這也是我們主要關注的點

再來看看開發者工具中的Memory一欄，其主要是用于記錄頁面堆記憶體的具體情況以及js堆記憶體隨加載時間線動態的分配情況

堆快照就像照相機一樣，能記錄你當前頁面的堆記憶體情況，每快照一次就會產生一條快照記錄，如圖所示：

如上圖所示，剛開始執行了一次快照，記錄了當時堆記憶體空間占用為13.9MB，然后我們點擊了頁面中某些按鈕，又執行一次快照，記錄了當時堆記憶體空間占用為13.4MB，并且點擊對應的快照記錄，能看到當時所有記憶體中的變數情況（結構、占總占用記憶體的百分比…）

然后我們還可以看一下頁面動態的記憶體變化情況，如圖所示：

在開始記錄后，我們可以看到圖中右上角有起伏的藍色與灰色的柱形圖，其中藍色表示當前時間線下占用著的記憶體；灰色表示之前占用的記憶體空間已被清除釋放，

從上圖程序來看，我們可以看到剛開始處于的tab所對應顯示的頁面中占用了一定的堆記憶體空間，成藍色柱形，在點擊別的tab后，原tab對應的內容消失，并且原來藍色的柱形變成灰色（表示原占用的記憶體空間得到了釋放），同時新tab所對應顯示的頁面也占用了一定的堆記憶體空間，因此后續我們就可以針對這個圖來查看記憶體的占用與清除情況

記憶體泄漏的場景

那么到底有哪些情況會出現記憶體泄漏的情況呢？這里列舉了常見的幾種：

閉包使用不當引起記憶體泄漏
全域變數
分離的DOM節點
控制臺的列印
遺忘的定時器

接下來介紹一下各種情況，并嘗試用剛才講到的兩種方法來捕捉問題所在

1.閉包使用不當

文章開頭的例子中，在退出fn1函式執行背景關系后，該背景關系中的變數a本應被當作垃圾資料給回收掉，但因fn1函式最終將變數a回傳并賦值給全域變數res，其產生了對變數a的參考，所以變數a被標記為活動變數并一直占用著相應的記憶體，假設變數res后續用不到，這就算是一種閉包使用不當的例子

接下來嘗試使用Performance和Memory來查看一下閉包導致的記憶體泄漏問題，為了使記憶體泄漏的結果更加明顯，我們稍微改動一下文章開頭的例子，代碼如下：

<button onclick="myClick()">執行fn1函式</button>
<script>
    function fn1 () {
        let a = new Array(10000)  // 這里設定了一個很大的陣列物件

        let b = 3

        function fn2() {
            let c = [1, 2, 3]
        }

        fn2()

        return a
    }

    let res = []  

    function myClick() {
        res.push(fn1())
    }
</script>

設定了一個按鈕，每次執行就會將fn1函式的回傳值添加到全域陣列變數res中，是為了能在performacne的曲線圖中看出效果，如圖所示：

在每次錄制開始時手動觸發一次垃圾回識訓制，這是為了確認一個初始的堆記憶體基準線，便于后面的對比，然后我們點擊了幾次按鈕，即往全域陣列變數res中添加了幾個比較大的陣列物件，最后再觸發一次垃圾回收，發現錄制結果的JS Heap曲線剛開始成階梯式上升的，最后的曲線的高度比基準線要高，說明可能是存在記憶體泄漏的問題

在得知有記憶體泄漏的情況存在時，我們可以改用Memory來更明確得確認問題和定位問題

首先可以用Allocation instrumentation on timeline來確認問題，如下圖所示：

在我們每次點擊按鈕后，動態記憶體分配情況圖上都會出現一個藍色的柱形，并且在我們觸發垃圾回收后，藍色柱形都沒變成灰色柱形，即之前分配的記憶體并未被清除

所以此時我們就可以更明確得確認記憶體泄漏的問題是存在的了，接下來就精準定位問題，可以利用Heap snapshot來定位問題，如圖所示：

第一次先點擊快照記錄初始的記憶體情況，然后我們多次點擊按鈕后再次點擊快照，記錄此時的記憶體情況，發現從原來的1.1M記憶體空間變成了1.4M記憶體空間，然后我們選中第二條快照記錄，可以看到右上角有個All objects的欄位，其表示展示的是當前選中的快照記錄所有物件的分配情況，而我們想要知道的是第二條快照與第一條快照的區別在哪，所以選擇Object allocated between Snapshot1 and Snapshot2，即展示第一條快照和第二條快照存在差異的記憶體物件分配情況，此時可以看到Array的百分比很高，初步可以判斷是該變數存在問題，點擊查看詳情后就能查看到該變數對應的具體資料了

以上就是一個判斷閉包帶來記憶體泄漏問題并簡單定位的方法了

2.全域變數

全域的變數一般是不會被垃圾回收掉的，在文章開頭也提到過了，當然這并不是說變數都不能存在全域，只是有時候會因為疏忽而導致某些變數流失到全域，例如未宣告變數，卻直接對某變數進行賦值，就會導致該變數在全域創建，如下所示：

function fn1() {
    // 此處變數name未被宣告
    name = new Array(99999999)
}

fn1()

此時這種情況就會在全域自動創建一個變數name，并將一個很大的陣列賦值給name，又因為是全域變數，所以該記憶體空間就一直不會被釋放

解決辦法的話，自己平時要多加注意，不要在變數未宣告前賦值，或者也可以開啟嚴格模式，這樣就會在不知情犯錯時，收到報錯警告，例如：

function fn1() {
    'use strict';
    name = new Array(99999999)
}

fn1()

3.分離的DOM節點

什么叫DOM節點？假設你手動移除了某個dom節點，本應釋放該dom節點所占用的記憶體，但卻因為疏忽導致某處代碼仍對該被移除節點有參考，最終導致該節點所占記憶體無法被釋放，例如這種情況：

<div id="root">
    <div class="child">我是子元素</div>
    <button>移除</button>
</div>
<script>

    let btn = document.querySelector('button')
    let child = document.querySelector('.child')
    let root = document.querySelector('#root')
    
    btn.addEventListener('click', function() {
        root.removeChild(child)
    })

</script>

該代碼所做的操作就是點擊按鈕后移除.child的節點，雖然點擊后，該節點確實從dom被移除了，但全域變數child仍對該節點有參考，所以導致該節點的記憶體一直無法被釋放，可以嘗試用Memory的快照功能來檢測一下，如圖所示：

同樣的先記錄一下初始狀態的快照，然后點擊移除按鈕后，再點擊一次快照，此時記憶體大小我們看不出什么變化，因為移除的節點占用的記憶體實在太小了可以忽略不計，但我們可以點擊第二條快照記錄，在篩選框里輸入detached，于是就會展示所有脫離了卻又未被清除的節點物件

解決辦法如下圖所示：

<div id="root">
    <div class="child">我是子元素</div>
    <button>移除</button>
</div>
<script>
    let btn = document.querySelector('button')

    btn.addEventListener('click', function() {  
        let child = document.querySelector('.child')
        let root = document.querySelector('#root')

        root.removeChild(child)
    })

</script>

改動很簡單，就是將對.child節點的參考移動到了click事件的回呼函式中，那么當移除節點并退出回呼函式的執行上文后就會自動清除對該節點的參考，那么自然就不會存在記憶體泄漏的情況了，我們來驗證一下，如下圖所示：

結果很明顯，這樣處理過后就不存在記憶體泄漏的情況了

4.控制臺的列印

控制臺的列印也會造成記憶體泄漏嗎？？？？是的呀，如果瀏覽器不一直保存著我們列印物件的資訊，我們為何能在每次打開控制的Console時看到具體的資料呢？先來看一段測驗代碼：

<button>按鈕</button>
<script>
    document.querySelector('button').addEventListener('click', function() {
        let obj = new Array(1000000)

        console.log(obj);
    })
</script>

我們在按鈕的點擊回呼事件中創建了一個很大的陣列物件并列印，用performance來驗證一下：

開始錄制，先觸發一次垃圾回收清除初始的記憶體，然后點擊三次按鈕，即執行了三次點擊事件，最后再觸發一次垃圾回收，查看錄制結果發現JS Heap曲線成階梯上升，并且最終保持的高度比初始基準線高很多，這說明每次執行點擊事件創建的很大的陣列物件obj都因為console.log被瀏覽器保存了下來并且無法被回收

接下來注釋掉console.log，再來看一下結果：

<button>按鈕</button>
<script>
    document.querySelector('button').addEventListener('click', function() {
        let obj = new Array(1000000)

        // console.log(obj);
    })
</script>

performance如圖所示：

可以看到沒有列印以后，每次創建的obj都立馬被銷毀了，并且最終觸發垃圾回識訓制后跟初始的基準線同樣高，說明已經不存在記憶體泄漏的現象了

其實同理，console.log也可以用Memory來進一步驗證

未注釋console.log

注釋掉了console.log

最后簡單總結一下：在開發環境下，可以使用控制臺列印便于除錯，但是在生產環境下，盡可能得不要在控制臺列印資料，所以我們經常會在代碼中看到類似如下的操作：

// 如果在開發環境下，列印變數obj
if(isDev) {
    console.log(obj)
}

這樣就避免了生產環境下無用的變數列印占用一定的記憶體空間，同樣的除了console.log之外，console.error、console.info、console.dir等等都不要在生產環境下使用

5.遺忘的定時器

其實定時器也是平時很多人會忽略的一個問題，比如定義了定時器后就再也不去考慮清除定時器了，這樣其實也會造成一定的記憶體泄漏，來看一個代碼示例：

<button>開啟定時器</button>
<script>

    function fn1() {
        let largeObj = new Array(100000)

        setInterval(() => {
            let myObj = largeObj
        }, 1000)
    }

    document.querySelector('button').addEventListener('click', function() {
        fn1()
    })
</script>

這段代碼是在點擊按鈕后執行fn1函式，fn1函式內創建了一個很大的陣列物件largeObj，同時創建了一個setInterval定時器，定時器的回呼函式只是簡單的參考了一下變數largeObj，我們來看看其整體的記憶體分配情況吧：

按道理來說點擊按鈕執行fn1函式后會退出該函式的執行背景關系，緊跟著函式體內的區域變數應該被清除，但圖中performance的錄制結果顯示似乎是存在記憶體泄漏問題的，即最終曲線高度比基準線高度要高，那么再用Memory來確認一次：

在我們點擊按鈕后，從動態記憶體分配的圖上看到出現一個藍色柱形，說明瀏覽器為變數largeObj分配了一段記憶體，但是之后這段記憶體并沒有被釋放掉，說明的確存在記憶體泄漏的問題，原因其實就是因為setInterval的回呼函式內對變數largeObj有一個參考關系，而定時器一直未被清除，所以變數largeObj的記憶體也自然不會被釋放

那么我們如何來解決這個問題呢，假設我們只需要讓定時器執行三次就可以了，那么我們可以改動一下代碼：

<button>開啟定時器</button>
<script>
    function fn1() {
        let largeObj = new Array(100000)
        let index = 0

        let timer = setInterval(() => {
            if(index === 3) clearInterval(timer);
            let myObj = largeObj
            index ++
        }, 1000)
    }

    document.querySelector('button').addEventListener('click', function() {
        fn1()
    })
</script>

現在我們再通過performance和memory來看看還不會存在記憶體泄漏的問題

performance

這次的錄制結果就能看出，最后的曲線高度和初始基準線的高度一樣，說明并沒有記憶體泄漏的情況

memory

這里做一個解釋，圖中剛開始出現的藍色柱形是因為我在錄制后重繪了頁面，可以忽略；然后我們點擊了按鈕，看到又出現了一個藍色柱形，此時就是為fn1函式中的變數largeObj分配了記憶體，3s后該記憶體又被釋放了，即變成了灰色柱形，所以我們可以得出結論，這段代碼不存在記憶體泄漏的問題

簡單總結一下： 大家在平時用到了定時器，如果在用不到定時器后一定要清除掉，否則就會出現本例中的情況，除了setTimeout和setInterval，其實瀏覽器還提供了一個API也可能就存在這樣的問題，那就是requestAnimationFrame

總結

在專案程序中，如果遇到了某些性能問題可能跟記憶體泄漏有關時，就可以參照本文列舉的5種情況去排查，一定能找到問題所在并給到解決辦法的，

雖然JavaScript的垃圾回收是自動的，但我們有時也是需要考慮要不要手動清除某些變數的記憶體占用的，例如你明確某個變數在一定條件下再也不需要，但是還會被外部變數參考導致記憶體無法得到釋放時，你可以用null對該變數重新賦值就可以在后續垃圾回收階段釋放該變數的記憶體了，

最后，歡迎大家關注公眾號：前端印象，關注即可第一時間閱讀，

另外有任何技術方面的問題，也可以加我主頁聯系方式

轉載請註明出處，本文鏈接：https://www.uj5u.com/qianduan/273740.html

標籤：其他

上一篇：JavaScript基礎入門

下一篇：CSS中em的正確打開方式