本文思维导图：

?G1垃圾回收器

传统的垃圾回收器一般情况下 内存占用、吞吐量、延时 只能同时满足两个。但是现在的发展，延迟这项的目标越来越重要。所以就有低延迟的垃圾回收器。

设计思想

随着 JVM 中内存的增大，STW 的时间成为 JVM 急迫解决的问题，但是如果按照传统的分代模型，总跳不出 STW 时间不可预测这点。为了实现 STW 的时间可预测，首先要有一个思想上的改变。G1 将堆内存“化整为零”，将堆内存划分成多个大小相等独立区域（Region），每一个 Region都可以根据需要，扮演新生代的 Eden 空间、Survivor 空间，或者老年代空间。回收器能够对扮演不同角色的 Region 采用不同的策略去处理，这样无论是新创建的对象还是已经存活了一段时间、熬过多次收集的旧对象都能获取很好的收集效果。

Region

Region 可能是 Eden,也有可能是 Survivor,也有可能是 Old,另外 Region 中还有一类特殊的 Humongous 区域，专门用来存储大对象。 G1 认为只要大小超过了一个 Region 容量一半的对象即可判定为大对象。每个 Region 的大小可以通过参数-XX:G1HeapRegionSize 设定，取值范围为 1MB~32MB,且应为 2 的 N 次幂。而对于那些超过了整个 Region 容量的超级大对象，将会被存放在 N 个连续的 Humongous Region 之中，G1 的进行回收大多数情况下都把 Humongous Region 作为老年代的一部分来进行看待。

G1参数设置

开启参数
-XX:+UseG1GC
启用垃圾优先(G1) 垃圾收集器的使用。它是一种服务器样式的垃圾收集器,适用于具有大量RAM的多处理器计算机。它极有可能满足GC暂停时间目标,同时保持良好的吞吐量。建议将G1收集器用于需要大堆(大小约为6 GB或更大)且GC延迟要求有限(稳定且可预测的暂停时间低于0.5秒)的应用程序。

分区大小
-XX: G1HeapRegionSize=大小
设置使用垃圾优先(G1)收集器时将Java堆细分为的区域的大小。取值范围是1 MB到32 MB。默认区域大小是根据堆大小根据人体工程学确定的。以下示例显示如何将细分的大小设置为16 MB：-XX: G1HeapRegionSize = 16m。一般建议逐渐增大该值，随着 size 增加，垃圾的存活时间更长，GC 间隔更长，但每次 GC 的时间也会更长。

最大 GC 暂停时间
-XX: MaxGCPauseMillis =时间
设置最大GC暂停时间的目标(以毫秒为单位)。这是一个软目标，并且JVM将尽最大的努力来实现它。默认情况下，没有最大暂停时间值。下面的示例显示如何将最大目标暂停时间设置为500 ms：-XX: MaxGCPauseMillis = 500。

G1运行过程

G1 的运作过程大致可划分为以下四个步骤:

初始标记( Initial Marking)：
仅仅只是标记一下 GC Roots 能直接关联到的对象，并且修改 TAMS 指针的值，让下一阶段用户线程并发运行时，能正确地在可用的 Region 中分配新对象。这个阶段需要停顿线程，但耗时很短，而且是借用进行 Minor GC 的时候同步完成的，所以 G1 收集器在这个阶段实际并没有额外的停顿。
TAMS 是什么？要达到 GC 与用户线程并发运行，必须要解决回收过程中新对象的分配，所以 G1 为每一个 Region 区域设计了两个名为 TAMS（Top at Mark Start）的指针，从 Region 区域划出一部分空间用于记录并发回收过程中的新对象。这样的对象认为它们是存活的，不纳入垃圾回收范围。
并发标记( Concurrent Marking)：
从 GC Root 开始对堆中对象进行可达性分析，递归扫描整个堆里的对象图，找出要回收的对象，这阶段耗时较长，但可与用户程序并发执行。当对象图扫描完成以后，并发时有引用变动的对象，这些对象会漏标（ 后续再讲三色标记的时候会细讲这个问题），漏标的对象会被一个叫做SATB(snapshot-at-the-beginning)算法来解决（这个下节课会细讲）
最终标记( Final Marking)：对用户线程做另一个短暂的暂停，用于处理并发阶段结后仍遗留下来的最后那少量的 SATB 记录(漏标对象)。
筛选回收( Live Data Counting and Evacuation)
负责更新 Region 的统计数据，对各个 Region 的回收价值和成本进行排序，根据用户所期望的停顿时间来制定回收计划，可以自由选择任意多个 Region 构成回收集，然后把决定回收的那一部分 Region 的存活对象复制到空的 Region 中，再清理掉整个旧 Region 的全部空间。这里的操作涉及存活对象的移动，是必须暂停用户线程，由多条收集器线程并行完成的。

