84-CMS垃圾收集器深入讲解

CMS垃圾收集器深入讲解

• CMS收集器：

  • Concurrent Mark Sweep（并发标记清除，并发：是指垃圾回收线程和用户业务线程可以同时执行[也并不是绝对的]）

  • CMS收集器，以获取最短回收停顿时间为目标，多数应用于互联网站或者B/S系统的服务器端上。

  • CMS是基于“标记——清除”算法实现的，整个过程分为4个步骤：

    • 初始标记（CMS initial mark）；

    • 并发标记（CMS concurrent mark）；

    • 重新标记（CMS remark）；

    • 并发清除（CMS concurrent sweep）。

      • 其中，初始标记、重新标记这两个步骤仍然需要“Stop The World”；【分清楚，并发标记和并发清除是可以和用户线程并发执行的！】
      • 初始标记只是标记一下GC Roots能直接关联到的对象速度很快；
      • 并发标记阶段就是进行GC Roots Tracing 的过程；
      • 重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分的标记记录，这个阶段的停顿时间一般会比初试标记阶段稍长一些，但远比并发标记的时间短。
      • ​ **重新标记的作用在于：**之前在并发标记时，因为是 GC 和用户程序是并发执行的，可能导致一部分已经标记为 从 GC Roots 不可达 的对象，因为用户程序的（并发）运行，又可达 了，Remark 的作用就是将这部分对象又标记为 可达对象。

      ​ 至于 “浮动垃圾”，因为 CMS 在 并发标记 时是并发的，GC 线程和用户线程并发执行，这个过程当然可能会因为线程的交替执行而导致新产生的垃圾（即浮动垃圾）没有被标记到；而 重新标记 的作用只是修改之前 并发标记 所获得的不可达对象，所以是没有办法处理 “浮动垃圾” 的。

• CMS收集器的运作步骤如下图所示，在整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作，因此，从总体上看，CMS收集器的内存回收过程是与用户线程一起并发执行的。
  

• 优点：

  • 并发收集、低停顿，oracle公司的一些官方文档中也称之为并发低停顿收集器（Concurrent Low Pause Collector）【一定要知道：停顿，停顿的是用户线程】

• 缺点：

  • CMS收集器对CPU资源非常敏感；
  • CMS收集器无法处理浮动垃圾（Floating Garbage）[并发清理阶段用户线程还在运行，这段时间就可能产生新的垃圾，新的垃圾在此次GC无法清除，只能等到下次清理（本来是垃圾，但GC认为不是垃圾没有回收）]，可能出现“Concurrent Mode Failure”失败而导致Full GC的产生。如果在应用中老年代增长不是太快，可以适当调高参数 -XX:CMSInitiatingOccupancyFraction 的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能。要是CMS运行期间预留的内存无法满足程序需要时，虚拟机将启动后备预案：临时启用 Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数 -XX:CMSInitiatingOccupancyFraction 设置得太高很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。
  • 收集结束时会有大量空间碎片产生，空间碎片过多时，将会给大对象分配带来很大麻烦，往往出现老年代还有很大空间剩余，但是无法找到足够的连续空间来分配当前对象，不得不提前进行一次Full GC。CMS收集器提供了一个 -XX:+UseCMSCompactAtFullCollection开关参数（默认就是开启的），用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程，内存整理的过程无法并发的，空间碎片问题没有了，但停顿时间不得不变长。

• 空间分配担保

  • 在发送Minor GC 之前，虚拟机会先检查老年代最大可用的连续空间是否大于新生代所有对象总空间，如果这个条件成立，那么Minor GC可以确保是安全的。当大量对象在Minor GC后仍然存活，就需要老年代进行空间分配担保，把Survivor无法容纳的对象直接进入老年代。如果老年代判断到剩余空间不足（根据以往每一次回收晋升到老年代对象容量的平均值作为经验值），则进行一次Full GC。