JDK8中Hotspot虛擬機有2種常用的併發收集器：
- Concurrent Mark Sweep (CMS) Collector：此收集器適用於那些希望更短的GC停頓時間並能夠與垃圾收集共享處理器資源的應用程序。
- Garbage-First Garbage Collector：這種服務器風格的收集器適用於內存較大的多處理器機器。在實現高吞吐量的同時，又能大概率地滿足GC停頓時間目標。
Overhead of Concurrency
大多數併發收集器用處理器資源交換更短的'major collection'停頓時間（否則應用程序可以使用這些資源）。最明顯的開銷是在回收的併發階段中使用一個或多個處理器。在一個N處理器系統上，回收的併發階段將使用K/N個可用處理器，其中1<=K<=上限{N/4}（注意，K的精確選擇和界限可能會發生變化）。除了在併發階段使用處理器之外，啓用併發也會造成額外的開銷。因此，雖然併發收集器的GC停頓時間通常要短得多，但應用程序吞吐量也往往比其他收集器的吞吐量略低。
在具有多個處理器的計算機上，應用線程可以在回收併發階段使用處理器，因此併發收集器線程不會“暫停”應用。這通常會導致更短的GC停頓，但是應用可用的處理器資源也會更少，並且應該預期會出現一些減速，特別是當應用程序最大限度地使用所有處理器時。隨着N的增加，由於併發垃圾回收對處理器資源造成的影響會變得更小，併發回收的優勢更加明顯。CMS中的併發模式故障中討論了這種擴展的潛在限制。
因爲在回收的併發階段至少使用了一個處理器，所以併發收集器通常不會在單處理器（單內核）機器上提供任何好處。然而，CMS（非G1）有一個單獨的模式，可以在只有一個或兩個處理器的系統上實現低（GC）停頓。詳見Incremental Mode。這個特性在Java SE 8中已經被棄用，可能在稍後的主要版本中被刪除。
Additional References