ZGC

介绍

ZGC（Z Garbage Collector）是一款性能比 G1 更加优秀的垃圾收集器。ZGC 第一次出现是在 JDK 11 中以实验性的特性引入，这也是 JDK 11 中最大的亮点。

ZGC 有3个重要特性：

暂停时间不会超过 10 ms。JDK 16 发布后，GC 暂停时间已经缩小到 1 ms 以内，并且时间复杂度是 o(1)，这也就是说 GC 停顿时间是一个固定值了，并不会受堆内存大小影响。

最大支持 16TB 的大堆，最小支持 8MB 的小堆。
跟 G1 相比，对应用程序吞吐量的影响小于 15 %。

内存多重映射（Multi-Mapping）

内存多重映射，就是使用 mmap （Multi-Mapping）把不同的虚拟内存地址映射到同一个物理内存地址上。

将多个不同的虚拟内存地址映射到同一物理内存地址上，这是一种多对一映射，意味着ZGC在虚拟内存中看到的地址空寂要比实际的堆内存容量来的更大。把染色指针中的标志位看作是地址的分段符，那只要将这些不同的地址段都映射到同一物理内裤空间，经过多重映射转换后，就可以使用染色指针正常进行寻址了。

如下图：

ZGC 为了更灵活高效地管理内存，使用了内存多重映射，把同一块儿物理内存映射为 Marked0、Marked1 和 Remapped 三个虚拟内存。

当应用程序创建对象时，会在堆上申请一个虚拟地址，这时 ZGC 会为这个对象在 Marked0、Marked1 和 Remapped 这三个视图空间分别申请一个虚拟地址，这三个虚拟地址映射到同一个物理地址。

Marked0、Marked1 和 Remapped 这三个虚拟内存作为 ZGC 的三个视图空间，在同一个时间点内只能有一个有效。ZGC 就是通过这三个视图空间的切换，来完成并发的垃圾回收。

染色指针

三色标记回顾

我们知道 G1 垃圾收集器使用了三色标记，这里先做一个回顾。下面是一个三色标记过程中的对象引用示例图：

总共有三种颜色，说明如下：

白色：本对象还没有被标记线程访问过。
灰色：本对象已经被访问过，但是本对象引用的其他对象还没有被全部访问。
黑色：本对象已经被访问过，并且本对象引用的其他对象也都被访问过了。

三色标记的过程如下：

初始阶段，所有对象都是白色。
将 GC Roots 直接引用的对象标记为灰色。
处理灰色对象，把当前灰色对象引用的所有对象都变成灰色，之后将当前灰色对象变成黑色。
重复步骤 3，直到不存在灰色对象为止。

三色标记结束后，白色对象就是没有被引用的对象（比如上图中的 H 和 G），可以被回收了。

染色指针

ZGC 出现之前， GC 信息保存在对象头的 Mark Word 中。比如 64 位的 JVM，对象头的 Mark Word 中保存的信息如下图：

前 62位保存了 GC 信息，最后两位保存了锁标志。

ZGC 的一大创举是将 GC 信息保存在了染色指针上。染色指针是一种将少量信息直接存储在指针上的技术。在 64 位 JVM 中，对象指针是 64 位，如下图：

在这个 64 位的指针上，高 16 位都是 0，暂时不用来寻址。剩下的 48 位支持的内存可以达到 256 TB（2 ^48）,这可以满足多数大型服务器的需要了。不过 ZGC 并没有把 48 位都用来保存对象信息，而是用高 4 位保存了四个标志位，这样 ZGC 可以管理的最大内存可以达到 16 TB（2 ^ 44）。

通过这四个标志位，JVM 可以从指针上直接看到对象的三色标记状态（Marked0、Marked1）、是否进入了重分配集（Remapped）、是否需要通过 finalize 方法来访问到（Finalizable）。

无需进行对象访问就可以获得 GC 信息，这大大提高了 GC 效率。

内存布局

首先我们回顾一下 G1 垃圾收集器的内存布局。G1把整个堆分成了大小相同的 region，每个堆大约可以有 2048 个region，每个 region 大小为 1~32 MB （必须是 2 的次方）。如下图：

跟 G1 类似，ZGC 的堆内存也是基于 Region 来分布，不过 ZGC 是不区分新生代老年代的。不同的是，ZGC 的 Region 支持动态地创建和销毁，并且 Region 的大小不是固定的，包括三种类型的 Region ：

