大家好，我是 ConardLi?。作為一名 Web? 應用程序開發者，排查和修復 JavaScript 代碼的內存泄漏一直是最困擾我的問題之一。

最近，Meta? 開源了一款檢測 JavaScript? 代碼內存泄漏的框架：MemLab，我們來一起看看這個框架有啥神奇之處吧～

2020? 年，Meta? 的工程師將 Facebook.com? 重構為了單頁應用(SPA?)，程序的大部分渲染和導航都會在客戶端使用 JavaScript? 完成。后來他們又使用類似的架構來重構了 Meta? 的大多數其他流行的網絡應用程序，包括 Instagram? 和 Workplace?。雖然這種架構能夠提供更快的用戶交互、更好的開發者體驗和更像原生應用程序的感覺，但是在客戶端維護 Web 應用的狀態會讓內存的管理變得更加復雜。

使用 Meta? 網站的用戶經常會快速注意到一些性能和功能正常使用的問題。然而，內存泄漏就是另一回事了。它不會立即被察覺出來，因為它一次會占用一大塊內存 — 然后逐漸影響整個 Web 會話并讓后續的交互和響應變得更慢。

Meta? 的工程師花費了大量時間來測試、優化和控制頁面加載和交互時間，以及 JavaScript? 的代碼大小。相比之下，他們在管理 Web? 瀏覽器內存方面做的工作并不多。當分析新 Facebook.com? 的內存使用情況時，發現客戶端的內存使用情況和內存不足 (OOM) 崩潰的數量一直在攀升。較高的內存使用對頁面加載、交互性能、用戶參與度等核心指標都有負面影響。

為了幫助開發者解決這個問題，Meta? 的工程師構建了 MemLab?，這是一個 JavaScript? 內存測試框架，可以自動進行內存泄漏檢測，并且更容易找到內存泄漏的根本原因。Meta? 使用 MemLab 成功地控制了不可持續的內存增長，并識別出了產品和基礎設施中的內存泄漏和內存優化的一些手段。

導致 Web 應用內存過高的原因

因為內存泄漏通常不是很明顯，在開發過程中，以及做 Code Review? 的時候都很難發現，而且在生產環境中通常也很難找到根本原因。雖然主流的 JavaScript 運行時都有垃圾回收機制，那么為什么還會有內存泄漏呢？

JavaScript 代碼中可能會有很多隱藏對象的引用，而隱藏的引用會以許多意想不到的方式導致內存泄漏。

例如：

var obj = {};
console.log(obj);
obj = null;

在 Chrome? 中，即使我們將引用設置為 null? ，這段代碼也會泄漏 obj? 。發生這種情況是因為 Chrome? 需要保留對打印對象的內部引用，以便以后可以在 Web 控制臺中對其進行檢查（即使在 Web 控制臺沒打開的情況下）。

在某些情況下，內存在技術上并沒有發生泄漏，而是在用戶會話期間線性增長而且沒有限制。最常見的原因是客戶端緩存沒有內置任何釋放的邏輯，無限滾動列表沒有任何虛擬化的功能，無法在添加新內容時從列表中刪除較早的內容。

我們也沒有適當的自動化系統和流程來控制內存，因此防止此類問題的唯一防御措施就是專家通過 Chrome DevTools 定期挖掘內存泄漏，一些大型的項目幾乎每天都會有發布和變更，這樣的工作方式是不可持續的。

MemLab 的工作原理

MemLab? 通過預定義的測試場景運行無頭瀏覽器并比較和分析 JavaScript 堆快照來發現內存泄漏的問題。

這個過程可以分為下面六個步驟：

1.「瀏覽器交互」：MemLab? 使用 Puppeteer 自動化瀏覽器，在目標頁面上查找泄露的對象；

2.「區分堆」：導航到一個頁面然后離開它，正常情況下該頁面分配的大部分內存也應該被釋放，如果沒有，可能暗示著存在內存泄漏。MemLab? 通過區分 JavaScript? 堆并記錄在頁面 B? 上分配的一組對象，這些對象沒有在頁面 ?A 上分配，但在重新加載頁面 A 時仍然存在，從而發現潛在的內存泄漏；

