JVM 不僅是大廠面試的一個(gè)高頻問(wèn)題，也是 Java程序員跨入高職級(jí)必須掌握的知識(shí)點(diǎn)，垃圾回收器作為 JVM中核心的一環(huán)，了解它的原理，可以幫助我們更好地調(diào)優(yōu)和故障排除，因此，今天我們就來(lái)聊聊 JVM中 9款常見的垃圾回收器。

背景 

因?yàn)?Java虛擬機(jī)的類型比較多，如果沒有特殊說(shuō)明，本文特指 HotSpot虛擬機(jī)，在分享回收器之前，我們首先對(duì) HotSpot 虛擬機(jī)背景做個(gè)簡(jiǎn)單的介紹。

HotSpot VM，最初是由 “Longview Technologies” 這家小公司設(shè)計(jì)，并且一開始也不是為 Java語(yǔ)言研發(fā)。

1997年，Sun公司收購(gòu)了這家公司，從而也就得到了 HotSpot虛擬機(jī)，在 Sun公司的一番優(yōu)化下，HotSpot 虛擬機(jī)就成了 Sun/OracleJDK 和 OpenJDK共同的默認(rèn)虛擬機(jī)。

2010年，Oracle 收購(gòu) Sun公司，HotSpot 虛擬機(jī)也就順理成章成為了 Oracle旗下產(chǎn)品。

Sun/OracleJDK 和 OpenJDK 都是 Oracle 旗下產(chǎn)品，Sun/OracleJDK 是商用版，OpenJDK 是免費(fèi)版，兩款虛擬機(jī)的內(nèi)核是一樣，只是功能略有差異。

關(guān)于使用的是 Sun/OracleJDK 還是 OpenJDK ，可以通過(guò) java -version 指令查看。

Sun/OracleJDK：

OpenJDK：

1.Serial 

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

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

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

盡管 Serial 收集器是單線程回收，并且會(huì)暫停其它的工作線程，看起來(lái)性能很差，但是，它依然是 HotSpot 虛擬機(jī)運(yùn)行在客戶端模式下的默認(rèn)新生代收集器，因?yàn)橄鄬?duì)于其它收集器的單線程，Serial 收集器消耗的內(nèi)存最低，加上沒有多線程交互的開銷，反而使得它簡(jiǎn)單高效。

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置 -XX:+UseSerialGC  -XX:+UseSerialOldGC 參數(shù)，使用上述回收器組合。

2.ParNew

ParNew 收集器是 Serial 收集器的多線程并行版本，除了使用多線程進(jìn)行垃圾回收之外，其它的行為和 Serial 收集器都是相同的。主要應(yīng)用在 HotSpot虛擬機(jī)運(yùn)行在服務(wù)端模式下的場(chǎng)景。

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

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置 -XX:+UseParNewGC  -XX:+UseSerialOldGC 參數(shù)，使用上述回收器組合。

3.Parallel Scavenge 

Parallel Scavenge 收集器也是一款用于年輕代的回收器，它和 ParNew 收集器一樣，采用多線程并發(fā)回收，但是，Parallel Scavenge可以通過(guò) -XX:MaxGCPauseMillis 參數(shù)設(shè)置 GC的最大停頓時(shí)間，這樣就可以達(dá)到一個(gè)吞吐量（Throughput）可控的目標(biāo)，從而優(yōu)于 ParNew回收器。

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

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置 -XX:+UseParallelGC  -XX:+UseSerailOldGC 參數(shù)，使用上述回收器組合。

但是，這種組合看起來(lái)很尷尬，年輕代使用的多線程并發(fā)收集，而老年代卻使用單線程進(jìn)行回收，怎么看起來(lái)老年代的回收都是“拖累”，因此，用于老年代的Parallel Old 并發(fā)收集器就誕生了。

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

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置 -XX:+UseParallelGC  -XX:+UseParallelOldGC 參數(shù)，使用上述回收器組合。

4.Serial Old 

Serial Old 收集器是 Serial 的老年代版本，它也是一個(gè)單線程收集器，使用‘標(biāo)記-整理’算法，和 Serial 收集器一樣也是用于 HotSpot客戶端模式。

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

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置 -XX:+UseSerialGC  -XX:+UseSerialOldGC 參數(shù)，使用上述回收器組合。

5.Parallel Old

