一文带你了解CMS收集器：并发低停顿收集器

一、工作流程

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。互联网网站或者基于B/S系统（B/S系统是指Browser/Server系统，也就是基于浏览器和服务器的系统架构）的服务端应用通常会关注服务的响应速度，希望系统停顿的时间尽可能短。CMS收集器就非常符合此类应用的需求。

CMS收集器基于标记-清除算法实现，包括四个步骤：

1）初始标记

2）并发标记

3）重新标记

4）并发清除

其中初始标记、重新标记这两个步骤仍然需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快；并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行；而重新标记阶段则是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，但也远比并发标记阶段的时间短；最后是并发清除阶段，清理删除掉标记阶段判断的已经死亡的对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

由于再整个过程中耗时最长的并发标记和并发清除阶段中，垃圾收集器线程都可以与用户线程一起工作，所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的·。

二、性能分析

优点：并发收集、低停顿。

缺点：

1、CMS收集器对处理器资源非常敏感。

事实上，面向并发设计的程序都对处理器资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程（或者说处理器的计算能力）而导致应用程序变慢，降低总吞吐量。

CMS默认启动的回收线程数是（处理器核心数量+3）/4，也就是说，如果处理器核心数在四个或以上，并发回收时垃圾收集线程只占用不超过25%的处理器运算资源，并且会随着处理器核心数量增加而下降。但是当处理器核心数量不足四个时，CMS对用户程序的影响就可能变得很大。

为了缓解这种情况，虚拟机提供了一种“增量式并发收集器”的CMS收集器变种，类似于单核操作系统靠抢占式多任务来模拟多核并行多任务的思想。在并发标记、清理的时候让收集器线程、用户线程交替运行，尽量减少垃圾收集线程的独占资源时间。这样整个垃圾收集时间更长，但对用户程序的影响就会少一些。实践证明增量式CMS收集器效果很一般，JDK 9发布后i-CMS模式被完全废弃。

2、会产生大量空间碎片。

基于“标记-清除”算法实现的收集器，收集结束时会产生大量空间碎片。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次Full GC的情况。

为了解决这个问题，CMS收集器提供了一个-XX：+UseCMS-CompactAtFullCollection开关参数（默认是开启的，此参数从JDK 9开始废弃），用于在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，（在Shenandoah和ZGC出现前）是无法并发的。这样空间碎片问题是解决了，但停顿时间又会变长，因此虚拟机设计者们还提供了另外一个参数-XX：CMSFullGCsBefore-Compaction（此参数从JDK 9开始废弃），这个参数的作用是要求CMS收集器在执行过若干次（数量由参数值决定）不整理空间的Full GC之后，下一次进入Full GC前会先进行碎片整理（默认值为0，表示每次进入Full GC时都进行碎片整理）。

3、由于CMS收集器无法处理“浮动垃圾”（Floating Garbage），有可能出现“Con-current Mode Failure”失败进而导致另一次完全“Stop The World”的Full GC的产生。

在CMS（Concurrent Mark Sweep）垃圾收集器中，它使用了一种并发标记和清除的算法来减少垃圾收集对应用程序的停顿时间。然而，CMS收集器无法处理"浮动垃圾"（Floating Garbage），也就是在并发标记阶段开始后，应用程序产生的新垃圾对象。当CMS收集器在并发标记阶段执行时，应用程序仍然在运行并产生新的垃圾对象。这些新的垃圾对象无法被并发标记阶段捕获到。如果在并发标记阶段结束之前，垃圾对象的数量变得过多，超过了CMS收集器的阈值，那么就会发生"Con-current Mode Failure"（并发模式失败）。 "Con-current Mode Failure"表示CMS收集器无法在预期的时间内完成垃圾收集，因为并发标记和清除的过程无法继续执行。当发生"Con-current Mode Failure"时，CMS收集器会触发一次完全的"Stop The World"的Full GC，即执行一次完全的垃圾收集过程。 Full GC会导致较长的停顿时间，因为它需要暂停应用程序的执行，以便对整个Java堆进行垃圾回收。这段停顿时间可能会对应用程序的响应性产生负面影响。

4、同样也是由于在垃圾收集阶段用户线程还需要持续运行，那就还需要预留足够内存空间提供给用户线程使用，因此CMS收集器不能像其他收集器那样等待到老年代几乎完全被填满了再进行收集，必须预留一部分空间供并发收集时的程序运作使用。

在JDK 5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果在实际应用中老年代增长并不是太快，可以适当调高参数-XX：CMSInitiatingOccu-pancyFraction的值来提高CMS的触发百分比，降低内存回收频率，获取更好的性能。到了JDK 6时，CMS收集器的启动阈值就已经默认提升至92%。但这又会更容易面临另一种风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次“并发失败”（Concurrent Mode Failure），这时候虚拟机将不得不启动后备预案：冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。所以参数-XX：CMSInitiatingOccupancyFraction设置得太高将会很容易导致大量的并发失败产生，性能反而降低，用户应在生产环境中根据实际应用情况来权衡设置。

三、知识补充

在Java虚拟机（JVM）中，Full GC（Full Garbage Collection）是指对整个Java堆进行垃圾回收的过程。Full GC会尽可能回收所有不再使用的对象，包括年轻代和老年代中的对象。 Full GC通常会涉及以下几个步骤：

停止应用程序的执行：Full GC需要停止应用程序的执行，以便进行垃圾回收操作。这个过程可能会导致一段时间的应用程序暂停，也就是停顿时间（Pause Time）。
标记阶段（Marking Phase）：Full GC会标记所有活动对象，即从根对象开始，递归遍历所有可达对象，并将其标记为活动对象。
清除阶段（Sweeping Phase）：Full GC会清除所有未标记（即不可达）的对象，释放它们所占用的内存空间。
压缩阶段（Compaction Phase）：Full GC会对内存空间进行整理和压缩，以减少碎片化，使得内存空间得到更好的利用。 Full GC通常在以下情况触发：
当年轻代无法容纳新的对象时，会触发一次Minor GC（部分垃圾回收）和一次Full GC（完全垃圾回收）。
当老年代空间不足时，会触发一次Full GC。
当显式调用System.gc()方法时，会触发一次Full GC，但这只是建议垃圾回收器执行回收操作，并不能保证立即执行。 Full GC的频率和性能会对应用程序的性能产生一定的影响，较长的停顿时间可能会导致应用程序的响应性下降。因此，在开发和调优过程中，需要综合考虑内存分配、垃圾回收算法和堆大小等因素，以减少Full GC的频率和停顿时间，提升应用程序的性能。