CMS垃圾收集器（基于标记清除算法）

本文主要是介绍CMS垃圾收集器（基于标记清除算法），对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

特点：

CMS是一种以获取回收停顿时间为目标的收集器。

多用于Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上。

过程：

初始标记：（stop the world）

只是标记GCroots能直接关联到的对象，速度很快。

并发标记：

从GCroots的直接关联对象开始遍历整个对象图的过程，虽然时间长但是不需要停止用户线程

重新标记：（stop the world）

修正并发标记时，用户操作导致标记变动的那一部分对象，虽然比初始标记常但是比并发标记短

并发清除：

清理掉已经被判定死亡的对象

缺点：

1、CMS对处理器资源敏感，

虽然在并发阶段会导致用户线程停顿，但却会因为占用了线程而导致程序变慢。CMS默认启动的线程数是（处理器核心+3）/4，可以看出处理器核心大于4个的时候占用才开始变低。

2、无法处理“浮动垃圾“

在CMS的并发标记和并发清理阶 段，用户线程是还在继续运行的，程序在运行自然就还会伴随有新的垃圾对象不断产生，但这一部分 垃圾对象是出现在标记过程结束以后，CMS无法在当次收集中处理掉它们，只好留待下一次垃圾收集时再清理掉。这一部分垃圾就称为“浮动垃圾”。

3、空间碎片

由于基于标记清除所以就导致会有大量的空间碎片产生，空间 碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找 到足够大的连续空间来分配当前对象，而不得不提前触发一次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时都进行碎片整理）。

这篇关于CMS垃圾收集器（基于标记清除算法）的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！