并发标记与三色标记

三色标记

在三色标记法之前有一个算法叫 Mark-And-Sweep（标记清除）。这个算法会设置一个标志位来记录对象是否被使用。最开始所有的标记位都是 0，如果发现对象是可达的就会置为 1，一步步下去就会呈现一个类似树状的结果。等标记的步骤完成后，会将未被标记的对象统一清理，再次把所有的标记位设置成 0 方便下次清理。

这个算法最大的问题是 GC 执行期间需要把整个程序完全暂停，不能异步进行 GC 操作。因为在不同阶段标记清扫法的标志位 0 和 1 有不同的含义，那么新增的对象无论标记为什么都有可能意外删除这个对象。对实时性要求高的系统来说，这种需要长时间挂起的标记清扫法是不可接受的。所以就需要一个算法来解决 GC 运行时程序长时间挂起的问题，那就三色标记法。

三色标记最大的好处是可以异步执行，从而可以以中断时间极少的代价或者完全没有中断来进行整个 GC。

三色标记法很简单。首先将对象用三种颜色表示，分别是白色、灰色和黑色。
黑色：根对象，或者该对象与它的子对象都被扫描过。
灰色：对本身被扫描，但是还没扫描完该对象的子对象。
白色：未被扫描对象，如果扫描完所有对象之后，最终为白色的为不可达对象，既垃圾对象。

三色标记的问题-GC并发情况下的漏标问题

问题描述：

CMS ?中的解决方案

Incremental Update 算法：

当一个白色对象被一个黑色对象引用，将黑色对象重新标记为灰色，让垃圾回收器重新扫描

G1 ?中的解决方案

SATB(snapshot-at-the-beginning) 保证在并发标记的正确性

刚开始做一个快照，当 B 和 C 消失的时候要把这个引用推到 GC 的堆栈，保证 C 还能被 GC 扫描到，最重要的是要把这个引用推到 GC 的堆栈，是灰色对象指向白色的引用，如果一旦某一个引用消失掉了，我会把它放到栈（GC 方法运行时数据也是来自栈中），我其实还是能找到它的，我下回直接扫描他就行了，那样白色就不会漏标。
对应 G1 的垃圾回收过程中的：
最终标记( Final Marking)
对用户线程做另一个短暂的暂停，用于处理并发阶段结后仍遗留下来的最后那少量的 SATB 记录(漏标对象)。

对比

SATB 算法是关注引用的删除。（B->C 的引用）
Incremental Update 算法关注引用的增加。（A->C 的引用）
G1 如果使用 Incremental Update 算法，因为变成灰色的成员还要重新扫，重新再来一遍，效率太低了。
所以 G1 ?在处理并发标记的过程比 CMS ?效率要高，这个主要是解决漏标的算法决定的。

G1中的技术细节

跨代引用

堆空间通常被划分为新生代和老年代。由于新生代的垃圾收集通常很频繁，如果老年代对象引用了新生代的对象，那么回收新生代的话，需要跟踪从老年代到新生代的所有引用，所以要避免每次 YGC 时扫描整个老年代，减少开销。

RSet （记忆集）-G1底层数据结构

记录了其他 Region 中的对象到本 Region 的引用,RSet 的价值在于使得垃圾收集器不需要扫描整个堆,找到谁引用了当前分区中的对象，只需要扫描 RSet 即可。RSet 本身就是一个 Hash 表，如果是在 G1 的话，则是在一个 Region 区里面。

RSet?是一个空间换时间的数据结构。卡表（Card?Table）的数据结构，用来解决跨代引用的问题。RSet?的功能与此类似，它的全称是?Remembered?Set，用于记录和维护?Region?之间的对象引用关系。

但?RSet?与?Card?Table?有些不同的地方。Card?Table?是一种?points-out（我引用了谁的对象）的结构。而?RSet?记录了其他?Region?中的对象引用本?Region?中对象的关系，属于?points-into?结构（谁引用了我的对象），有点倒排索引的味道。

你可以把?RSet?理解成一个?Hash，key?是引用的?Region?地址，value?是引用它的对象的卡页集合。

有了这个数据结构，在回收某个?Region?的时候，就不必对整个堆内存的对象进行扫描了。它使得部分收集成为了可能。

对于年轻代的?Region，它的?RSet?只保存了来自老年代的引用，这是因为年轻代的回收是针对所有年轻代?Region?的，没必要画蛇添足。所以说年轻代?Region?的?RSet?有可能是空的。

而对于老年代的?Region?来说，它的?RSet?也只会保存老年代对它的引用。这是因为老年代回收之前，会先对年轻代进行回收。这时，Eden?区变空了，而在回收过程中会扫描?Survivor?分区，所以也没必要保存来自年轻代的引用。