Small Region：2MB，主要用于放置小于 256 KB 的小对象。
Medium Region：32MB，主要用于放置大于等于 256 KB 小于 4 MB 的对象。
Large Region：N * 2MB。这个类型的 Region 是可以动态变化的，不过必须是 2MB 的整数倍，最小支持 4 MB。每个 Large Region 只放置一个大对象，并且是不会被重分配的。

读屏障

读屏障类似于 Spring AOP 的前置增强，是 JVM 向应用代码中插入一小段代码，当应用线程从堆中读取对象的引用时，会先执行这段代码。注意：只有从堆内存中读取对象的引用时，才会执行这个代码。下面代码只有第一行需要加入读屏障。

Object o = obj.FieldA
Object p = o //不是从堆中读取引用
o.dosomething() //不是从堆中读取引用
int i =  obj.FieldB //不是引用类型

读屏障在解释执行时通过 load 相关的字节码指令加载数据。作用是在对象标记和转移过程中，判断对象的引用地址是否满足条件，并作出相应动作。如下图：

标记、转移和重定位这些过程请看下一节。

读屏障会对应用程序的性能有一定影响，据测试，对性能的最高影响达到 4%，但提高了 GC 并发能力，降低了 STW。

GC 过程

前面已经讲过，ZGC 使用内存多重映射技术，把物理内存映射为 Marked0、Marked1 和 Remapped 三个地址视图，利用地址视图的切换，ZGC 实现了高效的并发收集。

ZGC 的垃圾收集过程包括标记、转移和重定位三个阶段。如下图：

ZGC 初始化后，整个内存空间的地址视图被设置为 Remapped。

初始标记

从 GC Roots 出发，找出 GC Roots 直接引用的对象，放入活跃对象集合，这个过程需要 STW，不过 STW 的时间跟 GC Roots 数量成正比，耗时比较短。

并发标记

并发标记过程中，GC 线程和 Java 应用线程会并行运行。这个过程需要注意下面几点：

GC 标记线程访问对象时，如果对象地址视图是 Remapped，就把对象地址视图切换到 Marked0，如果对象地址视图已经是 Marked0，说明已经被其他标记线程访问过了，跳过不处理。
标记过程中Java 应用线程新创建的对象会直接进入 Marked0 视图。
标记过程中Java 应用线程访问对象时，如果对象的地址视图是 Remapped，就把对象地址视图切换到 Marked0，可以参考前面讲的读屏障。
标记结束后，如果对象地址视图是 Marked0，那就是活跃的，如果对象地址视图是 Remapped，那就是不活跃的。

标记阶段的活跃视图也可能是 Marked1，为什么会采用两个视图呢？

这里采用两个视图是为了区分前一次标记和这一次标记。如果这次标记的视图是 Marked0，那下一次并发标记就会把视图切换到 Marked1。这样做可以配合 ZGC 按照页回收垃圾的做法。如下图：

第二次标记的时候，如果还是切换到 Marked0，那么 2 这个对象区分不出是活跃的还是上次标记过的。如果第二次标记切换到 Marked1，就可以区分出了。

这时 Marked0 这个视图的对象就是上次标记过程被标记过活跃，转移的时候没有被转移，但这次标记没有被标记为活跃的对象。Marked1 视图的对象是这次标记被标记为活跃的对象。Remapped 视图的对象是上次垃圾回收发生转移或者是被 Java 应用线程访问过，本次垃圾回收中被标记为不活跃的对象。

再标记

并发标记阶段 GC 线程和 Java 应用线程并发执行，标记过程中可能会有引用关系发生变化而导致的漏标记问题。再标记阶段重新标记并发标记阶段发生变化的对象，还会对非强引用（软引用，虚引用等）进行并行标记。

这个阶段需要 STW，但是需要标记的对象少，耗时很短。

初始转移

转移就是把活跃对象复制到新的内存，之前的内存空间可以被回收。

初始转移需要扫描 GC Roots 直接引用的对象并进行转移，这个过程需要 STW，STW 时间跟 GC Roots 成正比。

并发转移

并发转移过程 GC 线程和 Java 线程是并发进行的。上面已经讲过，转移过程中对象视图会被切回 Remapped 。转移过程需要注意以下几点：

