本篇目錄

• 1、GC的分類與性能指標
• • 1.1 GC分類
  • 1.2 評估GC的性能指標
  • • 1.2.1 吞吐量
    • 1.2.2 暫停時間
• 2、不同垃圾回收器概述
• • 2.1 垃圾收集器發展史
  • 2.2 7款經典的垃圾收集器
  • 2.3 7款經典的垃圾收集器與垃圾分代之間的關系
  • 2.4 垃圾收集器的組合關系
  • 2.5 查看默認的垃圾收集器
• 3、Serial回收器:串行回收
• • 3.1 概述
  • 3.2 優勢
• 4、ParNew回收器:并行回收
• 5、Parallel回收器:吞吐量優先
• • 5.1 概述
• 6、CMS回收器:低延遲、并發回收
• • 6.1 概述
  • 6.2 工作過程
  • 6.3 CMS的優點：
  • 6.4 CMS的弊端
  • 6.5 JDK 后續版本中CMS的變化
• 7、G1回收器:區域化分代式
• • 7.1 **為什么名字叫做Garbage First （G1）呢**
  • 7.2 優勢
  • 7.3 缺點
  • 7.4 適用場景
  • 7.5 分區region,化整為零
  • 7.6 垃圾回收過程
  • • 7.6.1 概述
    • 7.6.2 詳解
    • • 7.6.2.1 年輕代GC
      • 7.6.2.2 并發標記過程
      • 7.6.2.3 混合回收
      • 7.6.2.4 Full GC
  • 7.7 補充
  • 7.8 記憶集與寫屏障

1、GC的分類與性能指標

1.1 GC分類

• 垃圾收集器沒有在規范中進行過多的規定，可以由不同的廠商、不同版本的JVM來實現。
• 由于JDK的版本處于高速迭代過程中，因此Java發展至今已經衍生了眾多的GC版本。
• 從不同角度分析垃圾收集器，可以將GC分為不同的類型。

1、按線程數分，可以分為串行垃圾回收器和并行垃圾回收器：

• 串行回收指的是在同一時間段內只允許有一個CPU用于執行垃圾回收操作，此時工作線程被暫停，直至垃圾收集工作結束。
  • ?在諸如單CPU處理器或者較小的應用內存等硬件平臺不是特別優越的場 合，串行回收器的性能表現可以超過并行回收器和并發回收器。所以，串行回收默認被應用在客戶端的Client模式下的JVM中；
  • ?在并發能力比較強的CPU上，并行回收器產生的停頓時間要短于串行回收器。
• 和串行回收相反，并行收集可以運用多個CPU同時執行垃圾回收，因此提升 了應用的吞吐量，不過并行回收仍然與串行回收一樣，采用獨占式，使用了“ Stop一the一world”機制。

2、按照工作模式分，可以分為并發式垃圾回收器和獨占式垃圾回收器

• 并發式垃圾回收器與應用程序線程交替工作，以盡可能減少應用程序的停頓時間。
• 獨占式垃圾回收器（Stop the world）一旦運行，就停止應用程序中的所有用戶線程，直到垃圾回收過程完全結束。

3、按碎片處理方式分，可分為壓縮式垃圾回收器和非壓縮式垃圾回收器：

• 壓縮式垃圾回收器會在回收完成后，對存活對象進行壓縮整理，消除回收后的碎片。再分配對象空間使用: 指針碰撞。
• 非壓縮式的垃圾回收器不進行這步操作。再分配對象空間使用: 空閑列表。

4、按工作的內存區間分，又可分為年輕代垃圾回收器和老年代垃圾回收器

1.2 評估GC的性能指標

• ① 吞吐量：運行用戶代碼的時間占總運行時間的比例
  • （總運行時間：程序的運行時間十內存回收的時間）
• 垃圾收集開銷：吞吐量的補數，垃圾收集所用時間與總運行時間的比例。
• ② 暫停時間：執行垃圾收集時，程序的工作線程被暫停的時間
• 收集頻率：相對于應用程序的執行，收集操作發生的頻率。
• ③ 內存占用： Java堆區所占的內存大小
• 快速：一個對象從誕生到被回收所經歷的時間。
• 這三者共同構成一個“不可能三角”。三者總體的表現會隨著技術進步而越來越好。一款優秀的收集器通常最多同時滿足其中的兩項。
• 這三項里，暫停時間的重要性日益凸顯。因為隨著硬件發展，內存占用 多些越來越能容忍，硬件性能的提升也有助于降低收集器運行時對應用程序的影響，即提高了吞吐量。而內存的擴大，對延遲反而帶來負面效果。
• 簡單來說，主要抓住兩點：吞吐量 、 暫停時間

1.2.1 吞吐量

• 吞吐量就是CPU用于運行用戶代碼的時間與CPU總消耗時間的比值，即吞吐量=運行用戶代碼時間 / （運行用戶代碼時間+垃圾收集時間）
  • ?比如：虛擬機總共運行了100分鐘，其中垃圾收集花掉1分鐘，那吞吐量就是99%
