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

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

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

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

1.Serial收集器

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

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

2.ParNew收集器

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

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

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

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

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

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

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

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

-XX:MaxGCPauseMillis參數以及直接設置吞吐量大小的-XX:GCTimeRatio參數

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

自適應調節策略也是Parallel Scavenge收集器與ParNew收集器的一個重要區別

4.Serial Old 收集器

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

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

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

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

Serial Old收集器的工作工程

5.Parallel Old 收集器

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

6.CMS收集器

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

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

（1）初始標記

（2）并發標記

（3）重新標記

（4）并發清除

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

CMS收集器主要優點：并發收集，低停頓。

CMS三個明顯的缺點：

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

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

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

7. G1收集器

G1收集器的優勢：

（1）并行與并發

（2）分代收集

（3）空間整理 （標記整理算法，復制算法）

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

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

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

G1 內存“化整為零”的思路

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

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

（1）初始標記

（2）并發標記

（3）最終標記

（4）篩選回收

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