本篇目錄

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

1、GC的分類與性能指標(biāo)

1.1 GC分類

• 垃圾收集器沒有在規(guī)范中進(jìn)行過多的規(guī)定，可以由不同的廠商、不同版本的JVM來(lái)實(shí)現(xiàn)。
• 由于JDK的版本處于高速迭代過程中，因此Java發(fā)展至今已經(jīng)衍生了眾多的GC版本。
• 從不同角度分析垃圾收集器，可以將GC分為不同的類型。

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

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

2、按照工作模式分，可以分為并發(fā)式垃圾回收器和獨(dú)占式垃圾回收器

• 并發(fā)式垃圾回收器與應(yīng)用程序線程交替工作，以盡可能減少應(yīng)用程序的停頓時(shí)間。
• 獨(dú)占式垃圾回收器（Stop the world）一旦運(yùn)行，就停止應(yīng)用程序中的所有用戶線程，直到垃圾回收過程完全結(jié)束。

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

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

4、按工作的內(nèi)存區(qū)間分，又可分為年輕代垃圾回收器和老年代垃圾回收器

1.2 評(píng)估GC的性能指標(biāo)

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

1.2.1 吞吐量

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

1.2.2 暫停時(shí)間

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

2、不同垃圾回收器概述

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

2.1 垃圾收集器發(fā)展史

有了虛擬機(jī)，就一定需要收集垃圾的機(jī)制，這就是Garbage Collection， 對(duì)應(yīng)的產(chǎn)品我們稱為Garbage Collector。

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

2.2 7款經(jīng)典的垃圾收集器

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

2.3 7款經(jīng)典的垃圾收集器與垃圾分代之間的關(guān)系

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

2.4 垃圾收集器的組合關(guān)系

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

其中Serial 0ld作為CMS 出現(xiàn)"Concurrent Mode Failure"失敗的后 備預(yù)案。

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

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

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

2.5 查看默認(rèn)的垃圾收集器

? 一xx：+PrintCommandLineFlags： 查看命令行相關(guān)參數(shù)（包含使用的垃圾收集器）
? 使用命令行指令： jinfo 一flag相關(guān)垃圾回收器參數(shù)進(jìn)程ID