• 這種情況下，應用程序能容忍較高的暫停時間，因此，高吞吐量的應用程序有更長的時間基準，快速響應是不必考慮的。
• 吞吐量優先，意味著在單位時間內，STW的時間最短： 0.2 + 0.2 = 0.4

1.2.2 暫停時間

• “暫停時間”是指一個時間段內應用程序線程暫停，讓GC線程執行的狀態
  • ?例如，GC期間100毫秒的暫停時間意味著在這100毫秒期間內沒有應用程序線程是活動的。
• 暫停時間優先，意味著盡可能讓單次STW的時間最短： 0.1 + 0.1 + 0.1 + 0.1+0.1=0.5
• 高吞吐量較好因為這會讓應用程序的最終用戶感覺只有應用程序線程在做“生產性”工作。直覺上，吞吐量越高程序運行越快。
• 低暫停時間（低延遲）較好因為從最終用戶的角度來看不管是GC還是其他原因導致一個應用被掛起始終是不好的。這取決于應用程序的類型，有時候甚至短暫的200毫秒暫停都可能打斷終端用戶體驗。因此，具有低的較大暫停時間是非常重要的，特別是對于一個交互式應用程序。
• 不幸的是”高吞吐量”和”低暫停時間”是一對相互競爭的目標（矛盾）。
  • ?因為如果選擇以吞吐量優先，那么必然需要降低內存回收的執行頻率，但是這樣會導致GC需要更長的暫停時間來執行內存回收。
  • ?相反的，如果選擇以低延遲優先為原則，那么為了降低每次執行內存回收時的暫停時間，也只能頻繁地執行內存回收，但這又引起了年輕代內存的縮誠和導致程序吞吐量的下降。
• 在設計（或使用） GC算法時，我們必須確定我們的目標： 一個GC算法只可能針對兩個目標之一（即只專注于較大吞吐量或最小暫停時間），或.嘗試找到一個二者的折衷。
• 現在標準：在最大吞吐量優先的情況下，降低停頓時間。

2、不同垃圾回收器概述

垃圾收集機制是Java的招牌能力，極大地提高了開發效率。那么，Java常見的垃圾收集器有哪些？

2.1 垃圾收集器發展史

有了虛擬機，就一定需要收集垃圾的機制，這就是Garbage Collection， 對應的產品我們稱為Garbage Collector。

• 1999年隨JDK1.3.1一 起來的是串行方式的Serial GC，它是第一款GC。ParNew垃圾收集器是Serial收集器的多線程版本
• 2002年2月26日，Parallel GC和Concurrent Mark Sweep GC跟隨JDK1.4.2一起發布
  Parallel GC在JDK6之后成為HotSpot默認GC。
• 2012年，在JDK1.7u4版本中，G1可用。
• 2017年，JDK9中G1變成默認的垃圾收集器，以替代CMS。
• 2018年3月，JDK10中G1垃圾回收器的并行完整垃圾回收，實現并行性來改善最壞情況下的延遲。
  ------------分水嶺------------
• 2018年9月，JDK11發布。引入Epsilon垃圾回收器，又被稱為"No一0p （無操作） "回收器。同時，引入ZGC：可伸縮的低延遲垃圾回收器（Experimental）。
• 2019年3月，JDK12發布。 增強G1，自動返回未用堆內存給操作系統。同時，引入Shenandoah GC：低停頓時間的GC （Experimental）。
• 2019年9月，JDK13發布。增強ZGC，自動返回未用堆內存給操作系統。
• 2020年3月，JDK14發布。刪除CMS垃圾回收器。擴展ZGC在macOS和Windows.上的應用

2.2 7款經典的垃圾收集器

• 串行回收器：Serial. Serial Old
• 并行回收器：ParNew. Parallel Scavenge. Parallel Old
• 并發回收器：CMS. G1
  

2.3 7款經典的垃圾收集器與垃圾分代之間的關系

• 新生代收集器： Serial、 ParNew、Parallel Scavenge；
• 老年代收集器： Serial Old、 Parallel Old、 CMS；
• 整堆收集器： G1；
  

2.4 垃圾收集器的組合關系

兩個收集器間有連線，表明它們可以搭配使用： Serial/Serial 01d、Serial/CMS、 ParNew/Serial 01d、ParNew/CMS、 Parallel Scavenge/Serial 01d、Parallel Scavenge/Parallel 0ld、G1；

其中Serial 0ld作為CMS 出現"Concurrent Mode Failure"失敗的后 備預案。

（紅色虛線）由于維護和兼容性測試的成本，在JDK 8時將Serial+CMS、 ParNew+Serial 01d這兩個組合聲明為廢棄（JEP 173） ，并在JDK 9中完全取消了這些組合的支持（JEP214），即：移除。

（綠色虛線）JDK 14中：棄用Parallel Scavenge和Serial0ld GC組合（JEP366 ）

