JVM 7種垃圾收集器的特點及使用場景是什么

這篇文章給大家介紹JVM 7種垃圾收集器的特點及使用場景是什么，內(nèi)容非常詳細，感興趣的小伙伴們可以參考借鑒，希望對大家能有所幫助。

這里討論的收集器基于JDK1.7Update 14之后的HotSpot虛擬機，這個虛擬機包含的所有收集器如下圖3-5所示：

上圖展示了7種作用于不同分代的收集器，如果兩個收集器之間存在連線，就說明它們可以搭配使用。

1.Serial收集器

Serial收集器是最基本、發(fā)展歷史最悠久的收集器。是單線程的收集器。它在進行垃圾收集時，必須暫停其他所有的工作線程，直到它收集完成。

Serial收集器依然是虛擬機運行在Client模式下默認新生代收集器，對于運行在Client模式下的虛擬機來說是一個很好的選擇。

2.ParNew收集器

ParNew收集器其實就是Serial收集器的多線程版本，除了使用多線程進行垃圾收集之外，其余行為包括Serial收集器可用的所有控制參數(shù)、收集算法、Stop The Worl、對象分配規(guī)則、回收策略等都與Serial 收集器完全一樣。

ParNew收集器是許多運行在Server模式下的虛擬機中首選新生代收集器，其中有一個與性能無關(guān)但很重要的原因是，除Serial收集器之外，目前只有ParNew它能與CMS收集器配合工作。

3.Parallel Scavenge（并行回收）收集器

Parallel Scavenge收集器是一個新生代收集器，它也是使用復(fù)制算法的收集器，又是并行的多線程收集器

該收集器的目標是達到一個可控制的吞吐量（Throughput）。所謂吞吐量就是CPU用于運行用戶代碼的時間與CPU總消耗時間的比值，即 吞吐量=運行用戶代碼時間/（運行用戶代碼時間+垃圾收集時間）

停頓時間越短就越適合需要與用戶交互的程序，良好

的響應(yīng)速度能提升用戶體驗，而高吞吐量則可用高效率地利用CPU時間，盡快完成程序的運算任務(wù)，主要適合在后臺運算而不需要太多交互的任務(wù)。

Parallel Scavenge收集器提供兩個參數(shù)用于精確控制吞吐量，分別是控制最大垃圾收起停頓時間的

-XX:MaxGCPauseMillis參數(shù)以及直接設(shè)置吞吐量大小的-XX:GCTimeRatio參數(shù)

Parallel Scavenge收集器還有一個參數(shù)：-XX:+UseAdaptiveSizePolicy。這是一個開關(guān)參數(shù)，當(dāng)這個參數(shù)打開后，就不需要手工指定新生代的大?。?Xmn）、Eden與Survivor區(qū)的比例（-XX:SurvivorRatio）、晉升老年代對象年齡（-XX:PretenureSizeThreshold）等細節(jié)參數(shù)，只需要把基本的內(nèi)存數(shù)據(jù)設(shè)置好（如-Xmx設(shè)置最大堆），然后使用MaxGVPauseMillis參數(shù)或GCTimeRation參數(shù)給虛擬機設(shè)立一個優(yōu)化目標。

自適應(yīng)調(diào)節(jié)策略也是Parallel Scavenge收集器與ParNew收集器的一個重要區(qū)別

4.Serial Old 收集器

Serial Old是Serial收集器的老年代版本，它同樣是一個單線程收集器，使用標記整理算法。這個收集器的主要意義也是在于給Client模式下的虛擬機使用。

如果在Server模式下，主要兩大用途：

（1）在JDK1.5以及之前的版本中與Parallel Scavenge收集器搭配使用

（2）作為CMS收集器的后備預(yù)案，在并發(fā)收集發(fā)生Concurrent Mode Failure時使用

Serial Old收集器的工作工程

5.Parallel Old 收集器

Parallel Old 是Parallel Scavenge收集器的老年代版本，使用多線程和“標記-整理”算法。這個收集器在1.6中才開始提供。

6.CMS收集器

CMS(Concurrent Mark Sweep)收集器是一種以獲取最短回收停頓時間為目標的收集器。目前很大一部分的Java應(yīng)用集中在互聯(lián)網(wǎng)站或者B/S系統(tǒng)的服務(wù)端上，這類應(yīng)用尤其重視服務(wù)器的響應(yīng)速度，希望系統(tǒng)停頓時間最短，以給用戶帶來較好的體驗。CMS收集器就非常符合這類應(yīng)用的需求

