OpenJDK ZGC 源码分析（一）概览

1. 前言

G1是JDK中最新最成熟的垃圾回收器，其稳定性和性能得到了广泛的认可。但是，一方面随着硬件的发展，堆空间越来越大，几十GB、上百GB的内存在生产环境逐渐出现；另一方面，对于停顿时间的需求日益严苛，从最初的秒级到百毫秒级，再到十毫秒级和毫秒级。G1对于这种情况逐渐力不从心，下一代低延迟垃圾回收器主要有ZGC和Shenandoah。本文将详细介绍ZGC相关原理。

2. 历史

Oracle在2017年将ZGC贡献给OpenJDK社区。

在JDK 11中作为实验性功能加入（JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)），

在JDK 13中将引入JEP 351: ZGC: Uncommit Unused Memory对ZGC进行改进，JEP 351可以返回未使用的堆内存给操作系统，G1在JDK 12中也有类似改动。

目前ZGC与Red Hat发起的Shenandoah处于竞争关系，抢夺下一代低延迟垃圾回收器的生态位。

3. 原理

ZGC的回收算法与Azul Systems 2005年提出的Pauseless GC类似。仅三次与堆大小无关的短暂STW，开始标记、结束标记、开始relocate，从而轻松实现毫秒级停顿的目标。

3.1 ZGC的目标

停顿时间小于10ms
停顿时间不随堆空间增长而增长
能够处理从几百MB到几TB的堆空间
3.2 ZGC的特性

并发
由于停顿时间小于10ms，显而易见的，回收周期绝大部分逻辑将于Mutator并发执行。

基于区域
与G1类似，JAVA Heap被划分为多个Region，但ZGC中Region大小并不唯一。

压缩算法
为了避免内存碎片，需要在回收周期中进行压缩。

支持NUMA
作为下一代垃圾回收算法，支持NUMA是必须的。

使用colored pointers
CMS和G1标记的是对象，而ZGC标记的是对象指针。

 

在JDK 13中，将支持16TB堆空间，指针标记可能与上图不同。

• 使用读屏障
  由于relocate步骤（类似于G1中的对象复制）是并发执行的，需要引入load barrier机制，根据colored pointer中的值，确保代码能够指向正确的对象地址。

3.3 回收过程

开始标记（STW），标记GC roots
并发的遍历堆中对象，描绘出引用关系
结束标记（STW），记录活动对象和需要回收的对象
并发的relocate准备阶段，弱引用和软引用的处理，类的卸载，relocate集合的选择等
开始relocate（STW），relocate GC roots
并发relocate，这是GC线程和Mutator线程的读屏障都可进行relocate
由于并发relocate非常消耗时间，该子阶段将于下一个回收周期的并发标记子阶段合并在一起，如下图所示：

 

4. 优缺点

4.1 优点

• 停顿时间短，且不随堆空间线性增长

4.2 缺点

不支持分代回收
由于ZGC尚出于实验阶段，且分代代码实现较困难，目前ZGC并没有区分新生代和老年代。
因为没有分代，每次回收都会试图并发标记整个JAVA Heap，并发标记过程可能达到分钟级，如果对象分配速率很高的话，在此期间就可能分配出大量对象，导致ZGC处理困难。
后续ZGC会推出分代机制或Thread Local GC修复此问题。

吞吐量较低，系统额外开销大

ZGC使用了读屏障机制，需要消耗更多的系统资源。

不支持指针压缩
由于引入了colored pointer机制，不再支持指针压缩。而指针压缩对于32GB以下堆有着显著的性能和空间利用率提升。

支持操作系统很少
仅支持Linux/x64，JDK 13中将支持Linux/AArch64

 

5. 引用

JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)[http://openjdk.java.net/jeps/333]
A FIRST LOOK INTO ZGC[http://dinfuehr.github.io/blog/a-first-look-into-zgc/]
ZGC - The Z Garbage Collector[http://openjdk.java.net/projects/zgc/]
ZGC wiki[https://wiki.openjdk.java.net/display/zgc/Main]
PL-Meetup 2019[http://cr.openjdk.java.net/~pliden/slides/ZGC-PLMeetup-2019.pdf]