ZGC源码分析（1）- ZGC概述

最新的JDK 11在2018年9月25号正式发布，这这一版本中有不少新的特性，但是最令人关注的是JDK 11中的新款的垃圾回收器ZGC虽然它被明确地标记为实验性质（意味着还不成熟），但是仍然阻挡不了众多Java程序员对它的追捧。那么为什么JDK要实现一个新的垃圾回收器，它解决的是什么问题？

为什么需要ZGC

回答这个问题要回顾一下垃圾回收的现状。目前JVM中最新新成熟的垃圾回收器是G1，它是CMS的取代者。G1也是分代内存管理，在设计上把大的连续的内存划分成众多的小分区进行管理；新引入了Refinement管理代际之间的引用用于加速垃圾对象的识别；引入了并发标记（并发标记指的是标记线程和应用线程并发执行，不需要STW）；垃圾回收过程中采用部分内存收集（G1有两种类型的垃圾回收，新生代回收-回收全部的新生代分区、混合回收-回收全部的新生代分区和部分老生代分区）。它的目的就是在可控的停顿时间完成垃圾回收，另外由于分区设计它支持的内存也可以达到几十GB或者上百GB。但是G1由于设计上的特点，导致存在下面的问题：

停顿时间过长，通常G1的停顿时间要达到几十到几百毫秒；
内存利用率不高，通常Refinement的额外内存消耗在1%~20%左右；
支持的内存空间有限，不能适用于超大内存的系统。
关于G1详细的介绍可以参考笔者的新书《JVM G1源码分析和调优》（-待出版）

所以有新垃圾回收器的需求。在2004年Redhat公司推出Shenandoah，并捐赠给OpenJDK社区。2017年Oracle公司推出ZGC并捐赠给OpenJDK社区。
这两款垃圾回收器都是以解决大内存、短停顿时间、高吞吐量为目的。但两者设计有所不同，相对而言ZGC效率更高、Shenandoah更成熟功能更完善，关于Shenandoah本文不再介绍。仅仅关注ZGC。
ZGC作为新一代的垃圾回收器，在设计之处就定义了3个大的目标：支持TB级内存，停顿时间控制在10ms之内，对程序吞吐量影响小于15%。
实际上目前ZGC已经能满足设计之初时定义的目标，并且垃圾回收时间并不会随着内存的增大而延长。下面我们看一看ZGC是如何设计来满足设计目标。

ZGC的创新在哪里

大家看到这三大目标，是不是都觉得不可思议，它应该怎么设计或者怎么改进以前的垃圾回收器才能实现这些目标。ZGC的设计思路借鉴了一款商业的垃圾回收器Azul的C4。这款垃圾回收器号称是无停顿时间。所以很多同学也以为ZGC也是完全无停顿时间。关于C4的介绍可以参考论文。在这里稍微对无停顿时间做个解释，实际上从垃圾回收器的角度出发，没有任何一款垃圾回收器能做到完全无停顿时间，所谓的无停顿时间只不过指的是停顿时间足够的短，这个时间不影响应用程序的运行，比如ZGC提到的小于10毫秒的停顿时间，从应用程序来看这个停顿时间就可以忽略，所以被称为无停顿时间。但是大家在学习的时候应该知道这一概念指的什么意思，另外ZGC希望能做到在10毫秒以内的停顿时间，但不是所有的垃圾回收活动（指的是需要STW的标记，重新标记和移动阶段，后文会有详细介绍）都能在10毫秒内完成，这里的10毫秒是一个目标值。那么哪些因素可能影响ZGC的目标停顿时间？除了ZGC中本身的STW活动，还有进入到安全点（执行GC活动之前）的花费，我们知道在JVM中进入安全点时会进行字符串回收（这里字符串的回收指的是使用String类中intern方法导致的垃圾），所以ZGC为了保证进入安全点的时间，会把这一部分工作优化并发处理。

