九款常見的JVM 垃圾回收器

JVM 不僅是大廠面試的一個高頻問題，也是Java程式設計師跨入高階必須掌握的知識點，垃圾回收器作為JVM中核心的一環，了解它的原理，可以幫助我們更好地調優和故障排除，因此，今天我們就來聊聊JVM中9款常見的垃圾回收器。

背景 

因為Java虛擬機的類型比較多，如果沒有特別說明，本文特別指HotSpot虛擬機，在分享回收器之前，我們先對HotSpot 虛擬機背景做個簡單的介紹。

HotSpot VM，最初是由「Longview Technologies」 這家小公司設計，一開始也不是為Java語言研發。

1997年，Sun公司收購了這家公司，因此也得到了HotSpot虛擬機，在Sun公司的一番優化下，HotSpot 虛擬機就成了Sun/OracleJDK 和OpenJDK共同的預設虛擬機。

2010年，Oracle 收購Sun公司，HotSpot 虛擬機器也就順理成章成為了Oracle旗下產品。

Sun/OracleJDK 和OpenJDK 都是Oracle 旗下產品，Sun/OracleJDK 是商用版，OpenJDK 是免費版，兩款虛擬機器的核心是一樣，只是功能略有差異。

關於使用的是 Sun/OracleJDK 還是 OpenJDK ，可以透過 java -version 指令查看。

Sun/OracleJDK：

OpenJDK：

1.串行 

Serial 收集器，見名知意，它是一個單線程的收集器，而且在進行垃圾回收時還必須暫停其它的工作線程，直到它收集結束（Stop The World）。

在JDK 1.3.1 之前，它是HotSpot虛擬機年輕代收集器的唯一選擇。

Serial(年輕代) 和Serial Old(老年代) 組合模式下，收集器大致的工作流程如下圖：

儘管Serial 收集器是單線程回收，並且會暫停其它的工作線程，看起來性能很差，但是，它仍然是HotSpot 虛擬機運行在客戶端模式下的默認新生代收集器，因為相對於其它收集器的單線程，Serial 收集器消耗的記憶體最低，加上沒有多線程互動的開銷，反而使得它簡單有效率。

在啟動Java程序時，可以透過設定 -XX:+UseSerialGC -XX:+UseSerialOldGC 參數，使用上述回收器組合。

2.標準桿新

ParNew 收集器是Serial 收集器的多執行緒並行版本，除了使用多執行緒進行垃圾回收之外，其它的行為和Serial 收集器都是相同的。主要應用在HotSpot虛擬機器運行在服務端模式下的場景。

ParNew(年輕代) 和Serial Old(老年代) 組合模式下，收集器大致的工作流程如下圖：

在啟動 Java進程時，可以透過設定 -XX:+UseParNewGC -XX:+UseSerialOldGC 參數，使用上述回收器組合。

3.並行清除 

Parallel Scavenge 收集器也是一款用於年輕代的回收器，它和ParNew 收集器一樣，採用多執行緒並發回收，但是，Parallel Scavenge可以透過-XX:MaxGCPauseMillis 參數設定GC的最大停頓時間，這樣就可以達到一個吞吐量（Throughput）可控的目標，從而優於ParNew回收器。

Parallel Scavenge(年輕代) 和Serial Old(老年代) 組合模式下，收集器大致的工作流程如下圖：

在啟動 Java進程時，可以透過設定 -XX:+UseParallelGC -XX:+UseSerailOldGC 參數，使用上述回收器組合。

但是，這種組合看起來很尷尬，年輕代使用的多線程並發收集，而老年代卻使用單線程進行回收，怎麼看起來老年代的回收都是“拖累”，因此，用於老年代的Parallel Old 並發收集器就誕生了。

Parallel Scavenge(年輕代) 與Parallel Old(老年代) 組合模式下，收集器大致的工作流程如下圖：

啟動 Java進程時，可以透過設定 -XX:+UseParallelGC -XX:+UseParallelOldGC 參數，使用上述回收器組合。

4.舊系列 

Serial Old 收集器是Serial 的老年代版本，它也是一個單線程收集器，使用'標記-整理'演算法，和Serial 收集器一樣也是用於HotSpot客戶端模式。

Serial(年輕代) 和Serial Old(老年代) 組合模式下，收集器大致的工作流程如下圖：

在啟動Java程序時，可以透過設定 -XX:+UseSerialGC -XX:+UseSerialOldGC 參數，使用上述回收器組合。

5.平行老

Parallel Old 收集器是從JDK 6 開始提供支援的，它是Parallel Scavenge 收集器的老年代版本，支援多執行緒並發收集，採用'標記-整理'演算法。 Parallel Old 收集器的出現，真正意義上實現了「吞吐量優先」的目標。

Parallel Scavenge(年輕代) 與Parallel Old(老年代) 組合模式下，收集器大致的工作流程如下圖：

啟動 Java進程時，可以透過設定 -XX:+UseParallelGC -XX:+UseParallelOldGC 參數，使用上述回收器組合。

6.內容管理系統

CMS 收集器，從JDK5發布之後正式誕生，可以毫不誇張地說：CMS是一個跨時代的收集器，曾幾何時，它是各互聯網大廠面試中垃圾回收器的必問知識點。

CMS 是Comcurrent Mark Sweep 的簡稱，用於老年代的垃圾回收。 CMS的收集過程包含5個步驟：

• Initial Mark(初始標記) Stop The World
• Concurrent Marking(並發標記)
• Remark(重複標記) Stop The World
• Concurrent Sweep(並發清除)
• Resetting(重置)

CMS 收集器大致的工作流程如下圖：

