深入理解jvm-CMS垃圾回收器

本文参考圣思园张龙深入理解jvm

 

CMS收集器 

CMS收集器：https://www.cnblogs.com/webor2006/p/11055468.html

介绍和优缺点

Concurrent 并发：垃圾收集的线程可以跟用户的执行线程同时执行，也非绝对。 而标记哪些对象是存活的，哪些对象是可以回收的。

CMS，以获取最短的回收停顿时间为目标，是一款基于“标记—清除”算法实现的收集器：初始标记(CMS-initial-mark)，并发标记(CMS-concurrent-mark)，重新标记(CMS-remark)，并发清除(CMS-concurrent-sweep)。

其中，初始标记、重新标记这两个步骤仍然需要Stop the world。初始标记仅仅只是标记一下GC Roots能直接关联到的对象，速度很快，并发标记阶段就是进行GC Roots Tracing的过程，而重新标记阶段则是为了修正并发标记期间因用户程序继续运作而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始阶段稍长一些，但远比并发标记的时间短。

由于整个过程中耗时最长的并发标记和并发清除过程收集器线程都可以与用户线程一起工作。所以从总体上来说，CMS收集器的内存回收过程是与用户线程一起并发执行的。

优点：并发收集、低停顿。Oracle公司的一些官方文档中也称之为并发低停顿收集器（Concurrent Low Pause Collector）

缺点：

1、CMS收集器对CPU资源非常敏感。

2、CMS收集器无法处理浮动垃圾（Floating Garbage，就是指在之前判断该对象不是垃圾，由于用户线程同时也是在运行过程中的，所以会导致判断不准确的， 可能在判断完成之后在清除之前这个对像已经变成了垃圾对象，所以有可能本该此垃圾被回收但是没有被回收，只能等待下一次GC再将该对象回收，所以这种对像就是浮动垃圾）,可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生。如果在应用中老年代增长不是太快，可能适当调高参数-XX：CMSInitiatingOccupancyFraction的值来提高触发百分比，以便降低内存回收次数从而获取更好的性能。要是CMS运行期间预留的内存无法满足程序需要时，虚拟机将启动后备预案:临时启用Serial Old收集器来重新进行老年代的垃圾收集，这样停顿时间就很长了。所以说参数-XX：CMSInitiatingOccupancyFraction设置得太高很容易导致大量“Concurrent Mode Failure”失败，性能反而降低。

3、收集结束时会有大量空间碎片产生，空间碎片过多时，将会给大对象分配带来很大麻烦，往往出现老年代还有很大空间剩余，但是无法找到足够大的连续空间来分配当前对象，不得不提前进行一次Full GC。CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开关参数（默认就是开启的），用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间不得不变长。

 

空间分配担保：

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

CMS收集器收集完整步骤：

Phase1 ：Initial Mark【初始标记】

Phase2 : Concurrent Mark 【并发标记】

Phase3 : Concurrent Preclean【并发预先清除】

Phase4 : Concurrent Abortable Preclean【并发可能失败的预先清除】

Phase5 : Final Remark【最终重新标记】

Phase6 : Concurrent Sweep【并发清除】

Phase7 : Concurrent Reset【并发重置】

Phase1 ：Initial Mark【初始标记】

这个是CMS两次stop-the-world事件的其中一次，这个阶段的目标是：标记那些直接被GC root引用或被年轻代存活对象所引用的所有对象。

Phase2 : Concurrent Mark 【并发标记】

在这个阶段Garbage Collector会遍历老年代，然后标记所有存活的对象，它会根据上个阶段找到GC ROOTS遍历查找。并发标记阶段，它会与用户的应用程序并发运行。并不是老年代所有的存活对象都会被标记，因为在标记期间用户的程序可能会改变一些引用。如下图：

在上面的图中，与阶段1的图进行对比，就会发现有一个对象的引用已经发生了变化，如标黑的那个对象。

 

Phase 3：Concurrent Preclean

这也是一个并发阶段，与应用的线程并发运行，并不会 stop 应用的线程。在并发运行的过程中，一些对象的引用可能会发生变化，但是这种情况发生时，JVM 会将包含这个对象的区域（Card）标记为 Dirty，这也就是 Card Marking。

在pre-clean阶段，那些能够从 Dirty 对象到达的对象也会被标记，这个标记做完之后，dirty card 标记就会被清除了

 

Phase4 : Concurrent Abortable Preclean【并发可能失败的预先清除】

这也是一个并发阶段，但是同样不会影响影响用户的应用线程，这个阶段是为了尽量承担 STW（stop-the-world）中最终标记阶段的工作。这个阶段持续时间依赖于很多的因素，由于这个阶段是在重复做很多相同的工作，直接满足一些条件（比如：重复迭代的次数、完成的工作量或者时钟时间等）。这个阶段的日志信息如下：

 

标记阶段完成

经历过着吴哥阶段后，老年代所有存活的对象都被标记过了，现在可以通过清除算法去清理那些老年代不再使用的对象。

 

 

Phase5 : Final Remark【最终重新标记】

这是第二个 STW 阶段，也是 CMS 中的最后一个，这个阶段的目标是标记所有老年代所有的存活对象，由于之前的阶段是并发执行的，gc 线程可能跟不上应用程序的变化，为了完成标记老年代所有存活对象的目标，STW 就非常有必要了。

通常 CMS 的 Final Remark 阶段会在年轻代尽可能干净的时候运行，目的是为了减少连续 STW 发生的可能性（年轻代存活对象过多的话，也会导致老年代涉及的存活对象会很多）。这个阶段会比前面的几个阶段更复杂一些

 

Phase6 : Concurrent Sweep【并发清除】

这里不需要 STW，它是与用户的应用程序并发运行，这个阶段是：清除那些不再使用的对象，回收它们的占用空间为将来使用。

 

Phase7 : Concurrent Reset【并发重置】

这个阶段也是并发执行的，它会重设 CMS 内部的数据结构，为下次的 GC 做准备。

 

总结：

CMS通过将大量工作分散到并发处理阶段来减少STW时间，在这块做得非常优秀，但是CMS也有一些其它的问题，主要是如下问题：1、CMS收集器无法处理浮动垃圾（Floating Garbage）,可能出现“Concurrent Mode Failure”失败而导致另一次Full GC的产生，可能引发串行Full GC； 2、空间碎片，导致无法分配大对象，CMS收集器提供了一个-XX:+UseCMSCompactAtFullCollection开发参数（默认就是开启的），用于在CMS收集器顶不住要进行Full GC时开启内存碎片的合并整理过程，内存整理的过程是无法并发的，空间碎片问题没有了，但停顿时间不得不变长；3、对于堆比较大的应用，GC的时间难以预估。