三色标记算法理论、漏标、SATB

野性酷女 2021-06-10 20:39 376阅读 0赞

**G1收集概览：**

G1算法将堆划分为若干个区域（Region），它仍然属于分代收集器。不过，这些区域的一部分包含新生代，新生代的垃圾收集依然采用暂停所有应用线程的方式，将存活对象拷贝到老年代或者Survivor空间。老年代也分成很多区域，G1收集器通过将对象从一个区域复制到另外一个区域，完成了清理工作。这就意味着，在正常的处理过程中，G1完成了堆的压缩（至少是部分堆的压缩），这样也就不会有CMS内存碎片问题的存在了。

**Humongous区域：**

在G1中，还有一种特殊的区域，叫Humongous区域。如果一个对象占用的空间达到或者超过了分区容量50%以上，G1收集器就认为这是一个巨型对象。这些巨型对象，默认直接会被分配在老年代，但是如果它是一个短期存在的巨型对象，就会对垃圾收集器造成负面影响。为了解决这个问题，G1划分了一个Humongous区，它用来专门存放巨型对象。如果一个H区装不下一个巨型对象，那么G1会寻找连续的H分区来存储。为了能找到连续的H区，有时候不得不启动Full GC。

**G1 Young GC:**

*  Young GC主要是对Eden区进行GC，它在Eden空间耗尽时会被触发。在这种情况下，Eden空间的数据移动到Survivor空间中，如果Survivor空间不够，Eden空间的部分数据会直接晋升到老年代空间。Survivor区的数据移动到新的Survivor区中，也有部分数据晋升到老年代空间中。最终Eden空间的数据为空，GC完成工作，应用线程继续执行。
 *  如果仅仅GC新生代对象，我们如何找到所有的根对象呢？老年代的所有对象都是根么？那这样扫描下来会耗费大量的时间。于是,G1引进了RSet的概念。它的全称是Remembered Set，作用是跟踪指向某个heap区内的对象引用。下面看图：  
    ![c10793dc2790a82a85ae0f49e2cc5df0.png][]
 *  在CMS中，也有RSet的概念，在老年代中有一块区域用来记录指向新生代的引用。这是一种point-out，在进行Young GC时，扫描根时，仅仅需要扫描这一块区域，而不需要扫描整个老年代。 
 *  但在G1中，并没有使用point-out，这是由于一个分区太小，分区数量太多，如果是用point-out的话，会造成大量的扫描浪费，有些根本不需要GC的分区引用也扫描了。
 *  于是G1中使用point-in来解决。point-in的意思是哪些分区引用了当前分区中的对象。这样，仅仅将这些对象当做根来扫描就避免了无效的扫描。
 *  由于新生代有多个，那么我们需要在新生代之间记录引用吗？这是不必要的，原因在于每次GC时，所有新生代都会被扫描，所以只需要记录老年代到新生代之间的引用既可。
 *  需要注意的是，如果引用的对象很多，赋值器需要对每个引用做处理，赋值器开销会很大，为了解决赋值器开销这个问题，在G1中又引入了另外一个概念，卡表（Card Table）。一个Card Table将一个分区在逻辑上划分为固定大小的连续区域，每个区域称之为卡。卡通常较小，介于128到512字节之间。Card Table通常为字节数组，由Card的索引（既数组下标）来标识每个分区的空间地址。
 *  默认情况下，每个卡都未被引用。当一个地址空间被引用时，这个地址空间对应的数组索引的值被标记为“0”，既标记为被引用，此外RSet也将这个数组下标记录下来。一般情况下，这个RSet其实是一个Hash Table，key是别的Region的起始地址，Value是一个集合，里面的元素是Card Table的Index。

另外它分为下几个阶段：

*  阶段1：根扫描  
    表态和本地对象被扫描
 *  阶段2：更新RS  
    处理dirty card队列更新RS
 *  阶段3：处理RS  
    检测从年轻代指向老年代的对象
 *  阶段4：对象拷贝  
    拷贝存活的对象到survivor/old区域
 *  阶段5：处理引用队列  
    软引用、弱引用、虚引用处理

**再谈Mixed GC:**

*  Mixed GC不仅进行正常的新生代垃圾收集，同时也回收部分后台扫描线程标记的老年代分区。
 *  这的GC步骤分为两步：  
    1、全局并发标记（global concurrent marking）  
    2、拷贝存活对象（evacuation）
 *  在G1 GC中，global concurrent marking主要是为Mixed GC提供标记服务的，并不是一次GC过程的一个必须环节。global concurrent marking的执行过程分为四个步骤，这个在之前已经学习过了，回忆一下：  
    ![f89c1218bc9bb06d4c93d4f1ab3dc99d.png][]