RSet?通常会占用很大的空间，大约?5%?或者更高。不仅仅是空间方面，很多计算开销也是比较大的。事实上，为了维护?RSet，程序运行的过程中，写入某个字段就会产生一个?post-write?barrier?。为了减少这个开销，将内容放入?RSet?的过程是异步的，而且经过了很多的优化：Write?Barrier?把脏卡信息存放到本地缓冲区（local?buffer），有专门的?GC?线程负责收集，并将相关信息传给被引用?Region?的?RSet。
参数?-XX:G1ConcRefinementThreads?或者?-XX:ParallelGCThreads?可以控制这个异步的过程。如果并发优化线程跟不上缓冲区的速度，就会在用户进程上完成。

CardTable

由于做新生代 GC 时，需要扫描整个 OLD 区，效率非常低，所以 JVM 设计了 CardTable,如果一个 OLD 区 CardTable 中有对象指向 Y 区， 就将它设为 Dirty（标志位 1）, 下次扫描时，只需要扫描 CARDTABLE 上是 Dirty 的内存区域即可。
字节数组 CARDTABLE 的每一个元素都对应着其标识的内存区域中一块特定大小的内存块，这个内存块被称作“卡页”(Card Page)。 一般来说，卡页大小都是以 2 的 N 次幂的字节数，假设使用的卡页是 2 的 10 次幂，即 1K,内存区域的起始地址是 0x0000 的话，数组 CARD_TABLE 的第 0、1、2 号元素，分别对应了地址范围为 0x0000~0x03FF、0x0400 ~ 0x07FF、0x0800~0x011FF 的卡页内存。

安全点与安全区域

安全点

用户线程暂停，GC 线程要开始工作，但是要确保用户线程暂停的这行字节码指令是不会导致引用关系的变化。所以 JVM 会在字节码指令中，选一些指令，作为“安全点”，比如方法调用、循环跳转、异常跳转等，一般是这些指令才会产生安全点。为什么它叫安全点，是这样的，GC 时要暂停业务线程，并不是抢占式中断（立马把业务线程中断）而是主动是中断。主动式中断是设置一个标志，这个标志是中断标志，各业务线程在运行过程中会不停的主动去轮询这个标志，一旦发现中断标志为 True,就会在自己最近的“安全点”上主动中断挂起。

安全区域

为什么需要安全区域？要是业务线程都不执行（业务线程处于 Sleep 或者是 Blocked 状态），那么程序就没办法进入安全点，对于这种情况，就必须引入安全区域。安全区域是指能够确保在某一段代码片段之中， 引用关系不会发生变化，因此，在这个区域中任意地方开始垃圾收集都是安全的。我们也可以把安全区城看作被扩展拉伸了的安全点。

当用户线程执行到安全区域里面的代码时，首先会标识自己已经进入了安全区域，这段时间里 JVM 要发起 GC 就不必去管这个线程了。
当线程要离开安全区域时，它要 JVM 是否已经完成了（根节点枚举，或者其他 GC 中需要暂停用户线程的阶段)
1、如果完成了，那线程就当作没事发生过，继续执行。
2、否则它就必须一直等待， 直到收到可以离开安全区域的信号为止

GC日志详解

G1 ?常用参数

-XX:+UseG1GC 启用 CMS 垃圾收集器
-XX:MaxGCPauseMillis 设置最大 GC 暂停时间的目标（以毫秒为单位）。这是一个软目标，并且 JVM 将尽最大的努力（G1 会尝试调整 Young 区的块数来）来实
现它。默认情况下，没有最大暂停时间值。
-XX:GCPauseIntervalMillis GC 的间隔时间
-XX:+G1HeapRegionSize 分区大小，建议逐渐增大该值，1 2 4 8 16 32。随着 size 增加，垃圾的存活时间更长，GC 间隔更长，但每次 GC 的时间也会更长
-XX:G1NewSizePercent 新生代最小比例，默认为 5%
-XX:G1MaxNewSizePercent 新生代最大比例，默认为 60%
-XX:GCTimeRatioGC 时间建议比例，G1 会根据这个值调整堆空间
-XX:ConcGCThreads 线程数量
-XX:InitiatingHeapOccupancyPercent 启动 G1 的堆空间占用比例，根据整个堆的占用而触发并发 GC 周期

总结

G1?垃圾回收器的回收过程，并着重看了一下底层的数据结构?RSet。相对于?CMS，G1?有了更可靠的驾驭度。而且有?RSet?和?SATB?等算法的支撑，Remark?阶段更加高效。
G1?最重要的概念，其实就是?Region。它采用分而治之，部分收集的思想，尽力达到我们给它设定的停顿目标。
G1?的垃圾回收过程分为三种，其中，并发标记阶段，为更加复杂的?Mixed?GC?阶段做足了准备。

cs