CMS收集器是基于“標記-清除”算法實現(xiàn)的。它的運作過程相對前面幾種收集器來說更復(fù)雜一些，整個過程分為4個步驟：

（1）初始標記

（2）并發(fā)標記

（3）重新標記

（4）并發(fā)清除

其中，初始標記、重新標記這兩個步驟仍然需要“Stop The World”.

CMS收集器主要優(yōu)點：并發(fā)收集，低停頓。

CMS三個明顯的缺點：

（1）CMS收集器對CPU資源非常敏感。CPU個數(shù)少于4個時，CMS對于用戶程序的影響就可能變得很大，為了應(yīng)付這種情況，虛擬機提供了一種稱為“增量式并發(fā)收集器”的CMS收集器變種。所做的事情和單CPU年代PC機操作系統(tǒng)使用搶占式來模擬多任務(wù)機制的思想

（2）CMS收集器無法處理浮動垃圾，可能出現(xiàn)“Concurrent Mode Failure”失敗而導(dǎo)致另一次Full GC的產(chǎn)生。在JDK1.5的默認設(shè)置下，CMS收集器當(dāng)老年代使用了68%的空間后就會被激活，這是一個偏保守的設(shè)置，如果在應(yīng)用中藍年代增長不是太快，可以適當(dāng)調(diào)高參數(shù)-XX:CMSInitiatingOccupancyFraction的值來提高觸發(fā)百分比，以便降低內(nèi)存回收次數(shù)從而獲取更好的性能，在JDK1.6中，CMS收集器的啟動閥值已經(jīng)提升至92%。

（3）CMS是基于“標記-清除”算法實現(xiàn)的收集器，手機結(jié)束時會有大量空間碎片產(chǎn)生?？臻g碎片過多，可能會出現(xiàn)老年代還有很大空間剩余，但是無法找到足夠大的連續(xù)空間來分配當(dāng)前對象，不得不提前出發(fā)FullGC。為了解決這個問題，CMS收集器提供了一個-XX:+UseCMSCompactAtFullCollection開關(guān)參數(shù)（默認就是開啟的），用于在CMS收集器頂不住要進行FullGC時開啟內(nèi)存碎片合并整理過程，內(nèi)存整理的過程是無法并發(fā)的，空間碎片問題沒有了，但停頓時間變長了。虛擬機設(shè)計者還提供了另外一個參數(shù)-XX:CMSFullGCsBeforeCompaction,這個參數(shù)是用于設(shè)置執(zhí)行多少次不壓縮的Full GC后，跟著來一次帶壓縮的（默認值為0，標識每次進入Full GC時都進行碎片整理）

7. G1收集器

G1收集器的優(yōu)勢：

（1）并行與并發(fā)

（2）分代收集

（3）空間整理 （標記整理算法，復(fù)制算法）

（4）可預(yù)測的停頓（G1處處理追求低停頓外，還能建立可預(yù)測的停頓時間模型，能讓使用者明確指定在一個長度為M毫秒的時間片段內(nèi)，消耗在垃圾收集上的時間不得超過N毫秒，這幾乎已經(jīng)實現(xiàn)Java（RTSJ）的來及收集器的特征）

使用G1收集器時，Java堆的內(nèi)存布局是整個規(guī)劃為多個大小相等的獨立區(qū)域（Region）,雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔離的了，它們都是一部分Region的集合。

G1收集器之所以能建立可預(yù)測的停頓時間模型，是因為它可以有計劃地避免在真?zhèn)€Java堆中進行全區(qū)域的垃圾收集。G1跟蹤各個Region里面的垃圾堆積的價值大?。ɑ厥账@取的空間大小以及回收所需要的時間的經(jīng)驗值），在后臺維護一個優(yōu)先列表，每次根據(jù)允許的收集時間，優(yōu)先回收價值最大的Region（這也就是Garbage-First名稱的又來）。這種使用Region劃分內(nèi)存空間以及有優(yōu)先級的區(qū)域回收方式，保證了G1收集器在有限的時間內(nèi)可以獲取盡量可能高的灰機效率

G1 內(nèi)存“化整為零”的思路

在GC根節(jié)點的枚舉范圍中加入Remembered Set即可保證不對全堆掃描也不會遺漏。

如果不計算維護Remembered Set的操作，G1收集器的運作大致可劃分為一下步驟：

（1）初始標記

（2）并發(fā)標記

（3）最終標記

（4）篩選回收

關(guān)于JVM 7種垃圾收集器的特點及使用場景是什么就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。