JVM CMS收集器

CMS收集器

• CMS收集器，以获取最短回收停顿时间为目标，多数应用于互联网站或者B/S系统的服务器端上。
• CMS是基于“标记-清除” 算法实现的，整个过程分为4个步骤

      1）初始标记 （CMS initial mark）

      2）并发标记（CMS concurrent mark）

      3）重新标记（CMS remark）

      4）并发清除（CMS concurrent sweep）

• 其中，初始标记 和重新标记 这两个步骤仍然需要stop the world
• 初始标记只是标记一下 GC Roots 能直接关联到第一层的对象，速度很快；
• 并发标记阶段就是进行GC Roots Tracing的过程，是直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。
• 重新标记阶段则是为了修正并发标记期间因用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段稍长一些，但远比并发标记的时间短。
• CMS收集器的运作步骤如下，整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，因此总体上看，CMS收集器的内存回收过程是与用户线程一起并发执行的。
• 由于最耗时间的并发标记与并发清除都不需要暂停工作，所以整体的回收是低停顿的
• 另外，由于在垃圾收集阶段用户线程没有中断，所以在cms回收过程中，还应该确保应用程序用户线程有足够的内存可用。因此，cms收集器不能像其他收集器那样等到老年代几乎完全被填满了在进行收集，而是当堆内存使用率达到某一阀值时，便开始回收，以确保应用程序在cms工作过程中依然有足够的空间支持应用运行。要是cms运行期间的内存无法满足程序需要，就会出现一次“conurrent mode failure”失败，这时虚拟机将启动后备预案：临时启用serial old 收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。
• cms收集器采用标记-清除算法，这意味着每次执行完内存回收后，由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续 的一些内存块，不可避免地将会产生一些内存碎片。那么cms在为新对象分配内存空间时，将无法使用指针碰撞技术，而只能使用空闲列表执行内存分配。

   

优点：

• 并发收集、低停顿

缺点：

• cms收集器对cpu资源非常敏感
• cms收集器无法处理浮动垃圾，可能出现“ concurrent mode failure” 失败而导致另一次full gc 的产生。由于cms并发清理阶段用户线程还在运行着，伴随程序运行自然就还会有新的垃圾不断产生，这一部分垃圾出现在标记过程之后，cms无法在当次收集中处理它们，只好待下一次gc在清理掉，这一部分就称为浮动垃圾。也是由于在垃圾收集阶段用户线程还需要运行，那也就还需要预留有足够的内存空间给用户线程使用，因此cms收集器不能像其他收集器那样等到老年代几乎完全被填满了在进行收集，需要预留一部分空间提供并发收集时的程序运作使用。如果在应用中 老年代增长不是太快，可以适当调高参数-XX:CMSInitiatingOccupancyFraction的值来提供触发百分比，以便降低内存回收次数从而获取更好的性能。要是cms运行期间预留的内存无法满足程序需要时，虚拟机将启动后备预案；临时启用Serial old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-X