JVM - CMS垃圾收集器（建议收藏）
今天，继续给大家分享关于JVM的文章，今天给大家带来的是一篇关于JVM CMS垃圾收集器的文章，好了，不多说了，进入今天的正题。
CMS是基于标记-清除算法的，收集的时候分为4个步骤：
- 初始标记
- 并发标记
- 重新标记
- 并发清除
初始标记
初始标记仅仅只是标记一下GC Roots能直接关联到的对象，所以速度很快。比如下图，这边的GC Roots只用了虚拟机栈为例。两个虚拟机栈分表创建了对象OBJ_A1和OBJ_B1，他们也各有自己的其他引用，在这个阶段，他只会标记OBJ_A1和OBJ_B1，其他的引用是不标记的，所以尽管这个阶段有STW，但是标记的数量少，时间很快，基本不影响。
并发标记
并发标记就是根据初始标记的对象所直接或间接引用的对象进行标记，比如下图对OBJ_A2，OBJ_AN进行并发标记。这个阶段并没有STW，所以可以创建对象，新增新的引用，也会让某些对象失去引用，比如下图，OBJ_B1已经变成垃圾了，OBJ_C1是新增存活的对象。这个阶段由于对老年代所有的对象进行跟踪，所以是非常耗时的。
重新标记
在并发标记中，我们看到存活对象OBJ_C1等以及垃圾对象OBJ_B1等是没有被标记出来的，所以这个阶段就是对这些对象进行重新标记。这个阶段也有STW，但是仅仅对并发标记中有变动的对象进行标记，这些数量比较少，所以速度也是很快。
并发清除
这个阶段，就是在重新标记后，对垃圾对象的清理，和并发标记一样，都很耗时，由于并没有STW，所以对程序的运行影响不大。CMS采用的是标记与清除算法。
缺点
CMS的4个阶段，初始标记和重新标记需要STW，但是时间短，影响不大。并发标记和并发清除不需要STW，虽然耗时，但是并发执行的，影响也不大，看起来CMS很完美，但是他也有一些缺点。
CPU
CMS默认启动的回收线程数是（CPU数量+3）/ 4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。比如服务器是2核4G，那就需要用(2+3)/4=1个线程去处理并发的标记和并发清除，这时候只剩下1个线程处理其他事情。
浮动垃圾
浮动垃圾的产生，主要是在并发清理阶段。重新标记后，CMS垃圾回收器会知道哪些需要清理，在并发清理阶段，清理重新标记后的垃圾对象，这个阶段并没有STW，所以有可能产生新的对象。
比如下图的OBJ_N，创建完后，栈帧被回收，引用就没了，他在这个阶段是不能被清除的，只能等下一次垃圾回收的时候，被标记并清除。
如果这个阶段进入老年代的对象超过了剩余空间，就会出现Concurrent Mode Failure失败，那虚拟机会临时启用Serial Old收集器进行老年代的垃圾收集。
可以用XX:CMSInitiatingOccupancyFraction设置老年代空间被占用多少百分比触发CMS回收，JDK1.6后默认92%。
空间碎片
在《[JVM垃圾回收算法] 》一文中提过，标记-清除算法会产生空间碎片的，如果连续的内存空间不够存放即将进入老年代的对象，此时就会触发Full GC。
为了避免这种情况，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection，默认打开的，当Full GC完成后，他会STW，进行内存整理，把存活的对象紧密的靠在一起，腾出连续空间。
如果每次都要重新内存，那都会STW，所以CMS还提供了-XX:CMSFullGCsBeforeCompaction参数，默认是0，表示进行了多少次Full GC后才整理内存。
好了，今天就到这儿吧， 我们下期见~~
转自：segmentfault.com/a/1190000038434817