[[286251]]

面試官：你認(rèn)識(shí)到的收集器都有哪些啊?

答：Serial、ParNew、Parallel Scavenge、Serial Old、Parallel Old、CMS、G1;

面試官：為什么HotSpot虛擬機(jī)需要這么多收集器?

答：HotsSpot垃圾是分代收集的，所以不用的分代收集器也不同，即使是同一年代里收集器也會(huì)不同，因?yàn)槊總€(gè)收集器特點(diǎn)和性能不同也就有了收集器的多樣性，所以各個(gè)收集器互相組合使用才能適應(yīng)不同場(chǎng)景。

面試官：那你說(shuō)一下每個(gè)收集器都有什么特點(diǎn)吧!

新生代收集器：Serial、ParNew、Parallel Scavenge;

老年代收集器：Serial Old、Parallel Old、CMS;

整堆收集器：G1;

開(kāi)始之前我們了解一個(gè)概念

Minor GC

又稱(chēng)新生代GC，指發(fā)生在新生代的垃圾收集動(dòng)作;

因?yàn)镴ava對(duì)象大多是朝生夕滅，所以Minor GC非常頻繁，一般回收速度也比較快;

Full GC

又稱(chēng)Major GC或老年代GC，指發(fā)生在老年代的GC;

出現(xiàn)Full GC經(jīng)常會(huì)伴隨至少一次的Minor GC(不是絕對(duì)，Parallel Sacvenge收集器就可以選擇設(shè)置Major GC策略);

Major GC速度一般比Minor GC慢10倍以上;

Serial收集器

這個(gè)收集器是最基本的，也是歷史最悠久的收集器，目前基本不會(huì)用了，想當(dāng)年那也是新生代的唯一選擇，但是這么多年過(guò)去了，HotSpot也沒(méi)有說(shuō)過(guò)河拆橋把它廢了，“老而無(wú)用、食之無(wú)味棄之可惜”。

他是一個(gè)單線程收集器，他在工作的時(shí)候，必須暫停其他所有的工作線程，直到收集結(jié)束。這里要知道一個(gè)很?chē)?yán)重的問(wèn)題就是，暫停一切線程的結(jié)果就是當(dāng)前運(yùn)行在這個(gè)JDK的所有程序里的用戶(hù)線程全部暫停，也就是說(shuō)這一瞬間都是死掉的，用戶(hù)看到的現(xiàn)象就是頁(yè)面無(wú)任何響應(yīng)，如果這種現(xiàn)象出現(xiàn)的時(shí)間長(zhǎng)且頻繁用戶(hù)就崩潰了。

這里埋下了一個(gè)伏筆，越優(yōu)秀的收集器，他的停頓時(shí)間一定越短，這也是所有收集器共同追求的目標(biāo)。

ParNew收集器

他是Serial收集器多線程版本，其所有控制參數(shù)、收集算法、對(duì)象分配規(guī)則、回收策略等都與Serial完全一樣。下面是ParNew收集器工作的過(guò)程。

他的重要之處在于，除了多線程提高了性能之外，他還可以與CMS收集器(下面介紹)搭配使用的原因。

在單CPU環(huán)境下ParNew的性能沒(méi)辦法超過(guò)Serial，但是隨著CPU數(shù)量增多他的優(yōu)勢(shì)就會(huì)越來(lái)越明顯。

Parallel Scavenge收集器

他也是一款新生代收集器，使用的是復(fù)制算法，并且是并行對(duì)線程收集器?？梢钥吹绞占鞯倪M(jìn)步都是保留上一代之長(zhǎng)，彌補(bǔ)上一代之短。

很多收集器關(guān)注用戶(hù)線程的停頓時(shí)間，但是Parallel Scavenge則關(guān)注吞吐量。所謂吞吐量就是CPU用于運(yùn)行用戶(hù)代碼的時(shí)間與CPU總消耗時(shí)間的比值，即吞吐量=運(yùn)行用戶(hù)代碼時(shí)間/(運(yùn)行用戶(hù)代碼時(shí)間+垃圾收集時(shí)間)，例：虛擬機(jī)運(yùn)行100分鐘，其中垃圾收集時(shí)間用了1分鐘，那吞吐量就是99%。

他是怎樣控制吞吐量呢?

使用參數(shù)控制最大垃圾收集停頓時(shí)間 -XX：MaxGCPauseMillis ，以及直接設(shè)置吞吐量大小 -XX：GCTimeRatio參數(shù)。

MaxGCPauseMillis參數(shù)是一個(gè)大于0的毫秒數(shù)，收集器一次工作盡可能不超過(guò)設(shè)定的這個(gè)值，但是設(shè)置太小GC停頓時(shí)間縮短，造成了垃圾收集頻率變快。如果你設(shè)定停頓100毫秒，10秒收集一次的頻率，改成70毫秒的停頓時(shí)間，那么頻率就可能變成5秒一次。停頓時(shí)間下降，吞吐量也會(huì)下降，GC還會(huì)變得更頻繁。

