內(nèi)存影響性能。當(dāng)你的應(yīng)用程序代碼消耗太多內(nèi)存時，你會得到一個卡頓的應(yīng)用程序，甚至可能會出現(xiàn)內(nèi)存耗盡的崩潰。

當(dāng)你在web瀏覽器中運行一個應(yīng)用程序時，大部分應(yīng)用程序內(nèi)存存儲在Javascript堆中，而這個堆位于計算機的RAM內(nèi)。在 Vue 或者 React 應(yīng)用程序的上下文中，存儲在JS堆中的常見對象包括：組件實例、虛擬DOM，以及如果你使用狀態(tài)管理工具（Vuex、Pinia、Redux、mobx）的話，包含 State、Action 等。

當(dāng)你與一個應(yīng)用程序進行交互時，JS堆可能會隨著時間的推移而增長。你可以通過使用Chrome DevTools進行剖析時觀察到這種增長。

我在瀏覽 Medium 首頁幾秒鐘后拍攝了上面的截圖。

由于內(nèi)存增長會影響應(yīng)用程序的性能，因此清除未使用的內(nèi)存以釋放空間非常重要。Javascript引擎回收未使用內(nèi)存的過程稱為垃圾回收（GC）。與某些語言（如C和C++）不同，Javascript引擎會自動進行垃圾回收。

讓我們從Chrome開始分析。

Javascript 與 Major GC 和 Minor GC

Major GC 和 Minor GC

Major GC（ 主垃圾回收器 ）：主要負責(zé)老生代的垃圾回收；

Minor GC（ 副垃圾回收器 ）：主要負責(zé)新生代的垃圾回收；

在瀏覽器中能找到他們（Major GC、Minor GC）之間的工作身影：

• JS HEAP SIZE 明顯降低的時候，必是Major GC在工作

• 反觀 Minor GC，則沒 Major工作這么明顯，但是Minor GC工作會比Major頻繁得多

Javascript使用 Major GC 和 Minor GC 清理JS堆

打開Chrome開發(fā)者工具，并導(dǎo)航到性能（Performance）選項卡，確保選中“內(nèi)存（Memory）”復(fù)選框。

這是Chrome分析器生成的配置文件：

你可以看到堆的大小會增長和縮小。如果你仔細觀察，你會發(fā)現(xiàn)堆大小的下降與垃圾回收活動是對應(yīng)的。"Major GC" 表示正在進行一次主要的垃圾回收。

當(dāng)JS堆大小大幅下降時，你很可能會在任何網(wǎng)站上看到這種模式。事實上，如果你在單頁應(yīng)用程序中切換標(biāo)簽頁時，JS堆的大小沒有顯著減少，但標(biāo)簽頁的內(nèi)容有所不同，這可能是內(nèi)存泄漏的跡象。

在剖析中，你還會看到“Minor GC”幀。

這些 Major GC 和 Minor GC 幀向你揭示了一些關(guān)于Javascript中垃圾回收的信息。

• 垃圾回收有兩種類型：Major GC 和 Minor GC。
• Minor GC 通常很短暫，而 Major GC 則需要更長的時間。
• 在“任務(wù)”下看到它們作為幀的事實表明它們都在主應(yīng)用程序線程上運行。
• 因為它們在主線程上運行，它們會阻塞Javascript執(zhí)行，因為瀏覽器只有一個主線程來運行你的Javascript代碼。
• 由于它們阻塞了Javascript執(zhí)行，過多的GC會影響應(yīng)用程序的性能。

注意：GC 只有在某些時候會阻塞Javascript執(zhí)行。它并不是一直阻塞，而是在顯示為幀時。我們在Chrome分析器中無法看到這一點，但在Firefox分析器中可以看到。

現(xiàn)在讓我們來看看Firefox分析器，它也揭示了Major GC和Minor GC之間的差異。

Major GC和Minor GC清理JS堆的兩個不同部分

我不是Firefox的用戶，我之所以將Firefox下載到我的筆記本電腦上，僅僅是因為它的剖析功能。Firefox的剖析器是開源的，并且比Chrome的剖析器有更多的可視化功能。

錄制一個剖析文件，并導(dǎo)航到“Marker Chart”可視化。Marker Chart本質(zhì)上是所有不同類型活動的時間軸，包括垃圾回收活動。

你可能會注意到的第一件事是，Minor GC 發(fā)生頻率相當(dāng)高，而 Major GC 則不是。這是有很好的原因的，因為如前面所述，Minor GC 很短暫，而 Major GC 則需要更長的時間。

如果你將鼠標(biāo)懸停在一個 Minor GC 切片上，你會得到以下描述：

因此，除了它們以不同的頻率運行外，Major GC 和 Minor GC 還清理JS堆的不同部分。

如上所述，Minor GC 清除了所謂的“苗圃集合(nursery collection)”。 如果對象在 Minor GC 中幸存下來，它們就會從 Nursery 移動到“終身(tenured)”堆或“長期(long-lived)”堆上。 因此，Major GC 必定是清除永久堆的對象。

Major GC通過一種名為mark—and—sweep的算法來清理永久化的堆，我們稍后將介紹該算法。

現(xiàn)在我們知道 JS 堆至少有 2 個組件：

• 一個用于最近分配的對象的苗圃集合(nursery collection)
• 一個用于長期存在的對象的永久堆。(“終身(tenured)”堆或“長期(long-lived)”堆)

主要GC算法（增量標(biāo)記和清除）

Marker Chart 最后一行的屏幕截圖中還有一個 GCSlide。 嗯，那是什么？

如果將鼠標(biāo)懸停在 Major GC 矩形上，你會看到 Major GC 的描述：

整個Major GC花費了580毫秒。然而，正如描述所說，主線程僅在個別切片上被阻塞。因此，最后一行的GCSlide指的是這些阻塞切片。再往下看，你會發(fā)現(xiàn)總切片時間是34.4毫秒，因此在Javascript主線程無法執(zhí)行應(yīng)用程序代碼時，只有34.4毫秒的工作。

如果你將鼠標(biāo)懸停在其中一個GC切片上，你會得到：

請注意，兩個工具提示都有“標(biāo)記階段”和“清除階段”。這意味著Javascript垃圾回收有兩個階段：標(biāo)記和清除。這個算法稱為標(biāo)記-清除。請注意，GC切片的描述中提到了“增量垃圾回收的一個切片”。增量GC是實現(xiàn)標(biāo)記-清除算法的一種方式。

標(biāo)記階段通過遍歷對象圖來“標(biāo)記”所有從根集合（例如全局變量、活動函數(shù)調(diào)用）可達的對象。然后，清除階段“掃描”整個堆，收集并釋放所有未標(biāo)記的對象的內(nèi)存，這些對象被視為不可達，因此是垃圾。

增量意味著你在標(biāo)記階段以增量方式進行操作，從而最小化主線程被阻塞的時間。

Chrome vs. Firefox

當(dāng)涉及到Javascript中的垃圾回收時，我想提出一些細微差別。

Chrome（以及NodeJS）使用V8 Javascript引擎。

另一方面，F(xiàn)irefox使用一個名為SpiderMonkey的不同引擎。正是Javascript引擎帶來了垃圾回收。V8使用術(shù)語“young generation”代替“nursery”，以及“old generation”代替“tenured heap”。然而，V8和SpiderMonkey都使用Minor GC來清理年輕對象和Major GC來清理老對象。

兩者都實現(xiàn)了增量標(biāo)記-清除算法用于Major GC。不過，具體的 增量標(biāo)記-清除算法 在V8和SpiderMonkey之間有所不同。

總結(jié)一下：