CMS垃圾回收器并发标记、内存碎片、浮动垃圾、优缺点总结

CMS垃圾收集器的浮动垃圾

1. 在并发标记阶段本来可达的对象，由于用户线程的作用变得不可达了，即产生新的垃圾对象，CMS将无法对这些垃圾对象进行标记，最终导致这些新产生的垃圾对象没有被及时回收。【重新标记阶段只会利用增量更新来解决因并发标记阶段产生的对象消失问题，而浮动垃圾的产生原因是因为已经被GC线程被标记为黑色了，但用户线程接着又取消了对它的所有引用，但是黑色对象并不会被重新扫描，所以重新标记是找不到浮动垃圾的，就算能解决，并发清理阶段一样会产生浮动垃圾，而并发清理已经是最后一个阶段了，所以浮动垃圾只能下次垃圾回收的时候才能被回收】
2. 在并发清理阶段也可能产生新的垃圾，也被称为浮动垃圾。

        重新标记阶段主要是对并发标记阶段所有标记的非可达对象进行标记，标记出在并发标记new的新对象，在初始标记阶段和并发标记阶段没有将其标记为可达的，从而产生致命性错误。

 CMS垃圾收集器的优缺点

优点：并发收集、低延迟。

缺点：会产生内存碎片、CMS收集器对CPU资源敏感、CMS收集器无法处理浮动垃圾

• 会产生内存碎片：,导致并发清除后,用户线程可用的空间不足。在无法分配大对象的情况下,不得不提前触发Full GC。
• CMS收集器对CPU资源非常敏感：。在并发阶段,它虽然不会导致用户停顿,但是会因为占用了一部分线程而导致应用程序变慢,总吞吐量会降低。
• CMS收集器无法处理浮动垃圾。可能出现"Concurrent Mode Failure"失败而导致另一次Full GC的产生。在并发标记阶段由于程序的工作线程和垃圾收集线程是同时运行或者交叉运行的,那么在并发标记阶段如果产生新的垃圾对象,CMS将无法对这些垃圾对象进行标记,最终会导致这些新产生的垃圾对象没有被及时回收,从而只能在下一次执行GC时释放这些之前未被回收的内存空间。

 CMS浮动垃圾引起的问题

        在并发标记阶段以及并发清理阶段可能产生一定的浮动垃圾，CMS对这部分垃圾不进行处理的，只会等下一次GC的时候处理。 这就会产生一个问题，当老年代的内存空间存放不下这些浮动垃圾时，就会导致并发失败。这时候虚拟机将不得不启动后备预案：冻结用户线程的执行，临时启用Serial Old收集器来重新进行老年代的垃圾收集，但这样停顿时间就很长了。

CMS内存碎片引起的问题

        CMS是一款基于“标记-清除”算法实现的收集器，这意味着收集结束时会有大量空间碎片产生。空间碎片过多时，将会给大对象分配带来很大麻烦，往往会出现老年代还有很多剩余空间，但就是无法找到足够大的连续空间来分配当前对象，而不得不提前触发一次Full GC的情况。

1. CMS存在一个默认的参数 “-XX:+UseCMSCompactAtFullCollection”，意思是在Full GC之后再次STW，停止工作线程，整理内存空间，将存活的对象移到一边。
2. 还有一个参数是“-XX:+CMSFullGCsBeforeCompaction”,表示在进行多少次Full GC之后进行内存碎片整理，默认为0，即每次Full GC之后都进行内存碎片整理。

CMS并发标记阶段是否会标记所有的对象

        不会，CMS会内置记录在并发标记期间那些被新建的对象或者有变动的对象，因此重新标记阶段不需要再重新标记所有对象，只对并发标记阶段改动过的对象做标记即可。

• 新建的对象。
• 有变动的对象，这里的有变动指的仅仅是原来不可达但是由于并发标记阶段线程之间的作用使不可达变为可达，此时在重新标记阶段需要对其标记，防止GC回收造成严重错误。
  • 为什么不对原本可到->不可达的对象进行标记，此时需要从GCroot重新开始依次查找标记，相当于返回了并发标记，不符合CMS设计理念。

参考链接

CMS垃圾收集器：重新标记和浮动垃圾的思考_重新标记阶段为什么不能处理浮动垃圾-CSDN博客 CMS的特点与弊端分析 - 简书