XX:GCTimeRatio參數(shù)設(shè)置垃圾收集時(shí)間占總時(shí)間的比率，0

GCTimeRatio相當(dāng)于設(shè)置吞吐量大小;

垃圾收集執(zhí)行時(shí)間占應(yīng)用程序執(zhí)行時(shí)間的比例的計(jì)算方法是：1 / (1 + n)

例如，選項(xiàng)-XX:GCTimeRatio=19，設(shè)置了垃圾收集時(shí)間占總時(shí)間的5%--1/(1+19);

默認(rèn)值是1%--1/(1+99)，即n=99;

看來(lái)找準(zhǔn)最優(yōu)的臨界點(diǎn)真的是Parallel Scavenge收集器比較配置的。

不要擔(dān)心，HotSpot又提供了一個(gè)參數(shù) XX:+UseAdptiveSizePolicy幫助我們實(shí)現(xiàn)GC自適應(yīng)的調(diào)節(jié)策略，他會(huì)根據(jù)當(dāng)前系統(tǒng)運(yùn)行情況收集性能監(jiān)控信息，動(dòng)態(tài)調(diào)整這些參數(shù)，以提供最合適的停頓時(shí)間或最大的吞吐量。

這個(gè)參數(shù)開(kāi)啟，JVM就可以動(dòng)態(tài)分配新生代的大小(-Xmn)、Eden與Survivor區(qū)的比例(-XX:SurvivorRation)、晉升老年代的對(duì)象年齡(-XX:PretenureSizeThreshold)等;

這里插入一個(gè)筆者的經(jīng)歷：當(dāng)時(shí)面試有人問(wèn)我，Eden與Survivor區(qū)的比例可以變化嗎?

看到這里童鞋們就可以回答：Parallel Scavenge收集器開(kāi)啟 XX:+UseAdptiveSizePolicy可以動(dòng)態(tài)分配。

這也是Parallel Scavenge收集器優(yōu)越于ParNew收集器一個(gè)重要點(diǎn)。

Serial Old收集器

Serial Old是 Serial收集器的老年代版本，也是繼承Serial收集器單線程的特點(diǎn)。

工作模型圖在Serial收集器中展示了。

Parallel Old收集器

Parallel Old垃圾收集器是Parallel Scavenge收集器的老年代版本，繼承了Parallel New多線程對(duì)特點(diǎn)，在JDK1.6及之后用來(lái)代替老年代的Serial Old收集器;

參數(shù)"-XX:+UseParallelOldGC"：指定使用Parallel Old收集器;

工作模型圖在Parallel New收集器中展示了。

接下來(lái)講解CMS于G1收集器，在將之前要理解一個(gè)概念

可能前面也提到過(guò)，不過(guò)在這里了解以下也不晚

并行(Parallel)

指多條垃圾收集線程并行工作，但此時(shí)用戶(hù)線程仍然處于等待狀態(tài);

如ParNew、Parallel Scavenge、Parallel Old;

并發(fā)(Concurrent)

指用戶(hù)線程與垃圾收集線程同時(shí)執(zhí)行(但不一定是并行的，可能會(huì)交替執(zhí)行);

用戶(hù)程序在繼續(xù)運(yùn)行，而垃圾收集程序線程運(yùn)行于另一個(gè)CPU上;

如CMS、G1(也有并行);

CMS收集器

并發(fā)標(biāo)記清理收集器也稱(chēng)為并發(fā)低停頓收集器或低延遲垃圾收集器;他的宗旨是：低停頓。

HotSpot在JDK1.5推出的第一款真正意義上的并發(fā)(Concurrent)收集器;

他采用的是“標(biāo)記-清除算法"，因此會(huì)生大量的空間碎片。為了解決這個(gè)問(wèn)題，CMS可以通過(guò)配置以下兩種參數(shù)解決：

• -XX:+UseCMSCompactAtFullCollection：參數(shù)，強(qiáng)制JVM在FGC完成后対老年代迸行圧縮，執(zhí)行一次空間碎片整理，但是空間碎片整理階段也會(huì)引發(fā)STW。為了減少STW次數(shù)，CMS還可以通過(guò)配置。
• -XX:+CMSFullGCsBeforeCompaction=n ：參數(shù)，在執(zhí)行了n次FGC后, JVM再在老年代執(zhí)行空間碎片整理

初始標(biāo)記 (Initial Mark)

停止一切用戶(hù)線程,僅使用一條初始標(biāo)記線程對(duì)所有與GC Roots直接相關(guān)聯(lián)的 老年代對(duì)象進(jìn)行標(biāo)記,速度很快

并發(fā)標(biāo)記 (Concurrent Marking Phase)

使用多條并發(fā)標(biāo)記線程并行執(zhí)行,并與用戶(hù)線程并發(fā)執(zhí)行.此過(guò)程進(jìn)行可達(dá)性分析,標(biāo)記所有這些對(duì)象可達(dá)的存貨對(duì)象,速度很慢

