从 JDK1.9 开始默认 G1，应用在多处理器和大容量内存环境中。

基础概念

Region

G1 给整一块Heap内存区域均匀等分了N个 Region，N 默认情况下是 2048。
Region的大小只能是1M、2M、4M、8M、16M或32M (1-32M,并且为2的指数)，比如-Xmx16g -Xms16g，G1就会采用16G / 2048 = 8M 的Region。

G1 的常用参数很简单，主要有下面几个

1. -XX:+UseG1GC：为开启G1垃圾收集器
2. -Xmx32g：堆内存的最大内存为32G
3. XX:MaxGCPauseMillis=200: 设置GC的最大暂停时间为200ms
4. -XX:G1HeapRegionSize: 设置每个region大小

一般的调优手段是修改最大暂停时间。同时，如果能预测到项目中大对象比较多，可以设置较大的region值。

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

SATB

全称是 Snapshot At The Beginning，是GC开始时活着的对象的一个快照。它是通过 Root Tracing 得到的，作用是维持并发GC的正确性。

三色标记算法

可达性分析进一步延伸出三色标记法。通常，GC 算法会维持一套对象图，图上节点表示对象，节点之间的连线表示对象间的引用关系，其中：

• 白色节点：尚未被标记的对象；
• 黑色节点：已经被垃圾收集器访问过，且这个对象的引用全部被扫描过；
• 灰色节点：已经被垃圾收集器访问过，且这个对象至少还有一个引用没被扫描；

RSet

由于并发标记期间，用户线程和GC线程是并发的，可能出现白对象漏标的情况。漏标发生有两个前提：

1. 用户线程赋值了一个黑对象到该白对象的引用
2. 用户线程删除了所有灰对象到白对象的引用

例如当垃圾扫描器扫描到下面的情况的时候：

这时候应用程序执行了以下操作：

A.c=C
B.c=null

这样，对象的状态图变成如下情形：

这时候垃圾收集器再标记扫描的时候就会下图成这样:

很显然，此时C是白色，被认为是垃圾需要清理掉，显然这是不合理的。那么我们如何保证应用程序在运行的时候，GC标记的对象不丢失呢？有如下2中可行的方式：

1. 在插入的时候记录对象
2. 在删除的时候记录对象

刚好这对应CMS和G1的2种不同实现方式：

CMS采用的是 写屏障+增量更新（Incremental update）

在CMS采用的是增量更新（Incremental update），只要在写屏障（write barrier）里发现要有一个白对象的引用被赋值到一个黑对象的字段里，那就把这个白对象变成灰色的。即插入的时候记录下来。

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

引用 R 大的话

其实只需要用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过程中新分配的对象都当做是活的，其他不可达的对象就是死的。

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

在TAMS以上的对象就是新分配的，因而被视为隐式marked。

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）。

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

• G1 Mixed GC

混合回收。之所以叫混合是因为回收所有的年轻代的Region+部分老年代的Region。

G1的强大之处在于他有一个停顿预测模型（Pause Prediction Model），他会有选择的挑选部分Region，去尽量满足停顿时间。

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

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

1. 全局并发标记（global concurrent marking）
   全局并发标记又可以进一步细分成下面几个步骤：

a. 初始标记（initial mark，STW）。它标记了从GC Root开始直接可达的对象。初始标记阶段借用young GC的暂停，因而没有额外的、单独的暂停阶段。
b. 根区域扫描（root region scan）。G1 GC 在初始标记的存活区扫描对老年代的引用(扫描CardTable和RSet)，并标记被引用的对象。该阶段与应用程序（非STW）同时运行，并且只有完成该阶段后，才能开始下一次STW年轻代垃圾回收。
c. 并发标记（Concurrent Marking）。这个阶段从GC Root开始对heap中的对象标记，标记线程与应用程序线程并行执行，并且收集各个Region的存活对象信息。过程中还会扫描上文中提到的SATB write barrier所记录下的引用。
d. 最终标记（Remark，STW）。标记那些在并发标记阶段发生变化的对象，将被回收。
e. 清除垃圾（Cleanup，部分STW）。这个阶段如果发现完全没有活对象的region就会将其整体回收到可分配region列表中。 清除空Region。

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

• Full GC

G1的垃圾回收过程是和应用程序并发执行的，当Mixed GC的速度赶不上应用程序申请内存的速度的时候，Mixed G1就会降级到Full GC，使用的是Serial GC。Full GC会导致长时间的STW，应该要尽量避免。
导致G1 Full GC的原因可能有两个：

1. Evacuation的时候没有足够的to-space来存放晋升的对象；
2. 并发处理过程完成之前空间耗尽