CMS垃圾回收器的有点缺点，产生promotion failed和concurrent mode failure的原因及解决方案

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器，它非常符合那些集中在互联网站或者B/S系统的服务端上的Java应用，这些应用都非常重视服务的响应速度。从名字上（“Mark Sweep”）就可以看出它是基于“标记-清除”算法实现的。

CMS收集器工作的整个流程分为以下4个步骤：

• 初始标记（CMS initial mark）：仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，需要“Stop The World”。
• 并发标记（CMS concurrent mark）：进行GC Roots Tracing的过程，在整个过程中耗时最长。
• 重新标记（CMS remark）：为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。此阶段也需要“Stop
  The World”。
• 并发清除（CMS concurrent sweep）

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作。

所以，从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

优点

CMS是一款优秀的收集器，它的主要优点在名字上已经体现出来了：并发收集、低停顿，因此CMS收集器也被称为并发低停顿收集器（Concurrent Low Pause Collector）。

缺点

• 对CPU资源非常敏感
  其实，面向并发设计的程序都对CPU资源比较敏感。在并发阶段，它虽然不会导致用户线程停顿，但会因为占用了一部分线程（或者说CPU资源）而导致应用程序变慢，总吞吐量会降低。
• CMS默认启动的回收线程数是（CPU数量+3）/4，也就是当CPU在4个以上时，并发回收时垃圾收集线程不少于25%的CPU资源，并且随着CPU数量的增加而下降。但是当CPU不足4个时（比如2个），CMS对用户程序的影响就可能变得很大，如果本来CPU负载就比较大，还要分出一半的运算能力去执行收集器线程，就可能导致用户程序的执行速度忽然降低了50%，其实也让人无法接受。
• 无法处理浮动垃圾（Floating Garbage） 可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。由于CMS并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生。这一部分垃圾出现在标记过程之后，CMS无法再当次收集中处理掉它们，只好留待下一次GC时再清理掉。这一部分垃圾就被称为“浮动垃圾”。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集，需要预留一部分空间提供并发收集时的程序运作使用。
• 标记-清除算法导致的空间碎片 CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。
• 空间碎片过多时，将会给大对象分配带来很大麻烦，往往出现老年代空间剩余，但无法找到足够大连续空间来分配当前对象。

可能出现的问题

• promotion failed 晋升失败
• concurrent mode failure 并发模式故障

第一个问题promotion failed，是在进行Minor GC时，Survivor Space放不下，对象只能放入老年代，而此时老年代也放不下造成的，多数是由于老年带有足够的空闲空间，但是由于碎片较多，导致不能放入老年代中。

第二个问题concurrent mode failure，是在执行CMS GC的过程中同时业务线程将对象放入老年代，而此时老年代空间不足，这时CMS还没有机会回收老年带产生的，或者在做Minor GC的时候，新生代救助空间放不下，需要放入老年代，而老年代也放不下而产生的。

解决办法：

首先我们经常遇到promotion failed问题，这也确实是个很头痛的问题，一般是进行Minor GC的时候，发现救助空间不够，所以，需要移动一些新生带的对象到老年带，然而，有些时候尽管老年带有足够的空间，但是由于CMS采用标记清除算法，默认并不使用标记整理算法，可能会产生很多碎片，因此，这些碎片无法完成大对象向老年带转移，因此需要进行CMS在老年带的Full GC来合并碎片。

这个问题的直接影响就是它会导致提前进行CMS Full GC, 尽管这个时候CMS的老年带并没有填满，只不过有过多的碎片而已，但是Full GC导致的stop-the-wold是难以接受的。

解决这个问题的办法就是：可以让CMS在进行一定次数的Full GC（标记清除）的时候进行一次标记整理算法。

也就是CMS在进行5次Full GC（标记清除）之后进行一次标记整理算法，从而可以控制老年带的碎片在一定的数量以内，甚至可以配置CMS在每次Full GC的时候都进行内存的整理。

另外，有些应用存在比较大的对象朝生熄灭，这些对象在救助空间无法容纳，因此，会提早进入老年带，老年带如果有碎片，也会产生promotion failed, 因此我们应该控制这样的对象在新生代，然后在下次Minor GC的时候就被回收掉，这样避免了过早的进行CMS Full GC操作，下面的一个配置样例就通过增加救助空间的大小来解决这个问题。

总结：
上面讨论了promotion failed引起的原因以及解决方案，除了promotion failed还有一个情况会引起CMS回收失败，从而退回到Serial Old收集器进行回收，我们在线上尤其要注意的是concurrent mode failure出现的频率，这可以通过-XX:+PrintGCDetails来观察，当出现concurrent mode failure的现象时，就意味着此时JVM将继续采用Stop-The-World的方式来进行Full GC，这种情况下，CMS就没什么意义了，造成concurrent mode failure的原因是当minor GC进行时，旧生代所剩下的空间小于Eden区域+From区域的空间，或者在CMS执行老年带的回收时有业务线程试图将大的对象放入老年带，导致CMS在老年带的回收慢于业务对象对老年带内存的分配。

解决这个问题的通用方法是：调低触发CMS GC执行的阀值，CMS GC触发主要由CMSInitiatingOccupancyFraction值决定，默认情况是当旧生代已用空间为68%时，即触发CMS GC，在出现concurrent mode failure的情况下，可考虑调小这个值，提前CMS GC的触发，以保证旧生代有足够的空间。