垃圾收集器G1详解

G1（Garbadge First Collector）作为一款JVM最新的垃圾收集器，可以解决CMS中Concurrent Mode Failed问题，尽量缩短处理超大堆的停顿，在G1进行垃圾回收的时候完成内存压缩，降低内存碎片的生成。G1在堆内存比较大的时候表现出比较高吞吐量和短暂的停顿时间，而且已成为Java 9的默认收集器

G1的GC原理

Region

G1的内存结构和传统的内存空间划分有比较的不同。G1将内存划分成了多个大小相等的Region（默认是512K），Region逻辑上连续，物理内存地址不连续。同时每个Region被标记成E、S、O、H，分别表示Eden、Survivor、Old、Humongous。其中E、S属于年轻代，O与H属于老年代

示意图如下：

在这里插入图片描述

H表示Humongous。从字面上就可以理解表示大的对象（下面简称H对象）。当分配的对象大于等于Region大小的一半的时候就会被认为是巨型对象。H对象默认分配在老年代，可以防止GC的时候大对象的内存拷贝。通过如果发现堆内存容不下H对象的时候，会触发一次GC操作

跨代引用

在进行Young GC的时候，Young区的对象可能还存在Old区的引用，这就是跨代引用的问题。为了解决Young GC的时候，扫描整个老年代，G1引入了Card Table 和Remember Set的概念，基本思想就是用空间换时间。这两个数据结构是专门用来处理Old区到Young区的引用。Young区到Old区的引用则不需要单独处理，因为Young区中的对象本身变化比较大，没必要浪费空间去记录下来

RSet：全称Remembered Sets, 用来记录外部指向本Region的所有引用，每个Region维护一个RSet
Card: JVM将内存划分成了固定大小的Card。这里可以类比物理内存上page的概念

下图展示的是RSet与Card的关系。每个Region被分成了多个Card，其中绿色部分的Card表示该Card中有对象引用了其他Card中的对象，这种引用关系用蓝色实线表示。RSet其实是一个HashTable，Key是Region的起始地址，Value是Card Table （字节数组）,字节数组下标表示Card的空间地址，当该地址空间被引用的时候会被标记为dirty_card

在这里插入图片描述

SATB

SATB的全称（Snapshot At The Beginning）字面意思是开始GC前存活对象的一个快照。SATB的作用是保证在并发标记阶段的正确性。如何理解这句话？

首先要介绍三色标记算法

在这里插入图片描述

黑色：根对象，或者该对象与它的子对象都被扫描
灰色：对象本身被扫描,但还没扫描完该对象中的子对象
白色：未被扫描对象，扫描完成所有对象之后，最终为白色的为不可达对象，即垃圾对象

在GC扫描C之前的颜色如下：

在这里插入图片描述

在并发标记阶段，应用线程改变了这种引用关系

A.c=C
B.c=null

得到如下结果

在这里插入图片描述

在重新标记阶段扫描结果如下

在这里插入图片描述

这种情况下C会被当做垃圾进行回收。Snapshot的存活对象原来是A、B、C，现在变成A、B了，Snapshot的完整遭到破坏了，显然这个做法是不合理

G1采用的是pre-write barrier解决这个问题。简单说就是在并发标记阶段，当引用关系发生变化的时候，通过pre-write barrier函数会把这种这种变化记录并保存在一个队列里，在JVM源码中这个队列叫satb_mark_queue。在remark阶段会扫描这个队列，通过这种方式，旧的引用所指向的对象就会被标记上，其子孙也会被递归标记上，这样就不会漏标记任何对象，snapshot的完整性也就得到了保证

这里引用R大对SATB的解释：

其实只需要用pre-write barrier把每次引用关系变化时旧的引用值记下来就好了。这样，等concurrent marker到达某个对象时，这个对象的所有引用类型字段的变化全都有记录在案，就不会漏掉任何在snapshot里活的对象。当然，很可能有对象在snapshot中是活的，但随着并发GC的进行它可能本来已经死了，但SATB还是会让它活过这次GC。CMS的incremental update设计使得它在remark阶段必须重新扫描所有线程栈和整个young gen作为root；G1的SATB设计在remark阶段则只需要扫描剩下的satb_mark_queue ，解决了CMS垃圾收集器重新标记阶段长时间STW的潜在风险。"

