本文部分摘自《深入理解 Java 虚拟机第三版》
概述
CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。由于大部分 Java 应用主要集中在互联网网站以及基于浏览器的 B/S 系统的服务端，这类应用通常会较为关注服务的响应速度，希望系统的停顿时间尽可能少，CMS 收集器就非常符合这类应用的需求
步骤
从名字可以知道，CMS 收集器是基于标记 - 清除算法实现的，它的运作过程分为四个步骤：
-
初始标记（CMS initial mark）
仅仅只是标记一下 GC Roots 能直接关联到的对象，速度很快，需要 Stop The World
-
并发标记（CMS concurrent mark）
就是从 GC Roots 的直接关联对象开始遍历整个对象图的过程，耗时较长，但不需要停顿用户线程，可与垃圾收集器线程一起并发执行
-
重新标记（CMS remark）
该阶段是为了修正并发标记期间，因用户程序运作而导致标记产生变动的那一部分对象的标记记录，这个阶段需要 Stop The World，而且停顿时间通常比初始阶段稍长一些，但也远比并发标记阶段的时间短
-
并发清除（CMS concurrent sweep）
清理删除掉标记阶段判断已经死亡的对象，由于不需要移动存活对象，所有这个阶段可以和用户线程并发执行
由于整个过程中耗时最长的是并发标记和并发清除阶段，而这两个阶段都可以和用户线程并发执行，所以从总体上看，CMS 收集器内存回收过程是与用户线程一起并发执行的
CMS 收集器的不足
CMS 收集器的主要优点就是：并发收集、低停顿，因此也称 CMS 收集器为并发低停顿收集器。但 CMS 还远未达到完美的程度，它至少有以下四个明显的缺点：
-
对处理器资源非常敏感
在并发阶段，CMS 虽然不会导致用户线程停顿，但却会因为占用了一部分线程（或者说是处理器的计算能力）而导致应用程序变慢，降低吞吐量。处理器核心数在四个或以上那还好，如果不足四个，CMS 会占用将近一半的运算能力去执行收集器线程，这将导致用户程序的执行效率大幅降低
-
无法处理浮动垃圾
在 CMS 的并发标记和并发清理阶段，由于用户线程继续运行，因此有可能会有新的垃圾对象产生。但这一部分垃圾对象是出现在标记结束之后，CMS 无法在当次收集中处理掉它们，只能留待下一次垃圾收集在清理，这一部分垃圾就称为浮动垃圾
-
可能会出现并发失败
同样也是由于垃圾收集阶段用户线程还需持续执行，那就必须预留足够的内存空间供用户线程使用。因此 CMS 收集器不能像其他收集器那样等老年代几乎完全填满再进行收集，而必须预留一部分空间供并发收集时的程序运作使用，这部分空间的大小可以通过 -XX:CMSInitiatingOccu-pancyFraction 参数来设置。如果 CMS 运行期间预留的内存无法满足程序分配对象的需要，就会出现一次并发失败，这时虚拟机不得不启用预备方案：冻结用户线程，临时启用 Serial Old 收集器来重新进行老年代的垃圾收集，导致 Stop The World
-
大量空间碎片的产生
CMS 是一款基于标记 - 清除算法实现的收集器，这也意味着收集结束时会产生大量空间碎片。为了解决这个问题，CMS 收集器提供了一个 -XX:+UseCMS-CompactAtFullCollection 开关参数，用于在收集结束后做一次内存整理，以及 -XX:CMSFullGCsBefore-Compaction 参数，要求 CMS 收集器在执行若干次不整理空间的 Full GC 之后，下一次 Full GC 前先做一次碎片整理