JDK8垃圾回收调优指南--(7)并发收集器

原文：Java Platform, Standard Edition HotSpot Virtual Machine Garbage Collection Tuning Guide--The Mostly Concurrent Collectors。

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

• G1
• G1调优