儘管CMS回收器實現了回收線程與應用線程能同時並發工作的目標，但它也有致命的問題：無法處理“浮動垃圾”，有可能出現Concurrent Mode Failure 失敗，導致Full GC。因此，Oracle官方目前已經將CMS 申明為“deprecated”，不建議使用。這也宣告了CMS收集器的歷史使命已結束。 

啟動 Java進程時，可以透過設定-XX:+UseConcMarkSweepGC 參數，顯示使用CMS回收器。

7.G1 

G1 回收器是Garbage First 的簡稱， 它是一款面向伺服器的垃圾回收器，用於大內存的多處理器計算機，目標是實現低延時垃圾回收。

從Oracle JDK 7 Update 4 及更高版本已完全支援G1，並且 JDK9 開始，G1 已經成為了預設的垃圾收集器。

應該說，G1是垃圾回收器歷史上的一個里程碑，開啟了基於Region回收的時代，和以往的垃圾回收器不一樣，G1儘管依然保留了年輕代和老年代的概念，但是各代存儲地址是不連續的，每一代包含了n個大小相同且不連續的Region，G1 的堆內存分配如下圖：

G1提供了兩種GC模式：Young GC和Mixed GC。

G1的收集過程包含4個步驟：

(1) Initial Marking（初始標記）：標記了從GC Root開始直接可達的對象

(2) Concurrent Marking（並發標記）：在整個堆上尋找活動對象，標記全部可達對象。這個階段可能會被年輕代垃圾回收中斷。

(3) Remark（重新標記）：完成對堆中活動物件的標記。使用一種稱為「快照在開始時」（Snapshot-at-the-Beginning，SATB）的演算法，其速度比CMS收集器中使用的演算法要快得多。

(4) Cleanup（清除垃圾）：流程完成3件事情

• 對活動對象和完全釋放的區域進行記帳。 （Stop The World） 
• 清理已記住的集合。 （Stop The World） 
• 重置空的區域並將其返回到空閒清單。 （並發執行）

G1 收集器大致的工作流程如下圖：

啟動 Java進程時，可以透過設定 -XX:+UseG1GC 參數，顯示使用G1回收器。

8.謝南多厄

Shenandoah 也是一款HotSpot 虛擬機回收器，首次出現在Open JDK12中，最初是由RedHat公司開發，2014年貢獻給OpenJDK，或許因為它不是Oracle公司自己開發的，所以，Shenandoah 目前只存在OpenJDK 而不存在OracleJDK商業版中。 Shenandoah主要使用連接矩陣和轉送指標的技術，連接矩陣取代 G1中的卡片表。

Shenandoah工作流程分為9個步驟：

• Initial Marking(初始標記)：和G1 一樣，標記了從GC Root開始直接可達的對象，Stop The World
• Concurrent Marking(並發標記)：和G1 一樣，在整個堆上尋找活動對象，標記全部可達對象。
• Final Marking(最終標記)：和G1 一樣，
• Concurrent Cleanup(並發清理)：清理無存活物件的Region
• Concurrent Evacuation(並發回收)：把存活的物件複製到空的Region中，
• Inital Update Reference(初始引用更新)：修正並發回收階段被複製物件的參考位址
• Concurrent Update Reference(並發引用更新)：引用更新操作
• Final Update Reference(最終引用更新)：修正存在於GCRoots中的引用
• Concurrent Cleanup(並發清理)：回收空的Region

2. Concurrent Marking(并发标记)：和G1 一样，在整个堆上查找活动对象，标记全部可达对象。
1.

Shenandoah 收集器大致的工作流程如下圖（圖片來自OpenJDK官方）：

啟動 Java進程時，可以透過設定XX:+UseShenandoahGC參數，顯示使用Shenandoah回收器。

注意，如果使用的是Sun/OracleJDK，將無法使用此回收器。

9.中關村 

ZGC 是Oracle官方研發並從JDK11引入，它是一款採用染色指針和讀取屏障技術的回收器，ZGC 和G1一樣，堆空間被劃分成多個Region，不同的是，ZGC的Region 被官方稱為Page，它可以動態建立和銷毀，容量也可以動態調整。

ZGC的Region分為三種：

• 小型Region：容量固定為2MB，用於存放< 256KB的物件；
• 中型Region：容量固定為32MB，用於存放>= 256KB且< 4MB的物件;
• 大型Region：容量為2^n MB，存放>= 4MB 的對象，而且每個大型Region 中只存放一個大對象。由於大物件移動代價過大，所以該物件不會被重新分配。

ZGC 工作流程分為4個步驟：

• Concurrent Mark（並發標記）：和G1 一樣，標記了從GC Root開始直接可達的對象
• Concurrent Prepare for Relocate（並發預備重分配）
• Concurrent for Relocate（並發重新分配）
• Concurrent Remap（並發重映射）

ZGC 收集器大致的工作流程如下圖：

ZGC垃圾回收過程幾乎全部是並發，實際Stop The World（STW）停頓時間極短，不到10ms。這得歸功於其採用的著色指針和讀取屏障技術。

啟動 Java進程時，可以透過設定XX:+UseZGC參數，顯示使用ZGC回收器。

到此，9款垃圾收集器就介紹完畢，如果你對垃圾回收器很感興趣，推薦閱讀周志明博士的《深入理解Java虛擬機》第三版，書中除了垃圾回收器， JVM其它相關的內容也都有詳細介紹，應該是國內很多Java程式設計師學習JVM的必備書籍。

因為篇幅有限，本文只是簡單地分析了HotSpot虛擬機常見的9款垃圾回收器，並沒有做原理上的分析，我會在接下來的文章中分別對CMS，G1，ZGC，Shenandoah 4款垃圾收集器做詳細的講解，連結：JVM專欄。最後用一張圖表對9款回收器做一個比較：