并发GC 之所以称为“并发”，是因为它的很多操作 与 应用程序的业务 是并发关系。
注意是“很多操作”而不是“所有操作”。所以提到它时会附带“Mostly”，即“Mostly Concurrent Collectors”。
Hotspot JDK 8 中 有 2个 并发GC：
-
CMS（Concurrent Mark Sweep Collector）： 适用于需要更短的GC暂停时间，且可以忍受处理器资源被GC共享 的应用程序。
（其实这是 并发GC 的一般特征，G1 也是这样的。）
-
G1（Garbage-First Garbage Collector）： 适用于大内存多处理器的机器。它可以在实现高吞吐量目标的同时，高概率满足暂停时间目标。
并发的开销
并发GC 以处理器资源为代价换取更短的 Major GC 暂停时间（这些处理器资源本可以用于执行应用程序的业务）。
最明显的开销就是在 GC 并发操作期间，它会用到 一个或多个 处理器。
在有 N 个 处理器的系统上，这些并发操作会使用 K/N 个处理器，其中 1<= K <=ceiling{N/4} 。（注意：K 的精度选择和边界可能会更改。）
除了在并发阶段使用处理器外，“启用并发性”也会产生额外的开销。
因此，虽然使用 并发GC 后暂停时间会短得多，但的吞吐量比 其它GC 稍低。
在多处理器机器上，GC并发阶段期间，业务线程仍然有可用的处理器，所以 并发GC 不会“暂停”应用程序。这个特性最终会表现为“较短的暂停”。但是，再提一次，应用程序可用的处理器资源会减少，而且处理速度会降低，特别是在应用程序业务最大限度地使用所有处理器的情况下。《Concurrent Mark Sweep （CMS）》中的“并发模式失败”讨论了这种“缩减”的潜在限制。
因为并发阶段至少要用到一个处理器，所以 并发GC 在单处理器机器上通常没有任何好处。
然而 CMS（不是G1）有一个特殊的模式，可以在只有一个或两个处理器的系统上实现低暂停。
参见《Concurrent Mark Sweep （CMS）》中的“增量模式”。
此特性在 Java SE 8 中被标记为“已废弃”，并且可能在后续的主干版本中被删除。
其它参考文献
