CMS垃圾收集器单项记录

CMS垃圾收集器学习记录

0、简介

​ 本篇主要是记录下CMS垃圾收集器的学习结果，由于记性差，所以想通过记录的方式加深印象，梳理思路。

1、CMS垃圾收集器简介

​ CMS收集器是一款追求最短回收停顿时间的收集器，互联网网站或者B/S系统的服务很重视服务的响应速度，希望系统停顿时间最短，给用户带来最好的体验。CMS收集器就非常适合这类应用的需求。

​ 从名字可以看出，CMS是基于标记–清除算法实现的，主要有以下几个阶段：

• 初始标记（Stop The World）
• 并发标记
• 重新标记（Stop The World）
• 并发清除

初始标记：初始标记仅仅是标记以下GC Roots能直接关联到的对象，速度很快，但是需要程序停顿

并发标记：进行GC Roots Tracing 的过程，由于是和应用程序并发执行，所以稍微复杂，用时稍长

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

并发清除：这个阶段时间稍长，不用全局停顿，和用户程序一起运行，进行垃圾清理。

CMS是一款并发收集、低停顿的垃圾收集器。但是有以下三个明显缺点：

• CMS收集器对CPU资源非常敏感，由于CMS垃圾回收线程是独占CPU资源的，当CMS收集线程占用一部分CPU资源后会导致用户线程变慢。CMS默认启动的回收线程数量为(CPU数量+3)/4，当CPU数量为4个以上时候，并发回收线程数量不超过CPU资源的25%，但是当CPU数量小于4，比如2个时候，那么CMS对用户程序的影响就非常大。虚拟机为这种情况提供了一种称为"增量式并发收集器"（i-CMS），这种收集器不独占CPU资源，而是在并发标记和并发清除阶段和用户线程交替执行，这样虽然加长了两个收集阶段的时间，但是对用户的影响就比较少了
• CMS收集器无法处理浮动垃圾，可能出现**“Concurrent Mode Failure”** 失败而导致一次Full GC的产生，由于CMS并发清理阶段是和用户线程一起运行的，伴随着程序运行自然就会有新的垃圾产生，由于这个阶段产生的垃圾在标记过程之后，CMS无法在本次收集中处理它们，得等到下次GC时候才能清理，这些垃圾就叫浮动垃圾。由于在垃圾收集阶段用户线程还在运行，即还需要预留内存空间给用户线程使用，同时由于垃圾收集线程也需要占用内存，所以CMS不想其他垃圾收集器等到老年代几乎占满才进行垃圾收集。在默认情况下CMS收集器在老年代使用了68%的空间后就会被激活，这个参数可以通过**-XX:CMSInitiatingOccupancyFraction**的值来调节。要是CMS运行期间预留的内存无法满足程序需要，就会出现一次"Concurrent Mode Failure"失败，这个时候虚拟机会临时启用Serial Old进行老年代垃圾收集，这样的停顿时间就更长，所以说-XX:CMSInitiatingOccupancyFraction设置的太高会导致大量"Concurrent Mode Failure"失败，性能反而降低。所以说当应用老年代增长不是太快的时候才可以适当调高-XX:CMSInitiatingOccupancyFraction的值
• CMS是基于"标记-擦除"算法的，这个意味着垃圾收集结束后会产生大量内存碎片，空间碎片过多会给大对象分配造成麻烦，往往出现老年代还有很大的空间剩余，但是无法找到足够大的连续空间分配当前对象，不得不提前触发一次Full GC ，为了解决这个问题，CMS收集器提供了一个参数**-XX:+UseCMSCompactAtFullCollection开关参数，这个参数的意思是当执行完Full GC后顺便执行一次内存碎片整理，但是整理过程不能并发，使得GC停顿时间边长。还有另外一个虚拟机参数-XX:CMSFullGCsBeforeCompaction** ，这个参数表示执行多少次不带内存整理的Full GC后伴随着执行一次带内存整理的Full GC。

总结

​ 由介绍可以看出CMS是一款追求低停顿的垃圾收集器，但是虚拟机参数不合适或者CPU个数较小的情况下反而会使停顿时间变长，所以使用的时候需要实测调整参数再用。

涉及的虚拟机参数：

-XX:CMSInitiatingOccupancyFraction: CMS收集器下设置老年代内存占用超过多少时候触发Full GC

-XX:+UseCMSCompactAtFullCollection:CMS收集器下执行完Full GC伴随一次内存整理

-XX:CMSFullGCsBeforeCompact:CMS收集器下，多少次无内存整理的Full GC后，执行一次带内存整理的

参考《深入理解Java虚拟机第二版》