JVM18_CMS低延迟垃圾收集器概述原理优缺点参数设置三色标记ASTB 和 Incremental Update记忆集与卡表

Posted 2021-06-29 所得皆惊喜

文章目录

• ①. CMS概述
• ②. CMS过程(原理)
• ③. CMS优缺点
• ④. CMS参数设置
• ⑤. CMS三色标记概述、问题、解决方案
• ⑥. 原始快照SATB 和 增量更新Incremental Update
• ⑦. 记忆集与卡表

①. CMS概述

• ①. 在JDK1.5时期, HotSpot推出了一款在强交互应用中几乎可认为有划时代意义的垃圾收集器: CMS (Concurrent 一Mark 一 Sweep)收集器,这款收集器是HotSpot虚拟机中第一款真正意义上的并发收集器,它第一次实现了让垃圾收集线程与用户线程同时工作

• ②. CMS收集器的关注点是尽可能缩短垃圾收集时用户线程的停顿时间。停顿时间越短(低延迟)就越适合与用户交互的程序,良好的响应速度能提升用户体验。

• ③. CMS的垃圾收集算法采用标记一清除算法,并且也会" stop一the一world"

• ④. 不幸的是,CMS 作为老年代的收集器,却无法与JDK 1.4.0 中已经存在的新生代收集器Parallel Scavenge配合工作,所以在JDK 1. 5中使用CMS来收集老年代的时候,新生代只能选择ParNew或者Serial收集器中的一个

• ⑤. 在G1出现之前,CMS使用还是非常广泛的。一直到今天,仍然有很多系统使用CMS GC
  

②. CMS过程(原理)

• ①. 初始标记(Initial一Mark)仅仅只是标记出和GCRoots能直接关联到的对象,有STW现象、暂时时间非常短

• ②. 并发标记(Concurrent一Mark)阶段:从GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行(并发标记阶段有三色标记,下文有记录)

• ③. 重新标记(Remark) 阶段:有些对象可能开始是垃圾,在并发标记阶段,由于用户线程的影响,导致不是垃圾了,这里需要重新标记的是这部分对象,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短

• ④. 并发清除:此阶段清理删除掉标记阶段判断的已经死亡的对象,释放内存空间。由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的

• ⑤. 补充说明:

1. 在CMS回收过程中,还应该确保应用程序用户线程有足够的内存可用。因此,CMS收集器不能像其他收集器那样等到老年代几乎完全被填满了再进行收集,而是当堆内存使用率达到某一阈值时,便开始进行回收,以确保应用程序在CMS工作过程中依然有足够的空间支持应用程序运行。要是CMS运行期间预留的内存无法满足程序需要,就会出现一次“Concurrent Mode Failure”失败,这时虚拟机将启动后备预案:临时启用Serial 0ld收集器来重新进行老年代的垃圾收集,这样停顿时间就很长了。
2. CMS收集器的垃圾收集算法采用的是标记一清除算法,这意味着每次执行完内存回收后,由于被执行内存回收的无用对象所占用的内存空间极有可能是不连续的一些内存块,不可避免地将会产生一些内存碎片。 那么CMS在为新对象分配内存空间时,将无法使用指针碰撞(Bump the Pointer) 技术,而只能够选择空闲列表(Free List) 执行内存分配。
   (在并发标记阶段一开始不是垃圾,最后变成了垃圾)

③. CMS优缺点

• ①. 优点:并发收集、低延迟

• ②. CMS的弊端:

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

• ③.区分两个注意事项

1. 并发标记阶段,在遍历GCRoots,用户线程也在执行,若此时遍历过一个对象发现没有引用,但由于用户线程并发执行,这期间可能导致遍历过的这个对象又被其他对象引用,所以才需要重新标记阶段再遍历一次看又没有漏标记的,否则就会导致被重新引用的对象被清理掉
2. 浮动垃圾:在并发标记阶段一开始不是垃圾,最后变成了垃圾(属于多标的情况)

④. CMS参数设置

• ①. -XX:+UseConcMarkSweepGc:手动指定使用CMS收集器执行内存回收任务
  (开启该参数后会自动将一XX: +UseParNewGc打开。即: ParNew (Young区用) +CMS (0ld区用) +Serial 0ld的组合)

• ②. -XX:CMSlnitiatingOccupanyFraction:设置堆内存使用率的阈值,一旦达到该阈值,便开始进行回收

1. JDK5及以前版本的默认值为68,即当老年代的空间使用率达到68%时,会执行一次CMS 回收。JDK6及以上版本默认值为92%
2. 如果内存增长缓慢,则可以设置一个稍大的值,大的阈值可以有效降低CMS的触发频率,减少老年代回收的次数可以较为明显地改善应用程序性能。反之,如果应用程序内存使用率增长很快,则应该降低这个阈值,以避免频繁触发老年代串行收集器。因此通过该选项便可以有效降低Full GC的执行次数

• ③. -XX:+UseCMSCompactAtFullCollection:用于指定在执行完Full GC后对内存空间进行压缩整理,以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行,所带来的问题就是停顿时间变得更长了

• ④. -XX:CMSFullGCsBeforeCompaction:设置在执行多少次Full GC后对内存空间进行压缩整理

• ⑤. -XX:ParallelCMSThreads:设置CMS的线程数量
  (CMS 默认启动的线程数是(ParallelGCThreads+3)/4,ParallelGCThreads 是年轻代并行收集器的线程数。当CPU 资源比较紧张时,受到CMS收集器线程的影响,应用程序的性能在垃圾回收阶段可能会非常糟糕)

⑤. CMS三色标记概述、问题、解决方案