（青色虛線）JDK 14中：刪除CMS垃圾回收器 （JEP 363）
? 為什么要有很多收集器個不夠嗎？ 因為Java的使用場景很多， 移動端，服務器等。所以就需要針對不同的場景，提供不同的垃圾收集器，提高垃圾收集的性能。
? 雖然我們會對各個收集器進行比較，但并非為了挑選一個最好的收集器出來。沒有一種放之四海皆準、任何場景下都適用的完美收集器存在，更加沒有萬能的收集器。所以我們選擇的只是對具體應用最合適的收集器。

2.5 查看默認的垃圾收集器

? 一xx：+PrintCommandLineFlags： 查看命令行相關參數（包含使用的垃圾收集器）
? 使用命令行指令： jinfo 一flag相關垃圾回收器參數進程ID

/*** -XX:+PrintCommandLineFlags** -XX:+UseSerialGC:表明新生代使用Serial GC ，同時老年代使用Serial Old GC** -XX:+UseParNewGC：標明新生代使用ParNew GC** -XX:+UseParallelGC:表明新生代使用Parallel GC* -XX:+UseParallelOldGC : 表明老年代使用 Parallel Old GC* 說明：二者可以相互激活** -XX:+UseConcMarkSweepGC：表明老年代使用CMS GC。同時，年輕代會觸發對ParNew 的使用*/ public class GCUseTest {public static void main(String[] args) {ArrayList<byte[]> list = new ArrayList<>();while(true){byte[] arr = new byte[100];list.add(arr);try {Thread.sleep(10);} catch (InterruptedException e) {e.printStackTrace();}}} }

輸出：

-XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseParallelGC

jdk8環境下，默認使用 Parallel Scavenge（新生代）+ Serial Old（老年代）

3、Serial回收器:串行回收

3.1 概述

• Serial收集器是最基本、歷史最悠久的垃圾收集器了。JDK1.3之前回收新生代唯一的選擇。
• Serial收集器作為HotSpot中Client模式下的默認新生代垃圾收集器。
• Serial收集器采用復制算法、串行回收和"Stop一 the一World"機制的方式執行內存回收。
• 除了年輕代之外，Serial收集器還提供用于執行老年代垃圾收集的Serial Old收集器。 Serial Old收集器同樣也采用了串行回收 和"Stop the World"機制，只不過內存回收算法使用的是標記一壓縮算 法。
  • ?Serial Old是運行在Client模式下默認的老年代的垃圾回收器
  • ?Serial Old在Server模式下主要有兩個用途：①與新生代的ParallelScavenge配合使用; ②作為老年代CMS收集器的后備垃圾收集方案
• 這個收集器是一個單線程的收集器，但它的“單線程”的意義并不僅僅說明它只會使用一個CPU或一條收集線程去完成垃圾收集工作，更重要的是在它進行垃圾收集時，必須暫停其他所有的工作線程，直到它收集結束（Stop The World ）。

3.2 優勢

• 簡單而高效（與其他收集器的單線程比），對于限定單個CPU的環境來說，Serial 收集器由于沒有線程交互的開銷，專心做垃圾收集自然可以獲得最高的單線程收集效率。
  • ?運行在Client模式下的虛擬機是個不錯的選擇。
• 在用戶的桌面應用場景中，可用內存一般不大（幾十MB至一兩百MB）， 可以在較短時間內完成垃圾收集（幾十ms至一百多ms） ，只要不頻繁發生，使用串行回收器是可以接受的。
• 在HotSpot虛擬機中，使用一XX： +UseSerialGC 參數可以指定年輕代和老年代都使用串行收集器。
  • 等價于新生代用Serial GC，且老年代用Serial Old GC
  • 控制臺輸出 -XX:InitialHeapSize=268435456 -XX:MaxHeapSize=4294967296 -XX:+PrintCommandLineFlags -XX:+UseCompressedClassPointers -XX:+UseCompressedOops -XX:+UseSerialGC

4、ParNew回收器:并行回收

• 如果說Serial GC是年輕代中的單線程垃圾收集器，那么ParNew收集器則是Serial收集器的多線程版本。
  • ?Par是Parallel 的縮寫，New： 只能處理的是新生代
• ParNew收集器除了采用并行回收的方式執行內存回收外，兩款垃圾收集器之間幾乎沒有任何區別。ParNew收集器在年輕代中同樣也是采用復制算法、"Stop一 the一World"機制。
• ParNew是很多JVM運行在Server模式下新生代的默認垃圾收集器。
• 對于新生代，回收次數頻繁，使用并行方式高效。
• 對于老年代，回收次數少，使用串行方式節省資源。（CPU并行 需要切換線程，串行可以省去切換線程的資源）
• 由于ParNew收集器是基于并行回收，那么是否可以斷定ParNew收集器的回收效率在任何場景下都會比Serial收集器更高效？
  • ?ParNew 收集器運行在多CPU的環境下，由于可以充分利用多CPU、 多核心等物理硬件資源優勢，可以更快速地完成垃圾收集，提升程序的吞吐量。
  • ?但是在單個CPU的環境下，ParNew收 集器不比Serial收集器更高 效。雖然Serial收集器是基于串行回收，但是由于CPU不需要頻繁地做任務切換，因此可以有效避免多線程交互過程中產生的一些額外開銷。
