CMS收集器

最新推荐文章于 2024-08-02 17:43:22 发布

至学者

最新推荐文章于 2024-08-02 17:43:22 发布

阅读量311

点赞数 2

分类专栏： JVM 文章标签： CMS 标记清除 Full GC Serial Old Stop The World

本文链接：https://blog.csdn.net/calm_encode/article/details/108750342

版权

JVM 专栏收录该内容

26 篇文章 0 订阅

订阅专栏

一概述

CMS(Concurrent Mark Sweep)收集器是一种以获取最短回收停顿时间为目标的收集器。所以它非常适用于系统要求比较快的相应速度且系统停顿时间尽可能短的应用。CMS收集器——并发标记清除收集器，它是基于标记—清除算法实现的。

二 CMS收集器处理的步骤

初始标记（CMS initial mark）
并发标记（CMS concurrent mark）
重新标记（CMS remark）
并发清除（CMS concurrent sweep）

上述步骤中的初始标记，重新标记这两个步骤仍然需要"Stop The World"【Stop The World简单的描述就是：当前操作需要全程暂停用户应用程序才能进行操作的停顿状态】。

初始标记仅仅只是很快速的标记一下GC Roots能直接关联的对象，速度很快。

并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，该过程耗时比较长但是并不需要停顿用户线程，而且用户线程可以同垃圾收集线程一起并发运行。

重新标记阶段则是为了修正并发标记期间，因用户线程继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间通常会比初始标记阶段稍长一些，当时会比并发标记的时间短；

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

CMS是一款优秀的收集器，它最主要的优点为并发收集地停顿。一些文档中CMS称为"并发低停顿收集器"（Concurrent Low Pause Collector）。CMS收集器是HotSpot虚拟机中追求低停顿的第一次成功尝试，但是并未达到完美的程度。

三 CMS收集器的缺点

缺点一：CMS收集器对处理器资源非常敏感。事实上，面向并发设计的程序都对处理器资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但却会占用了一部分线程（或者说处理器的计算能力）而导致应用程序变慢，降低总吞吐量。CMS默认启动的回收线程数是（处理器核心数+3）/4，也就是说，如果处理器核心数在四个或以上，并发回收时垃圾收集线程只占用不超过25%的运算资源，并会随着处理器核心数的增加而降低。但是当处理器核心数量小于4时，CMS对用户程序的影响就可能变得很大。如果应用本来处理器负载就很高，还要分一半的运算能力执行收集器线程，就可能导致用户程序的执行速度忽然大幅度降低。为了缓解这种情况，虚拟机提供了一种为"增量式并发收集器"（Incremental Concurrent Mark Sweep/i-CMS）的CMS收集器的变种，所做的事情和以前单核处理器年代PC机操作系统靠抢占式多任务来模拟多核多任务的思想一样，是在并发标记，清理的时候让收集器线程，用户线程交替运行，尽量减少垃圾收集器的独占资源的时间，这样整个垃圾收集的过程会更长，但对用户程序的影响就会显得较少一些，这样使得速度变慢的时间更多了，但是速度下降的幅度没有那么明显。时间证明增量式的CMS收集器效果一般，从JDK7开始，i-CMS模式已经被声明为"deprecated"，即已经过时不再提倡用户使用，而在JDK9之后就将i-CMS模式被完全废弃。

简述为：存在垃圾回收线程和用户线程抢占系统资源的问题，使得处理用户线程和垃圾收集之间存在相互影响。

缺陷二：由于CMS收集器无法处理"浮动垃圾"（Floating Garbage），有可能出现"Concurrent Mode Failure"失败进而导致另一次完全"Stop The World"的Full GC的产生。在CMS的并发标记和并发清除阶段，用户线程是还在继续运行的，程序在运行自然就会伴随有新的垃圾对象不断产生，但这一部分垃圾对象是出现在标记过程以后，CMS无法在当次收集中处理掉它们，只好等待下一次垃圾收集时再清理掉。这一部分垃圾就称为"浮动垃圾"。同样也是由于在垃圾收集阶段用户线程还需要持续运行，那就还需要预留足够内存空间提供给用户线程使用，因此CMS收集器不能像其他收集器那样等待到老年底几乎完全被填满了再进行收集，必须预留一部分空间供并发收集时的程序运行使用。

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

在JDK6的时候，CMS收集器的启动阈值已经提升至92%，但这又会更容易面临另一种风险：如果CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次"并发失败"（Concurrent Mode Failure），这时候虚拟机讲不得不启动后备预案：冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集，当这样停顿时间就会很长。所以参数-XX：CMSInitiatingOccupancy设置的太高很容易导致大量并发并发失败产生，性能反而降低，用户应该在生产环境中根据实际应用情况来权衡设置。

简述为：存在"浮动垃圾"（Floating Garbage），在执行垃圾回收时需要预留空间给用户线程执行，当预留的空间无法满足程序分配新对象时，出现冻结用户线程，使用serial Old收集器对老年代的垃圾进行回收，导致用户线程停顿时间过长。

缺陷三：由于CMS是一款基于"标记-清除"算法实现的收集器，所以在垃圾回收时会又大量的碎片产生。空间碎片过多时，将会给大对象的分配带来很大麻烦。往往会出现老年代还有很多剩余空间，但是无法找到足够大的连续空间来非陪当前对象，而不得不提前触发一次Full GC的情况。为了解决这个问题，CMS收集器提供了一个-XX：+UseCMS-CompactAtFullCollection开关参数（默认为开启状态，在JDK9开始废弃），用于在CMS收集器不得不进行Full GC时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，在Shenandoah和ZGC出现之前是无法并发的。这样空间碎片问题是解决了，但是这样会导致停顿的时间变长，因此存在另一个参数-XX：CMSFullGCsBefore-Compaction(JDK9开始废弃)，这个参数的作用是要求CMS收集器在执行过若干次（数量为参数值）不整理空间Full GC之后，下一次进入Full GC前会先进行碎片整理（默认为0，标识每次进入Full GC时都进行碎片整理）。

简述为：由于使用"标记-清除"算法，导致垃圾回收之后存在很多内存碎片无法给大对象分配内存空间，所以会使用Full GC对内存进行整理，存在对象的移动，导致用户线程停顿等待时间变长。