如果 GC 线程访问对象的视图是 Marked0，则转移对象，并把对象视图设置成 Remapped。
如果 GC 线程访问对象的视图是 Remapped，说明被其他 GC 线程处理过，跳过不再处理。
并发转移过程中 Java 应用线程创建的新对象地址视图是 Remapped。
如果 Java 应用线程访问的对象被标记为活跃并且对象视图是 Marked0，则转移对象，并把对象视图设置成 Remapped。

重定位

转移过程对象的地址发生了变化，在这个阶段，把所有指向对象旧地址的指针调整到对象的新地址上。

垃圾收集算法

ZGC 采用标记 - 整理算法，算法的思想是把所有存活对象移动到堆的一侧，移动完成后回收掉边界以外的对象。如下图：

JDK 16 之前

在 JDK 16 之前，ZGC 会预留（Reserve）一块儿堆内存，这个预留内存不能用于 Java 线程的内存分配。即使从 Java 线程的角度看堆内存已经满了也不能使用 Reserve，只有 GC 过程中搬移存活对象的时候才可以使用。如下图：

这样做的好处是算法简单，非常适合并行收集。但这样做有几个问题：

因为有预留内存，能给 Java 线程分配的堆内存小于 JVM 声明的堆内存。
Reserve 仅仅用于存放 GC 过程中搬移的对象，有点内存浪费。
因为 Reserve 不能给 GC 过程中搬移对象的 Java 线程使用，搬移线程可能会因为申请不到足够内存而不能完成对象搬移，这返回过来又会导致应用程序的 OOM。

JDK 16 改进

JDK 16 发布后，ZGC 支持就地搬移对象（G1 在 Full GC 的时候也是就地搬移）。这样做的好处是不用预留空闲内存了。如下图：

不过就地搬移也有一定的挑战。比如：必须考虑搬移对象的顺序，否则可能会覆盖尚未移动的对象。这就需要 GC 线程之间更好的进行协作，不利于并发收集，同时也会导致搬移对象的 Java 线程需要考虑什么可以做什么不可以做。

为了获得更好的 GC 表现，JDK 16 在支持就地搬移的同时，也支持预留（Reserve）堆内存的方式，并且 ZGC 不需要真的预留空闲的堆内存。默认情况下，只要有空闲的 region，ZGC 就会使用预留堆内存的方式，如果没有空闲的 region，否则 ZGC 就会启用就地搬移。如果有了空闲的 region， ZGC 又会切换到预留堆内存的搬移方式。

总结

内存多重映射和染色指针的引入，使 ZGC 的并发性能大幅度提升。

ZGC 只有 3 个需要 STW 的阶段，

其中初始标记和初始转移只需要扫描所有 GC Roots，STW 时间 GC Roots 的数量成正比，不会耗费太多时间。

再标记过程主要处理并发标记引用地址发生变化的对象，这些对象数量比较少，耗时非常短。

可见整个 ZGC 的 STW 时间几乎只跟 GC Roots 数量有关系，不会随着堆大小和对象数量的变化而变化。

ZGC 也有一个缺点，就是浮动垃圾。因为 ZGC 没有分代概念，虽然 ZGC 的 STW 时间在 1ms 以内，但是 ZGC 的整个执行过程耗时还是挺长的。在这个过程中 Java 线程可能会创建大量的新对象，这些对象会成为浮动垃圾，只能等下次 GC 的时候进行回收。

跨代引用概述

在Java堆内存中，年轻代和老年代之间存在的对象相互引用，假设现在要进行一次新生代的YGC，但新生代中的对象可能被老年代所引用的，为了找到新生代中的存活对象，不得不遍历整个老年代。这样明显效率很低下，那么如何快速识别并回收这种引用对象呢？

这就不得不提到Card Table(卡表)和 Remember Set（记忆集,简称RSet）了。

GCRoots在新生代

假设现在整个堆空间只有两个对象。此时两个对象都在新生代。此时GC线程是非常容易判断这两个对象被GCRoots引用，属于存活对象。

随着程序的长时间运行。此时出现了以下情况：

GCRoots移动到老年代

可以看到，老年代的对象HumongN被GCRoots所引用，此时HumongN->S就是跨代引用。S又引用着E，因此这三个对象都不是垃圾。

我们说在新生代中，由E找到S是非常快速简单的。然而由S找到HumongN就需要遍历整个老年代的对象，这个过程是相当耗时的。所以要避免每次 YGC 时扫描整个老年代，减少开销。