• 除Serial外，目前只有ParNew GC能與CMS收集器配合工作
• 在程序中，開發人員可以通過選項"一XX： +UseParNewGC"手動指定使用.ParNew收集器執行內存回收任務。它表示年輕代使用并行收集器，不影響老年代。
• 一XX：ParallelGCThreads 限制線程數量，默認開啟和CPU數據相同的線程數。

5、Parallel回收器:吞吐量優先

5.1 概述

• HotSpot的年輕代中除了擁有ParNew收集器是基于并行回收的以外，Parallel Scavenge收集器同樣也采用了復制算法、并行回收和"Stop the World"機制。
• 那么Parallel收集器的出現是否多此一舉？
  • ?和ParNew收集器不同，Parallel Scavenge收集 器的目標則是達到一個可控制的吞吐量（Throughput），它也被稱為吞吐量優先的垃圾收集器。
  • ?自適應調節策略也是Parallel Scavenge 與ParNew一個重要區別。
• 高吞吐量則可以高效率地利用CPU 時間，盡快完成程序的運算任務，主 要適合在后臺運算而不需要太多交互的任務。因此，常見在服務器環境中使用。例如，那些執行批量處理、訂單處理、工資支付、科學計算的應用程序。
• Parallel收集器在JDK1.6時提供了用于執行老年代垃圾收集的 Parallel Old收集器，用來代替老年代的Serial Old收集器。
• Parallel Old收集器采用了標記一壓縮算法，但同樣也是基于并行回收和”Stop一the一World"機制。
• 在程序吞吐量優先的應用場景中，Parallel 收集器和Parallel Old收集器的組合，在Server模式下的內存回收性能很不錯。

6、CMS回收器:低延遲、并發回收

6.1 概述

• 在JDK1.5時期， HotSpot推出了一款在強交互應用中幾乎可認為有劃 時代意義的垃圾收集器： CMS （Concurrent 一Mark 一 Sweep）收集器，這款收集器是HotSpot虛擬機中第一款真正意義上的并發收集器，它第一次實現了讓垃圾收集線程與用戶線程同時工作。
• CMS收集器的關注點是盡可能縮短垃圾收集時用戶線程的停頓時間。停頓時 間越短（低延遲）就越適合與用戶交互的程序，良好的響應速度能提升用戶體驗。
  • ?目前很大一部分的Java應用集中在互聯網站或者B/S系統的服務端上，這類應用尤其重視服務的響應速度，希望系統停頓時間最短，以給用戶帶來較好的體驗。CMS收集器就非常符合這類應用的需求。
• CMS的垃圾 收集算法采用標記一清除算法，并且也 會" stop一the一world"
• 不幸的是，CMS 作為老年代的收集器，卻無法與JDK 1.4.0 中已經存在的新生代收集器Parallel Scavenge配合工作，所以在JDK 1. 5中使用CMS來收集老年代的時候，新生代只能選擇ParNew或者Serial收集器中的一個。
• 在G1出現之前，CMS使用還是非常廣泛的。一直到今天，仍然有很多系統使用CMS GC。

6.2 工作過程

CMS整個過程比之前的收集器要復雜，整個過程分為4個主要階段，即初始標記階段、并發標記階段、重新標記階段和并發清除階段。

• 初始標記（Initial一Mark） 階段：在這個階段中，程序中所有的工作線程都將會因為. “Stop一the一World"機制而出現短暫的暫停，這個階段的主要任務僅僅只是標記出GCRoots能直接關聯到的對象。一旦標記完成之后就會恢復之前被暫停的所有應用.線程。由于直接關聯對象比較小，所以這里的速度非常快。

• 并發標記（Concurrent一Mark）階段：從GC Roots的 直接關聯對象開始遍歷整個對 象圖的過程，這個過程耗時較長但是不需要停頓用戶線程，可以與垃圾收集線程一起并發運行。

• 重新標記（Remark） 階段：由于在并發標記階段中，程序的工作線程會和垃圾收集線程同時運行或者交叉運行，因此為了修正并發標記期間，因用戶程序繼續運作而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間通常會比初始標記階段稍長一些，但也遠比并發標記階段的時間短。