Parallel Old 收集器是從 JDK 6 開始提供支持的，它是 Parallel Scavenge 收集器的老年代版本，支持多線程并發(fā)收集，采用‘標(biāo)記-整理’算法。Parallel Old 收集器的出現(xiàn)，真正意義上實(shí)現(xiàn)了“吞吐量?jī)?yōu)先”的目標(biāo)。

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

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置 -XX:+UseParallelGC  -XX:+UseParallelOldGC 參數(shù)，使用上述回收器組合。

6.CMS

CMS 收集器，從 JDK5發(fā)布之后正式誕生，可以毫不夸張地說(shuō)：CMS是一個(gè)跨時(shí)代的收集器，曾幾何時(shí)，它是各互聯(lián)網(wǎng)大廠面試中垃圾回收器的必問(wèn)知識(shí)點(diǎn)。

CMS 是 Comcurrent Mark Sweep 的簡(jiǎn)稱，用于老年代的垃圾回收。CMS的收集過(guò)程包含 5個(gè)步驟：

• Initial Mark(初始標(biāo)記) Stop The World
• Concurrent Marking(并發(fā)標(biāo)記)
• Remark(重復(fù)標(biāo)記) Stop The World
• Concurrent Sweep(并發(fā)清除)
• Resetting(重置)

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

盡管 CMS回收器實(shí)現(xiàn)了回收線程與應(yīng)用線程能同時(shí)并發(fā)工作的目標(biāo)，但它也有致命的問(wèn)題：無(wú)法處理“浮動(dòng)垃圾”，有可能出現(xiàn) Concurrent Mode Failure 失敗，導(dǎo)致Full GC。因此，Oracle官方目前已經(jīng)將 CMS 申明為 “deprecated”，不推薦使用。這也宣告了 CMS收集器的歷史使命已結(jié)束。 

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置-XX:+UseConcMarkSweepGC 參數(shù)，顯示使用 CMS回收器。

7.G1 

G1 回收器是 Garbage First 的簡(jiǎn)稱， 它是一款面向服務(wù)器的垃圾回收器，用于大內(nèi)存的多處理器計(jì)算機(jī)，目標(biāo)是實(shí)現(xiàn)低延時(shí)垃圾回收。

從 Oracle JDK 7 Update 4 及更高版本已完全支持 G1，并且  JDK9 開始，G1 已經(jīng)成為了默認(rèn)的垃圾收集器。

應(yīng)該說(shuō)，G1是垃圾回收器歷史上的一個(gè)里程碑，開啟了基于 Region回收的時(shí)代，和以往的垃圾回收器不一樣，G1盡管依然保留了年輕代和老年代的概念，但是各代存儲(chǔ)地址是不連續(xù)的，每一代包含了 n個(gè)大小相同且不連續(xù)的 Region，G1 的堆內(nèi)存分配如下圖：

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

G1的收集過(guò)程包含 4個(gè)步驟：

(1) Initial Marking（初始標(biāo)記）：標(biāo)記了從 GC Root開始直接可達(dá)的對(duì)象

(2) Concurrent Marking（并發(fā)標(biāo)記）：在整個(gè)堆上查找活動(dòng)對(duì)象，標(biāo)記全部可達(dá)對(duì)象。這個(gè)階段可能會(huì)被年輕代垃圾回收中斷。

(3) Remark（重新標(biāo)記）：完成對(duì)堆中活動(dòng)對(duì)象的標(biāo)記。使用一種稱為“快照在開始時(shí)”（Snapshot-at-the-Beginning，SATB）的算法，其速度比 CMS收集器中使用的算法要快得多。

(4) Cleanup（清除垃圾）：該過(guò)程完成 3個(gè)事情

• 對(duì)活動(dòng)對(duì)象和完全釋放的區(qū)域進(jìn)行記賬。（Stop The World） 
• 清理已記住的集合。（Stop The World） 
• 重置空的區(qū)域并將其返回到空閑列表。（并發(fā)執(zhí)行）

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

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置 -XX:+UseG1GC 參數(shù)，顯示使用 G1回收器。

8.Shenandoah

Shenandoah 也是一款 HotSpot 虛擬機(jī)回收器，首次出現(xiàn)在Open JDK12中，最初是由 RedHat公司開發(fā)，2014年貢獻(xiàn)給 OpenJDK，或許因?yàn)樗皇?Oracle公司自己開發(fā)的，所以，Shenandoah 目前只存在 OpenJDK 而不存在 OracleJDK商業(yè)版中。Shenandoah主要使用連接矩陣和轉(zhuǎn)發(fā)指針的技術(shù)，連接矩陣替代 G1中的卡表。

