轉載自：https://www.cnblogs.com/chengxuyuanzhilu/p/7088316.html
這裏討論的收集器基於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）篩選回收
