CMS垃圾回收器
CMS是一种已获得最短回收停顿时间为目标的收集器。
CMS垃圾回收器基于标记-清除算法实现,那么使用该算法的最大缺点也显而易见——大量的内存碎片。内存碎片过多时会给大对象分配带来麻烦,即会存在空间足够,但是连续的空间太小,这样的话就会触发Full GC
CMS解决办法:使用 -XX:CMSFullGCsBefore-Compaction(JDK9之后废弃),即CMS在并发执行若干此Full GC之后,下一次Full GC会先进行碎片整理。(默认为0,即每次都整理)
回收流程:
- 初始标记:仅仅是标记GCRoots能直接关联到的对象,速度快
- 并发标记:从GCRoots能直接关联到的对象开始进行引用链的遍历,耗时长但不需要停顿用户线程
- 重新标记:修正并发标记阶段,因用户线程继续运作而导致的标记产生变动的那一部分对象的标记记录,CMS使用增量更新来解决,停顿时间长但也比并发标记阶段短
- 并发清除:清理被标记的对象,该阶段也是与用户现场并发执行。
CMS默认回收线程数:(处理器核心数量 + 3) / 4
相关面试题
CMS垃圾收集器,用在哪个年代为什么
用在老年代,因为CMS垃圾回收器使用的标记-清除算法,而标记和清除的效率随着对象的增多而降低,如果用在新生代那么效率会很低
CMS怎样进行垃圾回收,哪些过程是stop the world
初始标记和重新标记需要 stop the world
CMS的缺点,什么是浮动垃圾,浮动垃圾过多会有什么影响
浮动垃圾:在CMS并发标记阶段,用户线程还是在继续运行的,程序在运行自然就还会伴随着新的垃圾对象产生,但是这部分垃圾对象实在标记完成后出现的,所以CMS无法处理它们,只能留着等待下一次垃圾回收进行处理。
浮动垃圾过多可能对导致Concurrent Mode Failure失败进而导致一次完全的 stop the world的Full GC产生。
最后
我是 Code皮皮虾,一个热爱分享知识的 皮皮虾爱好者,未来的日子里会不断更新出对大家有益的博文,期待大家的关注!!!
创作不易,如果这篇博文对各位有帮助,希望各位小伙伴可以一键三连哦!,感谢支持,我们下次再见~~~
分享大纲
更多精彩内容分享,请点击 Hello World (●’◡’●)