**三色标记算法：**

*  提到并发标记，我们不得不了解并发标记的三色标记算法。它是描述追踪式回收器的一种有效的方法，利用它可以推演回收器的正确性。 
 *  我们将对象分成三种类型：  
    1、黑色：根对象，或者该对象与它的子对象都被扫描过（对象被标记了，且它的所有field也被标记完了）。  
    2、灰色：对象本身被扫描，但还没扫描完该对象中的子对象（它的field还没有被标记或标记完）。  
    3、白色：未被扫描对象，扫描完成所有对象之后，最终为白色的为不可达对象，既垃圾对象（对象没有被标记到）。

![46edcede4f14c2ab709c6cc92f0ee719.png][]

下面来看一下三色标记算法的整个过程：

*  根对象被置为黑色，子对象被置为灰色。如下图：![83200eb134b5fd682ae66404a10e643a.png][]
    
    其中可以看到灰色对象是已经被扫描过了，但是灰色对象里面所引用的子对象还未被扫描，所以可以看到灰色对象指向了未被扫描过的白色对象。
 *  继续由灰色遍历，将已扫描了子对象的对象置为黑色，如下：![407984b73d0e88d58411b9dd972861df.png][]
    
    可以看到由于灰色里面的子对象已经被扫描过了，所以原灰色对象就变成了黑色了，而它所引用的白色对象由于被扫描到了，所以白色变成了灰色了。  
    ![cc167ae3b8b1bd571e1d8b0d12ab352d.png][]
 *  遍历了所有可达的对象后，所有可达的对象都变成了黑色。不可达的对象既为白色，需要被清理：![f92495fc48210db29cadb9ed6ad8d27b.png][]
    
    其中：  
    ![57af8a31eb346d8a6418e4c0e6c0da7a.png][]
    
    因为这三个对象被扫描完之后就会由白色变成灰色，然后由于这三个对象里面没有任何其它子对象，所以就由灰度变为了黑色了。
 *  但是如果在标记过程中，应用程序也在运行，那么对象的指针就有可能改变。这样的话，我们就会遇到一个问题：对象丢失问题。那问题是如何产生的呢，下面来说一下。
 *  当垃圾收集器扫描到下面情况时：  
    ![b798a142eda203b0fae2afef02dd91db.png][]
 *  由于在GC扫描时应用程序线程也在同步执行，这时候应用程序执行了以下操作：  
    A.c = C  
    B.c = null
 *  这样， 对象的状态图变成如下情形：  
    ![844c0ff4d0710cfdad9e7f55b7d03678.png][]
 *  这时候垃圾收集器再标记扫描的时候就会变成下图这样：  
    ![034528614292fef79b7d879d21f09616.png][]
 *  由于A变成了黑色，垃圾收信器是永远不会再扫描它了，因为垃圾回收器认为A里面的所有子对象都已经扫描完了，而问题就来了，此时C是白色，被认为是垃圾需要清理掉，显示这是不合理的，明明C是一个正常可用的对象。

**SATB：**

*  在G1中，使用的是SATB(Snapshot-At-The-Beginning)的方式，删除的时候记录所有的对象。
 *  它有3个步骤【重要！】：  
    1、在开始标记的时候生成一个快照图，标记存活对象。  
    2、在并发标记的时候所有被改变的对象入队（在write barrier【写屏障】里把所有旧的引用所指向的对象都变成非白的）。  
    这样的话对于之前用三色标记可能出错的这个白色对象就会变成灰色的，如下：  
    ![dff6f02f52953e9f428613307a1426eb.png][]  
    就可以避免C正常的不被回收了。  
    3、可能存在浮动垃圾，将在下次被收集。

**G1混合式回收：**

*  G1到现在可以知道哪些老的分区可加收垃圾最多。当全局并发标记完成后，在某个时刻，就开始了Mixed GC。这些垃圾回收被称作“混合式”是因为他们不仅仅进行正常的新生代垃圾收集，同时也回收部分后台扫描线程标记的分区。
 *  混合式GC也是采用的复制清理策略，当GC完成后，会重新释放空间。

**G1分代算法：**

*  为老年代设置分区的目的是老年代里有的分区垃圾多，有的分区垃圾少，这样在回收的时候可以专注于收集垃圾多的分区，这也是G1名称的由来。
 *  不过这个算法并不适合新生代垃圾收集，因为新生代的垃圾收集算法是复制算法，但是新生代也使用了分区机制主要是因为便于代大小的调整。

**SATB详解：**