Shenandoah工作流程分為 9個(gè)步驟：

• Initial Marking(初始標(biāo)記)：和G1 一樣，標(biāo)記了從 GC Root開始直接可達(dá)的對(duì)象，Stop The World
• Concurrent Marking(并發(fā)標(biāo)記)：和G1 一樣，在整個(gè)堆上查找活動(dòng)對(duì)象，標(biāo)記全部可達(dá)對(duì)象。
• Final Marking(最終標(biāo)記)：和G1 一樣，
• Concurrent Cleanup(并發(fā)清理)：清理無(wú)存活對(duì)象的 Region
• Concurrent Evacuation(并發(fā)回收)：把存活的對(duì)象復(fù)制到空的 Region中，
• Inital Update Reference(初始引用更新)：修正并發(fā)回收階段被復(fù)制對(duì)象的引用地址
• Concurrent Update Reference(并發(fā)引用更新)：引用更新操作
• Final Update Reference(最終引用更新)：修正存在于 GCRoots中的引用
• Concurrent Cleanup(并發(fā)清理)：回收空的 Region

2. Concurrent Marking(并發(fā)標(biāo)記)：和G1 一樣，在整個(gè)堆上查找活動(dòng)對(duì)象，標(biāo)記全部可達(dá)對(duì)象。

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

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置XX:+UseShenandoahGC參數(shù)，顯示使用 Shenandoah回收器。

注意，如果使用的是Sun/OracleJDK，將無(wú)法使用該回收器。

9.ZGC 

ZGC 是 Oracle官方研發(fā)并從 JDK11中引入，它是一款采用染色指針和讀屏障技術(shù)的回收器，ZGC 和 G1一樣，堆空間被劃分成多個(gè) Region，不同的是，ZGC的 Region 被官方稱為Page，它可以動(dòng)態(tài)創(chuàng)建和銷毀，容量也可以動(dòng)態(tài)調(diào)整。

ZGC的 Region分為三種：

• 小型 Region：容量固定為 2MB，用于存放 < 256KB的對(duì)象；
• 中型 Region：容量固定為 32MB，用于存放 >= 256KB且 < 4MB的對(duì)象;
• 大型 Region：容量為 2^n MB，存放 >= 4MB 的對(duì)象，而且每個(gè)大型Region 中只存放一個(gè)大對(duì)象。由于大對(duì)象移動(dòng)代價(jià)過(guò)大，所以該對(duì)象不會(huì)被重分配。

ZGC 工作流程分為 4個(gè)步驟：

• Concurrent Mark（并發(fā)標(biāo)記）：和G1 一樣，標(biāo)記了從 GC Root開始直接可達(dá)的對(duì)象
• Concurrent Prepare for Relocate（并發(fā)預(yù)備重分配）
• Concurrent for Relocate（并發(fā)重分配）
• Concurrent Remap（并發(fā)重映射）

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

ZGC垃圾回收過(guò)程幾乎全部是并發(fā)，實(shí)際 Stop The World（STW）停頓時(shí)間極短，不到10ms。這得益于其采用的著色指針和讀屏障技術(shù)。

在啟動(dòng) Java進(jìn)程時(shí)，可以通過(guò)設(shè)置XX:+UseZGC參數(shù)，顯示使用 ZGC回收器。

到此，9款垃圾收集器就介紹完畢，如果你對(duì)垃圾回收器很感興趣，推薦閱讀周志明博士的《深入理解Java虛擬機(jī)》第三版，書中除了垃圾回收器， JVM其它相關(guān)的內(nèi)容也都有詳細(xì)地介紹，應(yīng)該是國(guó)內(nèi)很多 Java程序員學(xué)習(xí) JVM的必備書籍。

因?yàn)槠邢蓿疚闹皇呛?jiǎn)單地分析了 HotSpot虛擬機(jī)常見的 9款垃圾回收器，并沒有做原理上的分析，我會(huì)在接下來(lái)的文章中分別對(duì) CMS，G1，ZGC，Shenandoah 4款垃圾收集器做詳細(xì)的講解，鏈接：JVM專欄 。最后用一張圖表對(duì) 9款回收器做一個(gè)對(duì)比：