CMS垃圾回收器存在的问题及解决方案

今天药忘吃喽~ 2024-04-18 16:56 102阅读 0赞

之前的文章介绍过了CMS垃圾回收器的工作原理，CMS是使用标记-清理算法去垃圾回收的。其中四个主要的流程分别是初始标记、并发标记、重新标记、并发清理。

1.  并发消耗CPU资源

其中的并发标记和并发清理是工作线程和垃圾回收线程并发工作，这样在需要STW的时间内不会让整个系统不可用。但是在并发标记阶段，需要根据GC Roots标记出大量的存活对象，而在并发清理阶段，则需要将垃圾对象从各种随机内存位置删掉，这两个阶段都非常消耗性能，所以垃圾回收线程会占用一部分的CPU资源，导致系统的执行效率降低。

CMS默认的回收线程数是 **(CPU个数+3)/4**，当在CPU核数较多的时候，对系统性能的影响并不是特别大。但是如果是CPU核数较少，例如双核的时候，就会占用一个CPU去处理垃圾回收，系统的CPU资源直接降低50%，这就严重影响了效率。

因为现在CPU的核数越来越多，所以这种场景基本不会对系统造成很大的影响，可以忽略不计。

1.  Concurrent Mode Failure问题

并发清理阶段，工作线程和垃圾回收线程并发工作的时候，此时工作线程会不断产生新的垃圾，但是垃圾回收线程并不会去处理这些新生成的垃圾对象，需要等到下次垃圾回收的时候才会去处理，这些垃圾对象称之为：**浮动垃圾** 。因为有这些浮动垃圾的存在，所以老年代不能在100%使用的时候才去进行垃圾回收，否则就放不下这些浮动垃圾了。有一个参数是“**-XX:CMSInitiatingOccupancyFraction**”，这个参数在jdk1.6里面默认是92%，意思是老年代使用了92%的空间就会执行垃圾回收了。但是即使预留了8%的内存去存放浮动垃圾，但是还是有可能放不下，这样就会产生**Concurrent Mode Failure**问题。一旦产生了Concurrent Mode Failure问题，系统会直接使用Serial Old垃圾回收器取代CMS垃圾回收器，从头开始进行GC Roots追踪对象，并清理垃圾，这样会导致整个垃圾回收的时间变得更长。

解决办法就是根据系统的需求，合理设置“-XX:CMSInitiatingOccupancyFraction”的值，如果过大，则会产生Concurrent Mode Failure问题，如果设置的过小，则会导致老年代更加频繁的垃圾回收。

1.  空间碎片问题

CMS的标记-清理算法会在并发清理的阶段产生大量的内存碎片，如果不整理的话，则会有大量不连续的内存空间存在，无法放入一些进入老年代的大对象，导致老年代频繁垃圾回收。所以CMS存在一个默认的参数 “**-XX:+UseCMSCompactAtFullCollection**”，意思是在Full GC之后再次STW，停止工作线程，整理内存空间，将存活的对象移到一边。还要一个参数是“**-XX:+CMSFullGCsBeforeCompaction**”,表示在进行多少次Full GC之后进行内存碎片整理，默认为0，即每次Full GC之后都进行内存碎片整理。

CMS虽然使用并发的方式降低了STW的时间，但是还需要配合一些CMS的参数才能完全发挥出CMS的优势，否则甚至会降低垃圾回收的效率。因此只有掌握了CMS的原理和参数的调试，才能让系统运行的更加流畅。