CMS收集器
适合多CPU，频繁和用户交互的业务场景，追求的是停顿时间最短,采用标记清除的回收算法（因为标记清除不会涉及存活对象的移动：复制和压缩，从而降低STW的时间）
CMS的缺点
- 对CPU资源敏感，因为在并发标记、并发清除的时候都需要占用一个单独的线程来完成操作，如果CPU为2的话，那么就只有1个CPU能干活，一个CPU在GC
- 无法处理浮动垃圾，也就是每次GC都扫不干净，因为并发清除的过程中，还会有新的垃圾产生，而且如果这个阶段新的垃圾导致空间不足，会PromotionFailure
- 基于标记清除算法会存在很多碎片，空间利用率不高，需要配置压缩参数，但是在压缩的过程中STW的时间会延长
PromotionFailure&Concurrent Mode Failure：都是年轻代promote引起的，一个是在正常情况下，一个是在FGC的情况下。都会引发Serious old的单线程回收
- PromotionFailure指的是，YGC时，发现年轻带promote到老年代时，老年代也不足，导致的。一般不会发生，因为默认70%时候，老年代就会扩容。
- Concurrent Mode Failure，非常类似，CMS在FGC老年代的时候，年轻代也在GC，且YGC产生的promote对象在老年代装不下。解决方案是：增大年轻代的大小，或者存活ratio，让年轻代对象慢一点进入老年代，老年代回收完了，再进入。
CMS GC时不能回收的对象：
- GC Roots直接可达的老年代对象
- 年轻代对象直接引用的老年代对象
- 以及这些对象引用到老年代的对象
垃圾回收过程
image
- 初始标记：STW，分为2块，因为只需要标记直接引用的对象，所以STW的时间并不长
- 根据GC Roots可达性，标记所有老年代直接可达的对象，不包括直接可达对象引用的其它对象，比如老年代对象A，是GC roots可达的对象，但是A又引用了B，B又引用了C，所以第一步是标记A
- 遍历年轻代，标记所有年轻代直接引用的老年代对象，不包括直接可达对象引用的其它对象
并发标记：开启多线程，根据第一步标记的对象，递归的检查所有的老年代最终可达的对象，此时可以标记到B 和C
预清理：对并发标记阶段，新晋升到老年代的对象，以及之前标记的对象的引用关系发生了改变的对象，都要做一个Dirty的标记处理
重新标记：STW，并发标记阶段，可能会发生引用关系的改变，或者新的对象晋升到了老年代等等操作。此时会多线程的形式重新做一次遍历新生代，找到所有引用的老年代的对象。以及GC Roots可达的老年代对象，以及这些对象引用到的对象。
其实这一步的大部分对象都在 第一步和第二步标记好了，所以比较快。主要是查缺补漏和再次确认的一个过程。并发清除：多线程的形式清楚掉没有被引用的对象。（也包括弱引用的对象）
参考
很棒的一篇带图解的回收过程
http://www.importnew.com/27822.html
