垃圾收集器-CMS、三色标记、记忆集

Posted 2023-04-27

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了垃圾收集器-CMS、三色标记、记忆集相关的知识，希望对你有一定的参考价值。

参考技术A     CMS（Concurrent Mark Sweep）收集器是一种以获取最短回收停顿时间为目标的收集器。它非常符合在注重用户体验的应用上使用，它是HotSpot虚拟机第一款真正意义上的并发收集器，它第一次实现了让垃圾收集线程与用户线程（基本上）同时工作。

    从名字中的Mark Sweep这两个词可以看出，CMS收集器是一种 “标记-清除”算法实现的，它的运作过程相比于前面几种垃圾收集器来说更加复杂一些。整个过程分为四个步骤：

初始标记：

  暂停所有的其他线程(STW)，并记录下gc roots直接能引用的对象，速度很快

并发标记：

  并发标记阶段就是从GC Roots的直接关联对象开始遍历整个对象图的过程，这个过程耗时较长但是不需要停顿用户线程，可以与垃圾收集线程一起并发运行。因为用户程序继续运行，可能会有导致已经标记过的对象状态发生改变。

重新标记：

  重新标记阶段就是为了修正并发标记期间因为用户程序继续运行而导致标记产生变动的那一部分对象的标记记录，这个阶段的停顿时间一般会比初始标记阶段的时间稍长，远远比并发标记阶段时间短。主要用到三色标记里的增量更新算法(见下面详解)做重新标记。

并发清理：

    开启用户线程，同时GC线程开始对未标记的区域做清扫。这个阶段如果有新增对象会被标记为黑色不做任何处理(见下面三色标记算法详解)。

并发重置：

  重置本次GC过程中的标记数据。

从它的名字就可以看出它是一款优秀的垃圾收集器，主要优点：并发收集、低停顿。但是它有下面几个明显的缺点：

1.对CPU资源敏感（会和服务抢资源）；

2.无法处理浮动垃圾( 在并发标记和并发清理阶段又产生垃圾，这种浮动垃圾只能等到下一次gc再清理了)；

3.它使用的回收算法-“标记-清除”算法会导致收集结束时会有大量空间碎片产生，当然通过参数-XX:+UseCMSCompactAtFullCollection可以让jvm在执行完标记清除后再做整理执行过程中的不确定性，会存在上一次垃圾回收还没执行完，然后垃圾回收又被触发的情况，特别是在并发标记和并发清理阶段会出现，一边回收，系统一边运行，也许没回收完就再次触发full gc，也就是"concurrent mode failure"，此时会进入stop the world，用serial old垃圾收集器来回收

CMS的相关核心参数

1.-XX:+UseConcMarkSweepGC：启用cms

2.-XX:ConcGCThreads：并发的GC线程数

3.-XX:+UseCMSCompactAtFullCollection：FullGC之后做压缩整理（减少碎片）

4.-XX:CMSFullGCsBeforeCompaction：多少次FullGC之后压缩一次，默认是0，代表每次FullGC后都会压缩一次

5.-XX:CMSInitiatingOccupancyFraction: 当老年代使用达到该比例时会触发FullGC（默认是92，这是百分比）

6.-XX:+UseCMSInitiatingOccupancyOnly：只使用设定的回收阈值(-XX:CMSInitiatingOccupancyFraction设定的值)，如果不指定，JVM仅在第一次使用设定值，后续则会自动调整

7.-XX:+CMSScavengeBeforeRemark：在CMS GC前启动一次minor gc，目的在于减少老年代对年轻代的引用，降低CMS GC的标记阶段时的开销，一般CMS的GC耗时 80%都在标记阶段

8.-XX:+CMSParallellnitialMarkEnabled：表示在初始标记的时候多线程执行，缩短STW

9.-XX:+CMSParallelRemarkEnabled：在重新标记的时候多线程执行，缩短STW;

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

黑色：

  表示对象已经被垃圾收集器访问过，且这个对象的所有引用都已经扫描过。黑色的对象代表已经扫描过，它是安全存活的，如果有其他对象引用指向了黑色对象，无须重新扫描一遍。黑色对象不可能直接（不经过灰色对象）指向某个白色对象。

灰色：

    表示对象已经被垃圾收集器访问过，但这个对象上至少存在一个引用还没有被扫描过。

白色:

    表示对象尚未被垃圾收集器访问过。显然在可达性分析刚刚开始的阶段，所有的对象都是白色的，若在分析结束的阶段，仍然是白色的对象，即代表不可达。

标记过程：

