JDK之ZGC介绍

拼搏现实的明天。 2022-12-29 06:41 190阅读 0赞

\*\*视频课：[https://edu.csdn.net/course/detail/31331][https_edu.csdn.net_course_detail_31331]  
前言

ZGC是最近由Oracle为OpenJDK开源的新垃圾收集器。它主要由Per Liden编写。ZGC类似于Shenandoah或Azul的C4，专注于减少暂停时间的同时仍然压缩堆 。

虽然我不会在这里给出完整的介绍，但“压缩堆”只是意味着将仍然存活的对象移动到堆的其他区域.这样做有助于减少碎片，但通常这也意味着整个应用程序（包括其所有线程）需要暂停,这通常被称为Stop the world 。只有GC完成后，才能恢复应用程序。

在GC相关的文献中，应用程序通常称为mutator ，因为从GC的角度来看，应用程序会改变堆(mutates the heap)。根据堆的大小，这样的暂停可能需要几秒钟，这对于交互式应用程序来说可能是难以接受的。

有几种方法可以减少暂停时间：

GC可以在压缩时使用多个线程（并行压缩 parallel compaction）
    压缩工作也可以分为多个暂停（增量压缩 incremental compaction）
    压缩堆的同时不暂停应用程序，或者只是很短时间暂停（并发压缩 concurrent compaction）
    Go的GC就是完全不压缩堆

如前所述，ZGC会进行并发压缩，这当然不是一个简单的实现功能，因此我想描述一下这是如何工作的。为什么这很复杂？

你需要将对象复制到另一个内存地址，同时另一个线程仍然可以读写旧对象。

如果对象已经复制成功，那么堆中仍有许多指向旧地址的引用需要更新到新地址。

虽然并发压缩（concurrent compaction）似乎是上述方案中降低暂停时间的最佳解决方案，但肯定会涉及一些权衡。因此，如果您不关心暂停时间，那么最好使用专注于吞吐量的GC。  
GC屏障 (GC Barriers)

理解ZGC如何进行并发压缩的关键是Load barrier (通常在GC文献中称为Read barrier).这里简单介绍一下，详细的描述请看下面的Load Barrier一节。

如果GC有读取屏障（Load barrier），则在从堆读取引用时，GC需要执行一些额外操作。在Java中,也就是像执行这样的代码Object xxx=obj.field时需要额外操作。

对于像obj.field = value这样的操作，GC也可能需要写入屏障(叫做Write Barrier或者Store Barrier)\[译注：在分代GC还有引用计数中会用到写入屏障\].

这两个操作都比较特殊因为它们在每次读取或写入堆时发生的。Load Barrier和Store Barrier的名称有点令人困惑，但注意这个屏障与CPU的内存障碍是完全不同的两个概念

堆中的读取和写入都非常常见，因此两种GC屏障都需要非常高效，在常见情况下就是一些汇编代码。Read barrier通常比Write Barrier大一个数量级（可能会因应用程序而异），因此Read Barrier对性能要求更高。

例如，分代GC通常只需要一个写屏障，不需要读屏障。ZGC则需要一个读屏障但没有写屏障。对于并发压缩，我没有看到没有读取障碍的解决方案。

这里需要注意：即使GC需要某种类型的屏障，只有在读取或写入堆中的引用时需要它们。读取或写入像int或double这样的基本类型是不需要屏障的.  
指针标记（Pointer tagging Or Colored Pointers ）

ZGC在堆引用中存储额外的元数据 ，在x64上是64 bit（ZGC目前不支持compressed oops和 class pointers）。64位中的48位用做x64上的虚拟内存地址 。虽然确切地说只有47位，因为第47位确定了位48-63的值（目前这些位都是0）。ZGC保留对象实际地址的前42位（在源代码中称为偏移量 ）。42位地址理论上就会有4TB的堆大小限制。其余的位用于这些标志： finalizable ， remapped ， marked1和marked0 （保留一位用于将来使用）。如下图所示:

6 4 4 4 4 4 0  
3 7 6 5 2 1 0  
±------------------±±—±----------------------------------------------+  
|00000000 00000000 0|0|1111|11 11111111 11111111 11111111 11111111 11111111|  
±------------------±±—±----------------------------------------------+  
| | | |  
| | | \* 41-0 Object Offset (42-bits, 4TB address space)  
| | |  
| | \* 45-42 Metadata Bits (4-bits) 0001 = Marked0  
| | 0010 = Marked1  
| | 0100 = Remapped  
| | 1000 = Finalizable  
| |  
| \* 46-46 Unused (1-bit, always zero)  
|

*  63-47 Fixed (17-bits, always zero)

在堆引用中具有元数据信息使得解引用更加昂贵，因为需要mask地址以获得没有元信息的真实地址。ZGC采用了一个很好的技巧来避免这种情况：

当从内存中读取时，会设置marked0 , marked1或remapped中的一个。

在偏移x处分配页面（allocating a page）时，ZGC将同一页面映射到3个不同的地址 ：

for marked0 ：(0b0001 << 42) | x
    for marked1 ： (0b0010 << 42) | x
    for remapped ： (0b0100 << 42) | x

因此，ZGC从地址4TB开始保留16TB的地址空间（但实际上并未使用所有这些内存）。如下图：

±-------------------------------+ 0x0000140000000000 (20TB)  
| Remapped View |  
±-------------------------------+ 0x0000100000000000 (16TB)  
| (Reserved, but unused) |  
±-------------------------------+ 0x00000c0000000000 (12TB)  
| Marked1 View |  
±-------------------------------+ 0x0000080000000000 (8TB)  
| Marked0 View |  
±-------------------------------+ 0x0000040000000000 (4TB)

在任何时间点，只使用这三个视图中的一个。调试时可以取消映射（unmapped）未使用的视图来验证正确性。  
Pages & Physical & Virtual Memory

Shenandoah将堆分成大量同样大小的区域 。除了不适合单个区域的大对象外，对象通常不会跨越多个区域。大对象被分配在多个连续区域中。我非常喜欢这种方法，因为它非常简单。

在这方面，ZGC与Shenandoah非常相似。在ZGC的说法中，区域称为页面Pages 。

与Shenandoah的主要区别：ZGC中的页面可以有不同的大小（但在x64上总是2MB的倍数）。

ZGC有3种不同的页面类型： 小型 （2MB大小）， 中型 （32MB大小）和大型 （2MB的倍数）。

在小页面中分配小对象（最大256KB大小），在中型页面中分配中型对象（最多4MB）。大页面中分配大于4MB的对象。大页面只能存储一个对象.小页面或中间页面可以分配多个。

有些令人困惑的是大页面实际上可能小于中等页面（例如，对于大小为6MB的大对象）。

ZGC的另一个不错的特性是，它还可以区分物理内存和虚拟内存。这背后的想法是通常有足够的虚拟内存（ZGC总是4TB），而物理内存更稀缺。物理内存可以扩展到最大堆大小（使用-Xmx设置），因此这比4 TB的虚拟内存要小得多。在ZGC中分配特定大小的页面意味着分配物理和虚拟内存。在ZGC中，物理内存不需要是连续的，虚拟内存空间是连续的。

为什么说这是一个不错的属性？

分配连续范围的虚拟内存是很容易的，因为我们通常有足够的虚拟内存。但在物理内存中有3个大小为2MB的空闲页面的情况很普通，但是对于大型对象分配我们需要6MB的连续内存。有足够的空闲物理内存，但不幸的是这个内存是不连续的。ZGC能够将这些非连续的物理页面映射到单个连续的虚拟内存空间。如果无法映射，我们就会耗尽内存（发生OOM）  
标记和重新安置对象（Marking & Relocating objects）

垃圾回收主要分为两个阶段：标记和重新安置（实际上不止这两个阶段，你可以查阅源码）。

\[译注：重新安置（Relocating）指的是把对象从一个内存区域移到另外一个区域，重映射(Remapping)只的是把指向老的地址的引用更新到新的地址\]

一次GC从标记阶段开始，标记所有可到达的对象。在这个阶段结束时，我们知道哪些对象仍然存活，哪些对象是垃圾。ZGC将此信息存储在每个页面的Live Map中。Live Map是一个位图(bitmap) ，用于存储给定索引处的对象是否可达和/或最终可达（对于具有finalize method的对象而言）。

在标记阶段，应用程序线程中的load-barrier将未标记的引用推送到线程局部标记缓冲区。只要此缓冲区已满，GC线程就可以获得此缓冲区的所有权，并以递归方式遍历此缓冲区中的所有可到达对象。在应用程序线程中标记只是将引用推送到缓冲区，GC线程负责遍历对象图并更新Live map.

标记阶段结束后，ZGC要重新安置 Relocation set中的所有活动对象。

Relocation Set表示一组需要被回收的页面（Pages)，例如那些垃圾最多的页面。存活的对象由GC线程或应用程序线程通过读取屏障（Load Barrier）重新安置（relocated）（也就是放到新的地址去）.ZGC为Relocation set中的每个页面分配Forwarding table.

