CMS收集器,哪些垃圾回收器可以搭配CMS使用

文章目录 GC步骤初始标记并发标记并发预处理重新标记并发清除 CMS的缺点总结：
垃圾收集器分为年轻代和老年代。


CMS全程为Concurrent Mark Sweep，即并发标记清除，对比以上的收集器，最大的区别在于并发：在GC线程工作的时候，用户线程不会完全停止，用户线程在部分场景下与GC线程一起并发执行。但是，无论是什么垃圾收集器，Stop the world是一定无法避免的。CMS只是在部分的GC场景下可以让GC线程与用户线程并发执行。

CMS的涉及目的是为了避免【老年代GC】出现长时间的卡顿(stop the word)。

CMS主要是实现了标记清除垃圾回收算法，可分为5个步骤：

初始标记会标记GCRoots直接关联的对象以及年轻代指向老年代的对象，初始标记这个过程会发生Stop the word。但是这个阶段的速度很快，因为没有向下追溯，即只标记一层。

这个过程不会停止用户线程(即不会发生stop the world)，这一阶段主要是GC Roots向下追溯，标记所有可达的对象，该阶段比较耗时，因为需要追溯。

这个阶段主要目的就是【减少下一阶段重新标记所消耗的时间】，因为下一阶段重新标记需要Stop the World.

并发标记阶段由于用户线程是没有被挂起的，所以对象有可能是发生变化的。可能有些对象，从潇洒的小懒猪代晋升到了老年代；可能有些对象，直接被分配到了老年代(大对象)。可能老年代或者潇洒的小懒猪代的对象引用发生了变化…
解决该问题就是——针对老年代的对象，可以借助类card table的存储，将老年代对象发生变化所对应的卡页标记为dirty.

所以并发预处理这个阶段会扫描可能由于并发标记时导致老年代发生变化的对象，会再扫描一边标记为dirty的卡页。

对于潇洒的小懒猪代的对象，还需要遍历潇洒的小懒猪代在并发标记过程中有没有对象引用了老年代。JVM提供了很多参数，可能在这个过程中触发一次minor GC（触发GC意味着可以更少地遍历潇洒的小懒猪代的对象）

该阶段你会Stop the world，这里停顿的时间很大程度上取决于并发预处理阶段

该阶段不会发生stop the world，用户线程一边执行，GC线程一边在回收不可达对象。这个过程可能存在用户线程在不断产生垃圾，但也只能留到下一次GC进行处理，这些垃圾又称为"浮动垃圾"。

全部结束后会重置CMS算法相关的内部数据，为下一次GC循环做准备。

以上就是CMS回收垃圾的过程，其实就是把垃圾回收的过程给细分了，然后再某些阶段可以不停止用户线程，一边回收垃圾，一边处理请求，来减少每次垃圾回收时stop the word的时间。当然，中间也做了很多的优化，比如dirty card标记，中途触发minor GC等等

空间需要预留：CMS垃圾收集器可以一边回收垃圾，一边处理用户线程，那需要在这个过程中保证有充足的内存空间供用户使用。如果CMS运行过程中预留的空间不够用，会报错，这时会启动Serial Old垃圾收集器进行老年代的垃圾回收，会导致停顿的时间很长。

内存碎片问题：CMS本质上是实现了标记清除算法的收集器，这意味着会产生内存碎片，由于碎片太多，又可能导致内存空间不足所触发full GC，CMS一般会触发full GC这个过程堆碎片进行整理。整理涉及到【移动】和【标记】，这个过程肯定会stop the world，如果内存足够大，这个过程卡顿也需要一定的时间。

综合来看，使用CMS的弊端好像一个死循环：

内存碎片过多，导致空间利用率降低，空间本身就需要预留给用于线程使用，现在碎片化又加剧了空间的问题，可能导致垃圾收集器降级为Serial Old，卡顿时间更长；要处理内存碎片问题，同样会卡顿。
所以，目前企业中一般都使用G1。

CMS垃圾回收器设计目的：为了避免「老年代 GC」出现「长时间」的卡顿（Stop The World）

CMS垃圾回收器回收过程：初始标记、并发标记、并发预处理、重新标记和并发清除。初始标记以及重新标记这两个阶段会Stop The World

CMS垃圾回收器的弊端：会产生内存碎片&&需要空间预留：停顿时间是不可预知的