*  SATB是维持并发GC的一种手段。G1并发的基础就是SATB。SATB可以理解成在GC开始之前对堆内存里的对象做一次快照，此时活的对像就认为是活的，从而开成一个对象图。
 *  在GC收集的时候，新生代的对象也认为是活的对象，除此之外其他不可达的对象都认为是垃圾对象。
 *  如何找到在GC过程中分配的对象呢？每个region记录着两个top-at-mark-start(TAMS)指针，分别为prevTAMS和nextTAMS。在TAMS以上的对象就是新分配的，因而被视为隐式marked。
 *  通过这种方式我们就找到了在GC过程中新分配的对象，并把这些对象认为是活的对象。
 *  解决了对象在GC过程中分配的问题，那么在GC过程中引用发生变化的问题怎么解决呢？
 *  G1给出的解决办法是通过Write Barrier。Write Barrier就是对引用字段进行赋值做了额外处理。通过Write Barrier就可以了解到哪些引用对象发生了什么样的变化。
 *  mark的过程就是遍历heap标记live object的过程，采用的是三色标记算法，这三种颜色为white（表示还未访问到）、gray（访问到但是它用到的引用还没有完全扫描）、back（访问到而且其用到的引用已经完全扫描完）。
 *  整个三色标记算法就是从GC roots出发遍历heap，针对可达对象先标记white为gray，然后再标记gray为black；遍历完成之后所有可达对象都是balck的，所有white都是可以回收的。
 *  SATB仅仅对于在marking开始阶段进行“snapshot”(marked all reachable at mark start)，但是concurrent的时候并发修改可能造成对象漏标记。
 *  对black新引用了一个white对象，然后又从gray对象中删除了对该white对象的引用，这样会造成了该white对象漏标记。
 *  对black新引用了一个white对象，然后从gray对象删了一个引用该white对象的white对象，这样也会造成了该white对象漏标记。
 *  对black新引用了一个刚new出来的white对象，没有其他gray对象引用该white对象，这样也会造成了该white对象漏标记。

![39097a356d34400241c3478ae8998ab0.png][]

接着继续：

**SATB详解：**

*  对于三色算法在concurrent的时候可能产生的漏标记问题，SATB在marking阶段中，对于从gray对象移除的目标引用对象标记为gray，对于black引用的新产生的对象标记为blcak；由于是在开始的时候进行snapshot，因而可能存在Floating Garbage。
 *  漏标与误标  
    误标没什么关系，顶多造成浮动垃圾，在下次gc还是可以回收的，但是漏标的后果是致命的，把本应该存活的对象给回收了，从而影响的程序的正确性。
 *  漏标的情况只会发生在白色对象中，且满足以下任意一个条件。  
    a、并发标记时，应用线程给一个黑色对象的引用类型字段赋值了该白色对象。  
    b、并发标记时，应用线程删除所有灰色对象到该白色对象的引用。这是为何呢？举个例子来说明这种漏标现象的发生：![f8e390a531998534335544a67b345225.png][]
    
    比如图上所示，有三个gray对象里面有个成员变量都指向了一个白色对象，此时这三个gray里面的成员变量还木有被扫描到，接着应用线程删除了所有灰色对象到该白色对象的引用，如下：  
    ![b338d1bf57aed9e70ff8bb6f5f1b20d2.png][]  
    此时该white对象就成为了一个垃圾对象待回收了，目测现在这条件都是如预期，但是！！！假如在删除之前有一个黑色对象也引用该白色对象了，如下：  
      
    ![40a11c5ba765300a437e32e4463c5646.png][]
    
    此时就会出现漏标的现象，本来该white对象不是垃圾反而当成垃圾被清理了。
 *  对于第一种情况，利用post-write barrier，记录所有新增的引用关系，然后根据这些引用关系为根重新扫描一遍。
 *  对于第二种情况，利用pre-write barrier，将所有既将被删除的引用关系的旧引用记录下来，最后以这些旧引用为根重新扫描一遍。

**停顿预测模型：**

*  G1收集器突出表现出来的一点是通过一个停顿预测模型根据用户配置的停顿时间来选择CSet的大小，从而达到用户期待的应用程序暂停时间。
 *  通过-XX:MaxGCPauseMillis参数来设置。这一点有点类似于ParallelScavenge收集器。关于停顿时间的设置并不是越短越好。 
 *  设置的时间越短意味着每次收集的CSet越小【设置的停顿时间越小则收集的垃圾越少，而收集的垃圾越少则意味着收集的region个数越少，而收集的region个数越少意味着由这些被收集的region所构成的CSet就越小】，导致垃圾逐步积累变多，最终不得不退化成Serial GC;停顿时间设置的过长，那么会导致每次都会产生长时间的停顿，影响了程序对外的响应时间。