Forwarding table基本上是一个hash map，它存储一个对象已被重新安置到的地址（如果该对象已经被重新安置）。

ZGC方法的优点是我们只需要为relocation set中的页面分配forwarding table的空间.  
相比之下，Shenandoah将转发指针存储在每个对象本身，这样就谁有一些额外的内存开销。

GC线程遍历 Relocation set中的存活对象，并重新安置（relocate）尚未重新安置的对象。这时可能发生应用程序线程和GC线程同时重新安置（relocate）同一个对象，在这种情况下，谁先relocate谁获胜，ZGC使用原子CAS操作来确定胜者。

当不处于marking阶段时，load-barrier会重新安置(relocates )/重新映射(remaps )从堆加载的所有引用。这确保了mutator看到的每个新引用都已指向对象的最新副本。重新映射（remaps）对象就是在forwarding table中查找新的对象地址。

一旦GC线程完成了relocation set的处理，重新安置阶段就完成了。虽然这意味着所有对象都已重新安置，但通常仍会有引用指向relocation set，需要将其重新映射（remapped ）到新地址。这些引用会被Load-Barrier自我修复。如果对于这些引用的读取发生的不够快，（也就是这段时间内，应用程序没有读到这些指向relocation set的引用），这些引用会在下一次mark阶段给修复。这意味着标记阶段还需要检查 forward table以重新映射(remap) （但不重新安置 ，所有对象之前阶段都保证被重新安置）对象到它们的新地址。

