快捷導(dǎo)航

Java中的垃圾收集器詳解

更新時間：2023年07月31日 11:51:57 作者：兔老大RabbitMQ

這篇文章主要介紹了Java中的垃圾收集器詳解,垃圾收集機制是?Java?的招牌能力,極大地提高了開發(fā)效率,如今垃圾收集幾乎成為現(xiàn)代語言的標(biāo)配,需要的朋友可以參考下

Serial

Serial（串行）收集器收集器是最基本、歷史最悠久的垃圾收集器了。

大家看名字就知道這個收集器是一個單線程收集器了。它的 “單線程” 的意義不僅僅意味著它只會使用一條垃圾收集線程去完成垃圾收集工作，更重要的是它在進(jìn)行垃圾收集工作的時候必須暫停其他所有的工作線程（ "Stop The World" ），直到它收集結(jié)束。

新生代采用復(fù)制算法，老年代采用標(biāo)記-整理算法。

Serial 收集器

虛擬機的設(shè)計者們當(dāng)然知道 Stop The World 帶來的不良用戶體驗，所以在后續(xù)的垃圾收集器設(shè)計中停頓時間在不斷縮短（仍然還有停頓，尋找最優(yōu)秀的垃圾收集器的過程仍然在繼續(xù)）。

但是 Serial 收集器有沒有優(yōu)于其他垃圾收集器的地方呢？當(dāng)然有，它簡單而高效（與其他收集器的單線程相比）。Serial 收集器由于沒有線程交互的開銷，自然可以獲得很高的單線程收集效率。Serial 收集器對于運行在 Client 模式下的虛擬機來說是個不錯的選擇。

ParNew

ParNew 收集器其實就是 Serial 收集器的多線程版本，除了使用多線程進(jìn)行垃圾收集外，其余行為（控制參數(shù)、收集算法、回收策略等等）和 Serial 收集器完全一樣。

新生代采用復(fù)制算法，老年代采用標(biāo)記-整理算法。

ParNew 收集器

它是許多運行在 Server 模式下的虛擬機的首要選擇，除了 Serial 收集器外，只有它能與 CMS 收集器（真正意義上的并發(fā)收集器，后面會介紹到）配合工作。

并行和并發(fā)概念補充：

并行（Parallel）：指多條垃圾收集線程并行工作，但此時用戶線程仍然處于等待狀態(tài)。
并發(fā)（Concurrent）：指用戶線程與垃圾收集線程同時執(zhí)行（但不一定是并行，可能會交替執(zhí)行），用戶程序在繼續(xù)運行，而垃圾收集器運行在另一個 CPU 上。

Parallel Scavenge

Parallel Scavenge 收集器也是使用復(fù)制算法的多線程收集器，它看上去幾乎和ParNew都一樣。

那么它有什么特別之處呢？

-XX:+UseParallelGC 
    使用 Parallel 收集器+ 老年代串行
-XX:+UseParallelOldGC
    使用 Parallel 收集器+ 老年代并行

Parallel Scavenge 收集器關(guān)注點是吞吐量（高效率的利用 CPU）。

CMS 等垃圾收集器的關(guān)注點更多的是用戶線程的停頓時間（提高用戶體驗）。

所謂吞吐量就是 CPU 中用于運行用戶代碼的時間與 CPU 總消耗時間的比值。

Parallel Scavenge 收集器提供了很多參數(shù)供用戶找到最合適的停頓時間或最大吞吐量，如果對于收集器運作不太了解的話，手工優(yōu)化存在困難的話可以選擇把內(nèi)存管理優(yōu)化交給虛擬機去完成也是一個不錯的選擇。

新生代采用復(fù)制算法，老年代采用標(biāo)記-整理算法。

Parallel Scavenge 收集器

Serial old

Serial 收集器的老年代版本，它同樣是一個單線程收集器。

它主要有兩大用途：

一種用途是在 JDK1.5 以及以前的版本中與 Parallel Scavenge 收集器搭配使用
另一種用途是作為 CMS 收集器的后備方案。

