JVM垃圾收集器之CMS

简介

CMS（Concurrent Mark Sweep）收集器是以获取最短回收停顿时间为目标，适合Java应用集中在互联网网站或者基于浏览器的B/S系统的服务端上。是基于标记-清除算法实现的。

运行过程

整个过程分为四个步骤：

• 初始标记
• 并发标记
• 重新标记
• 并发清除

其中初始标记、重新标记这两个步骤需要“Stop The World”。初始标记仅仅只是标记一下GC Roots能直接引用到的对象，速度很快；并发标记阶段就是GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长，不需要停顿用户线程，可以与垃圾收集线程一起并发运行，所以这个阶段会导致标记产生变动，但会被记录下来；重新标记阶段是为了修正并发标记期间记录的标记变动，最后是并发清除阶段，清理删除掉标记阶段的已经判断死亡的对象，不需要移动存活对象，所以可以与用户线程同时并发。下面是CMS收集器运行示意图：

浮动垃圾

在CMS的并发标记和并发清理阶段，用户线程还是在运行的，同时也会产生新的垃圾对象，但这一部分的垃圾对象是出现在标记过程结束以后的，CMS无法在当次收集中处理掉它们，只能在下一次垃圾收集时清理掉。这一部分垃圾就称为“浮动垃圾”。

缺点

虽然它有着并发收集、低停顿的优点，甚至被称为“并发低停顿收集器”。但至少还是有以下三个明显的缺点：

• 吞吐量会收到影响。因为CMS是并发收集，在GC时，需要把执行用户的线程分出来一个执行GC，用户线程的执行速度会变慢，吞吐量会降低。由于面向并发设计的程序都会CPU有要求，所以如果CPU不是多核的或者核心数量比较少，也可能会对用户程序产生很大的影响。
• CMS无法处理“浮动垃圾”，有可能出现“Con-current Mode Failure”失败进而导致另一次完全“Stop The World”的Full GC的产生。由于垃圾收集阶段，用户线程还在运行，浮动垃圾只能在下一次垃圾收集被清理，而一般收集器都是在老年代几乎被填满了再进行收集，如果在这时进行垃圾收集，可能会没有内存存储浮动垃圾，所以必须预留一部分空间供并发收集时使用。
• 容易提前触发Full GC。因为CMS是基于“标记-清除”算法实现的收集器，会产生大量空间碎片，碎片过多时，虽然老年代还有很多剩余空间，但无法找到连续空间来话分配大对象，不得不提前触发一次Full GC。对于这个问题，在JDK9之前，CMS收集器在执行过若干次不整理空间的Full GC后，下一次进入Full GC前会先进行碎片整理。