1. 介紹
瀏覽器的 Javascript 具有自動垃圾回收機(jī)制(GC:Garbage Collecation)，也就是說，執(zhí)行環(huán)境會負(fù)責(zé)管理代碼執(zhí)行過程中使用的內(nèi)存。其原理是：垃圾收集器會定期(周期性)找出那些不在繼續(xù)使用的變量，然后釋放其內(nèi)存。但是這個過程不是實時的，因為其開銷比較大并且 GC 時停止響應(yīng)其他操作，所以垃圾回收器會按照固定的時間間隔周期性的執(zhí)行。
不再使用的變量也就是生命周期結(jié)束的變量，當(dāng)然只可能是局部變量，全局變量的生命周期直至瀏覽器卸載頁面才會結(jié)束。局部變量只在函數(shù)的執(zhí)行過程中存在，而在這個過程中會為局部變量在?；蚨焉戏峙湎鄳?yīng)的空間，以存儲它們的值，然后在函數(shù)中使用這些變量，直至函數(shù)結(jié)束，而閉包中由于內(nèi)部函數(shù)的原因，外部函數(shù)并不能算是結(jié)束。
還是上代碼說明吧：
我們來看代碼是如何執(zhí)行的。首先聲明了兩個函數(shù)，分別叫做 fn1 和 fn2，當(dāng) fn1 被調(diào)用時，進(jìn)入 fn1 的環(huán)境，會開辟一塊內(nèi)存存放對象 {name:'hanzichi',age:10}，而當(dāng)調(diào)用結(jié)束后，出了 fn1 的環(huán)境，那么該塊內(nèi)存會被 JS 引擎中的垃圾回收器自動釋放;在 fn2 被調(diào)用的過程中，返回的對象被全局變量 b 所指向，所以該塊內(nèi)存并不會被釋放。
這里問題就出現(xiàn)了：到底哪個變量是沒有用的?所以垃圾收集器必須跟蹤到底哪個變量沒用，對于不再有用的變量打上標(biāo)記，以備將來收回其內(nèi)存。用于標(biāo)記的無用變量的策略可能因?qū)崿F(xiàn)而有所區(qū)別，通常情況下有兩種實現(xiàn)方式：標(biāo)記清除和引用計數(shù)。引用計數(shù)不太常用，標(biāo)記清除較為常用。
2. 標(biāo)記清除
js中最常用的垃圾回收方式就是標(biāo)記清除。當(dāng)變量進(jìn)入環(huán)境時，例如，在函數(shù)中聲明一個變量，就將這個變量標(biāo)記為“進(jìn)入環(huán)境”。從邏輯上講，永遠(yuǎn)不能釋放進(jìn)入環(huán)境的變量所占用的內(nèi)存，因為只要執(zhí)行流進(jìn)入相應(yīng)的環(huán)境，就可能會用到它們。而當(dāng)變量離開環(huán)境時，則將其標(biāo)記為“離開環(huán)境”。
垃圾回收器在運行的時候會給存儲在內(nèi)存中的所有變量都加上標(biāo)記(當(dāng)然，可以使用任何標(biāo)記方式)。然后，它會去掉環(huán)境中的變量以及被環(huán)境中的變量引用的變量的標(biāo)記(閉包)。而在此之后再被加上標(biāo)記的變量將被視為準(zhǔn)備刪除的變量，原因是環(huán)境中的變量已經(jīng)無法訪問到這些變量了。最后，垃圾回收器完成內(nèi)存清除工作，銷毀那些帶標(biāo)記的值并回收它們所占用的內(nèi)存空間。到目前為止，IE9+、Firefox、Opera、Chrome、Safari 的 JS 實現(xiàn)使用的都是標(biāo)記清除的垃圾回收策略或類似的策略，只不過垃圾收集的時間間隔互不相同。
3. 引用計數(shù)
引用計數(shù)的含義是跟蹤記錄每個值被引用的次數(shù)。當(dāng)聲明了一個變量并將一個引用類型值賦給該變量時，則這個值的引用次數(shù)就是 1。如果同一個值又被賦給另一個變量，則該值的引用次數(shù)加 1。相反，如果包含對這個值引用的變量又取得了另外一個值，則這個值的引用次數(shù)減 1。當(dāng)這個值的引用次數(shù)變成 0 時，則說明沒有辦法再訪問這個值了，因而就可以將其占用的內(nèi)存空間回收回來。這樣，當(dāng)垃圾回收器下次再運行時，它就會釋放那些引用次數(shù)為 0 的值所占用的內(nèi)存。
Netscape Navigator3 是最早使用引用計數(shù)策略的瀏覽器，但很快它就遇到一個嚴(yán)重的問題：循環(huán)引用。循環(huán)引用指的是對象 A 中包含一個指向?qū)ο驜的指針，而對象 B 中也包含一個指向?qū)ο?A 的引用。
以上代碼 a 和 b 的引用次數(shù)都是 2， fn 執(zhí)行完畢后，兩個對象都已經(jīng)離開環(huán)境，在標(biāo)記清除方式下是沒有問題的，但是在引用計數(shù)策略下，因為 a 和 b 的引用次數(shù)不為 0，所以不會被垃圾回收器回收內(nèi)存，如果 fn函數(shù)被大量調(diào)用，就會造成內(nèi)存泄露。在 IE7 與 IE8 上，內(nèi)存直線上升。
我們知道，IE 中有一部分對象并不是原生 JS 對象。例如，其內(nèi)存泄露 DOM 和 BOM 中的對象就是使用 C++ 以 COM 對象的形式實現(xiàn)的，而 COM 對象的垃圾回收機(jī)制采用的就是引用計數(shù)策略。因此，即使IE的js引擎采用標(biāo)記清除策略來實現(xiàn)，但 JS 訪問的COM對象依然是基于引用計數(shù)策略的。換句話說，只要在 IE 中涉及 COM 對象，就會存在循環(huán)引用的問題。
這個例子在一個 DOM 元素 element 與一個原生js對象 myObject 之間創(chuàng)建了循環(huán)引用。其中，變量 myObject 有一個屬性 e 指向 element 對象;而變量 element 也有一個屬性 o 回指 myObject。由于存在這個循環(huán)引用，即使例子中的 DOM 從頁面中移除，它也永遠(yuǎn)不會被回收。
舉個栗子：
- 黃色是指直接被 js變量所引用，在內(nèi)存里
- 紅色是指間接被 js變量所引用，如上圖，refB 被 refA 間接引用，導(dǎo)致即使 refB 變量被清空，也是不會被回收的
- 子元素 refB 由于 parentNode 的間接引用，只要它不被刪除，它所有的父元素(圖中紅色部分)都不會被刪除
另一個例子：
這段代碼看起來沒什么問題，但是 obj 引用了 document.getElementById('element')，而 document.getElementById('element') 的 onclick 方法會引用外部環(huán)境中的變量，自然也包括 obj，是不是很隱蔽啊。(在比較新的瀏覽器中在移除Node的時候已經(jīng)會移除其上的event了，但是在老的瀏覽器，特別是 IE 上會有這個 bug)
解決辦法：
最簡單的方式就是自己手工解除循環(huán)引用，比如剛才的函數(shù)可以這樣
將變量設(shè)置為 null 意味著切斷變量與它此前引用的值之間的連接。當(dāng)垃圾回收器下次運行時，就會刪除這些值并回收它們占用的內(nèi)存。
要注意的是，IE9+ 并不存在循環(huán)引用導(dǎo)致 DOM 內(nèi)存泄露問題，可能是微軟做了優(yōu)化，或者 DOM 的回收方式已經(jīng)改變。
4. 內(nèi)存管理
4.1 什么時候觸發(fā)垃圾回收?
垃圾回收器周期性運行，如果分配的內(nèi)存非常多，那么回收工作也會很艱巨，確定垃圾回收時間間隔就變成了一個值得思考的問題。IE6的垃圾回收是根據(jù)內(nèi)存分配量運行的，當(dāng)環(huán)境中存在256個變量、4096個對象、64k的字符串任意一種情況的時候就會觸發(fā)垃圾回收器工作，看起來很科學(xué)，不用按一段時間就調(diào)用一次，有時候會沒必要，這樣按需調(diào)用不是很好嗎?但是如果環(huán)境中就是有這么多變量等一直存在，現(xiàn)在腳本如此復(fù)雜，很正常，那么結(jié)果就是垃圾回收器一直在工作，這樣瀏覽器就沒法兒玩兒了。
微軟在 IE7 中做了調(diào)整，觸發(fā)條件不再是固定的，而是動態(tài)修改的，初始值和 IE6 相同，如果垃圾回收器回收的內(nèi)存分配量低于程序占用內(nèi)存的15%，說明大部分內(nèi)存不可被回收，設(shè)的垃圾回收觸發(fā)條件過于敏感，這時候把臨街條件翻倍，如果回收的內(nèi)存高于 85%，說明大部分內(nèi)存早就該清理了，這時候把觸發(fā)條件置回。這樣就使垃圾回收工作職能了很多
4.2 合理的GC方案
1. 基礎(chǔ)方案
Javascript 引擎基礎(chǔ)GC方案是(simple GC)：mark and sweep(標(biāo)記清除)，即：
遍歷所有可訪問的對象。
回收已不可訪問的對象。
2. GC的缺陷
和其他語言一樣，JS 的 GC 策略也無法避免一個問題：GC 時，停止響應(yīng)其他操作，這是為了安全考慮。而 Javascript 的 GC 在 100ms 甚至以上，對一般的應(yīng)用還好，但對于 JS 游戲，動畫對連貫性要求比較高的應(yīng)用，就麻煩了。這就是新引擎需要優(yōu)化的點：避免GC造成的長時間停止響應(yīng)。
3. GC優(yōu)化策略
David 大叔主要介紹了2個優(yōu)化方案，而這也是最主要的2個優(yōu)化方案了：
分代回收(Generation GC)
這個和Java回收策略思想是一致的，也是V8所主要采用的。目的是通過區(qū)分“臨時”與“持久”對象;多回收“臨時對象”區(qū)(young generation)，少回收“持久對象”區(qū)(tenured generation)，減少每次需遍歷的對象，從而減少每次GC的耗時。如圖：
這里需要補充的是：對于 tenured generation 對象，有額外的開銷：把它從 young generation 遷移到 tenured generation，另外，如果被引用了，那引用的指向也需要修改。這里主要內(nèi)容可以參考深入淺出Node中關(guān)于內(nèi)存的介紹，很詳細(xì)~
2. 增量GC 這個方案的思想很簡單，就是“每次處理一點，下次再處理一點，如此類推”。如圖：
這種方案，雖然耗時短，但中斷較多，帶來了上下文切換頻繁的問題。因為每種方案都其適用場景和缺點，因此在實際應(yīng)用中，會根據(jù)實際情況選擇方案。比如：低 (對象/s) 比率時，中斷執(zhí)行GC的頻率，simple GC更低些;如果大量對象都是長期“存活”，則分代處理優(yōu)勢也不大。
4. Vue 中的內(nèi)存泄漏問題
JS 程序的內(nèi)存溢出后，會使某一段函數(shù)體永遠(yuǎn)失效(取決于當(dāng)時的 JS 代碼運行到哪一個函數(shù))，通常表現(xiàn)為程序突然卡死或程序出現(xiàn)異常。
這時我們就要對該 JS 程序進(jìn)行內(nèi)存泄漏的排查，找出哪些對象所占用的內(nèi)存沒有釋放。這些對象通常都是開發(fā)者以為釋放掉了，但事實上仍被某個閉包引用著，或者放在某個數(shù)組里面。
4.1 泄漏點
DOM/BOM 對象泄漏;
script 中存在對 DOM/BOM 對象的引用導(dǎo)致;
JS 對象泄漏;
通常由閉包導(dǎo)致，比如事件處理回調(diào)，導(dǎo)致 DOM 對象和腳本中對象雙向引用，這個是常見的泄漏原因;
4.2 代碼關(guān)注點
主要關(guān)注的就是各種事件綁定場景，比如：
DOM 中的 addEventLisner 函數(shù)及派生的事件監(jiān)聽，比如 Jquery 中的 on 函數(shù)，Vue 組件實例的 $on 函數(shù);
其它 BOM 對象的事件監(jiān)聽， 比如 websocket 實例的 on 函數(shù);
避免不必要的函數(shù)引用;
如果使用 render 函數(shù)，避免在 HTML 標(biāo)簽中綁定 DOM/BOM 事件;
4.3 如何處理
如果在 mounted/created 鉤子中使用 JS 綁定了 DOM/BOM 對象中的事件，需要在 beforeDestroy 中做對應(yīng)解綁處理;
如果在 mounted/created 鉤子中使用了第三方庫初始化，需要在 beforeDestroy 中做對應(yīng)銷毀處理(一般用不到，因為很多時候都是直接全局 Vue.use);
如果組件中使用了 setInterval，需要在 beforeDestroy 中做對應(yīng)銷毀處理;
4.4 在 vue 組件中處理 addEventListener
調(diào)用 addEventListener 添加事件監(jiān)聽后在 beforeDestroy 中調(diào)用 removeEventListener移除對應(yīng)的事件監(jiān)聽。為了準(zhǔn)確移除監(jiān)聽，盡量不要使用匿名函數(shù)或者已有的函數(shù)的綁定來直接作為事件監(jiān)聽函數(shù)。
4.5 觀察者模式引起的內(nèi)存泄漏
在 spa 應(yīng)用中使用觀察者模式的時候如果給觀察者注冊了被觀察的方法，而沒有在離開組件的時候及時移除，可能造成重復(fù)注冊而內(nèi)存泄漏;
舉個栗子：進(jìn)入組件的時候 ob.addListener("enter",_func)，如果離開組件 beforeDestroy 的時候沒有 ob.removeListener("enter",_func)，就會導(dǎo)致內(nèi)存泄漏。
更詳細(xì)的栗子參考：德州撲克栗子
4.6 上下文綁定引起的內(nèi)存泄漏
有時候使用 bind/apply/call 上下文綁定方法的時候，會有內(nèi)存泄漏的隱患。
使用 chrome dev tool>memory>profiles 查看內(nèi)存中 ClassA 的實例數(shù)，發(fā)現(xiàn)有兩個實例， a和 b。雖然 a 設(shè)置成 null 了，但是 b 的方法中 bind 的閉包上下文 self 綁定了 a，因此雖然 a釋放，但是 b/b.func沒有釋放，閉包的 self 一直存在并保持對 a 的引用。
【責(zé)任編輯：武曉燕 TEL：（010）68476606】