3.「細化內存泄漏列表」：內存泄漏檢測器進一步結合了特定框架的知識來細化泄漏對象的列表。例如，React? 分配的 Fiber? 節點（React? 用于渲染虛擬 DOM 的內部數據結構）應該在我們訪問多個選項卡后清理時釋放。

4.「生成 retainer traces」：遍歷堆并為每個泄漏的對象生成 retainer traces? 。trace? 顯示了泄漏對象為何以及如何在內存中保持活動狀態。打破引用鏈意味著泄漏的對象將不再可以從 GC? 的根訪問，因此可以進行垃圾回收。通過一步步地跟蹤，就可以找到應該設置為 null 的引用；

5.「聚合 retainer traces」：將所有 retainer traces? 聚集在一起，并為每個共享相似 retainer traces 的泄漏對象聚合顯示為一個跟蹤，其中還包括調試信息，例如支配節點和保留大小。

6.「報告泄漏」：定期運行 MemLab?，以持續收集 retainer traces?，任何新的 traces? 都會記錄到內部儀表板，開發者可以查看每個內存泄漏的 retainer traces 上的對象屬性。

MemLab 有哪些能力

內存泄漏檢測

對于瀏覽器內存泄漏的檢測，MemLab? 需要開發者提供的唯一輸入就是一個測試場景文件，這個文件定義了如何通過使用 Puppeteer API? 和 CSS? 選擇器覆蓋三個回調來與網頁交互。MemLab? 會自動區分 JavaScript 堆、優化內存泄漏并聚合結果。

JavaScript 堆的 Graph-view API

MemLab? 支持一個自定義的泄漏檢測器，作為篩選器回調，應用于每個由目標交互分配的泄漏候選對象，但之后從不釋放。泄漏過濾器回調函數可以遍歷堆并確定哪些對象是內存泄漏。例如，我們的內置檢漏器會跟蹤 React Fiber? 節點的返回鏈路，檢查 Fiber? 節點是否與 React Fiber 樹分離。

為了分析每個可能內存泄漏的上下文，MemLab? 提供了一個 JavaScript? 堆的內存效率圖。這可以在不了解 V8? 堆快照文件結構的任何領域知識的情況下查詢和遍歷 JavaScript 堆。

在視圖中，堆中的每個 JavaScript? 對象或原生對象都是一個圖節點，堆中的每個 JavaScript? 引用都是一個圖的邊。實際應用程序的堆大小通常很大，因此圖視圖需要在提供直觀的面向對象堆遍歷 API? 的同時提高內存效率。因此，圖節點被設計成了虛擬的，不通過 JavaScript? 引用進行連接。當分析代碼遍歷堆時，虛擬圖會部分地即時構建圖的接觸部分。圖的任何部分都可以很容易地釋放，因為這些虛擬節點彼此之間沒有 JavaScript 引用。

堆視圖可以從基于 Chromium? 的瀏覽器、Node.js、Electron? 和 Hermes? 獲取的 JavaScript? 堆快照加載。這允許分析復雜的模式并回答諸如 “有多少 React Fiber? 節點是備用的 Fiber 節點，它們用于不完整的并發渲染？”之類的問題。

