CMS垃圾收集器

 

       CMS收集器（Concurrent Mark Sweep），年老代垃圾收集器，最主要目标是获取最短垃圾回收停顿时间，使用多线程的标记-清除算法，实现了让垃圾收集线程和用户线程同时工作。

 

• 初始标记（CMS initial mark）只是标记一下GC Roots能直接关联的对象，速度很快，仍然需要暂停所有的工作线程。
• 并发标记（CMS concurrent mark）进行GC Roots跟踪的过程，和用户线程一起工作，不需要暂停工作线程。
• 重新标记（CMS remark）为了修正在并发标记期间，因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，仍然需要暂停所有的工作线程。
• 并发清除（CMS concurrent sweep）清除GC Roots不可达对象，和用户线程一起工作，不需要暂停工作线程。
• 重置(CMS concurrent reset) 清理数据结构,为下一个并发收集做准备.

       由于耗时最长的并发标记和并发清除过程中，垃圾收集线程可以和用户现在一起并发工作，所以总体上来看CMS收集器的内存回收和用户线程是一起并发地执行。

       CMS收集器有以下三个不足：
        a. CMS收集器对CPU资源非常敏感。在并发阶段虽然不会导致用户线程停顿，但是会因为占用了一部分线程（或者说CPU资源而导致应用程序变慢），总吞吐量会降低。CMS默认启动的回收线程数=(CPU数量+3)/4，在用户程序本来CPU负荷已经比较高的情况下，如果还要分出CPU资源用来运行垃圾收集器线程，会使得CPU负载加重。
        b. CMS无法处理浮动垃圾(Floating Garbage)，可能会导致“Concurrent Mode Failure“而导致另一次Full GC的产生。在与用户线程并发运行的过程中，不断会有新的垃圾产生，这部分垃圾出现在标记过程之后，CMS无法在当次收集中处理掉它们，只能留待下一次GC时再清理，这部分垃圾就称为“浮动垃圾”。 CMS垃圾收集器不能像其它垃圾收集器那样等待年老代几乎完全被填满之后再进行收集，需要预留一部分空间供并发收集时的使用，可以通过参数-XX:CMSInitiatingOccupancyFraction来设置年老代空间达到多少的百分比时触发CMS进行垃圾收集。如果在CMS运行期间，预留的内存无法满足程序需要，就会出现一次“ConcurrentMode Failure“，此时虚拟机将启动预备方案，临时使用Serial Old收集器重新进行年老代垃圾回收。
        c. CMS收集器是基于标记-清除算法，因此不可避免会产生大量不连续的内存碎片，空间碎片过多时，将会给大对象分配带来很大麻烦。如果无法找到足够大的连续内存来分配对象时，将会触发因此Full GC。CMS提供一个开关参数-XX:+UseCMSCompactAtFullCollection，用于指定在Full GC之后进行内存整理，这个过程无法并发，会导致垃圾收集停顿时间变长，CMS提供了另外一个参数-XX:CMSFullGCsBeforeCompaction，用于设置在执行多少次不压缩的Full GC之后，跟着来一次带压缩的Full GC。

       相关的参数配置可以参考http://blog.youkuaiyun.com/zero__007/article/details/49278849中关于CMS的介绍。