• 并發清除（ Concurrent一Sweep）階段：此階段清理刪除掉標記階段判斷的已經死亡的對象，釋放內存空間。由于不需要移動存活對象，所以這個階段也是可以與用戶線程同時并發的。

  盡管CMS收集器采用的是并發回收（非獨占式），但是在其初始化標記和再次標記這兩個階段中仍然需要執行“Stop一the一World”機制暫停程序中的工作線程，不過暫停時間并不會太長，因此可以說明目前所有的垃圾收集器都做不到完全不需要“Stop一the一World”，只是盡可能地縮短暫停時間。
  ??由于最耗費時間的并發標記與并發清除階段都不需要暫停工作，所以整體的回收是低停頓的。
  ??另外，由于在垃圾收集階段用戶線程沒有中斷，所以在CMS回收過程中，還應該確保應用程序用戶線程有足夠的內存可用。因此，CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進行收集，而是當堆內存使用率達到某一閾值時，便開始進行回收，以確保應用程序在CMS工作過程中依然有足夠的空間支持應用程序運行。要是CMS運行期間預留的內存無法滿足程序需要，就會出現一次“Concurrent Mode Failure”失敗，這時虛擬機將啟動后備預案：臨時啟用Serial 0ld收集器來重新進行老年代的垃圾收集，這樣停頓時間就很長了。
  ??CMS收集器的垃圾收集算法采用的是標記一清除算法，這意味著每次執行完內存回收后，由于被執行內存回收的無用對象所占用的內存空間極有可能是不連續的一些內存塊，不可避免地將會產生一些內存碎片。 那么CMS在為新對象分配內存空間時，將無法使用指針碰撞（Bump the Pointer） 技術，而只能夠選擇空閑列表（Free List） 執行內存分配。

有人會覺得既然Mark Sweep會造成內存碎片，那么為什么不把算法換成Mark Compact呢？

答案其實很簡答，因為當并發清除的時候，用Compact整理內存的話，原來的用戶線程使用的內存還怎么用呢？要保證用戶線程能繼續執行，前提的它運行的資源不受影響嘛。Mark Compact更適合“Stop the World”這種場景”下使用。

6.3 CMS的優點：

? 并發收集
? 低延遲

6.4 CMS的弊端

1）會產生內存碎片，導致并發清除后，用戶線程可用的空間不足。在無法分配大對象的情況下，不得不提前觸發Full GC。
2） CMS收集器對CPU資源非常敏感。在并發階段，它雖然不會導致用戶停頓，但是會因為占用了一部分線程而導致應用程序變慢，總吞吐量會降低。
3） CMS收集器無法處理浮動垃圾。可能出現“Concurrent Mode Failure" 失敗而導致另一次Full GC的產生。在并發標記階段由于程序的工作線程和垃圾收集線程是同時運行或者交叉運行的，那么在并發標記階段如果產生新的垃圾對象，CMS將 無法對這些垃圾對象進行標記，最終會導致這些新產生的垃圾對象沒有被及時回收，從而只能在下一次執行GC時釋放這些之前未被回收的內存空間。

6.5 JDK 后續版本中CMS的變化

? JDK9新特性： CMS被標記為Deprecate了（JEP291）
? 如果對JDK 9及以上版本的HotSpot虛擬機使用參數一XX：+UseConcMarkSweepGC來開啟CMS收集器的話，用戶會收到一個警告信息，提示CMS未來將會被廢棄。
? JDK14新特性： 刪除CMS垃圾回收器（JEP363）
? 移除了CMS垃圾收集器，如果在JDK14中使用一XX： +UseConcMarkSweepGC的話，JVM不會報錯，只是給出一個warning信息，但是不會exit。JVM會自動回退以默認GC方式啟動JVM

7、G1回收器:區域化分代式

既然我們已經有了前面幾個強大的GC，為什么還要發布Garbage First （G1）GC？
??原因就在于應用程序所應對的業務越來越龐大、復雜，用戶越來越多，沒有GC就不能保證應用程序正常進行，而經常造成STW的GC又跟不上實際的需求，所以才會不斷地嘗試對GC進行優化。G1 （Garbage一First） 垃圾回收器是在Java7 update4之后引入的一個新的垃圾回收器，是當今收集器技術發展的最前沿成果之一。
??與此同時，為了適應現在不斷擴大的內存和不斷增加的處理器數量，進一步降低暫停時間（pause time） ，同時兼顧良好的吞吐量。
??官方給G1設定的目標是在延遲可控的情況下獲得盡可能高的吞吐量，所以才擔當起“全功能收集器”的重任與期望

7.1 為什么名字叫做Garbage First （G1）呢

• 因為G1是一個并行回收器，它把堆內存分割為很多不相關的區域（Region） （物理上 不連續的）。使用不同的Region來表示Eden、幸存者0區，幸存者1區，老年代等。
• G1 GC有計劃地避免在整個Java 堆中進行全區域的垃圾收集。G1跟蹤各個Region 里面的垃圾堆積的價值大小（回收所獲得的空間大小以及回收所需時間的經驗值），在后臺維護一個優先列表，每次根據允許的收集時間，優先回收價值最大的Region。
• 由于這種方式的側重點在于回收垃圾最大量的區間（Region），所以我們給G1一個名字：垃圾優先（Garbage First） 。
• G1 （Garbage一First） 是一款面向服務端應用的垃圾收集器，主要針對配備多核CPU及大容量內存的機器，以極高概率滿足GC停頓時間的同時，還兼具高吞吐量的性能特征。
• 在JDK1. 7版本正式啟用，移除了Experimental的標識，是JDK 9以后的默認垃圾回收器，取代了CMS回收器以及Parallel + Parallel Old組合。被Oracle官方稱為“全功能的垃圾收集器” 。
  與此同時，CMS已經在JDK 9中被標記為廢棄（deprecated） 。在jdk8中還不是默認的垃圾回收器，需要使用一XX： +UseG1GC來啟用。

