CMS收集过程和优化思路

CMS（Concurrent Mark Sweep），是JDK1.5时的默认收集器（1.6及其之后版本不再使用）。回收区域是老年代，使用标记-清楚算法。设计初衷暂且认为是对并发回收的大胆尝试。

通常的收集搭档是：
ParNew（针对新生代）+CMS（针对老年代）+Serial Old（老年代兜底后续会讲）。
（Parallel Scavenge 因无法与CMS搭配使用，在 Parallel Old 没出来前，它都处于一个很尴尬的位置）

优点：在垃圾收集过程中，时间占比比较多的操作阶段（可达性分析和收集垃圾），垃圾收集线程与用户线程并发进行，可以减少GC带来的用户线程的停顿时间。
缺点：1.基于标记-清除算法，导致内存碎片化，在没有足够的情况下只能依赖于Serial old收集器（标记-整理算法）做兜底。2.由于收集收集过程中，用户线程仍在运行（浮动垃圾），因此需要预留一些空间，收集过程中空间不足以分配对象也会导致STP（Stop The World）做Full GC。
这两个条件也就意味着，GC的频率会变得频繁，整体吞吐量反而降低了。

GC吞吐量 = 用户代码运行时间 / (用户代码运行时间+GC停顿时间)

作为JVM众多GC收集器中，第一款可以与用户线程并行的垃圾收集器，了解其原理对后续G1、Shenandoah和ZGC有重要的意义。

CMS_work.png

初始标记（initial mark）：重点做枚举根节点操作，需要STW，但借助于OopMap结构，这个过程可以在ms级别快速完成。
并发标记（concurrent mark）：可达性分析阶段，耗时，并行，不需要STW。用户线程在新增对象引用时，会通过写屏障，将这些引用保存下来，用于重新标记阶段。
重新标记（remark）：处理并发标记阶段，用户线程新增的引用关系（浮动垃圾）。需要STW。整体来讲，采用的是增量更新的方式，解决用户线程在并发阶段修改对象引用图引发的问题。
并发清除（concurrent sweep）：使用标记-清楚算法，清除无用对象，不需要STW。

CMS在并发阶段，用户线程仍然会产生对象。如果此时预留内存不满足程序分配对象需要，就会出现一次“并发失败”（Concurrent Mode Failure），STW 临时启用Serial Old。

GC线程数：CMS默认启动线程数=(CPU核心数+3)/4，CPU核心数越多，极限越趋向n/4（25%）。在单核情况下表现糟糕，因考虑Serial Old，对于CPU资源敏感成需要应适当调小小点。-XX: ParallelCMSThreads=4
并发阶段由于浮动垃圾引发Full GC：并发阶段，用户线程仍会产生新的对象，当新对象无处存放时，启用Serial Old收集器做预案操作。据此，CMS在进行垃圾收集时，要预留一定空闲空间。这个空间不易太小，也不易太大。-XX:CMSInitiatingOccupancyFraction设置。
内存碎片化，大对象没有空隙分配，导致Full GC：-XX:+UseCMSCompactAtFullCollection，在进行Full GC是开启合并整理过程，默认开启。-XX:CMSFullGCsBeforeCompaction（JDK9废弃），在执行了若干次不整理内存空间的GC后，下一次进入FullGC前先进行碎片整理，默认值为0，表示每次进入Full GC时都进行内存碎片整理。