CMS的收集器的特点就是低延迟
在JDK1.5 推出了一款在强交互应用中具有划时代意义的垃圾收集器，CMS这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程同时工作
CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间，停顿时间越短用户体验越好
目前有很大一部分的java应用集中在互联网站或者B/S系统的服务端上，这类应用非常重视服务的响应速度，希望系统停顿时间最短，以给用户带来较好的体验，CMS收集器适合这类
注意:CMS垃圾收集算法采用的标记-清除算法，并且也是会STW的
但是可惜的是 CMS作为老年代的收集器，无法与JDK1.4中已经存在的新生代收集器Parallel Scavenge配合工作，所以在JDK1.5中使用CMS来收集老年代的时候，新生代只能选择ParNew或者Serial收集器中的一个
需要注意的是 重新标记阶段 - 能重新标记到从垃圾变成不是垃圾的部分，但是从不是垃圾变为垃圾的那部分是不知道的，这部分在本次垃圾收集时候是不会回收的
CMS的bi特点和弊端分析
1.尽管CMS收集器采用的是并发回收(非独占式)，但是在其初始化标记和重新标记这两个阶段中仍然需要执行STW机制暂停程序中的工作线程，不过暂停时间不会太长，因此说CMS没有STW是不对的，只是尽可能的缩短暂停时间，因为最耗费时间的并发标记和并发清除阶段都不需要暂停，所以整体的回收是低停顿的
2.由于垃圾收集阶段用户线程是没有中断的，所以CMS回收过程中，还应该确保应用程序用户线程有足够的内存可用。这就要求CMS收集器不能像其他收集器那样等到老年代几乎完全被填满在进行收集，而是当堆内存使用率达到某一阈值，便开始回收。以便于确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行，如果CMS运行期间预留的内存无法满足程序需要，就会出现一次"Concurrent Mode Failure"失败，这时虚拟机将启动后备案:也就是之前说过的，临时启动Serial Old 收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了
3.CMS采用的是标记-清除算法，这意味着，收集完会会产生内存碎片，那么新对象分配的时候就只能使用空间列表分配而不能使用指针碰撞了(因为清除阶段是并发的，所以也没法使用压缩算法，毕竟你在应用程序还在运行的时候总不能把对象存活对象给移动了把。。。)
总结一下
CMS的优点很明确就是并发收集，低延迟
CMS的弊端
1.产生内存碎片，导致并发清除后，用户线程的可用空间不足了，可能明明空间够，但是因为是碎片化的，放不下大对象，提前触发Full GC
2.CMS收集器对CPU资源非常敏感，并发阶段，他虽然不会导致用户停顿，但是会因为占用了一部分线程而导致应用程序变慢，总的吞吐量降低了
3.CMS收集器无法处理浮动垃圾，可能出现Concurrent Mode Failure 失败而导致另一次Full GC产生。在并发标记阶段，由于用户线程和垃圾回收线程是同时运行或者是交叉运行的，那么在并发标记阶段新产生的垃圾会想，CMS将无法对这些对象进行处理，导致无法及时回收，从而只能在下一次执行GC时候释放这些之前未被回收的内存空间
参数设置
-XX:ParallelCMSThreads 设置CMS的线程数量
CMS默认启动的线程数是(ParallelGCThreads +3)/4，ParallelGCThreads是年轻代并行收集器的线程数，当CPU资源比较紧张时，收到CMS收集器线程影响，应用程序的性能在垃圾回收阶段可能会非常糟糕
-XX:+UseConcMarkSweepGC 设置CMS回收老年代
开启该参数后，将自动将 -XX:+UseParNewGC打开
-XX:CMSInitiatingOccupanyFraction 设置堆内存使用率的阈值，一旦达到该阈值，便开始进行回收
jDK5以前默认 68 JDK6以及以上版本 默认为92，当然如果内存增长缓慢，可以设置一个稍大的值，有助于降低CMS的触发频率，减少老年代回收的次数可以明显的改善应用程序的性能，反之，如果应用程序内存使用率增长太快，则应该降低这个阈值，以避免频繁触发老年代串行收集器
-XX:UseCMSCompactAtFullCollection 用于指定在执行完Full GC后对内存空间进行压缩整理，以避免内存碎片的产生，不过由于聂村压缩整理算法无法并发执行，所带来的弊端就是停顿的时间变长了(是在一次CMS回收之后，在下一次开始前执行这个)
-XX:CMSFullGCsBeforeCompaction 设置在执行多少次Full GC后对内存空间进行压缩整理 必须是在上一个参数开启条件下才有效
小结
