JVM(HotSpot) 7種垃圾收集器的特色及使用場景

上圖展現了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）篩選回收