介绍
CMS（Concurrent Mark-Sweep）是以牺牲吞吐量为代价来获得最短回收停顿时间的垃圾回收器。对于要求服务器响应速度的应用上，这种垃圾回收器非常适合。
在启动JVM参数加上-XX:+UseConcMarkSweepGC ，这个参数表示对于老年代的回收采用CMS。
CMS采用的基础算法是：标记–清除
CMS过程
1、初始标记（CMS initial mark）。
2、并发标记（CMS concurrent mark）。
3、重新标记（CMS remark）。
4、并发清除（CMS concurrent sweep）
3次标记，1次清除。
初始标记、重新标记这两个步骤仍然需要“Stop The World”。（1、3要stw，2、4都是并发操作，没有stw）
触发条件
1. 周期性GC
由后台线程ConcurrentMarkSweepThread循环判断（默认2s）是否需要触发。
- 如果没有设置-XX:+UseCMSInitiatingOccupancyOnly，虚拟机会根据收集的数据决定是否触发
- 老年代使用率达到阈值 CMSInitiatingOccupancyFraction，默认92%。
- 永久代的使用率达到阈值 CMSInitiatingPermOccupancyFraction，默认92%，前提是开启 CMSClassUnloadingEnabled。
- 新生代的晋升担保失败。
2. 主动触发
- YGC过程发生Promotion Failed，进而对老年代进行回收
- 比如执行了System.gc()，前提是没有参数ExplicitGCInvokesConcurrent
CMS的缺点
1、产生空间碎片：CMS采用的是标记–清除。CMS不会压缩内存碎片，经过CMS收集的堆会产生空间碎片。
2、需要更多的CPU资源：为了让应用程序不停顿，CMS线程和应用程序线程并发执行，这样就需要有更多的CPU，单纯靠线程切换是不靠谱的。
3、需要更大的堆空间：因为CMS标记阶段应用程序的线程还是在执行的，那么就会有堆空间继续分配的情况，为了保证在CMS回 收完堆之前还有空间分配给正在运行的应用程序，必须预留一部分空间。
4、CMS只回收老年代：年轻带只能配合Parallel New或Serial回收器；
CMS的使用场景
如果你的应用程序对停顿比较敏感，并且在应用程序运行的时候可以提供更大的内存和更多的CPU(硬件好)，那么使用CMS来收集会给你带来好处。还有，如果在JVM中，有相对较多存活时间较长的对象(老年代比较大)会更适合使用CMS。
晋升失败和并发模式失败
CMS大部分的收集过程可以和用户线程并发执行，大大降低应用的暂停时间，不过也会带来负面影响，在收集完 old gen 之后，CMS并不会做整理过程，会产生空间碎片，如果这些碎片空间得不到利用，就会造成空间的浪费，整个过程中可能发生 concurrent mode failure，导致一次真正意义的Full GC，采用单线程对整个堆（young+old+perm） 使用MSC（Mark-Sweep-Compact）进行收集，这个过程意味着很慢很慢很慢，而且这个碎片问题是无法预测的.
只有CMS算法中才会出现concurrent mode failed，一旦它的出现，意味着有一次耗时很长的FGC了
- promotion failure（晋升失败）：年轻代晋升的时候老年代没有足够的连续空间容纳，很有可能是内存碎片导致的，会去触发Full GC。
- concurrent mode failure（并发模式失败）：并发过程中jvm觉得在并发过程结束前堆就会满了，需要提前触发Full GC。
解决办法就是要让年老代留有足够的空间，以保证新对象空间的分配。
问题
（1）CMS 是如何降低GC延时提高性能呢？
整个CMS垃圾回收过程初始标记和重新标记最耗时，因为他们都会STW。
但是，在初始标记阶段 到 最终重标记阶段 之间，基本上中间所有阶段的努力都是并发执行的，且都是为了让重标记阶段的时延成本降到最低
（2）什么时候会触发Stop the world
第一步初始标记
第五步重新标记
会Stop the world
（3）为什么需要Stop the world
当虚拟机完成两次标记后，便确认了可以回收的对象。但是，垃圾回收并不会阻塞我们程序的线程，他是与当前程序并发执行的。所以问题就出在这里，当GC线程标记好了一个对象的时候，此时我们程序的线程又将该对象重新加入了“关系网”中
虚拟机的解决方法就是在一些特定指令位置设置一些“安全点”，当程序运行到这些“安全点”的时候就会暂停所有当前运行的线程（Stop The World 所以叫STW），暂停后再找到“GC Roots”进行关系的组建，进而执行标记和清除。
（4）CMS参数配置有哪些？
-XX:+UseConcMarkSweepGC
该标志首先是激活CMS收集器。默认HotSpot JVM使用的是并行收集器。
-XX:+CMSClassUnloadingEnabled
相对于并行收集器，CMS收集器默认不会对永久代进行垃圾回收。如果希望对永久代进行垃圾回收，可用设置该标志
-XX:+CMSParallelRemarkEnabled
采用并行标记方式降低停顿。
-XX:+CMSConcurrentMTEnabled
当该标志被启用时，并发的CMS阶段将以多线程执行
-XX:+UseCompressedOops
这个参数用于对类对象数据进行压缩处理，提高内存利用率。
-XX:MaxGCPauseMillis=50
这个参数用于设置GC暂停等待时间，单位为毫秒，不要设置过低。
一般推荐使用如下的参数设置：
-XX:+UseCompressedOops
-XX:MaxGCPauseMillis=50
-XX:+UseConcMarkSweepGC
-XX:+CMSParallelRemarkEnabled
-XX:+CMSClassUnloadingEnabled（5）什么时候会压缩内存碎片？
CMS不会压缩内存碎片，但会做一些优化，比如会合并老生代中相邻的free空间。
（6）CMS回收日志打印
（7）如何解决内存碎片问题？
Sun官方给出了以下的四种解决方法：
1、增大Xmx或者减少Xmn
2、在应用访问量最低的时候，在程序中主动调用System.gc()，比如每天凌晨。
3、在应用启动并完成所有初始化工作后，主动调用System.gc()，它可以将初始化的数据压缩到一个单独的chunk中，以腾出更多的连续内存空间给新生代晋升使用。
4、 降低-XX:CMSInitiatingOccupancyFraction参数以提早执行CMSGC动作，虽然CMSGC不会进行内存碎片的压缩整理，但它会合并老生代中相邻的free空间。这样就可以容纳更多的新生代晋升行为。
stop the world（STW）的实现原理
1、到安全点再挂起
JVM有个叫做“安全点”和“安全区域”的东西，在发生GC时，所有的线程都会执行到“安全点”停下来。
在需要GC的时候，JVM会设置一个标志，当线程执行到安全点的时候会轮询检测这个标志，如果发现需要GC，则线程会自己挂起，直到GC结束才恢复运行。
2、直接全部挂起再恢复不在安全点的
还有另一种策略是在GC发生时，直接把所有线程都挂起，然后检测所有线程是否都在安全点，如果不在安全点则恢复线程的执行，等执行到安全点再挂起。
但是对于一些没有获得或无法获得CPU时间的线程，就没办法等到它执行到安全点了，所以这个时候只要这个线程是在安全区域的，也可以进行GC，安全区域是一段代码段，在这段代码段中对象的引用关系不会发生变化，所以这个时候进行GC也是安全的。