解决跨代引用流程

在判断新生代对象是否根可达时，一部分对象是朝生夕死的对象，而另一部分可能是有由相当老年代的对象引用而来的。而一般老年代的引用关系都相当复杂，为了节约扫描时间成本，我们在每个新生代对象中存入一个RSet记录卡表。在检索新生代引用即将跨代时，会根据卡表的Key，Value快速定位到正确的老年代引用，以达到减少开销的目的。

RSet（记忆集）

记录了其它Region中的对象到Region的引用。

RSet的价值在于使得垃圾回收不需要扫描整个堆，能够快速定位到真正引用它的堆对象地址。ReSet本身就是一个Hash表，存储在新生代的每个Region中。但是存储需要消耗空间，多的能达到百分之20。因此G1对内存的空间要求较高(小空间没资本玩)，空间越大性能越彪悍。

CardTable

由于新生代GC时，需要扫描整个old区，效率非常低。所以old区就是用卡表的方式进行一次逻辑分区。一般一页卡表的大小是2的n次幂。每一个区域也是用Key，Value结构进行记录。每一区域记录为Key不重复，Value则记录这片区域的老年代对象与新生代对象是否存在引用关系，存在则标记为1，否则为0。记录完毕后把value为1的key作为ReSet的key进行记录，并且ReSet的value存储引用，从而提高跨代引用的查询效率。

总结

G1的设计因为这些记录，划分Region的原因，对基础内存的要求比较高。CMS也存在ReSet与CardTabe。但是因为CMS没有Region的存在，新生代只有一份，所以只需要记录一份，对空间要求不高。所以虽然G1优点很多，但是不推荐堆空间小于6G以下使用G1。

卡表Card Table

卡表是一种用于跟踪年轻代对象被老年代对象引用的数据结构。它将堆内存划分为一系列固定大小的区域（卡片），每个卡片记录了年轻代对象被老年代对象引用的情况。在老年代垃圾回收时，垃圾收集器会扫描卡表，以确定哪些年轻代对象是存活的，即被老年代对象引用。

在 JVM 中，一个 card 的大小（通常是）512字节。在多线程并行收集时，每个线程可以批量扫描多个 card，一批 card 被称为一个 stride。默认一个 stride 含有 256个 card，即每个线程要每次扫描 512 * 256 = 128 K 的内存区域。stride数量太多就会导致线程在stride之间切换的开销增加，进而导致 GC Pause 增长， strides 太少恐怕也会导致单次扫描的时间增长，进而影响整个 GC Pause 。

我们知道，JVM在进行垃圾收集时，需要先标记所有可达对象，然后再清除不可达对象，释放内存空间。那么，如何快速的找到所有可达对象呢？
最简单粗暴的实现，就是每次进行垃圾收集时，都对整个堆中的所有对象进行扫描，找到所有存活对象。逻辑是简单，但性能比较差。
简单粗暴的实现方式，通常都是不可取的。那JVM是如何实现快速标记可达对象的？
答案是GC Roots。
现代JVM，堆空间通常被划分为新生代和老年代。由于新生代的垃圾收集通常很频繁，如果老年代对象引用了新生代的对象，那么，需要跟踪从老年代到新生代的所有引用，从而避免每次YGC时扫描整个老年代，减少开销。
对于HotSpot JVM，使用了卡标记（Card Marking）技术来解决老年代到新生代的引用问题。具体是，使用卡表（Card Table）和写屏障（Write Barrier）来进行标记并加快对GC Roots的扫描。

基于卡表（Card Table）的设计，通常将堆空间划分为一系列2次幂大小的卡页（Card Page）。

卡表（Card Table），用于标记卡页的状态，每个卡表项对应一个卡页

HotSpot JVM的卡页（Card Page）大小为512字节，卡表（Card Table）被实现为一个简单的字节数组，即卡表的每个标记项为1个字节

当对一个对象引用进行写操作时（对象引用改变），写屏障逻辑将会标记对象所在的卡页为dirty。

OpenJDK/Oracle 1.6/1.7/1.8 JVM默认的卡标记简化逻辑如下：

CARD_TABLE [this address >> 9] = 0;

首先，计算对象引用所在卡页的卡表索引号。将地址右移9位，相当于用地址除以512（2的9次方）。可以这么理解，假设卡表卡页的起始地址为0，那么卡表项0、1、2对应的卡页起始地址分别为0、512、1024（卡表项索引号乘以卡页512字节）。