**G1的收集模式：**

*  Young GC:收集年轻代里的Region。
 *  Mixed GC：年轻代的所有Region + 全局并发标记阶段选出的收益高的Region。
 *  无论是Young GC还是Mixed GC都只是并发拷贝的阶段。
 *  分代G1模式下选择CSet有两种子模式，分别对应Young GC和Mixed GC：  
    Young GC：CSet就是所有年轻代里面的Region。  
    Mixed GC：CSet是所有年轻代里的Region加上在全局并发标记阶段标记出来的收益高的Region。
 *  G1的运行过程是这样的：会在Young GC和Mixed GC之间不断地切换运行，同时定期地做全局并发标记，在实在赶不上对象创建速度的情况下使用Full GC(Serial GC，也就是从G1会回收到备选的方案，一定要尽量避免此情况出现)。
 *  初始标记是在Young GC上执行的，在进行全局并发标记的时候不会做Mixed GC，在做Mixed GC的时候也不会启动初始标记阶段。
 *  当Mixed GC赶不上对象产生的速度的时候就退化成Full GC，这一点是需要重点调优的地方。

**G1最佳实践：**

*  不断调优暂停时间指标  
    通过-XX:MaxGCPauseMillis=x可以设置启动应用程序暂停的时间，G1在运行的时候会根据这个参数选择CSet来满足响应时间的设置。一般情况下这个值设置到100ms或者200ms都是可以的（不同情况下会不一样），但是如果设置成50ms就不太合理。**暂停时间设置的太短，就会导致出现G1跟不上垃圾产生的速度**。最终退化成Full GC。所以对这个参数的调优是一个持续的过程，逐步调整到最佳状态。
 *  不要设置新生代和老年代的大小  
    1、G1收集器在运行的时候会调整新生代和老年代的大小。通过改变代的大小来调整对象晋升的速度以及晋升年龄，从而达到我们为收集器设置的暂停时间目标。  
    2、设置了新生代大小相当于放弃了G1为我们做的自动调优。我们需要做的只是设置整个堆内存的大小，剩下的交给G1自已去分配各个代的大小既可。
 *  关注Evacuation Failure  
    Evacuation Failure类似于CMS里面的晋升失败，堆空间的垃圾太多导致无法完成Region之间的拷贝，于是不得不退化成Full GC来做一次全局范围内的垃圾收集。

[c10793dc2790a82a85ae0f49e2cc5df0.png]: /images/20210527/a9c058d19d6a4e25885f8c1003b47111.png
[f89c1218bc9bb06d4c93d4f1ab3dc99d.png]: /images/20210527/e3b26a5f5e484fd5b6fe9ae7f61a74b9.png
[46edcede4f14c2ab709c6cc92f0ee719.png]: /images/20210527/939a5c8515354fa4b23d685455017162.png
[83200eb134b5fd682ae66404a10e643a.png]: /images/20210527/9f62fb91f20645c5b06bd18d23bd720a.png
[407984b73d0e88d58411b9dd972861df.png]: /images/20210527/8e229baf775c424c9bb2f0ebfb41a47f.png
[cc167ae3b8b1bd571e1d8b0d12ab352d.png]: /images/20210527/f9d0ae6132154009ad4ab445c0337c62.png
[f92495fc48210db29cadb9ed6ad8d27b.png]: /images/20210527/4472ff46c5cb49989ca425215d027410.png
[57af8a31eb346d8a6418e4c0e6c0da7a.png]: /images/20210527/1a2b76cf9e964019b75167f85820d3ae.png
[b798a142eda203b0fae2afef02dd91db.png]: /images/20210527/1b0d64333d004cbe8480a3f97f498bd2.png
[844c0ff4d0710cfdad9e7f55b7d03678.png]: /images/20210527/17adae74b4d947449fff22c421824417.png
[034528614292fef79b7d879d21f09616.png]: /images/20210527/243dac8601b44eb190472a1a5bc50970.png
[dff6f02f52953e9f428613307a1426eb.png]: /images/20210527/43d0950b3ef342359f0f740f5822331a.png
[39097a356d34400241c3478ae8998ab0.png]: /images/20210527/4be14b95462f427495cac736e457e879.png
[f8e390a531998534335544a67b345225.png]: /images/20210527/305e9781e9c5463eb53200446dddd7e7.png
[b338d1bf57aed9e70ff8bb6f5f1b20d2.png]: /images/20210527/e22abd588e454b8d865642640f4e2580.png
[40a11c5ba765300a437e32e4463c5646.png]: /images/20210527/adecff63945f46c4864e580427590344.png