CMS收集器

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

一、CMS收集器

CMS收集器（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。从名字（包含“Mark Sweep”）上就可以看出CMS收集器是基于标记-清除算法实现的。CMS是一款优秀的收集器，它最主要的优点在名字上已经体现出来：并发收集、低停顿，一些官 方公开文档里面也称之为“并发低停顿收集器”

二、运作过程

1、初始标记

初始标记仅仅只是标记一下GC Roots能直接关联到的对象，此过程需要“Stop The World”，停止用户进程。不过这个阶段非常快。

2、并发标记

并发标记就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但不需要停顿用户线程

3、重新标记

重新标记阶段是为了修正并发标记期间，因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录。这个阶段也会停顿用户线程，比初始标记时间要长，但远比并发标记阶段时间要短。

4、并发清除

段，清理删除掉标记阶段判断的已经死亡的 对象，由于不需要移动存活对象，所以这个阶段也是可以与用户线程同时并发的。

二、CMS 收集器的缺陷

1、对处理器资源敏感
面向并发设计的程序都会对处理器资源敏感。在并发阶段虽然不会停顿用户线程，但是他还是会占用处理器的计算能力，导致其他应用程序变慢，降低总吞吐量。

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

2、无法处理浮动垃圾
浮动垃圾：并发标记和并发清理阶段用户线程 还在继续运行，自然不断伴随新的垃圾对象产生，这些产生的垃圾对象只能在下一次垃圾收集时清楚掉。

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

在JDK 5的默认设置下，CMS收集器当老年代使用了68%的空间后就会被激活，这是一个偏保守的设置，如果 在实际应用中老年代增长并不是太快，可以适当调高参数**-XX：CMSInitiatingOccu-pancyFraction**的值 来提高CMS的触发百分比，降低内存回收频率，获取更好的性能。到了JDK 6时，CMS收集器的启动 阈值就已经默认提升至92%。

CMS触发百分比阈值太高的话会容易出现预留内存不够分配的情况，会出现“并发失败”（Concurrent Mode Failure）这时虚拟机启动后备方案：冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集。就会产生“Stop The World”

3、产生大量空间碎片
CMS是基于“标记-清楚”算法实现的，这就意味着收集结束会产生大量的空间碎片。

这样就会造成明明老年代有很大的空间，但却无法提供足够大的来连续的空间来分配对象。不得不提前触发一次Full GC。

为了解决这个问题， CMS收集器提供了一个-XX：+UseCMS-CompactAtFullCollection开关参数（默认是开启的，此参数从 JDK 9开始废弃），用于在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程，由于这个 内存整理必须移动存活对象。

此虚拟机设计者们还提供了另外一个参数-XX：CMSFullGCsBefore- Compaction（此参数从JDK 9开始废弃），这个参数的作用是要求CMS收集器在执行过若干次（数量 由参数值决定）不整理空间的Full GC之后，下一次进入Full GC前会先进行碎片整理（默认值为0，表 示每次进入Full GC时都进行碎片整理）。