7.2 優勢

與其他GC收集器相比，G1使用了全新的分區算法，其特點如下所示：

• 并行與并發
  ? ?并行性： G1在回收期間，可以有多個Gc線程同時工作，有效利用多核計算能力。此時用戶線程STW
  ? ?并發性： G1擁有與應用程序交替執行的能力，部分工作可以和應用程序同時執行，因此，一般來說，不會在整個回收階段發生完全阻塞應用程序的情況
• 分代收集
  ? ?從分代上看，G1依然屬于分代型垃圾回收器，它會區分年輕代和老年代，年輕代依然有Eden區和Survivor區。但從堆的結構上看，它不要求整個Eden區、年輕代或者老年代都是連續的，也不再堅持固定大小和固定數量。
  ? ?將堆空間分為若干個區域（Region） ，這些區域中包含了邏輯上的年輕代和老年代。
  ? ?和之前的各類回收器不同，它同時兼顧年輕代和老年代。對比其他回收器，或者工作在年輕代，或者工作在老年代；
  
  
• 空間整合
  ? ?CMS： “標記一清除”算法、內存碎片、若干次Gc后進行一次碎片整理
  ? ?G1將內存劃分為一個個的region。 內存的回收是以region作為基本單位的.Region之間是復制算法，但整體上實際可看作是標記一壓縮（Mark一Compact）算法，兩種算法都可以避免內存碎片。這種特性有利于程序長時間運行，分配大對象時不會因為無法找到連續內存空間而提前觸發下一次GC。尤其是當Java堆非常大的時候，G1的優勢更加明顯。
• 可預測的停頓時間模型（即：軟實時soft real一time） 這是G1相對于CMS的另一大優勢，G1除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度為M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒。
  ? ?由于分區的原因，G1可以只選取部分區域進行內存回收，這樣縮小了回收的范圍，因此對于全局停頓情況的發生也能得到較好的控制。
  ? ?G1跟蹤各個Region里面的垃圾堆積的價值大小（回收所獲得的空間大小以 及回收所需時間的經驗值），在后臺維護一個優先列表，每次根據允許的收集時間，優先回收價值最大的Region。保證了G1 收集器在有限的時間內可以獲取盡可能高的收集效率。
  ? ?相比于CMSGC，G1未必能做到CMS在最好情況下的延時停頓，但是最差情況要好很多。

7.3 缺點

? 相較于CMS，G1還不具備全方位、壓倒性優勢。比如在用戶程序運行過程中，G1無論是為了垃圾收集產生的內存占用（Footprint） 還是程序運行時的額外執行負載（overload） 都要比CMS要高。
? 從經驗上來說，在小內存應用上CMS的表現大概率會優于G1，而G1在大內存應用，上則發揮其優勢。平衡點在6一8GB之間。

7.4 適用場景

• 面向服務端應用，針對具有大內存、多處理器的機器。（在普通大小的堆里表現并不驚喜）
• 最主要的應用是需要低GC延遲，并具有大堆的應用程序提供解決方案；
• 如：在堆大小約6GB或更大時，可預測的暫停時間可以低于0.5秒； （ G1通過每次只清理一部分而不是全部的Region的增量式清理來保證每次GC停頓時間不會過長）。
• 用來替換掉JDK1.5中的CMS收集器； 在下面的情況時，使用G1可能比CMS好：
  ①超過50%的Java堆被活動數據占用；
  ②對象分配頻率或年代提升頻率變化很大；
  ③GC停頓時間過長（長于0. 5至1秒）。
• HotSpot垃圾收集器里，除了G1以外，其他的垃圾收集器使用內置的JVM線程執行 GC的多線程操作，而G1 GC可以采用應用線程承擔后臺運行的GC工作，即當JVM的GC線程處理速度慢時，系統會調用應用程序線程幫助加速垃圾回收過程。

7.5 分區region,化整為零

使用G1收集器時，它將整個Java堆劃分成約2048個大小相同的獨立Region塊，每個Region塊大小根據堆空間的實際大小而定，整體被控制在1MB到32MB之間，且為2的N次冪，即1MB， 2MB， 4MB， 8MB， 1 6MB， 32MB。可以通過一 XX：G1HeapRegionSize設定。所有的Region大小相同，且在JVM生命周期內不會被改變。
??雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，它們都是一部分Region （不需要連續）的集合。通過Region的動態分配方式實現邏輯上的連續。
??