SATB的方式记录活对象，也就是那一时刻对象snapshot, 但是在之后这里面的对象可能会变成垃圾, 叫做浮动垃圾（floating garbage），这种对象只能等到下一次收集回收掉。在GC过程中新分配的对象都当做是活的，其他不可达的对象就是死的

如何知道哪些对象是GC开始之后新分配的呢？

在Region中通过top-at-mark-start（TAMS）指针，分别为prevTAMS和nextTAMS来记录新配的对象。示意图如下：

在这里插入图片描述

每个region记录着两个top-at-mark-start（TAMS）指针，分别为prevTAMS和nextTAMS。在TAMS以上的对象就是新分配的，因而被视为隐式marked。这里引用R大的解释

G1的concurrent marking用了两个bitmap：一个prevBitmap记录第n-1轮concurrent marking所得的对象存活状态。由于第n－1轮concurrent marking已经完成，这个bitmap的信息可以直接使用。一个nextBitmap记录第n轮concurrent marking的结果。这个bitmap是当前将要或正在进行的concurrent marking的结果，尚未完成，所以还不能使用。

其中top是该region的当前分配指针，[bottom, top)是当前该region已用（used）的部分，[top, end)是尚未使用的可分配空间（unused）

[bottom, prevTAMS): 这部分里的对象存活信息可以通过prevBitmap来得知
[prevTAMS, nextTAMS): 这部分里的对象在第n-1轮concurrent marking是隐式存活的
[nextTAMS, top): 这部分里的对象在第n轮concurrent marking是隐式存活的

G1的GC模式

Young GC

Young GC 回收的是所有年轻代的Region。当E区不能再分配新的对象时就会触发。E区的对象会移动到S区，当S区空间不够的时候，E区的对象会直接晋升到O区，同时S区的数据移动到新的S区，如果S区的部分对象到达一定年龄，会晋升到O区

Yung GC过程示意图如下：

在这里插入图片描述

Mixed GC

Mixed GC 翻译过来叫混合回收。之所以叫混合是因为回收所有的年轻代的Region+部分老年代的Region

1、为什么是老年代的部分Region？

2、什么时候触发Mixed GC?

这两个问题其实可以一并回答。回收部分老年代是参数-XX:MaxGCPauseMillis，用来指定一个G1收集过程目标停顿时间，默认值200ms，当然这只是一个期望值。G1的强大之处在于他有一个停顿预测模型（Pause Prediction Model），它会有选择的挑选部分Region，去尽量满足停顿时间

Mixed GC的触发也是由一些参数控制。比如XX:InitiatingHeapOccupancyPercent表示老年代占整个堆大小的百分比，默认值是45%，达到该阈值就会触发一次Mixed GC

Mixed GC主要可以分为两个阶段：

1、全局并发标记（global concurrent marking）

全局并发标记又可以进一步细分成下面几个步骤：

初始标记（initial mark，STW）。它标记了从GC Root开始直接可达的对象。初始标记阶段借用young GC的暂停，因而没有额外的、单独的暂停阶段
并发标记（Concurrent Marking）。这个阶段从GC Root开始对heap中的对象标记，标记线程与应用程序线程并行执行，并且收集各个Region的存活对象信息。过程中还会扫描上文中提到的SATB write barrier所记录下的引用
最终标记（Remark，STW）。标记那些在并发标记阶段发生变化的对象，将被回收
清除垃圾（Cleanup，部分STW）。这个阶段如果发现完全没有活对象的region就会将其整体回收到可分配region列表中。清除空Region

2、拷贝存活对象（Evacuation）

Evacuation阶段是全暂停的。它负责把一部分region里的活对象拷贝到空region里去（并行拷贝），然后回收原本的region的空间。Evacuation阶段可以自由选择任意多个region来独立收集构成收集集合（collection set，简称CSet），CSet集合中Region的选定依赖于上文中提到的停顿预测模型，该阶段并不evacuate所有有活对象的region，只选择收益高的少量region来evacuate，这种暂停的开销就可以（在一定范围内）可控

Mixed GC的清理过程示意图如下：

在这里插入图片描述