/*** -XX:+PrintCommandLineFlags** -XX:+UseSerialGC:表明新生代使用Serial GC ，同時(shí)老年代使用Serial Old GC** -XX:+UseParNewGC：標(biāo)明新生代使用ParNew GC** -XX:+UseParallelGC:表明新生代使用Parallel GC* -XX:+UseParallelOldGC : 表明老年代使用 Parallel Old GC* 說明：二者可以相互激活** -XX:+UseConcMarkSweepGC：表明老年代使用CMS GC。同時(shí)，年輕代會(huì)觸發(fā)對(duì)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環(huán)境下，默認(rèn)使用 Parallel Scavenge（新生代）+ Serial Old（老年代）

3、Serial回收器:串行回收

3.1 概述

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

3.2 優(yōu)勢(shì)

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

4、ParNew回收器:并行回收

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

5、Parallel回收器:吞吐量?jī)?yōu)先

5.1 概述

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

6、CMS回收器:低延遲、并發(fā)回收

6.1 概述

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

6.2 工作過程

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

• 初始標(biāo)記（Initial一Mark） 階段：在這個(gè)階段中，程序中所有的工作線程都將會(huì)因?yàn)? “Stop一the一World"機(jī)制而出現(xiàn)短暫的暫停，這個(gè)階段的主要任務(wù)僅僅只是標(biāo)記出GCRoots能直接關(guān)聯(lián)到的對(duì)象。一旦標(biāo)記完成之后就會(huì)恢復(fù)之前被暫停的所有應(yīng)用.線程。由于直接關(guān)聯(lián)對(duì)象比較小，所以這里的速度非常快。

• 并發(fā)標(biāo)記（Concurrent一Mark）階段：從GC Roots的 直接關(guān)聯(lián)對(duì)象開始遍歷整個(gè)對(duì) 象圖的過程，這個(gè)過程耗時(shí)較長(zhǎng)但是不需要停頓用戶線程，可以與垃圾收集線程一起并發(fā)運(yùn)行。

• 重新標(biāo)記（Remark） 階段：由于在并發(fā)標(biāo)記階段中，程序的工作線程會(huì)和垃圾收集線程同時(shí)運(yùn)行或者交叉運(yùn)行，因此為了修正并發(fā)標(biāo)記期間，因用戶程序繼續(xù)運(yùn)作而導(dǎo)致標(biāo)記產(chǎn)生變動(dòng)的那一部分對(duì)象的標(biāo)記記錄，這個(gè)階段的停頓時(shí)間通常會(huì)比初始標(biāo)記階段稍長(zhǎng)一些，但也遠(yuǎn)比并發(fā)標(biāo)記階段的時(shí)間短。

• 并發(fā)清除（ Concurrent一Sweep）階段：此階段清理刪除掉標(biāo)記階段判斷的已經(jīng)死亡的對(duì)象，釋放內(nèi)存空間。由于不需要移動(dòng)存活對(duì)象，所以這個(gè)階段也是可以與用戶線程同時(shí)并發(fā)的。

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

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

答案其實(shí)很簡(jiǎn)答，因?yàn)楫?dāng)并發(fā)清除的時(shí)候，用Compact整理內(nèi)存的話，原來(lái)的用戶線程使用的內(nèi)存還怎么用呢？要保證用戶線程能繼續(xù)執(zhí)行，前提的它運(yùn)行的資源不受影響嘛。Mark Compact更適合“Stop the World”這種場(chǎng)景”下使用。

6.3 CMS的優(yōu)點(diǎn)：

? 并發(fā)收集
? 低延遲

6.4 CMS的弊端

1）會(huì)產(chǎn)生內(nèi)存碎片，導(dǎo)致并發(fā)清除后，用戶線程可用的空間不足。在無(wú)法分配大對(duì)象的情況下，不得不提前觸發(fā)Full GC。
2） CMS收集器對(duì)CPU資源非常敏感。在并發(fā)階段，它雖然不會(huì)導(dǎo)致用戶停頓，但是會(huì)因?yàn)檎加昧艘徊糠志€程而導(dǎo)致應(yīng)用程序變慢，總吞吐量會(huì)降低。
3） CMS收集器無(wú)法處理浮動(dòng)垃圾。可能出現(xiàn)“Concurrent Mode Failure" 失敗而導(dǎo)致另一次Full GC的產(chǎn)生。在并發(fā)標(biāo)記階段由于程序的工作線程和垃圾收集線程是同時(shí)運(yùn)行或者交叉運(yùn)行的，那么在并發(fā)標(biāo)記階段如果產(chǎn)生新的垃圾對(duì)象，CMS將 無(wú)法對(duì)這些垃圾對(duì)象進(jìn)行標(biāo)記，最終會(huì)導(dǎo)致這些新產(chǎn)生的垃圾對(duì)象沒有被及時(shí)回收，從而只能在下一次執(zhí)行GC時(shí)釋放這些之前未被回收的內(nèi)存空間。

6.5 JDK 后續(xù)版本中CMS的變化

? JDK9新特性： CMS被標(biāo)記為Deprecate了（JEP291）
? 如果對(duì)JDK 9及以上版本的HotSpot虛擬機(jī)使用參數(shù)一XX：+UseConcMarkSweepGC來(lái)開啟CMS收集器的話，用戶會(huì)收到一個(gè)警告信息，提示CMS未來(lái)將會(huì)被廢棄。
? JDK14新特性： 刪除CMS垃圾回收器（JEP363）
? 移除了CMS垃圾收集器，如果在JDK14中使用一XX： +UseConcMarkSweepGC的話，JVM不會(huì)報(bào)錯(cuò)，只是給出一個(gè)warning信息，但是不會(huì)exit。JVM會(huì)自動(dòng)回退以默認(rèn)GC方式啟動(dòng)JVM

7、G1回收器:區(qū)域化分代式

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

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

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

7.2 優(yōu)勢(shì)

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

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

7.3 缺點(diǎn)

? 相較于CMS，G1還不具備全方位、壓倒性優(yōu)勢(shì)。比如在用戶程序運(yùn)行過程中，G1無(wú)論是為了垃圾收集產(chǎn)生的內(nèi)存占用（Footprint） 還是程序運(yùn)行時(shí)的額外執(zhí)行負(fù)載（overload） 都要比CMS要高。
? 從經(jīng)驗(yàn)上來(lái)說，在小內(nèi)存應(yīng)用上CMS的表現(xiàn)大概率會(huì)優(yōu)于G1，而G1在大內(nèi)存應(yīng)用，上則發(fā)揮其優(yōu)勢(shì)。平衡點(diǎn)在6一8GB之間。

7.4 適用場(chǎng)景

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

7.5 分區(qū)region,化整為零

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

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

7.6 垃圾回收過程

7.6.1 概述

G1 GC的垃圾回收過程主要包括如下三個(gè)環(huán)節(jié)：

• 年輕代GC （Young GC ）
• 老年代并發(fā)標(biāo)記過程（ Concurrent Marking）
• 混合回收（Mixed GC ）

（如果需要，單線程、獨(dú)占式、高強(qiáng)度的Full GC還是繼續(xù)存在的。它針對(duì)GC的評(píng)估失敗提供了一種失敗保護(hù)機(jī)制，即強(qiáng)力回收。）

順時(shí)針， young gc 一> young gc + concurrent mark 一> Mixed GC順序，進(jìn)行垃圾回收。

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

7.6.2 詳解

7.6.2.1 年輕代GC

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

7.6.2.2 并發(fā)標(biāo)記過程

• 初始標(biāo)記階段：標(biāo)記從根節(jié)點(diǎn)直接可達(dá)的對(duì)象。這個(gè)階段是STW的，并且會(huì)觸發(fā)一次年輕代GC。
• 根區(qū)域掃描（Root Region Scanning） ： G1 GC掃描Survivor區(qū) 直接可達(dá)的老年代區(qū)域?qū)ο?#xff0c;并標(biāo)記被引用的對(duì)象。這一過程必 須在young GC之前完成。
• 并發(fā)標(biāo)記（Concurrent Marking）： 在整個(gè)堆中進(jìn)行并發(fā)標(biāo)記（和應(yīng)用程序并發(fā)執(zhí)行），此過程可能被young GC中斷。在并發(fā)標(biāo)記階段，若發(fā)現(xiàn)區(qū)域?qū)ο笾械乃袑?duì)象都是垃圾，那這個(gè)區(qū)域會(huì)被立即回收。同時(shí)，并發(fā)標(biāo)記過程中，會(huì)計(jì)算每個(gè)區(qū)域的對(duì)象活性（區(qū)域中存活對(duì)象的比例）。
• 再次標(biāo)記（Remark）： 由 于應(yīng)用程序持續(xù)進(jìn)行，需要修正上一次的標(biāo)記結(jié)果。是STW的。G1中采用了比CMS更快的初始快照算法：snapshot一at一the一beginning （SATB）。
• 獨(dú)占清理（cleanup，STW）：計(jì)算各個(gè)區(qū)域的存活對(duì)象和GC回收比例，并進(jìn)行排序，識(shí)別可以混合回收的區(qū)域。為下階段做鋪墊。是STW的。?這個(gè)階段并不會(huì)實(shí)際上去做垃圾的收集
• 并發(fā)清理階段：識(shí)別并清理完全空閑的區(qū)域。

7.6.2.3 混合回收

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

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

7.6.2.4 Full GC

G1的初衷就是要避免Full GC的出現(xiàn)。但是如果上述方式不能正常工作，G1會(huì)停止應(yīng)用程序的執(zhí)行（Stop一 The一World），使用單線程的內(nèi)存回收算法進(jìn)行垃圾回收，性能會(huì)非常差，應(yīng)用程序停頓時(shí)間會(huì)很長(zhǎng)。

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

7.7 補(bǔ)充

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

7.8 記憶集與寫屏障

一個(gè)對(duì)象被不同區(qū)域引用的問題(分代引用問題)

一個(gè)Region不可能是孤立的，一個(gè)Region中的對(duì)象可能被其他任意Region中對(duì)象引用，判斷對(duì)象存活時(shí)，是否需要掃描整個(gè)Java堆才能保證準(zhǔn)確？

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

解決方法：

• ?無(wú)論G1還是其他分代收集器，JVM都是使用RememberedSet來(lái)避免全局掃描：
• ?每個(gè)Region都有 一個(gè)對(duì)應(yīng)的Remembered Set；
• ?每次Reference類 型數(shù)據(jù)寫操作時(shí)，都會(huì)產(chǎn)生一個(gè)Write Barrier暫 時(shí)中斷操作；
• ?然后檢查將要寫入的引用指向的對(duì)象是否和該Reference類型數(shù)據(jù)在不同的Region （其他收集器：檢查老年代對(duì)象是否引用了新生代對(duì)象） ；
• ?如果不同，通過CardTable把相關(guān)引用信息記錄到引用指向?qū)ο蟮乃赗egion對(duì)應(yīng)的Remembered Set中；
• ?當(dāng)進(jìn)行垃圾收集時(shí)，在GC根節(jié)點(diǎn)的枚舉范圍加入Remembered Set；就可以保證不進(jìn)行全局掃描，也不會(huì)有遺漏。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。