JVM虚拟机--CMS垃圾回收器

CMS垃圾回收器

第一个并发收集器 基于标记-清除 老年代收集器

1：初始标记

将于GC Roots直接关联的对象标记，用户线程需要阻塞

2：并发标记

与用户线程并发执行

3：重新标记

对并发标记过程中存活但被标记未垃圾的对象再次扫描，用户线程需要阻塞

4：并发清除

将标记为垃圾的对象清除，与用户线程并发执行

优点：

由于在整个过程中耗时最长的并发标记和并发清除都是和用户线程并发执行，所以总体来说整个GC过程都是和用户线程并发执行的。减少了用户在GC过程中的停顿时间

缺点：

1:由于CMS采用增量更新解决可行性分析中出现的错标情况，所以会产生浮动垃圾，有可能出现“Concurrent Mode Failure”失败而进行一次完全STW的Full GC产生。且在清除阶段与用户线程并发执行，所以会产生新的垃圾对象。
所以收集器不能等到老年代几乎完全填满再进行GC，需要预留一定的空间。
需要设置参数决定预留空间的大小，如果设置空间过小，无法为新产生的对象分配内存空间，出现Concurrent Mode Failure，不得不启动后备方案，停顿用户线程，启用Serial Old收集器来重新进行老年代垃圾收集，这样效率就更低了，停顿的时间反而更长了。

2:基于标记-清除算法会产生大量空间碎片，可能会出现无法为大对象分配内存空间。

3：对处理器资源敏感，在并发阶段会占用处理器资源，降低总吞吐量，应用程序变慢，默认启动回收线程数为（处理器核心数量+3）/4，当核心数较多时，影响较小，当核心数少时，影响较大。

总结：CMS的使用非常复杂，需要根据情况调整大量的参数，使用起来非常不稳定，官方已经声明为不推荐使用。

最后还有一个疑问？

就是在并发清楚阶段，如果产生新的垃圾，或者是对象被重新引用而又活过来了，这个CMS是如何处理的呢，知道的朋友可以私信教教我呢