• 一個region 有可能屬于Eden， Survivor 或者Old/Tenured 內存區域。但是一個region只可能屬于一個角色。圖中的E表示該region屬于Eden內存區域，s表示屬于Survivor內存區域，O表示屬于Old內存區域。圖中空白的表示未使用的內存空間。
• G1垃圾收集器還增加了一種新的內存區域，叫做Humongous內存區域，如圖中的H塊。主要用于存儲大對象，如果超過1. 5個region，就放到H。
• 設置H的原因：
  • 對于堆中的大對象，默認直接會被分配到老年代，但是如果它是一個短期存在的大對象，就會對垃圾收集器造成負面影響。為了解決這個問題，G1劃分了一個Humongous區，它用來專門存放大對象。如果一個H區裝不下一個大對象，那么G1會尋找連續的H區來存儲。為了能找到連續的H區，有時候不得不啟動Full GC。G1的大多數行為都把H區作為老年代的一部分來看待。

7.6 垃圾回收過程

7.6.1 概述

G1 GC的垃圾回收過程主要包括如下三個環節：

• 年輕代GC （Young GC ）
• 老年代并發標記過程（ Concurrent Marking）
• 混合回收（Mixed GC ）

（如果需要，單線程、獨占式、高強度的Full GC還是繼續存在的。它針對GC的評估失敗提供了一種失敗保護機制，即強力回收。）

順時針， young gc 一> young gc + concurrent mark 一> Mixed GC順序，進行垃圾回收。

• 應用程序分配內存，當年輕代的Eden區用盡時開始年輕代回收過程；G1的年輕代收集階段是一個并行的獨占式收集器。在年輕代回收期，G1 GC暫停所有應用程序線程，啟動多線程執行年輕代回收。然后從年輕代區間移動存活對象到Survivor區間或者老年區間，也有可能是兩個區間都會涉及。
• 當堆內存使用達到一定值（默認45%）時，開始老年代并發標記過程。
• 標記完成馬上開始混合回收過程。對于一個混合回收期，G1 GC從老年區間移動存活對象到空閑區間，這些空閑區間也就成為了老年代的一部分。和年輕代不同，老年代的G1回收器和其他GC不同，G1的老年代回收器不需要整個老年代被回收，一次只需要掃描/回收一小部分老年代的Region就可以了。同時，這個老年代Region是和年輕代一起 被回收的。
• 舉個例子：一個web服務器，Java進程最大堆內存為4G，每分鐘響應1500個請求，每45秒鐘會新分配大約2G的內存。G1會每45秒鐘進行一次年輕代回收，每31 個小時整個堆的使用率會達到45%，會開始老年代并發標記過程，標記完成后開始四到五次的混合回收。

7.6.2 詳解

7.6.2.1 年輕代GC

• JVM啟動時，G1 先準備好Eden區，程序在運行過程中不斷創建對象到Eden區，當Eden空間耗盡時，G1會啟動一次年輕代垃圾回收過程。
• 年輕代垃圾回收只會回收Eden區和Survivor區。
• YGC時，首先G1停止應用程序的執行（Stop一The一World），G1創建回收集（Collection Set），回收集是指需要被回收的內存分段的集合，年輕代回收過程的回收集包含年輕代Eden區和Survivor區所有的內存分段。
• 然后開始如下回收過程：
  • 第一階段，掃描根。根是指static變量指向的對象，正在執行的方法調用鏈條上的局部變量等。根引用連同RSet記錄的外部引用作為掃描存活對象的入口。
  • 第二階段，更新RSet。處理dirty card queue（ 見備注）中的card，更新RSet。 此階段完成后，RSet可 以準確的反映老年代對所在的內存分段中對象的引用。
    • （dirty card queue: 對于應用程序的引用賦值語句object.field=object，JVM會在之前和之后執行特殊的操作以在dirty card queue中入隊一個保存了對象引用信息的card。在年輕代回收的時候， G1會對Dirty Card Queue中所有的card進行處理，以更新RSet，保證RSet實時準確的反映引用關系。 那為什么不在引用賦值語句處直接更新RSet呢？這是為了性能的需要，RSet的處理需要線程同步，開銷會很大，使用隊列性能會好很多。）
  • 第三階段，處理RSet。識別被老年代對象指向的Eden中的對象，這些被指向的Eden中的對象被認為是存活的對象。
  • 第四階段，復制對象。此階段，對象樹被遍歷，Eden區內存段中存活的對象會被復制到Survivor區中空的內存分段，Survivor區內存段中存活的對象如果年齡未達閾值，年齡會加1，達到閥值會被會被復制到01d區中空的內存分段。如果Survivor空間不夠，Eden空間的 部分數據會直接晉升到老年代空間。
  • 第五階段，處理引用。處理Soft，Weak， Phantom， Final， JNI Weak等引用。最終Eden空間的數據為空，GC停止工作，而目標內存中的對象都是連續存儲的，沒有碎片，所以復制過程可以達到內存整理的效果，減少碎片。

7.6.2.2 并發標記過程