初始时，所有对象都在【白色集合】中；

将GC Roots 直接引用到的对象挪到【灰色集合】中；

从灰色集合中获取对象：

3.1. 将本对象引用到的其他对象全部挪到【灰色集合】中；

3.2. 将本对象挪到【黑色集合】里面。

重复步骤3，直至【灰色集合】为空时结束。

结束后，仍在【白色集合】的对象即为GC Roots 不可达，可以进行回收

多标-浮动垃圾

    在并发标记过程中，如果由于方法运行结束导致部分局部变量(gcroot)被销毁，这个gcroot引用的对象之前又被扫描过 (被标记为非垃圾对象)，那么本轮GC不会回收这部分内存。这部分本应该回收但是没有回收到的内存，被称之为“浮动垃圾”。浮动垃圾并不会影响垃圾回收的正确性，只是需要等到下一轮垃圾回收中才被清除。

    另外，针对并发标记(还有并发清理)开始后产生的新对象，通常的做法是直接全部当成黑色，本轮不会进行清除。这部分对象期间可能也会变为垃圾，这也算是浮动垃圾的一部分。

漏标-读写屏障

漏标只有同时满足以下两个条件时才会发生：

   条件一：灰色对象断开了白色对象的引用；即灰色对象原来成员变量的引用发生了变化。

    条件二：黑色对象重新引用了该白色对象；即黑色对象成员变量增加了新的引用。

漏标会导致被引用的对象被当成垃圾误删除，这是严重bug，必须解决，有两种解决方案：增量更新（Incremental Update）和原始快照（Snapshot At The Beginning，SATB）。

增量更新就是当黑色对象插入新的指向白色对象的引用关系时，就将这个新插入的引用记录下来，等并发扫描结束之后，再将这些记录过的引用关系中的黑色对象为根，重新扫描一次。这可以简化理解为，黑色对象一旦新插入了指向白色对象的引用之后，它就变回灰色对象了。

原始快照就是当灰色对象要删除指向白色对象的引用关系时，就将这个要删除的引用记录下来，在并发扫描结束之后，再将这些记录过的引用关系中的灰色对象为根，重新扫描一次，这样就能扫描到白色的对象，将白色对象直接标记为黑色(目的就是让这种对象在本轮gc清理中能存活下来，待下一轮gc的时候重新扫描，这个对象也有可能是浮动垃圾)

以上无论是对引用关系记录的插入还是删除，虚拟机的记录操作都是通过写屏障实现的。

写屏障实现原始快照（SATB）：当对象B的成员变量的引用发生变化时，比如引用消失（a.b.d = null），我们可以利用写屏障，将B原来成员变量的引用对象D记录下来：

写屏障实现增量更新：当对象A的成员变量的引用发生变化时，比如新增引用（a.d = d），我们可以利用写屏障，将A新的成员变量引用对象D 记录下来：

记忆集

当我们进行young gc时，我们的 gc roots除了常见的栈引用、静态变量、常量、锁对象、class对象这些常见的之外，如果老年代有对象引用了我们的新生代对象，那么老年代的对象也应该加入gc roots的范围中，但是如果每次进行young gc我们都需要扫描一次老年代的话，那我们进行垃圾回收的代价实在是太大了，因此我们引入了一种叫做记忆集的抽象数据结构来记录这种引用关系。

什么是记忆集?

    记忆集是一种用于记录从非收集区域指向收集区域的指针集合的数据结构。

    如果我们不考虑效率和成本问题，我们可以用一个数组存储所有有指针指向新生代的老年代对象。但是如果这样的话我们维护成本就很好，打个比方，假如所有的老年代对象都有指针指向了新生代，那么我们需要维护整个老年代大小的记忆集，毫无疑问这种方法是不可取的。因此我们引入了卡表的数据结构

什么是卡表？

    记忆集是我们针对于跨代引用问题提出的思想，而卡表则是针对于该种思想的具体实现。（可以理解为记忆集是结构，卡表是实现类）

    在hotspot虚拟机中，卡表是一个字节数组，数组的每一项对应着内存中的某一块连续地址的区域，如果该区域中有引用指向了待回收区域的对象，卡表数组对应的元素将被置为1，没有则置为0；

G1的记忆集