这也解释了为什么对象引用中有两个标记位（marked0 和marked1 ）。标记阶段在标记的marked0和marked1位之间交替。在重新安置阶段之后，仍可能存在未重定向（remapped）的引用，所以我们需要知道上一个gc周期的情况。如果新的标记阶段使用相同的标记位，则Load-Barrier就知道该引用为已标记。

(译注：这里看起来像是GC周期remap和mark可以重叠，实际上确实是重叠的。如图所示：  
gc phase  
更详细的信息可以看这个Slide)  
Load-Barrier

从堆中读取引用时，ZGC需要一个所谓的load-barrier（也称为read-barrier）。每次Java程序访问对象类型的字段时，我们都需要插入此load-barrier，例如obj.field 。访问某些其他原始类型的字段不需要屏障，例如obj.anInt或obj.anDouble 。ZGC不需要obj.field = someValue存储/写入障碍。

根据GC当前所处的阶段（存储在全局变量ZGlobalPhase中 ），如果尚未标记或重新安置对象，则屏障会标记对象或重新安置它

全局变量ZAddressGoodMask和ZAddressBadMask  
存储对应的掩码，该掩码确定引用是否已被认为是好的（这意味着已经标记或重新映射/重新安置remapped/relocated）或者是否仍然需要一些操作。这些变量仅在标记开始阶段和重新安置阶段同时改变.ZGC源代码中的这个表格可以很好地概述这些掩码的状态：

GoodMask         BadMask          WeakGoodMask     WeakBadMask
               --------------------------------------------------------------

Marked0 001 110 101 010  
Marked1 010 101 110 001  
Remapped 100 011 100 011

屏障的汇编代码可以在MacroAssembler for x64中看到，我只会为这个屏障显示一些伪汇编代码：

mov rax, \[r10 + some\_field\_offset\]  
test rax, \[address of ZAddressBadMask\]  
jnz load\_barrier\_mark\_or\_relocate

# otherwise reference in rax is considered good #

第一个汇编指令从堆读取引用： r10存储对象引用， some\_field\_offset是一些字段偏移常量。加载的引用存储在rax寄存器中。

然后针对当前的坏掩码测试该引用（这只是一个位与）。此处不需要同步，因为ZAddressBadMask仅在STW时才更新。如果结果不为零，我们需要执行屏障。

屏障需要根据我们当前所处的GC阶段标记或重新安置对象。在此操作之后， 他需要更新存储在r10 + some\_field\_offset中的引用来指向新引用。这步操作是必要的，以便来该字段的后续加载返回正确的引用。

由于我们可能需要更新引用地址，因此我们需要使用两个寄存器r10和rax作为加载的引用和对象地址。正确的引用也需要存储到寄存器rax中 ，这样在后面的执行过程中我们就已经加载了正确的引用。

由于每个引用都需要标记或重新安置，因此在开始标记或重新安置阶段后，吞吐量可能会立即降低。当大多数引用被修复时，这应该会变得更快。  
Stop-the-World 停顿

ZGC并没有彻底摆脱STW。收集器在开始标记,结束标记和开始重新安置时需要暂停。但这种暂停通常很短,只有几毫秒。

当开始标记时，ZGC遍历所有线程堆栈以标记root set。root set是遍历对象图的开始的地方。root set通常由本地和全局变量组成，但也包括其他内部VM结构（例如JNI句柄）。

