CMS清理流程及问题

CMS（Concurrent Mark Sweep，并发标记清除）收集器是以获取最短回收停顿时间为目标的收集器（追求低停顿)，它在垃圾收集时使得用户线程和GC线程并发执行，因此在垃圾收集过程中用户也不会感到明显的卡顿。从名字就可以知道，CMS是基于"标记-清除"算法实现的。CMS回收过程分为以下四步:

• 初始标记（CMS initial mark）：根据可达性分析算法，标记GC Root 开始的下级（注:仅下一级)对象，这个过程会STW，但是跟GC Root直接关联的下级对象不会很多，因此这个过程其实很快。

• 并发标记（CMS concurrent mark）：根据上一步的结果，继续向下标识所有关联的对象，直到这条链上的最尽头。这个过程是多线程的，会出现错标、漏标的情况，虽然耗时理论上会比较长，但是其它工作线程并不会阻塞，没有STW。

• 重新标记（CMS remark）：顾名思义，就是要再标记一次。为啥还要再标记一次?因为第2步并没有阻塞其它工作线程，其它线程在标识过程中，很有可能会产生新的垃圾。会有stw。

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

CMS的问题:

(1）并发回收导致CPU资源紧张:

在并发阶段，它虽然不会导致用户线程停顿，但却会因为占用了一部分线程而导致应用程序变慢，降低程序总吞吐量。CMS默认启动的回收线程数是：(CPU核数＋3)/4，当CPU核数不足四个时，CMS对用户程序的影响就可能变得很大。

(2) 无法清理浮动垃圾:

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

(3） 并发失败(Concurrent Mode Failure) :

由于在垃圾回收阶段用户线程还在并发运行，那就还需要预留足够的内存空间提供给用户线程使用，因此CMS不能像其他回收器那样等到老年代几乎完全被填满了再进行回收，必须预留一部分空间供并发回收时的程序运行使用。默认情况下，当老年代使用了92%的空间后就会触发CMS垃圾回收，这个值可以通过-XX:CMSInitiatingOccupancyFraction参数来设置。

这里会有一个风险：要是CMS运行期间预留的内存无法满足程序分配新对象的需要，就会出现一次"并发失败”(Concurrent Mode Failure)，这时候虚拟机将不得不启动后备预案：Stop The World，临时启用Serial Old来重新进行老年代的垃圾回收，这样—来停顿时间就很长了。

(4) 内存碎片问题: CMS是一款基于"标记-清除"算法实现的回收器，这意味着回收结束时会有内存碎片产生。内存碎片过多时，将会给大对象分配带来麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次Full GC的情况。

为了解决这个问题，CMS收集器提供了一个-XX**:十UseCMSCompactAtFullCollection开关参数（默认开启)，用于在Full GC时开启内存碎片的合并整理过程，由于这个内存整理必须移动存活对象，是无法并发的，这样停顿时间就会变长。

还有另外一个参数-XX:**CMSFullGCsBeforeCompaction，这个参数的作用是要求CNS在执行过若干次不整理空间的Full GC之后，下一次进入Full GC前会先进行碎片整理（默认值为0，表示每次进入Full GC时都进行碎片整理)。