CMS（concurrent Mark Sweep）收集器，以获取最短回收停顿时间（Stop The World）为目标，这符合多数应用于类似B/S系统的服务端这类关注响应速度的应用。
一、收集过程
CMS是基于“标记-清除”算法实现的，整个过程包括四个步骤：
- 初始标记（CMS initial mark）
- 并发标记（CMS concurrent mark）
- 重新标记（CMS remark）
- 并发清除（CMS concurrent sweep）
其中并发标记以及重新标记这两个步骤仍然需要“Stop The World”。
初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；
并发标记就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时很长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；
而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍微长一些，但也远比并发标记阶段的时间短；
最后是并发清除阶段，清除删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程并发进行的。
二、缺点
- CMS收集器对处理器资源非常敏感。事实上，面向并发设计的程序都对处理器资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程（或者说处理器的计算能力）而导致应用线程变慢，降低总吞吐量。
- 由于CMS收集器无法处理“浮动垃圾”（Floating Garbage），有可能出现”Concurrent Mode Failure“失败进而导致另一次完全”Stop The World“的Full GC的产生。
- 浮动垃圾：并发清理阶段用户线程还在运行，这段时间内就可能产生新的垃圾，新的垃圾在此次GC无法清除，只能等到下次清理。这些垃圾有个专业的名词：浮动垃圾；
- CMS是一款基于”标记-清除“的算法实现的垃圾收集器，这意味着收集结束时会有大量的空间碎片产生。空间碎片过多时，将会给大对象的分配带来很大的麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象。
文章来源：《深入理解Java虚拟机》-周志明