JVM系列篇：深刻剖析G1收集器+回收流程+推薦用例

金三已通過去一半了，即將進入面試的高峯期。在BAT面試中，JVM基本都是必考的系列。你至少須要掌握：JVM內存模型與JVM參數詳細配置、JVM的4種垃圾回收算法、垃圾回收機制等（文末直達）

以及今天重點談到的JVM垃圾回收算法的實現：JVM垃圾收集器。

我先從JVM收集器的發展過程談起，而後再聚焦在G1收集器，從G1的內存模型，再到G1的回收流程，最後再談談G1的實際應用場景。

1、JVM垃圾收集器發展歷程

JVM垃圾收集器發展歷程

第一階段，Serial（串行）收集器

在jdk1.3.1以前，java虛擬機僅僅能使用Serial收集器。 Serial收集器是一個單線程的收集器，但它的「單線程」的意義並不只僅是說明它只會使用一個CPU或一條收集線程去完成垃圾收集工做，更重要的是在它進行垃圾收集時，必須暫停其餘全部的工做線程，直到它收集結束。

第二階段，Parallel（並行）收集器

Parallel收集器也稱吞吐量收集器，相比Serial收集器，Parallel最主要的優點在於使用多線程去完成垃圾清理工做，這樣能夠充分利用多核的特性，大幅下降gc時間。

第三階段，CMS（併發）收集器

CMS收集器在Minor GC時會暫停全部的應用線程，並以多線程的方式進行垃圾回收。在Full GC時再也不暫停應用線程，而是使用若干個後臺線程按期的對老年代空間進行掃描，及時回收其中再也不使用的對象。

第四階段，G1（併發）收集器

G1收集器（或者垃圾優先收集器）的設計初衷是爲了儘可能縮短處理超大堆（大於4GB）時產生的停頓。相對於CMS的優點而言是內存碎片的產生率大大下降。

 

2、JVM垃圾收集器種類

JVM垃圾收集器

1.新生代

Serial (第一代)

PraNew (第二代)

Parallel Scavenge (第三代)

G1收集器(第四代)

2.老年代

Serial Old (第一代)

Parallel Old (第二代)

CMS (第三代)

G1收集器 (第四代)

詳細的垃圾收集器比較，具體能夠查看往期文章：7種JVM垃圾收集器特色（文末直達）。

JDK1.7後全新的JVM垃圾收集器G1收集器, 目標用於取代CMS收集器。

 

G1收集器概述

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

G1(Garbage First)垃圾收集器是當今垃圾回收技術最前沿的成果之一。早在JDK7就已加入JVM的收集器你們庭中，成爲HotSpot重點發展的垃圾回收技術。同優秀的CMS垃圾回收器同樣，G1也是關注最小時延的垃圾回收器，也一樣適合大尺寸堆內存的垃圾收集，官方也推薦使用G1來代替選擇CMS。

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的堆內存算法

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收集器的方式運行。

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模式

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。

 

以爲不錯請點贊支持下。

----end----

以爲不錯請點贊支持，歡迎留言或進個人我的羣855801563領取【架構資料專題目合集90期】、【BATJTMD大廠JAVA面試真題1000+】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不按期答題、探討。