import {getHeapFromFile} from '@memlab/heap-analysis';
const heapGraph = await getHeapFromFile(heapFile);
heapGraph.nodes.forEach(node => {
  // heap node traversal
  node.type
  node.references
);

內存斷言

Node.js? 程序或 Jest? 測試也可以使用 graph-view API 來獲取其自身狀態的堆視圖，進行自內存檢查，并編寫各種內存斷言。

import type {IHeapSnapshot} from '@memlab/core';
import {config, takeNodeMinimalHeap, tagObject} from '@memlab/core';

test('memory test', async () => {
  config.muteConsole = true;
  const o1 = {};
  let o2 = {};

  // tag o1 with marker: "memlab-mark-1", does not modify o1 in any way
  tagObject(o1, 'memlab-mark-1');
  // tag o2 with marker: "memlab-mark-2", does not modify o2 in any way
  tagObject(o2, 'memlab-mark-2');

  o2 = null;

  const heap: IHeapSnapshot = await takeNodeMinimalHeap();

  // expect object with marker "memlab-mark-1" exists
  expect(heap.hasObjectWithTag('memlab-mark-1')).toBe(true);

  // expect object with marker "memlab-mark-2" can be GCed
  expect(heap.hasObjectWithTag('memlab-mark-2')).toBe(false);

}, 30000);

內存工具箱

除了內存泄漏檢測，MemLab? 還包括一組內置的 CLI? 命令和 API，用于尋找可能的內存優化機會：

Meta 使用 MemLab 的實踐

在過去的幾年中，Meta? 一直在使用 MemLab 檢測和診斷內存泄漏，并收集了很多有助于優化內存、減少 OOM 崩潰并改善用戶體驗的手段。

在 2021? 年上半年， Facebook.com? 上的 OOM? 崩潰減少了 50%。

React Fiber 節點清理

為了渲染組件，React? 構建了 Fiber? 樹 — 一個 React? 用于渲染虛擬 DOM? 的內部數據結構。雖然 Fiber? 樹看起來像一棵樹，但它是一個雙向圖，將所有 Fiber? 節點、React? 組件實例和關聯的 HTML DOM? 元素強連接起來。理想情況下，React? 維護對組件 Fiber? 樹的根的引用，并防止 Fiber? 樹被垃圾回收。當一個組件被卸載時，React 會斷開組件的根與 Fiber 樹的其余部分之間的連接，然后這些部分就可以被垃圾回收了。

擁有這樣的強連接圖的缺點是，如果有任何外部引用指向圖的任何部分，就無法對整個圖進行垃圾回收。例如，下面 export? 語句在模塊范圍級別緩存 React? 組件，因此相關的 Fiber? 樹和分離的 DOM 元素永遠不會被釋放。

export const Component = (( 
  <List> ... </List> 
): React.Element<typeof List>);

也不僅僅是 React 數據結構要 keep alive? ，Hooks? 和它們的閉包也可以讓各種其他對象保活。這意味著單個 React 組件泄漏可能會導致頁面對象的重要部分泄漏，從而導致巨大的內存泄漏。

為了防止 Fiber? 樹中內存泄漏的級聯效應，MemLab? 添加了一個樹的完整遍歷，當組件在 React 18? 中卸載時會進行清理。這可以讓垃圾回收器在清理未掛載的樹方面做得更好一點。這個優化將 Facebook? 上的平均內存使用量減少了近 25%?，其他使用 React? 的站點在升級時也有了很大的改進。你可能會擔心這種比較激進的清理方式可能會減慢 React 組件的卸載速度，但令人驚訝的是，由于內存的減少，性能也有顯著的提升。

string interning

通過利用 MemLab? 中的 heap analysis API，Meta? 團隊發現字符串占據了 70%? 的堆內存，其中一半的字符串至少有一個重復的實例。（V8? 對 string interning 支持的不是很好，這是一種對具有相同值的字符串實例進行重復數據刪除的優化。）

另外很大一部分字符串內存被 Relay? 中緩存的鍵字符串消耗。通過與 Relay? 和 React Apps? 團隊合作，可以在客戶端插入和縮短過長的字符串鍵來優化 Relay 緩存鍵字符串。

這種優化使 Relay? 能夠緩存更多數據，允許站點向用戶顯示更多內容，尤其是在客戶端 RAM? 有限的情況下。內存 p99? 和 OOM? 崩潰減少了 20%，頁面渲染速度更快，用戶體驗得到改善，在收入上也有一定提升。

試用 MemLab：

npm i -g memlab

最后：MemLab Github：https://github.com/facebookincubator/memlab