上述的卡表机制基本上适用于CMS垃圾回收器，因为CMS垃圾回收器只需要在young gc时维护老年代对新生代的引用即可，但是G1垃圾回收器不一样，因为G1垃圾回收器是基于分区模型的，所以每一个Region需要知道有哪些region的引用指向了它，并且这些region是不是本次垃圾回收区域的一部分。因此G1垃圾回收器不能简单的只维护一个卡表(卡表只能简单的知道某块内存区域有没有引用收集区域的对象，但是不能知道到底是谁引用了自己)，所以在 G1垃圾回收器的记忆集的实现实际上是基于哈希表的，key代表的是其他region的起始地址，value是一集合，里面存放了对应区域的卡表的索引，因此G1的region能够通过记忆集知道，当前是哪个region有引用指向了它，并且能知道是哪块区域存在指针指向。

但是大家应该能注意到，每个region都维护一个记忆集，内存占用量肯定很大，这也就是为什么G1垃圾回收器比传统的其他垃圾回收器要有更高的内存占用。据统计G1至少要耗费大约10%-20%的Java堆空间来维护收集器的工作。

参考：

https://blog.csdn.net/xc1989xc/article/details/107466313

https://blog.csdn.net/shangshanzixu/article/details/113918994

JVM18_CMS低延迟垃圾收集器概述原理优缺点参数设置三色标记ASTB 和 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收集器在JDK9中被废弃,在JDK14中被移除

②. CMS过程(原理)

①. 初始标记(Initial一Mark)仅仅只是标记出和GCRoots能直接关联到的对象,有STW现象、暂时时间非常短
②. 并发标记(Concurrent一Mark)阶段:从GC Roots的直接关联对象开始遍历整个对象图的过程,这个过程耗时较长但是不需要停顿用户线程,可以与垃圾收集线程一起并发运行(并发标记阶段有三色标记,下文有记录)
③. 重新标记(Remark) 阶段:有些对象可能开始是垃圾,在并发标记阶段,由于用户线程的影响,导致不是垃圾了,这里需要重新标记的是这部分对象,这个阶段的停顿时间通常会比初始标记阶段稍长一些,但也远比并发标记阶段的时间短
④. 并发清除:此阶段清理删除掉标记阶段判断的已经死亡的对象,释放内存空间。由于不需要移动存活对象,所以这个阶段也是可以与用户线程同时并发的
⑤. 补充说明:

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

③. CMS优缺点

①. 优点:并发收集、低延迟
②. CMS的弊端:

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

③.区分两个注意事项

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

④. CMS参数设置

①. -XX:+UseConcMarkSweepGc:手动指定使用CMS收集器执行内存回收任务
(开启该参数后会自动将一XX: +UseParNewGc打开。即: ParNew (Young区用) +CMS (0ld区用) +Serial 0ld的组合)
②. -XX:CMSlnitiatingOccupanyFraction:设置堆内存使用率的阈值,一旦达到该阈值,便开始进行回收

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

③. -XX:+UseCMSCompactAtFullCollection:用于指定在执行完Full GC后对内存空间进行压缩整理,以此避免内存碎片的产生。不过由于内存压缩整理过程无法并发执行,所带来的问题就是停顿时间变得更长了
④. -XX:CMSFullGCsBeforeCompaction:设置在执行多少次Full GC后对内存空间进行压缩整理
⑤. -XX:ParallelCMSThreads:设置CMS的线程数量
(CMS 默认启动的线程数是(ParallelGCThreads+3)/4,ParallelGCThreads 是年轻代并行收集器的线程数。当CPU 资源比较紧张时,受到CMS收集器线程的影响,应用程序的性能在垃圾回收阶段可能会非常糟糕)

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

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

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

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

把一个白对象的引用存到黑对象的字段里,如果这个情况发生,因为标记为黑色的对象认为是扫描完成的,不会再对他进行扫描。只能通过灰色的对象(CMS垃圾收集器)
(如上图中的D如果是白色对象没有引用,某一个时刻由于用户线程的影响,将A黑色对象引用了D的情况,解决办法:使用写屏障和增量更新解决)
某个白对象失去了所有能从灰对象到达它的引用路径(直接或间接)(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对于卡页的维护也是通过写屏障的方式,这也就是为什么刚刚我们跟进写屏障操作到最后会发现它会对卡表进行一系列的操作。
注意:(1). 卡表是使用一个字节数组实现:CARD_TABLE[ ],每个元素对应着其标识的内存区域一块特定大小的内存块,称为"卡页"。hotSpot使用的卡页是2^9大小,即512字节
(2). 一个卡页中可包含多个对象,只要有一个对象的字段存在跨代指针,其对应的卡表的元素标识就变成1,表示该元素变脏,否则为0。GC时,只要筛选本收集区的卡表中变脏的元素加入GCRoots里。