结束标记阶段时需要再次暂停。在此暂停中，GC需要清空并遍历所有线程局部标记缓冲区。由于GC可能会发现一个未标记的大型子图，因此可能需要更长时间。ZGC试图通过在1毫秒后停止标记阶段的结束来避免这种情况。它返回到并发标记阶段，直到遍历整个对象图，然后可以再次开始结束标记阶段

启动重新安置阶段会再次暂停应用程序。此阶段与开始标记非常相似，不同之处在于此阶段重新安置Root Set中的对象。  
zgc是一款可拓展的低时延，为实现以下几个目标而诞生的垃圾回收器：

停顿时间不超过10ms
    停顿时间不会因堆变大而变长
    堆大小范围可支持几G到几T

再看一下zgc的标签：

region-based (和G1一样)
    NUMA-aware
    Concurrent
    Compacting
    Using load barriers(让一个CPU处理单元中的内存状态对其它处理单元可见的一项技术，java的volatile底层使用的就是load barrier)
    Using colored pointers()

zgc介绍-by hotspot garbage collector team:https://archive.fosdem.org/2018/schedule/event/zgc/attachments/slides/2211/export/events/attachments/zgc/slides/2211/ZGC\_FOSDEM\_2018.pdf  
一、zgc在jdk各个版本的changelog：

JDK 13 (Released September 2019)

Increased max heap size from 4TB to 16TB
    Support for uncommitting unused memory (JEP 351)
    Support for -XX:SoftMaxHeapSIze
    Support for the Linux/AArch64 platform
    Reduced Time-To-Safepoint

JDK 12 (Released March 2019)

Support for concurrent class unloading
    Further pause time reductions

JDK 11 (Released September 2018)

Initial version of ZGC
    Does not support class unloading (using -XX:+ClassUnloading has no effect)

二、ZGC相关VM Options

General GC Options ZGC Options ZGC Dianostic Options （-XX:+UnlockDianosticVMOptions）

\-XX:MinHeapSize, -Xms

\-XX:InitialHeapSize, -Xms

\-XX:MaxHeapSize, -Xmx

\-XX:SoftMaxHeapSize

\-XX:SoftRefLRUPolicyMSPerMB

\-XX:ZAllocationSpikeTolerance

\-XX:ZCollectionInterval

\-XX:ZFragmentationLimit

\-XX:ZMarkStackSpaceLimit

\-XX:ZPath

\-XX:ZUncommit

\-XX:ZUncommitDelay

\-XX:ZProactive

\-XX:ZStatisticsForceTrace

\-XX:ZStatisticsInterval

\-XX:ZVerifyForwarding

\-XX:ZVerifyMarking

\-XX:ZVerifyObjects

\-XX:ZVerifyRoots

\-XX:ZVerifyViews

1、激活ZGC

\-XX:+UnlockExperimentalVMOptions -XX:+UseZGC

2、设置堆大小，堆

\-Xmx

3、并发线程数，并发线程数太多会导致占用太多cpu时间分片，太少会导致回收速度跟不上垃圾生产速度。如果系统追求的是低时延，尽量不要让系统超负荷工作，cpu使用率尽量控制在70%以下

\-XX:ConcGCThreads=

4、return unused memery to os

这里指的是设置了xms和xmx且xmx>xms的情况，zgc默认会返回未使用的内存给操作系统，对于内存水位是重要指标的系统，返回未使用内存可以更好的观察内存使用情况。但如果要禁用这个功能，可以使用：-XX:-ZUncommit 。但无论使用哪种策略，jvm不会uncommit unsed memery导致堆大小小于xms。这也意味着如果配置xms=xmx，该特性会被隐式禁用

5、Enable Large Pages

启用方式：-XX:+UseLargePages

Large Pages在Linux称为Huge Pages，配置zgc使用Huge Pages可以获得更好的性能（吞吐量、延迟、启动时间），并且基本没有缺点，除了配置稍微复杂一点。配置Huge Pages大小，需要注意JVM除了堆以外其他需要使用到的内存也得算进去，具体配置方法如下，就不翻译了：

6、 Enable Transparent Huge Page(THP)

一般不建议在对延时敏感的系统下使用，THP一个使管理Huge Pages自动化的抽象层。

7、Enable NUMA Support

zgc默认开启NUMA支持，意味着在分配堆内存时，会尽量使用NUMA-local的内存（比跨die访问快3倍）。但当jvm发现程序使用的只是cpu的一个子集（限定使用），则会自动禁用该特性。一般不需要关注这个特性，如果需要指定，可以通过以下参数指定

\-XX:+/-UseNUMA

8、Enable GC logging

[https_edu.csdn.net_course_detail_31331]: https://edu.csdn.net/course/detail/31331