重新標(biāo)記 ( Remark)

因?yàn)椴l(fā)標(biāo)記時(shí)有用戶(hù)線程在執(zhí)行，標(biāo)記結(jié)果可能有變化

停止一切用戶(hù)線程,并使用多條重新標(biāo)記線程并行執(zhí)行,重新遍歷所有在并發(fā)標(biāo)記期間有變化的對(duì)象進(jìn)行最后的標(biāo)記.這個(gè)過(guò)程的運(yùn)行時(shí)間介于初始標(biāo)記和并發(fā)標(biāo)記之間

并發(fā)清除 (Concurrent Sweeping)

只使用一條并發(fā)清除線程,和用戶(hù)線程們并發(fā)執(zhí)行,清除剛才標(biāo)記的對(duì)象

這個(gè)過(guò)程非常耗時(shí)

G1收集器

G1(Garbage-First)是JDK7-u4才推出商用的收集器;他比CMS更高級(jí)了，他是并行與并發(fā)，能充分利用多CPU、多核環(huán)境下的硬件優(yōu)勢(shì);

G1以下特點(diǎn)

并行與并發(fā)

能充分利用多CPU、多核環(huán)境下的硬件優(yōu)勢(shì);

可以并行來(lái)縮短"Stop The World"停頓時(shí)間;

也可以并發(fā)讓垃圾收集與用戶(hù)程序同時(shí)進(jìn)行;

分代收集，收集范圍包括新生代和老年代

能獨(dú)立管理整個(gè)GC堆(新生代和老年代)，而不需要與其他收集器搭配;

能夠采用不同方式處理不同時(shí)期的對(duì)象;

雖然保留分代概念，但Java堆的內(nèi)存布局有很大差別;

將整個(gè)堆劃分為多個(gè)大小相等的獨(dú)立區(qū)域(Region);

新生代和老年代不再是物理隔離，它們都是一部分Region(不需要連續(xù))的集合;

結(jié)合多種垃圾收集算法，空間整合，不產(chǎn)生碎片

從整體看，是基于標(biāo)記-整理算法;

從局部(兩個(gè)Region間)看，是基于復(fù)制算法;

這是一種類(lèi)似火車(chē)算法的實(shí)現(xiàn);

都不會(huì)產(chǎn)生內(nèi)存碎片，有利于長(zhǎng)時(shí)間運(yùn)行;

可預(yù)測(cè)的停頓：低停頓的同時(shí)實(shí)現(xiàn)高吞吐量

G1除了追求低停頓處，還能建立可預(yù)測(cè)的停頓時(shí)間模型;

可以明確指定M毫秒時(shí)間片內(nèi)，垃圾收集消耗的時(shí)間不超過(guò)N毫秒;

如：在堆大小約6GB或更大時(shí)，可預(yù)測(cè)的暫停時(shí)間可以低于0.5秒;

用來(lái)替換掉JDK1.5中的CMS收集器;

上面提到Region 概念，肯定都不會(huì)理解，讓我們看一下G1的內(nèi)存模型

G1將Java堆空間分割成了若干相同大小的區(qū)域，即region

Humongous是特殊的Old類(lèi)型,專(zhuān)門(mén)放置大型對(duì)象

在JDK11中，已經(jīng)將G1設(shè)為默認(rèn)垃圾回收器

G1垃圾收集過(guò)程

初始標(biāo)記

標(biāo)記與GC Roots直接關(guān)聯(lián)的對(duì)象,停止所有用戶(hù)線程,只啟動(dòng)一條初始標(biāo)記線程,這個(gè)過(guò)程很快。

并發(fā)標(biāo)記

進(jìn)行全面的可達(dá)性分析,開(kāi)啟一條并發(fā)標(biāo)記線程與用戶(hù)線程并行執(zhí)行.這個(gè)過(guò)程比較長(zhǎng)。

最終標(biāo)記

標(biāo)記出并發(fā)標(biāo)記過(guò)程中用戶(hù)線程新產(chǎn)生的垃圾.停止所有用戶(hù)線程,并使用多條最終標(biāo)記線程并行執(zhí)行。

篩選回收

回收廢棄的對(duì)象.此時(shí)也需要停止一切用戶(hù)線程,并使用多條篩選回收線程并行執(zhí)行。

題外話：我們知道目前為止JDK8是應(yīng)用最廣泛對(duì)版本，并且JDK9、10是一個(gè)過(guò)度版，企業(yè)應(yīng)用效果不好，JDK11是一個(gè)里程碑版本，重要程度相當(dāng)于現(xiàn)在JDK8，并且JDK11默認(rèn)使用G1收集器，G1的性能在早些年就突出于CMS并且官方對(duì)性能測(cè)試結(jié)果也是這樣說(shuō)明的。

本文轉(zhuǎn)載自微信公眾號(hào)「 晏霖」，可以通過(guò)以下二維碼關(guān)注。轉(zhuǎn)載本文請(qǐng)聯(lián)系 晏霖公眾號(hào)。