垃圾收集器是內存回收的具體實現
併發收集器：指多條垃圾收集線程並行工作，但此時用戶線程仍然處於等待狀態
併發收集器：指用戶線程與垃圾收集線程同時執行（但不一定時並行的，可能會交替執行），用戶程序在繼續運行，而垃圾收集程序運行於另一個CPU上。
上圖展示了作用於不同分代的收集器，若兩個收集器之間存在連線，則說明它們可以搭配使用。虛擬機所處的區域，則表示它是屬於新生代收集器還是老年代收集器。
Serial收集器
單線程收集器，進行垃圾收集時，必須暫停其他所有的工作線程，直至其收集結束。
優點：簡單高效（與其他收集器的單線程比），對於限定單個CPU的環境來說，Serial收集器由於沒有線程交互的開銷，專心做垃圾收集自然可以獲得最 高的單線程收集效率。在用戶的桌面應用場景中，分配給虛擬機管理的內存一般來說不會很 大，收集幾十兆甚至一兩百兆的新生代（僅僅是新生代使用的內存，桌面應用基本上不會再 大了），停頓時間完全可以控制在幾十毫秒最多一百多毫秒以內，只要不是頻繁發生，這點 停頓是可以接受的。所以，Serial收集器對於運行在Client模式下的虛擬機來說是一個很好的 選擇。
ParNew收集器
Serial收集器的多線程版本
ParNew收集器在單CPU的環境中絕對不會有比Serial收集器更好的效果，甚至由於存在線程交互的開銷，該收集器在通過超線程技術實現的兩個CPU的環境中都不能百分之百地保 證可以超越Serial收集器。當然，隨着可以使用的CPU的數量的增加，它對於GC時系統資源 的有效利用還是很有好處的。它默認開啓的收集線程數與CPU的數量相同，在CPU非常多 （譬如32個，現在CPU動輒就4核加超線程，服務器超過32個邏輯CPU的情況越來越多了）的環境下，可以使用-XX：ParallelGCThreads參數來限制垃圾收集的線程數
Parallel Scavenge收集器
採用複製算法的新生代收集器，也是並行的多線程收集器。
特點是儘可能達到一個可控制的吞吐量。
- 吞吐量=運行用戶代碼時間/(運行用戶代碼時間+垃圾收集時間)
支持GC自適應調節策略（GC Erogonomics）
Serial Old收集器
是Serial收集器的老年代版本，它同樣是一個單線程收集器，使用“標記-整理”算法。
。這個收集器的主要意義也是在於給Client模式下的虛擬機使用。如果在Server模式 下，那麼它主要還有兩大用途：一種用途是在JDK 1.5以及之前的版本中與Parallel Scavenge 收集器搭配使用[1]，另一種用途就是作爲CMS收集器的後備預案，在併發收集發生Concurrent Mode Failure時使用。
Parallel Old收集器
是Parallel Scavenge收集器的老年代版本，使用多線程和“標記-整理”算法。
直到Parallel Old收集器出現後，“吞吐量優先”收集器終於有了比較名副其實的應用組 合，在注重吞吐量以及CPU資源敏感的場合，都可以優先考慮Parallel Scavenge加Parallel Old 收集器。
CMS收集器
CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間爲目標的收集器。目前很大一部分的Java應用集中在互聯網站或者B/S系統的服務端上，這類應用尤其重 視服務的響應速度，希望系統停頓時間最短，以給用戶帶來較好的體驗。CMS收集器就非常 符合這類應用的需求。 、
CMS收集器是基於“標記—清除”算法實現 的，它的運作過程相對於前面幾種收集器來說更復雜一些，整個過程分爲4個步驟，包括：
- 初始標記
- 併發標記
- 重新標記
- 併發清除
由於整個過程中耗時最長的併發標記和併發清除過程收集器線程都可以與用戶線程一起 工作，所以，從總體上來說，CMS收集器的內存回收過程是與用戶線程一起併發執行的。通 過圖3-10可以比較清楚地看到CMS收集器的運作步驟中併發和需要停頓的時間。