G1垃圾收集器深入剖析(圖文超詳解)

JVM垃圾收集器屬於必備必考內容，本篇重點談談G1收集器@mikechen

G1收集器概述

HotSpot團隊一直努力朝着高效收集、減少停頓(STW: Stop The World)的方向努力，也貢獻了從串行Serial收集器、到並行收集器Parallerl收集器，再到CMS並發收集器，乃至如今的G1在內的一系列優秀的垃圾收集器。

G1(Garbage First)垃圾收集器關注最小時延的垃圾回收器，也同樣適合大尺寸堆內存的垃圾收集，官方也推薦使用G1來代替選擇CMS。

1.G1收集器的最大特點

• G1最大的特點是引入分區的思路，弱化了分代的概念。
• 合理利用垃圾收集各個周期的資源，解決了其他收集器甚至CMS的眾多缺陷。

2.G1相比較CMS的改進

• 算法：G1基於標記-整理算法, 不會產生空間碎片，分配大對象時不會無法得到連續的空間而提前觸發一次FULL GC。
• 停頓時間可控：G1可以通過設置預期停頓時間（Pause Time）來控制垃圾收集時間避免應用雪崩現象。
• 並行與並發：G1能更充分的利用CPU，多核環境下的硬件優勢來縮短stop the world的停頓時間。

3.CMS和G1的區別

• CMS中，堆被分為PermGen，YoungGen，OldGen；而YoungGen又分了兩個survivo區域。在G1中，堆被平均分成幾個區域(region)，在每個區域中，雖然也保留了新老代的概念，但是收集器是以整個區域為單位收集的。
• G1在回收內存後會馬上同時做合併空閑內存的工作、而CMS默認是在STW（stop the world）的時候做。
• G1會在Young GC中使用、而CMS只能在O區使用。

4.G1收集器的應用場景

G1垃圾收集算法主要應用在多CPU大內存的服務中，在滿足高吞吐量的同時，儘可能的滿足垃圾回收時的暫停時間。
就目前而言、CMS還是默認首選的GC策略、可能在以下場景下G1更適合：

• 服務端多核CPU、JVM內存佔用較大的應用（至少大於4G）
• 應用在運行過程中會產生大量內存碎片、需要經常壓縮空間
• 想要更可控、可預期的GC停頓周期，防止高並發下應用雪崩現象

G1的堆內存算法

1.G1之前的JVM內存模型

• 新生代：伊甸園區(eden space) + 2個倖存區
• 老年代
• 持久代(perm space)：JDK1.8之前
• 元空間(metaspace)：JDK1.8之後取代持久代

2.G1收集器的內存模型

1)G1堆內存結構
堆內存會被切分成為很多個固定大小區域（Region），每個是連續範圍的虛擬內存。
堆內存中一個區域(Region)的大小可以通過-XX:G1HeapRegionSize參數指定，大小區間最小1M、最大32M，總之是2的冪次方。

默認把堆內存按照2048份均分。

2)G1堆內存分配
每個Region被標記了E、S、O和H，這些區域在邏輯上被映射為Eden，Survivor和老年代。
存活的對象從一個區域轉移（即複製或移動）到另一個區域。區域被設計為並行收集垃圾，可能會暫停所有應用線程。
如上圖所示，區域可以分配到Eden，survivor和老年代。此外，還有第四種類型，被稱為巨型區域（Humongous Region）。Humongous區域是為了那些存儲超過50%標準region大小的對象而設計的，它用來專門存放巨型對象。如果一個H區裝不下一個巨型對象，那麼G1會尋找連續的H分區來存儲。為了能找到連續的H區，有時候不得不啟動Full GC。

G1回收流程

在執行垃圾收集時，G1以類似於CMS收集器的方式運行。

1.G1收集器的階段分以下幾個步驟：

1）G1執行的第一階段：初始標記(Initial Marking )
這個階段是STW(Stop the World )的，所有應用線程會被暫停，標記出從GC Root開始直接可達的對象。

2）G1執行的第二階段：並發標記
從GC Roots開始對堆中對象進行可達性分析，找出存活對象，耗時較長。當並發標記完成後，開始最終標記(Final Marking )階段

3）最終標記（標記那些在並發標記階段發生變化的對象，將被回收）

4）篩選回收（首先對各個Regin的回收價值和成本進行排序，根據用戶所期待的GC停頓時間指定回收計劃，回收一部分Region）

最後，G1中提供了兩種模式垃圾回收模式，Young GC和Mixed GC，兩種都是Stop The World(STW)的。

G1的GC模式

1.YoungGC年輕代收集

在分配一般對象（非巨型對象）時，當所有eden region使用達到最大閥值並且無法申請足夠內存時，會觸發一次YoungGC。每次younggc會回收所有Eden以及Survivor區，並且將存活對象複製到Old區以及另一部分的Survivor區。
YoungGC的回收過程如下：

• 根掃描,跟CMS類似，Stop the world，掃描GC Roots對象。
• 處理Dirty card,更新RSet.
• 掃描RSet,掃描RSet中所有old區對掃描到的young區或者survivor去的引用。
• 拷貝掃描出的存活的對象到survivor2/old區
• 處理引用隊列，軟引用，弱引用，虛引用

2.mixed gc

當越來越多的對象晉陞到老年代old region時，為了避免堆內存被耗盡，虛擬機會觸發一個混合的垃圾收集器，即mixed gc，該算法並不是一個old gc，除了回收整個young region，還會回收一部分的old region，這裡需要注意：是一部分老年代，而不是全部老年代，可以選擇哪些old region進行收集，從而可以對垃圾回收的耗時時間進行控制。
G1沒有fullGC概念，需要fullGC時，調用serialOldGC進行全堆掃描（包括eden、survivor、o、perm）。

G1的推薦用例

G1的第一個重要特點是為用戶的應用程序的提供一個低GC延時和大內存GC的解決方案。這意味着堆大小6GB或更大，穩定和可預測的暫停時間將低於0.5秒。
如果應用程序使用CMS或ParallelOld垃圾回收器具有一個或多個以下特徵，將有利於切換到G1：

• Full GC持續時間太長或太頻繁
• 對象分配率或年輕代升級老年代很頻繁
• 不期望的很長的垃圾收集時間或壓縮暫停（超過0.5至1秒）

注意：如果你正在使用CMS或ParallelOld收集器，並且你的應用程序沒有遇到長時間的垃圾收集暫停，則保持與您的當前收集器是很好的，升級JDK並不必要更新收集器為G1。

以上！

閱讀更多架構技術合集

作者：陳睿|mikechen mikechen的互聯網架構作者

原文地址：https://mikechen.cc/7126.html

本文由 @mikechen 原創發佈於mikechen的互聯網架構，未經許可，禁止轉載。