Parallel old

Parallel Scavenge 收集器的老年代版本。

使用多線程和“標(biāo)記-整理”算法。

在注重吞吐量以及 CPU 資源的場合，都可以優(yōu)先考慮 Parallel Scavenge 收集器和 Parallel Old 收集器。

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標(biāo)的收集器。

它非常符合在注重用戶體驗的應(yīng)用上使用。

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虛擬機第一款真正意義上的并發(fā)收集器，它第一次實現(xiàn)了讓垃圾收集線程與用戶線程（基本上）同時工作。

從名字中的Mark Sweep這兩個詞可以看出，CMS 收集器是一種 “標(biāo)記-清除”算法實現(xiàn)的，它的運作過程相比于前面幾種垃圾收集器來說更加復(fù)雜一些。

整個過程分為四個步驟：

初始標(biāo)記：暫停所有的其他線程，并記錄下直接與 root 相連的對象，速度很快；
并發(fā)標(biāo)記：同時開啟 GC 和用戶線程，用一個閉包結(jié)構(gòu)去記錄可達(dá)對象。但在這個階段結(jié)束，這個閉包結(jié)構(gòu)并不能保證包含當(dāng)前所有的可達(dá)對象。因為用戶線程可能會不斷的更新引用域，所以 GC 線程無法保證可達(dá)性分析的實時性。所以這個算法里會跟蹤記錄這些發(fā)生引用更新的地方。
重新標(biāo)記：重新標(biāo)記階段就是為了修正并發(fā)標(biāo)記期間因為用戶程序繼續(xù)運行而導(dǎo)致標(biāo)記產(chǎn)生變動的那一部分對象的標(biāo)記記錄，這個階段的停頓時間一般會比初始標(biāo)記階段的時間稍長，遠(yuǎn)遠(yuǎn)比并發(fā)標(biāo)記階段時間短
并發(fā)清除：開啟用戶線程，同時 GC 線程開始對為標(biāo)記的區(qū)域做清掃。

CMS 垃圾收集器

從它的名字就可以看出它是一款優(yōu)秀的垃圾收集器

主要優(yōu)點：

并發(fā)收集
低停頓

但是它有下面三個明顯的缺點：

對 CPU 資源敏感；
無法處理浮動垃圾；
它使用的回收算法-“標(biāo)記-清除”算法會導(dǎo)致收集結(jié)束時會有大量空間碎片產(chǎn)生。

G1收集器

G1 (Garbage-First) 是一款面向服務(wù)器的垃圾收集器,主要針對配備多顆處理器及大容量內(nèi)存的機器。以極高概率滿足 GC 停頓時間要求的同時,還具備高吞吐量性能特征。

被視為 JDK1.7 中 HotSpot 虛擬機的一個重要進(jìn)化特征。

它具備以下特點：

并行與并發(fā)：G1 能充分利用 CPU、多核環(huán)境下的硬件優(yōu)勢，使用多個 CPU（CPU 或者 CPU 核心）來縮短 Stop-The-World 停頓時間。部分其他收集器原本需要停頓 Java 線程執(zhí)行的 GC 動作，G1 收集器仍然可以通過并發(fā)的方式讓 java 程序繼續(xù)執(zhí)行。
分代收集：雖然 G1 可以不需要其他收集器配合就能獨立管理整個 GC 堆，但是還是保留了分代的概念。
空間整合：與 CMS 的“標(biāo)記--清理”算法不同，G1 從整體來看是基于“標(biāo)記整理”算法實現(xiàn)的收集器；從局部上來看是基于“復(fù)制”算法實現(xiàn)的。
可預(yù)測的停頓：這是 G1 相對于 CMS 的另一個大優(yōu)勢，降低停頓時間是 G1 和 CMS 共同的關(guān)注點，但 G1 除了追求低停頓外，還能建立可預(yù)測的停頓時間模型，能讓使用者明確指定在一個長度為 M 毫秒的時間片段內(nèi)。

G1 收集器的運作大致分為以下幾個步驟：