• ①. 在并发标记的过程中,因为标记期间应用线程还在继续跑,对象间的引用可能发生变化,多标和漏标的情况就有可能发生。这里我们引入“三色标记”来给大家解释下,把Gcroots可达性分析遍历对象过程中遇到的对象, 按照“是否访问过”这个条件标记成以下三种颜色:

1. 黑色(black):节点被遍历完成,而且子节点都遍历完成
2. 灰色(gray): 当前正在遍历的节点,而且子节点还没有遍历
3. 白色(white):还没有遍历到的节点,即灰色节点的子节点
   

• ②. 根据三色扫描算法,如果有下面两种情况发生,则会出现漏扫描的场景:

1. 把一个白对象的引用存到黑对象的字段里,如果这个情况发生,因为标记为黑色的对象认为是扫描完成的,不会再对他进行扫描。只能通过灰色的对象(CMS垃圾收集器)
   (如上图中的D如果是白色对象没有引用,某一个时刻由于用户线程的影响,将A黑色对象引用了D的情况,解决办法:使用写屏障和增量更新解决)
2. 某个白对象失去了所有能从灰对象到达它的引用路径(直接或间接)(G1垃圾收集器)
   (如上图中的B灰色对象某一个时刻由于用户线程的影响将B到D的引用置为null,解决办法:使用写屏障和原始快照)

• ③. 三色过程:如下图所示,假如说A引入了B,B引用了C,D没有被任何引用。那么首先我们的CMS首先扫描到了A,发现A有引用B,那么我们的CMS会将A标记为黑色,B标记为灰色,然后这时候,通过B又找到了C那么这个时候发现C已经没有任何引用了就会将C标记为黑色。但是我们的D到目前为止没有被任何引用,记住我这里说的条件!那么D从始至终都没有被扫描,此时就会一直是白色,对于白色的对象来说CMS在执行并发清理的时候就会将此类对象干掉。
  但是这里有了一个问题:如果我们的扫描过程已经结束这一段了,但是此时此刻我的A突然引用了D类型怎么办,这样一来我们的D只要被GC干掉是不是就会出现问题？也就是说我这里产生了一个漏标的问题。当然,我们的JVM开发人员可不是傻子,这里他们用了一个操作叫做增量更新和写屏障来解决这种问题的。

⑥. 原始快照SATB 和 增量更新Incremental Update

• ①. 增量更新(Incremental Update):在并发标记过程中,把赋值的这种新增的引用,做一个集合存起来。 在重新标记的时候会找到集合里面的引用然后重新去扫描,再把源头标记为灰色。这就是我们的增量更新
  (如下图中的D如果是白色对象没有引用,某一个时刻由于用户线程的影响,将A黑色对象引用了D的情况,解决办法:使用写屏障(这个写屏障在之后)和增量更新解决)
  
• ②. 在把我们新增的引用放到集合的时候,会实现一种写屏障的方式。在对象前后通过一个dirty card queue将引用信息, 存在card中,这个dirty card queue会放在cardtable中,而cardtable是记忆集的具体实现,最终这个引用就会放在记忆集中的
  (写屏障我们可以理解为在赋值操作的前面加一个方法,赋值的后面做一些操作,也可以理解为AOP。具体的C++实现代码如下图:)

• ③. 原始快照(SATB)算法认为开始标记的都认为是活的对象,如上下图所示,引用B到D的引用改为B到C时,通过write barrier写屏障技术,会把B到D的引用推到gc遍历执行的堆栈上,保证还可以遍历到D对象,相对于d来说,引用从B–>A,SATB 是从源入手解决的,即上面说的第2种情况,
  这也能理解为啥叫satb了,即认为开始时所有能遍历到的对象都是需要标记的,即都认为是活的。如果我把b = null,那么d就是垃圾了, satb算法也还是会把D最终标记为黑色,导致D在本轮gc不能回收,成了浮动垃圾
  (自己的理解:如上图中的B灰色对象某一个时刻由于用户线程的影响将B到D的引用置为null,解决办法:使用原始快照和写屏障 注意:这个写屏障在前面)
  
  

⑦. 记忆集与卡表

• ①. 在刚刚我们再说写屏障的时候提到了卡表,那么我们现在就来说说卡表是干什么用的。但是在说记忆集与卡表之前,我们要先知道what is 跨带引用~

• ②. 跨带引用:
  所谓跨带引用就是老年代的对象引用了新生代的对象,或者新生代的对象引用了老年代的对象。那对于这种情况我们的GC在进行扫描的时候不可能直接把我们的整个堆都扫描完,那这样效率也太低了。所以这时候就需要开辟了一小块空间,维护这种引用,而不必让GC扫描整个堆区域。

• ③. 记忆集(在新生代中)
  记忆集也叫rememberSet,垃圾收集器在新生代中建立了记忆集这样的数据结构,用来避免把整个老年代加入到GC ROOTS的扫描范围中。对于记忆集来说,我们可以理解为他是一个抽象类,那么具体实现它的方法将由子类去完成。这里我们简单列举一下实现记忆集的三种方式:
  1.字长精度
  2.对象精度
  3.卡精度(卡表)

• ④. 卡表(在老年代中)
  卡表(Card Table)是一种对记忆集的具体实现。主要定义了记忆集的记录精度、与堆内存的映射关系等。卡表中的每一个元素都对应着一块特定大小的内存块,这个内存块我们称之为卡页(card page),当存在跨带引用的时候,它会将卡页标记为dirty。那么JVM对于卡页的维护也是通过写屏障的方式,这也就是为什么刚刚我们跟进写屏障操作到最后会发现它会对卡表进行一系列的操作。