• 初始標記階段：標記從根節點直接可達的對象。這個階段是STW的，并且會觸發一次年輕代GC。
• 根區域掃描（Root Region Scanning） ： G1 GC掃描Survivor區 直接可達的老年代區域對象，并標記被引用的對象。這一過程必 須在young GC之前完成。
• 并發標記（Concurrent Marking）： 在整個堆中進行并發標記（和應用程序并發執行），此過程可能被young GC中斷。在并發標記階段，若發現區域對象中的所有對象都是垃圾，那這個區域會被立即回收。同時，并發標記過程中，會計算每個區域的對象活性（區域中存活對象的比例）。
• 再次標記（Remark）： 由 于應用程序持續進行，需要修正上一次的標記結果。是STW的。G1中采用了比CMS更快的初始快照算法：snapshot一at一the一beginning （SATB）。
• 獨占清理（cleanup，STW）：計算各個區域的存活對象和GC回收比例，并進行排序，識別可以混合回收的區域。為下階段做鋪墊。是STW的。?這個階段并不會實際上去做垃圾的收集
• 并發清理階段：識別并清理完全空閑的區域。

7.6.2.3 混合回收

當越來越多的對象晉升到老年代oldregion時，為了避免堆內存被耗盡，虛擬機會觸發一個混合的垃圾收集器，即Mixed GC， 該算法并不是一個0ldGC，除了回收整個Young Region，還會回收一部分的0ldRegion。這里需要注意：是一部分老年代， 而不是全部老年代。可以選擇哪些0ldRegion進行收集，從而可以對垃圾回收的耗時時間進行控制。也要注意的是Mixed GC并不是Full GC。

• 并發標記結束以后，老年代中百分百為垃圾的內存分段被回收了，部分為垃圾的內存分段被計算了出來。默認情況下，這些老年代的內存分段會分8次（可以通過一XX： G1MixedGCCountTarget設置）被回收。
• 混合回收的回收集（Collection Set） 包括八分之一的老年代內存分段，Eden區內存分段，Survivor區內存分段。混合回收的算法和年輕代回收的算法完全一樣，只是回收集多了老年代的內存分段。具體過程請參考上面的年輕代回收過程。
• 由于老年代中的內存分段默認分8次回收，G1會優先回收垃圾多的內存分段。垃圾占內存分段比例越高的，越會被先回收。并且有一個閾值會決定內存分段是否被回收，一xX： G1MixedGCLiveThresholdPercent，默認為65%，意思是垃圾占內存分段比例要達到65%才會被回收。如果垃圾占比太低，意味著存活的對象占比高，在復制的時候會花費更多的時間。
• 混合回收并不一定要進行8次。有一個閾值一Xx： G1HeapWastePercent，默認值為10%，意思是允許整個堆內存中有10%的空間被浪費，意味著如果發現可以回收的垃圾占堆內存的比例低于10%，則不再進行混合回收。因為GC會花費很多的時間但是回收到的內存卻很少。

7.6.2.4 Full GC

G1的初衷就是要避免Full GC的出現。但是如果上述方式不能正常工作，G1會停止應用程序的執行（Stop一 The一World），使用單線程的內存回收算法進行垃圾回收，性能會非常差，應用程序停頓時間會很長。

要避免Full GC的發生，一旦發生需要進行調整。什么時候會發生Full GC呢？比如堆內存太小，當G1在復制存活對象的時候沒有空的內存分段可用，則會回退到full gc， 這種情況可以通過增大內存解決。
導致G1Full GC的原因可能有兩個：
? 1.Evacuation的時候沒有足夠的to一 space來存放晉升的對象；
? 2.并發處理過程完成之前空間耗盡。

7.7 補充

從Oracle官方透露出來的信息可獲知，回收階段（Evacuation）其實本也有想過設計成與用戶程序一起并發執行，但這件事情做起來比較復雜，考慮到G1只是回收一部分Region， 停頓時間是用戶可控制的，所以并不迫切去實現，而選擇把這個特性放到了G1之后出現的低延遲垃圾收集器（即ZGC）中。另外，還考慮到G1不是僅僅面向低延遲，停頓用戶線程能夠最大幅度提高垃圾收集效率，為了保證吞吐量所以才選擇了完全暫停用戶線程的實現方案。

7.8 記憶集與寫屏障

一個對象被不同區域引用的問題(分代引用問題)

一個Region不可能是孤立的，一個Region中的對象可能被其他任意Region中對象引用，判斷對象存活時，是否需要掃描整個Java堆才能保證準確？

在其他的分代收集器，也存在這樣的問題（ 而G1更突出）。回收新生代也不得不同時掃描老年代？這樣的話會降低MinorGC的效率。

解決方法：

• ?無論G1還是其他分代收集器，JVM都是使用RememberedSet來避免全局掃描：
• ?每個Region都有 一個對應的Remembered Set；
• ?每次Reference類 型數據寫操作時，都會產生一個Write Barrier暫 時中斷操作；
• ?然后檢查將要寫入的引用指向的對象是否和該Reference類型數據在不同的Region （其他收集器：檢查老年代對象是否引用了新生代對象） ；
• ?如果不同，通過CardTable把相關引用信息記錄到引用指向對象的所在Region對應的Remembered Set中；
• ?當進行垃圾收集時，在GC根節點的枚舉范圍加入Remembered Set；就可以保證不進行全局掃描，也不會有遺漏。

總結

以上是生活随笔為你收集整理的垃圾回收③---垃圾回收器的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。