本文主要主要介紹 Web 開發中需要了解的內存分析與內存泄露定位手段。

　　無論是分布式計算系統、服務端應用程序還是 iOS、Android 原生應用都會存在內存泄漏問題，Web 應用自然也不可避免地存在著類似的問題。雖然因為網頁往往都是即用即走，較少地存在某個網頁長期運行的問題，即使存在內存泄漏可能表現地也不明顯;但是在某些數據展示型的，需要長期運行的頁面上，如果不及時解決內存泄漏可能會導致網頁占據過大地內存，不僅影響頁面性能，還可能導致整個系統的崩潰。前端每周清單推薦過的 How JavaScript works 就是非常不錯地介紹 JavaScript 運行機制的系列文章，其也對內存管理與內存泄漏有過分析，本文部分圖片與示例代碼即來自此系列。

　　類似于 C 這樣的語言提供了 malloc（） 與 free（） 這樣的底層內存管理原子操作，開發者需要顯式手動地進行內存的申請與釋放;而 Java 這樣的語言則是提供了自動化的內存回收機制，筆者在垃圾回收算法與 JVM 垃圾回收器綜述一文中有過介紹。JavaScript 也是采用的自動化內存回收機制，無論是 Object、String 等都是由垃圾回收進程自動回收處理。自動化內存回收并不意味著我們就可以忽略內存管理的相關操作，反而可能會導致更不易發現的內存泄漏出現。

　　內存分配與回收

　 JavaScript 的內存模型，其主要也是由堆、棧、隊列三方面組成：

　　其中隊列指的是消息隊列、棧就是函數執行棧，其基本結構如下所示：

　　而主要的用戶創建的對象就存放在堆中，這也是我們內存分析與內存泄漏定位所需要關注的主要的區域。所謂內存，從硬件的角度來看，就是無數觸發器的組合;每個觸發器能夠存放 1 bit 位的數據，不同的觸發器由唯一的標識符定位，開發者可以根據該標識符讀寫該觸發器。抽象來看，我們可以將內存當做比特數組，而數據就是在內存中順序排布：

　　JavaScript 中開發者并不需要手動地為對象申請內存，只需要聲明變量，JavaScript Runtime 即可以自動地分配內存：

　　某個對象的內存生命周期分為了內存分配、內存使用與內存回收這三個步驟，當某個對象不再被需要時，它就應該被清除回收;所謂的垃圾回收器，Garbage Collector 即是負責追蹤內存分配情況、判斷某個被分配的內存是否有用，并且自動回收無用的內存。大部分的垃圾回收器是根據引用（Reference）來判斷某個對象是否存活，所謂的引用即是某個對象是否依賴于其他對象，如果存在依賴關系即存在引用;譬如某個 JavaScript 對象引用了它的原型對象。最簡單的垃圾回收算法即是引用計數（Reference Counting），即清除所有零引用的對象：

　　不過這種算法往往受制于循環引用問題，即兩個無用的對象相互引用：

　　稍為復雜的算法即是所謂的標記-清除（Mark-Sweep）算法，其根據某個對象是否可達來判斷某個對象是否可用。標記-清除算法會從某個根元素開始，譬如 window 對象開始，沿著引用樹向下遍歷，標記所有可達的對象為可用，并且清除其他未被標記的對象。

　　2012 年之后，幾乎所有的主流瀏覽器都實踐了基于標記-清除算法的垃圾回收器，并且各自也進行有針對性地優化。

　　內存泄漏

　　所謂的內存泄漏，即是指某個對象被無意間添加了某條引用，導致雖然實際上并不需要了，但還是能一直被遍歷可達，以致其內存始終無法回收。本部分我們簡要討論下 JavaScript 中常見的內存泄漏情境與處理方法。在新版本的 Chrome 中我們可以使用 Performance Monitor 來動態監測網頁性能的變化：

　　上圖中各項指標的含義為：

　　CPU usage - 當前站點的 CPU 使用量;

　　JS heap size - 應用的內存占用量;

　　DOM Nodes - 內存中 DOM 節點數目;

　　JS event listeners- 當前頁面上注冊的 JavaScript 時間監聽器數目;

　　Documents - 當前頁面中使用的樣式或者腳本文件數目;

　　Frames - 當前頁面上的 Frames 數目，包括 iframe 與 workers;

　　Layouts / sec - 每秒的 DOM 重布局數目;

　　Style recalcs / sec - 瀏覽器需要重新計算樣式的頻次;

　　當發現某個時間點可能存在內存泄漏時，我們可以使用 Memory 標簽頁將此時的堆分配情況打印下來：

　　全局變量

　　JavaScript 會將所有的為聲明的變量當做全局變量進行處理，即將其掛載到 global 對象上;瀏覽器中這里的 global 對象就是 window：

　　一旦某個變量被掛載到了 window 對象，就意味著它永遠是可達的。為了避免這種情況，我們應該盡可能地添加 use strict 或者進行模塊化編碼（參考 JavaScript 模塊演化簡史）。我們也可以擴展類似于下文的掃描函數，來檢測出 window 對象的非原生屬性，并加以判斷：

　　5

　　定時器與閉包

　　我們經常會使用 setInterval 來執行定時任務，很多的框架也提供了基于回調的異步執行機制;這可能會導致回調中聲明了對于某個變量的依賴，譬如：

　　定時器保有對于 serverData 變量的引用，如果我們不手動清除定時器話，那么該變量也就會一直可達，不被回收。而這里的 serverData 也是閉包形式被引入到 setInterval 的回調作用域中;閉包也是常見的可能導致內存泄漏的元兇之一：

　　上述代碼中 replaceThing 會定期執行，并且創建大的數組與 someMethod 閉包賦值給 theThing。someMethod 作用域是與 unused 共享的，unused 又有一個指向 originalThing 的引用。盡管 unused 并未被實際使用，theThing 的 someMethod 方法卻有可能會被外部使用，也就導致了 unused 始終處于可達狀態。unused 又會反向依賴于 theThing，最終導致大數組始終無法被清除。

　　DOM 引用與監聽器

　　有時候我們可能會將 DOM 元素存放到數據結構中，譬如當我們需要頻繁更新某個數據列表時，可能會將用到的數據列表存放在 JavaScript 數組中;這也就導致了每個 DOM 元素存在了兩個引用，分別在 DOM 樹與 JavaScript 數組中：

　　此時我們就需要將 DOM 樹與 JavaScript 數組中的引用皆刪除，才能真實地清除該對象。類似的，在老版本的瀏覽器中，如果我們清除某個 DOM 元素，我們需要首先移除其監聽器，否則瀏覽器并不會自動地幫我們清除該監聽器，或者回收該監聽器引用的對象：

　　現代瀏覽器使用的現代垃圾回收器則會幫我們自動地檢測這種循環依賴，并且予以清除;jQuery 等第三方庫也會在清除元素之前首先移除其監聽事件。

　　iframe

　　iframe 是常見的界面共享方式，不過如果我們在父界面或者子界面中添加了對于父界面某對象的引用，譬如：

　　就有可能導致 iframe 卸載（移除元素）之后仍然有部分對象保留下來，我們可以在移除 iframe 之前執行強制的頁面重載：

　　或者手動地執行頁面清除操作：

　　Web Worker

　　現代瀏覽器中我們經常使用 Web Worker 來運行后臺任務，不過有時候如果我們過于頻繁且不加容錯地在主線程與工作線程之間傳遞數據，可能會導致內存泄漏：

　　在實際的代碼中我們應該檢測 Transferable Objects 是否正常工作：