回到ZGC如何设计达成目标这一问题。简单的回答就是ZGC就是把一切能并发处理的工作都并发执行。（在这里再强调一点JVM中并行和并发这两个词，并行指的只有JVM线程运行，应用程序不运行；并发指的是JVM线程和应用程序同时运行，由操作系统调度交替执行）
那么哪些工作是可以并发执行？我们在这里比较一下Parallel GC和G1就能清晰的了解到ZGC做了什么样的优化。

Parallel GC指的是并行垃圾回收，它是分代回收的。在新生代采用复制（Copy）算法，在执行复制算法之前，需要进行STW；在老生代采用标记（Mark）算法，在执行标记压缩之前也需要进行STW；如果内存不足需要进行Full GC时，也需要STW对整个内存进行串行回收。简单的总结就是Parallel GC在进入垃圾回收阶段都是并行执行，应用程序会被暂停。所以Parallel GC是一款注重吞吐率而不是停顿时间的垃圾回收器。
G1为了改进停顿时间这个指标，对整个复制算法（关于复制算法可以参考其他的文章或者笔者的新书）作了优化，把整个复制算法划分成2个大的阶段：对象标记阶段，对象复制阶段。在标记阶段引入了并发标记，所以整个标记阶段重新划分成3个子阶段：初始标记，并发标记，再标记。其中初始标记和在标记需要STW，但是他们的工作量比较小，所以对整体停顿时间影响不大，由于大部分标记工作是并发执行从而大大的减少了停顿时间。但是G1的复制算法的对象复制阶段仍然是串行执行，它需要在STW中。另外G1中如果发生了Full GC，整个Full GC也是需要STW。

从G1的角度理解ZGC可能更加容易，可以简单的的说ZGC把G1中的两个并行阶段（对象复制，Full GC）消除了。让对象复制也并发执行，另外ZGC中没有Full GC这个概念，那么大家可能会问如果对象分配不成功，此时需要传统意义上的Full GC，ZGC既然没有Full GC它是怎么处理这种情况呢？这里先留一个悬念，后文回答这个问题。

所以我们可以看一下Parallel GC,G1,ZGC活动图如下

ZGChuodongtu.JPG

其中绿色表示引用程序的执行，红色表示STW即GC线程并行执行，蓝色标记并发执行的GC线程。

除了并发执行这个显著特点之外，ZGC还有一下特点：

仅支持Linux 64位系统；
内存分区管理，且支持不同的分区粒度；
颜色指针，通过设计不同的标记位区分不同的虚拟空间，而这些不同标记位指示的不同虚拟空间又通过mmap被映射在同一物理地址；
设计了读屏障，实现了增量标记；
垃圾回收时属于部分回收；
NUMA支持，能够满足对象尽量分配在访问速度比较快的地方。
这些内容将在后文一一介绍。

JDK 11中ZGC的不足

ZGC的设计是一样所有能够并发执行的全部并发执行，所以也带了实现的复杂性。目前仅仅是实验性质的垃圾回收器，实验性质就是说ZGC在一些大内存的场景中表现了良好的性能，同时也说明ZGC还有一些不足，主要有：

ZGC仅实现了单代内存管理，也就是说没有考虑热点数据与冷数据，这个在商业的C4已经支持。据说Auzl实现的分代内存管理器比没有分代的内存管理器效率高10倍（并没有找到相关的资料文献），也就是说ZGC还有巨大的进步空间；
C2的支持还不够完善；
不支持Graal， HDSB等功能。
粗略估计要到下一个Long Term Support才能得到完善。

那么为什么还不完善的ZGC这么快加入OpendJDK的官方项目，据Per Lin， Eric等ZGC的几个主要的维护者的观点，希望能尽快推出得到广大开源爱好者的支持，由社区推动快速发展。

另外还要再提一下，虽然ZGC作为实验性质代码合入主干，并不意味着ZGC就是下一代唯一的发展方向，Shenandoah也并未放弃寻求合入主干的机会。据最新的消息，Shenandoah会在JDK 12也作为实验性质的GC合入主干。（目前正在审阅中，2018年12月6号日完成审阅）

申明：本文为笔者原创，任何形式的转载和引用必须得到授权。