其次，通过卡表索引号，设置对应卡标识为dirty。

带来的2个问题

无条件写屏障带来的性能开销

每次对引用的更新，无论是否更新了老年代对新生代对象的引用，都会进行一次写屏障操作。显然，这会增加一些额外的开销。但是，与YGC时扫描整个老年代相比较，这个开销就低得多了。

不过，在高并发环境下，写屏障又带来了虚共享（false sharing）问题。

高并发下虚共享带来的性能开销

在高并发情况下，频繁的写屏障很容易发生虚共享（false sharing），从而带来性能开销。

假设CPU缓存行大小为64字节，由于一个卡表项占1个字节，这意味着，64个卡表项将共享同一个缓存行。

HotSpot每个卡页为512字节，那么一个缓存行将对应64个卡页一共64*512=32KB。

如果不同线程对对象引用的更新操作，恰好位于同一个32KB区域内，这将导致同时更新卡表的同一个缓存行，从而造成缓存行的写回、无效化或者同步操作，间接影响程序性能。

一个简单的解决方案，就是不采用无条件的写屏障，而是先检查卡表标记，只有当该卡表项未被标记过才将其标记为dirty。

这就是JDK 7中引入的解决方法，引入了一个新的JVM参数-XX:+UseCondCardMark，在执行写屏障之前，先简单的做一下判断。如果卡页已被标识过，则不再进行标识。

简单理解如下：

if (CARD_TABLE [this address >> 9] != 0)
  CARD_TABLE [this address >> 9] = 0;

与原来的实现相比，只是简单的增加了一个判断操作。

虽然开启-XX:+UseCondCardMark之后多了一些判断开销，但是却可以避免在高并发情况下可能发生的并发写卡表问题。通过减少并发写操作，进而避免出现虚共享问题（false sharing）。

也用于CMS GC

CMS在并发标记阶段，应用线程和GC线程是并发执行的，因此可能产生新的对象或对象关系发生变化，例如：

新生代的对象晋升到老年代；
直接在老年代分配对象；
老年代对象的引用关系发生变更；

等等。

对于这些对象，需要重新标记以防止被遗漏。为了提高重新标记的效率，并发标记阶段会把这些发生变化的对象所在的Card标识为Dirty，这样后续阶段就只需要扫描这些Dirty Card的对象，从而避免扫描整个老年代。

记忆集（Remembered Sets）

伴随 G1 垃圾收集器的诞生，传统的老年代和新生代都从物理上的连续空间，变成了一个个物理上不连续的空间 region。

JVM 针对这些Region 提供了一个数据结构，也就是 CSet（Collection Set），存储任意年代的region。

物理上不连续的 region 造成了新生代和老年的引用破碎化，新生代引用老年代，所以产生了 old->young和young->old的跨代对象引用，这时候 JVM 只要扫描 CSet 中的 R Set 即可。

逻辑上说每个Region都有一个RSet，RSet记录了其他Region中的对象引用本Region中对象的关系。

每个Region会在自身的Remembered Set中纪录下来自其他Region的指向自身的Card位置。这个Remembered Set是一个Hash Table，Key是别的Region的起始地址，Value是一个集合，里面的元素是Card Table的Index。

RSet、Card和Region的关系

下图表示了RSet、Card和Region的关系：

图中是相互引用的三个region。R1 和 R3 的被细分到了card table 级别。R2 被 R1 和 R3的某些区域引用，所以 R2 的 RSet 会记录到 R1 和 R2 的区域索引，即产生某些循环引用的作用。

一个 Region 的 RSet 如果有值，至少可以证明这个区域是有引用的；一个区域如果无值，则可以认为这个区域不可达，可以不扫描这个区域（Card Table 可以减少 Minor GC 扫描 old 区来理解 young 区的时间，RSet 则可以减少扫描生成 CSet 选取候选 region 的时间）。

在做YGC的时候，只需要选定young generation region的RSet作为根集，这些RSet记录了old->young的跨代引用，避免了扫描整个old generation。而mixed gc的时候，old generation中记录了old->old的 RSet，young->old的引用由扫描全部young generation region（的 card table）得到，这样也不用扫描全部old generation region。所以RSet的引入大大减少了GC的工作量。