CMS(Concurrent-Mark-Sweep)垃圾回收器
1.1 概述
CMS垃圾回收器在jdk1.5时诞生,在jdk的历史上有划时代的意义,因为他是第一个并发垃圾回收器,支持垃圾回收线程和用户线程交替执行,从而达到低延迟的目的.
因此,CMS的目标和适用场景就是低延迟,与Parallel是两个方向
CMS是针对老年代回收垃圾回收器,但是因为底层框架原因,他只能与Serial/ParNew组合使用,并不能与Parallel Scavenge组合使用.
CMS使用**标记-清除算法,**同时存在STW问题,但是STW的时间要远远小于其他垃圾回收器.
在jdk14中,已经移除CMS垃圾回收器,其实就是使用G1全面替代CMS
1.2 CMS执行过程
作为一个并发执行的垃圾回收器,CMS就不存在STW了吗,并发执行是怎么执行的?
从执行过程中详细了解:
执行图:
1、 初始标记(Initial-Mark):STW,初始标记主要标记GCRoots直接关联的可达对象,不考虑层级关系,标记完成后就恢复用户线程,所以时间较短;
2、 并发标记(Concurrent-Mark):这段时间是不存在STW的,垃圾回收线程与用户线程并发执行,主要是根据初始标记中的直接对象关联层级对象,这个过程用户线程不受影响;
3、 重新标记(Remark):STW,重新标记主要是为了修正并发标记中用户程序变动的一部分可达对象,为了准确性,因此需要停止用户线程,这个时间要比初始标记稍长,但也远远小于并发标记的时间,因为只标记用户线程在并发标记阶段运行的那部分对象.;
4、 并发清理(Concurrent-Sweep):并发清理,在标记完成后,清理阶段其实跟用户线程已经没有太多的关系,因此并发执行用户线程不受影响.;
可以看到CMS将垃圾回收的过程分为几个部分,将需要STW的阶段拆分出来,减少了不必要的STW,从而减少延迟.
1.3 工作原理
1.3.1 简述CMS工作原理
低延迟是怎么实现的?
CMS通过并发标记非直接对象和并发清理来缩短STW,从而达到低延迟的效果
CMS是内存不足时才开始回收的吗?
不是,由于CMS的垃圾回收过程中包含了用户线程并发执行,因此必须预留用户线程能够正常执行的内存,所以在内存占用到某一个阈值时就必须开始回收.
CMS如果回收过程中,内存不足,用户线程怎么执行,CMS还能并发回收吗?
如果在并发回收的过程中出现内存不足的情况,那么CMS会报错 Concurrent Mode Failure,然后启用后备方案Serial Old进行垃圾回收,此时改为串行垃圾回收器,不在具有低延迟的优点.
CMS采用标记-清除算法,存在碎片问题,为什么不使用标记-压缩算法?
因为CMS在清除阶段是并发执行的,垃圾回收线程和用户线程交替执行,而压缩算法的原理是将可达对象的内存地址修改到另外一块内存区域,从而使内存占用规整,这个移动的过程中,对象是不可以使用的,即(STW状态下才能移动对象内存地址),显然CMS并发清理不适用这种场景.
可以说标记-压缩算法/复制算法都必须在STW的前提下.
1.4 优点
低延迟
并发收集
1.5 缺点
1、 采用标记-清除算法,容易删除内存碎片,内存碎片过多会导致提前出发FullGC;
2、 并发执行垃圾回收线程,占用一部分用户线程资源,降低吞吐量;
3、 无法回收浮动垃圾,浮动垃圾只能等到下次gc才能回收.;
1、 浮动垃圾:在并发标记阶段由用户线程执行产生的垃圾称为浮动垃圾;CMS重新标记阶段只能标记在并发标记阶段怀疑的垃圾对象,不能标记新产生的垃圾对象.;
1.6 CMS相关jvm参数
1.6.1 指定使用CMS垃圾回收器
-XX:+UseConcMarkSweepGC
使用此参数会指定 新生代使用ParNew 老年代使用CMS+Serial Old(后备方案)
运行结果:
1.6.2 指定触发CMS垃圾回收的内存阈值
在工作原理中提到过,当内存占用到达一定的阈值,则会触发CMS,这个阈值在jdk1.6之前默认是68%,在jdk1.6之后是**92%,**我们也可以通过参数设置
-XX:CMSInitiatingOccupanyFraction
注意: 这个参数的调整需要根据内存增长的速度来调整,此参数直接影响应用程序的性能
当内存增长较慢时,可以将阈值调大,降低CMS的频率,从而提高吞吐量
当内存增长较快时,将阈值调小,避免在CMS并发回收时,出现内存不足,导致CMS回收失败,触发Serial Old串行垃圾回收器的情况.
1.6.3 设置内存碎片整理
工作原理中提到过CMS是基于标记-清除算法的,存在内存碎片问题,那么如何整理内存碎片呢? 通过jvm参数可以控制:
# 启用在FullGC后使用压缩算法整理内存空间
-XX:+UseCMSCompactAtFullCollection
# 设置多少次FullGC后整理
-XX:CMSFullGCsBeforeCompaction
两个参数配套使用,可以设置多少次FullGC后整理一次内存空间.
1.6.4 设置CMS并发线程数量
-XX:ParallelCMSThreads
默认值为: (ParallelGCThreads(默认cpu核数) + 3 ) / 4
例:4核cpu 默认值为 (4+3)/4 = 1 垃圾并发线程为1
垃圾回收线程不宜过多,过多影响用户线程的执行,减小吞吐量.
版权声明:本文不是「本站」原创文章,版权归原作者所有 | 原文地址: