HotSpot JVM 的并发标记清理收集器 (CMS 收集器) 的主要目标就是：低应用停顿时间。该目标对于大多数交互式应用很重要，比如 web 应用。在我们看一下有关 JVM 的参数之前, 让我们简要回顾 CMS 收集器的操作和使用它时可能出现的主要挑战。
就像吞吐量收集器 (参见本系列的第 6 部分),CMS 收集器处理老年代的对象, 然而其操作要复杂得多。吞吐量收集器总是暂停应用程序线程，并且可能是相当长的一段时间，然而这能够使该算法安全地忽略应用程序。相比之下，CMS 收集器被设计成在大多数时间能与应用程序线程并行执行，仅仅会有一点 (短暂的) 停顿时间。GC 与应用程序并行的缺点就是，可能会出现各种同步和数据不一致的问题。为了实现安全且正确的并发执行，CMS 收集器的 GC 周期被分为了好几个连续的阶段。
CMS 收集器的过程
CMS 收集器的 GC 周期由 6 个阶段组成。其中 4 个阶段 (名字以 Concurrent 开始的) 与实际的应用程序是并发执行的，而其他 2 个阶段需要暂停应用程序线程。
- 初始标记：为了收集应用程序的对象引用需要暂停应用程序线程，该阶段完成后，应用程序线程再次启动。
- 并发标记：从第一阶段收集到的对象引用开始，遍历所有其他的对象引用。
- 并发预清理：改变当运行第二阶段时，由应用程序线程产生的对象引用，以更新第二阶段的结果。
- 重标记：由于第三阶段是并发的，对象引用可能会发生进一步改变。因此，应用程序线程会再一次被暂停以更新这些变化，并且在进行实际的清理之前确保一个正确的对象引用视图。这一阶段十分重要，因为必须避免收集到仍被引用的对象。
- 并发清理：所有不再被应用的对象将从堆里清除掉。
- 并发重置：收集器做一些收尾的工作，以便下一次 GC 周期能有一个干净的状态。
一个常见的误解是, CMS 收集器运行是完全与应用程序并发的。我们已经看到，事实并非如此，即使 “stop-the-world” 阶段相对于并发阶段的时间很短。
应该指出，尽管 CMS 收集器为老年代垃圾回收提供了几乎完全并发的解决方案，然而年轻代仍然通过 “stop-the-world” 方法来进行收集。对于交互式应用，停顿也是可接受的，背后的原理是年轻带的垃圾回收时间通常是相当短的。
挑战
当我们在真实的应用中使用 CMS 收集器时，我们会面临两个主要的挑战，可能需要进行调优：
- 堆碎片
- 对象分配率高
堆碎片是有可能的，不像吞吐量收集器，CMS 收集器并没有任何碎片整理的机制。因此，应用程序有可能出现这样的情形，即使总的堆大小远没有耗尽，但却不能分配对象——仅仅是因为没有足够连续的空间完全容纳对象。当这种事发生后，并发算法不会帮上任何忙，因此，万不得已 JVM 会触发 Full GC。回想一下，Full GC 将运行吞吐量收集器的算法，从而解决碎片问题——但却暂停了应用程序线程。因此尽管 CMS 收集器带来完全的并发性，但仍然有可能发生长时间的 “stop-the-world” 的风险。这是 “设计”，而不能避免的——我们只能通过调优收集器来它的可能性。想要 100% 保证避免”stop-the-world”，对于交互式应用是有问题的。
第二个挑战就是应用的对象分配率高。如果获取对象实例的频率高于收集器清除堆里死对象的频率，并发算法将再次失败。从某种程度上说，老年代将没有足够的可用空间来容纳一个从年轻代提升过来的对象。这种情况被称为 “并发模式失败”，并且 JVM 会执行堆碎片整理：触发 Full GC。
当这些情形之一出现在实践中时 (经常会出现在生产系统中)，经常被证实是老年代有大量不必要的对象。一个可行的办法就是增加年轻代的堆大小，以防止年轻代短生命的对象提前进入老年代。另一个办法就似乎利用分析器，快照运行系统的堆转储，并且分析过度的对象分配，找出这些对象，最终减少这些对象的申请。
下面我看看大多数与 CMS 收集器调优相关的 JVM 标志参数。
-XX：+UseConcMarkSweepGC
该标志首先是激活 CMS 收集器。默认 HotSpot JVM 使用的是并行收集器。
-XX：UseParNewGC
当使用 CMS 收集器时，该标志激活年轻代使用多线程并行执行垃圾回收。这令人很惊讶，我们不能简单在并行收集器中重用 - XX：UserParNewGC 标志，因为概念上年轻代用的算法是一样的。然而，对于 CMS 收集器，年轻代 GC 算法和老年代 GC 算法是不同的，因此年轻代 GC 有两种不同的实现，并且是两个不同的标志。
注意最新的 JVM 版本，当使用 - XX：+UseConcMarkSweepGC 时，-XX：UseParNewGC 会自动开启。因此，如果年轻代的并行 GC 不想开启，可以通过设置 - XX：-UseParNewGC 来关掉。
-XX：+CMSConcurrentMTEnabled
当该标志被启用时，并发的 CMS 阶段将以多线程执行 (因此，多个 GC 线程会与所有的应用程序线程并行工作)。该标志已经默认开启，如果顺序执行更好，这取决于所使用的硬件，多线程执行可以通过 - XX：-CMSConcurremntMTEnabled 禁用。
-XX：ConcGCThreads
标志 - XX：ConcGCThreads=
如果还标志未设置，JVM 会根据并行收集器中的 - XX：ParallelGCThreads 参数的值来计算出默认的并行 CMS 线程数。该公式是 ConcGCThreads = (ParallelGCThreads + 3)/4。因此，对于 CMS 收集器， -XX:ParallelGCThreads标志不仅影响“stop-the-world”垃圾收集阶段，还影响并发阶段。
总之，有不少方法可以配置 CMS 收集器的多线程执行。正是由于这个原因, 建议第一次运行 CMS 收集器时使用其默认设置, 然后如果需要调优再进行测试。只有在生产系统中测量 (或类生产测试系统) 发现应用程序的暂停时间的目标没有达到 , 就可以通过这些标志应该进行 GC 调优。
-XX:CMSInitiatingOccupancyFraction
当堆满之后，并行收集器便开始进行垃圾收集，例如，当没有足够的空间来容纳新分配或提升的对象。对于 CMS 收集器，长时间等待是不可取的，因为在并发垃圾收集期间应用持续在运行 (并且分配对象)。因此，为了在应用程序使用完内存之前完成垃圾收集周期，CMS 收集器要比并行收集器更先启动。
因为不同的应用会有不同对象分配模式，JVM 会收集实际的对象分配 (和释放) 的运行时数据，并且分析这些数据，来决定什么时候启动一次 CMS 垃圾收集周期。为了引导这一过程， JVM 会在一开始执行 CMS 周期前作一些线索查找。该线索由 -XX:CMSInitiatingOccupancyFraction=
-XX：+UseCMSInitiatingOccupancyOnly
我们用 -XX+UseCMSInitiatingOccupancyOnly 标志来命令 JVM 不基于运行时收集的数据来启动 CMS 垃圾收集周期。而是，当该标志被开启时，JVM 通过 CMSInitiatingOccupancyFraction 的值进行每一次 CMS 收集，而不仅仅是第一次。然而，请记住大多数情况下，JVM 比我们自己能作出更好的垃圾收集决策。因此，只有当我们充足的理由 (比如测试) 并且对应用程序产生的对象的生命周期有深刻的认知时，才应该使用该标志。
-XX:+CMSClassUnloadingEnabled
相对于并行收集器，CMS 收集器默认不会对永久代进行垃圾回收。如果希望对永久代进行垃圾回收，可用设置标志 -XX:+CMSClassUnloadingEnabled。在早期 JVM 版本中，要求设置额外的标志 - XX:+CMSPermGenSweepingEnabled。注意，即使没有设置这个标志，一旦永久代耗尽空间也会尝试进行垃圾回收，但是收集不会是并行的，而再一次进行 Full GC。
-XX:+CMSIncrementalMode