.png){kind=small}
衡量垃圾收集器的三项最重要的指标是：内存占用（Footprint）、吞吐量（Throughput）和延迟
（Latency），三者共同构成了一个“不可能三角[1]”。三者总体的表现会随技术进步而越来越好，但是
要在这三个方面同时具有卓越表现的“完美”收集器是极其困难甚至是不可能的，一款优秀的收集器通
常最多可以同时达成其中的两项。
在内存占用、吞吐量和延迟这三项指标里，延迟的重要性日益凸显，越发备受关注。其原因是随
着计算机硬件的发展、性能的提升，我们越来越能容忍收集器多占用一点点内存；硬件性能增长，对
软件系统的处理能力是有直接助益的，硬件的规格和性能越高，也有助于降低收集器运行时对应用程
序的影响，换句话说，吞吐量会更高。但对延迟则不是这样，硬件规格提升，准确地说是内存的扩
大，对延迟反而会带来负面的效果，这点也是很符合直观思维的：虚拟机要回收完整的1TB的堆内
存，毫无疑问要比回收1GB的堆内存耗费更多时间。由此，我们就不难理解为何延迟会成为垃圾收集
器最被重视的性能指标了。现在我们来观察一下现在已接触过的垃圾收集器的停顿状况，如图3-14所
示。
图3-14中浅色阶段表示必须挂起用户线程，深色表示收集器线程与用户线程是并发工作的。由图
3-14可见，在CMS和G1之前的全部收集器，其工作的所有步骤都会产生“Stop The World”式的停顿；
CMS和G1分别使用增量更新和原始快照（见3.4.6节）技术，实现了标记阶段的并发，不会因管理的堆
内存变大，要标记的对象变多而导致停顿时间随之增长。但是对于标记阶段之后的处理，仍未得到妥
善解决。CMS使用标记-清除算法，虽然避免了整理阶段收集器带来的停顿，但是清除算法不论如何优
化改进，在设计原理上避免不了空间碎片的产生，随着空间碎片不断淤积最终依然逃不过“Stop The
World”的命运。G1虽然可以按更小的粒度进行回收，从而抑制整理阶段出现时间过长的停顿，但毕竟
也还是要暂停的。
Shenandoah和ZGC，几乎整个工作过程全
部都是并发的，只有初始标记、最终标记这些阶段有短暂的停顿，这部分停顿的时间基本上是固定
的，与堆的容量、堆中对象的数量没有正比例关系。实际上，它们都可以在任意可管理的（譬如现在
ZGC只能管理4TB以内的堆）堆容量下，实现垃圾收集的停顿都不超过十毫秒这种以前听起来是天方
夜谭、匪夷所思的目标。
Shenandoah收集器
Oracle仍明确拒绝在OracleJDK 12中支持Shenandoah收集器，并执意在打包
OracleJDK时通过条件编译完全排除掉了Shenandoah的代码，换句话说，Shenandoah是一款只有
OpenJDK才会包含，而OracleJDK里反而不存在的收集器，“免费开源版”比“收费商业版”功能更多，这
是相对罕见的状况[2]。如果读者的项目要求用到Oracle商业支持的话，就不得不把Shenandoah排除在选
择范围之外。
这个项目的目标
是实现一种能在任何堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的垃圾收集器，该
目标意味着相比CMS和G1，Shenandoah不仅要进行并发的垃圾标记，还要并发地进行对象清理后的整
理动作。
从代码历史渊源上讲，比起稍后要介绍的有着Oracle正朔血统的ZGC，Shenandoah反而更像是G1
的下一代继承者，它们两者有着相似的堆内存布局，在初始标记、并发标记等许多阶段的处理思路上
都高度一致，甚至还直接共享了一部分实现代码，这使得部分对G1的打磨改进和Bug修改会同时反映
在Shenandoah之上，而由于Shenandoah加入所带来的一些新特性，也有部分会出现在G1收集器中，譬
如在并发失败后作为“逃生门”的Full GC [3]，G1就是由于合并了Shenandoah的代码才获得多线程Full
GC的支持。
那Shenandoah相比起G1又有什么改进呢？虽然Shenandoah也是使用基于Region的堆内存布局，同样
有着用于存放大对象的Humongous Region，默认的回收策略也同样是优先处理回收价值最大的
Region……但在管理堆内存方面，它与G1至少有三个明显的不同之处，最重要的当然是支持并发的整
理算法，G1的回收阶段是可以多线程并行的，但却不能与用户线程并发，这点作为Shenandoah最核心
的功能稍后笔者会着重讲解。其次，Shenandoah（目前）是默认不使用分代收集的，换言之，不会有
专门的新生代Region或者老年代Region的存在，没有实现分代，并不是说分代对Shenandoah没有价值，
这更多是出于性价比的权衡，基于工作量上的考虑而将其放到优先级较低的位置上。最后，
Shenandoah摒弃了在G1中耗费大量内存和计算资源去维护的记忆集，改用名为“连接矩阵”（Connection
Matrix）的全局数据结构来记录跨Region的引用关系，降低了处理跨代指针时的记忆集维护消耗，也降
低了伪共享问题（见3.4.4节）的发生概率。连接矩阵可以简单理解为一张二维表格，如果Region N有
对象指向Region M，就在表格的N行M列中打上一个标记，如图3-15所示，如果Region 5中的对象Baz
引用了Region 3的Foo，Foo又引用了Region 1的Bar，那连接矩阵中的5行3列、3行1列就应该被打上标
记。在回收时通过这张表格就可以得出哪些Region之间产生了跨代引用。
Shenandoah收集器的工作过程大致可以划分为以下九个阶段
·初始标记（Initial Marking）：与G1一样，首先标记与GC Roots直接关联的对象，这个阶段仍
是“Stop The World”的，但停顿时间与堆大小无关，只与GC Roots的数量相关。
·并发标记（Concurrent Marking）：与G1一样，遍历对象图，标记出全部可达的对象，这个阶段
是与用户线程一起并发的，时间长短取决于堆中存活对象的数量以及对象图的结构复杂程度 。
·最终标记（Final Marking）：与G1一样，处理剩余的SATB扫描，并在这个阶段统计出回收价值
最高的Region，将这些Region构成一组回收集（Collection Set）。最终标记阶段也会有一小段短暂的停
顿。
·并发清理（Concurrent Cleanup）：这个阶段用于清理那些整个区域内连一个存活对象都没有找到
的Region（这类Region被称为Immediate Garbage Region）。
·并发回收（Concurrent Evacuation）：并发回收阶段是Shenandoah与之前HotSpot中其他收集器的
核心差异。在这个阶段，Shenandoah要把回收集里面的存活对象先复制一份到其他未被使用的Region之
中。复制对象这件事情如果将用户线程冻结起来再做那是相当简单的，但如果两者必须要同时并发进
行的话，就变得复杂起来了。其困难点是在移动对象的同时，用户线程仍然可能不停对被移动的对象
进行读写访问，移动对象是一次性的行为，但移动之后整个内存中所有指向该对象的引用都还是旧对象的地址，这是很难一瞬间全部改变过来的。对于并发回收阶段遇到的这些困难，Shenandoah将会通
过读屏障和被称为“Brooks Pointers”的转发指针来解决（讲解完Shenandoah整个工作过程之后笔者还要
再回头介绍它）。并发回收阶段运行的时间长短取决于回收集的大小。
·初始引用更新（Initial Update Reference）：并发回收阶段复制对象结束后，还需要把堆中所有指
向旧对象的引用修正到复制后的新地址，这个操作称为引用更新。引用更新的初始化阶段实际上并未
做什么具体的处理，设立这个阶段只是为了建立一个线程集合点，确保所有并发回收阶段中进行的收
集器线程都已完成分配给它们的对象移动任务而已。初始引用更新时间很短，会产生一个非常短暂的
停顿。
·并发引用更新（Concurrent Update Reference）：真正开始进行引用更新操作，这个阶段是与用户
线程一起并发的，时间长短取决于内存中涉及的引用数量的多少。并发引用更新与并发标记不同，它
不再需要沿着对象图来搜索，只需要按照内存物理地址的顺序，线性地搜索出引用类型，把旧值改为
新值即可。
·最终引用更新（Final Update Reference）：解决了堆中的引用更新后，还要修正存在于GC Roots
中的引用。这个阶段是Shenandoah的最后一次停顿，停顿时间只与GC Roots的数量相关。
·并发清理（Concurrent Cleanup）：经过并发回收和引用更新之后，整个回收集中所有的Region已
再无存活对象，这些Region都变成Immediate Garbage Regions了，最后再调用一次并发清理过程来回收
这些Region的内存空间，供以后新对象分配使用。
转发
指针（Forwarding Pointer，也常被称为Indirection Pointer）来实现对象移动与用户程序并发的一种解决
方案。此前，要做类似的并发操作，通常是在被移动对象原有的内存上设置保护陷阱（Memory
Protection Trap），一旦用户程序访问到归属于旧对象的内存空间就会产生自陷中段，进入预设好的异
常处理器中，再由其中的代码逻辑把访问转发到复制后的新对象上。虽然确实能够实现对象移动与用
户线程并发，但是如果没有操作系统层面的直接支持，这种方案将导致用户态频繁切换到核心态[6]，
代价是非常大的，不能频繁使用[7]。
Brooks提出的新方案不需要用到内存保护陷阱，而是在原有对象布局结构的最前面统一增加一个
新的引用字段，在正常不处于并发移动的情况下，该引用指向对象自己，如图3-17所示。
从结构上来看，Brooks提出的转发指针与某些早期Java虚拟机使用过的句柄定位（关于对象定位
详见第2章）有一些相似之处，两者都是一种间接性的对象访问方式，差别是句柄通常会统一存储在专
门的句柄池中，而转发指针是分散存放在每一个对象头前面。
有了转发指针之后，有何收益暂且不论，所有间接对象访问技术的缺点都是相同的，也是非常显
著的——每次对象访问会带来一次额外的转向开销，尽管这个开销已经被优化到只有一行汇编指令的
程度，譬如以下所示：
不过，毕竟对象定位会被频繁使用到，这仍是一笔不可忽视的执行成本，只是它比起内存保护陷阱的方案已经好了很多。转发指针加入后带来的收益自然是当对象拥有了一份新的副本时，只需要修
改一处指针的值，即旧对象上转发指针的引用位置，使其指向新对象，便可将所有对该对象的访问转
发到新的副本上。这样只要旧对象的内存仍然存在，未被清理掉，虚拟机内存中所有通过旧引用地址
访问的代码便仍然可用，都会被自动转发到新对象上继续工作，如图3-18所示。
需要注意，Brooks形式的转发指针在设计上决定了它是必然会出现多线程竞争问题的，如果收集
器线程与用户线程发生的只是并发读取，那无论读到旧对象还是新对象上的字段，返回的结果都应该
是一样的，这个场景还可以有一些“偷懒”的处理余地；但如果发生的是并发写入，就一定必须保证写
操作只能发生在新复制的对象上，而不是写入旧对象的内存中。读者不妨设想以下三件事情并发进行
时的场景：
1）收集器线程复制了新的对象副本；
2）用户线程更新对象的某个字段；
3）收集器线程更新转发指针的引用值为新副本地址。
如果不做任何保护措施，让事件2在事件1、事件3之间发生的话，将导致的结果就是用户线程对对
象的变更发生在旧对象上，所以这里必须针对转发指针的访问操作采取同步措施，让收集器线程或者用户线程对转发指针的访问只有其中之一能够成功，另外一个必须等待，避免两者交替进行。实际上
Shenandoah收集器是通过比较并交换（Compare And Swap，CAS）操作[8]来保证并发时对象的访问正
确性的。
转发指针另一点必须注意的是执行频率的问题，尽管通过对象头上的Brooks Pointer来保证并发时
原对象与复制对象的访问一致性，这件事情只从原理上看是不复杂的，但是“对象访问”这四个字的分
量是非常重的，对于一门面向对象的编程语言来说，对象的读取、写入，对象的比较，为对象哈希值
计算，用对象加锁等，这些操作都属于对象访问的范畴，它们在代码中比比皆是，要覆盖全部对象访
问操作，Shenandoah不得不同时设置读、写屏障去拦截。
之前介绍其他收集器时，或者是用于维护卡表，或者是用于实现并发标记，写屏障已被使用多
次，累积了不少的处理任务了，这些写屏障有相当一部分在Shenandoah收集器中依然要被使用到。除
此以外，为了实现Brooks Pointer，Shenandoah在读、写屏障中都加入了额外的转发处理，尤其是使用
读屏障的代价，这是比写屏障更大的。代码里对象读取的出现频率要比对象写入的频率高出很多，读
屏障数量自然也要比写屏障多得多，所以读屏障的使用必须更加谨慎，不允许任何的重量级操作。
它的开发者也意识到数量庞大的读屏障带来的性
能开销会是Shenandoah被诟病的关键点之一[9]，所以计划在JDK 13中将Shenandoah的内存屏障模型改
进为基于引用访问屏障（Load Reference Barrier）[10]的实现，所谓“引用访问屏障”是指内存屏障只拦
截对象中数据类型为引用类型的读写操作，而不去管原生数据类型等其他非引用字段的读写，这能够
省去大量对原生类型、对象比较、对象加锁等场景中设置内存屏障所带来的消耗。
Shenandoah停顿时间比其他几款收集器确实有了质的飞跃，但也并未实现最大停顿时间控制在十毫秒以内
的目标，而吞吐量方面则出现了很明显的下降，其总运行时间是所有测试收集器中最长的。
ZGC收集器
ZGC和Shenandoah的目标是高度相似的，都希望在尽可能对吞吐量影响不太大的前提下[2]，实现
在任意堆内存大小下都可以把垃圾收集的停顿时间限制在十毫秒以内的低延迟。但是ZGC和
Shenandoah的实现思路又是差异显著的，如果说RedHat公司开发的Shen-andoah像是Oracle的G1收集器
的实际继承者的话，那Oracle公司开发的ZGC就更像是Azul System公司独步天下的PGC（Pauseless
GC）和C4（Concurrent Continuously CompactingCollector）收集器的同胞兄弟。
ZGC收集器是一款基于Region内存布局的，（暂时）
不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的，以低
延迟为首要目标的一款垃圾收集器。
首先从ZGC的内存布局说起。与Shenandoah和G1一样，ZGC也采用基于Region的堆内存布局，但
与它们不同的是，ZGC的Region具有动态性——动态创建和销毁，以及动态的区域容量大小。在x64硬件平台下，ZGC的
Region可以具有如图3-19所示的大、中、小三类容量：
·小型Region（Small Region）：容量固定为2MB，用于放置小于256KB的小对象。
·中型Region（Medium Region）：容量固定为32MB，用于放置大于等于256KB但小于4MB的对
象。
·大型Region（Large Region）：容量不固定，可以动态变化，但必须为2MB的整数倍，用于放置
4MB或以上的大对象。每个大型Region中只会存放一个大对象，这也预示着虽然名字叫作“大型
Region”，但它的实际容量完全有可能小于中型Region，最小容量可低至4MB。大型Region在ZGC的实
现中是不会被重分配（重分配是ZGC的一种处理动作，用于复制对象的收集器阶段，稍后会介绍到）
的，因为复制一个大对象的代价非常高昂。
接下来是ZGC的核心问题——并发整理算法的实现。Shenandoah使用转发指针和读屏障来实现并
发整理，ZGC虽然同样用到了读屏障，但用的却是一条与Shenandoah完全不同，更加复杂精巧的解题
思路。
染色指针是一种直接将少量额外的信息存储在指针上的技术，可是为什么指针本身也可以存储额
外信息呢？在64位系统中，理论可以访问的内存高达16EB（2的64次幂）字节[3]。实际上，基于需求
（用不到那么多内存）、性能（地址越宽在做地址转换时需要的页表级数越多）和成本（消耗更多晶
体管）的考虑，在AMD64架构[4]中只支持到52位（4PB）的地址总线和48位（256TB）的虚拟地址空
间，所以目前64位的硬件实际能够支持的最大内存只有256TB。此外，操作系统一侧也还会施加自己
的约束，64位的Linux则分别支持47位（128TB）的进程虚拟地址空间和46位（64TB）的物理地址空
间，64位的Windows系统甚至只支持44位（16TB）的物理地址空间。
尽管Linux下64位指针的高18位不能用来寻址，但剩余的46位指针所能支持的64TB内存在今天仍
然能够充分满足大型服务器的需要。鉴于此，ZGC的染色指针技术继续盯上了这剩下的46位指针宽
度，将其高4位提取出来存储四个标志信息。通过这些标志位，虚拟机可以直接从指针中看到其引用对
象的三色标记状态、是否进入了重分配集（即被移动过）、是否只能通过finalize()方法才能被访问
到，如图3-20所示。当然，由于这些标志位进一步压缩了原本就只有46位的地址空间，也直接导致
ZGC能够管理的内存不可以超过4TB（2的42次幂）。
·染色指针可以使得一旦某个Region的存活对象被移走之后，这个Region立即就能够被释放和重用
掉，而不必等待整个堆中所有指向该Region的引用都被修正后才能清理。这点相比起Shenandoah是一个
颇大的优势，使得理论上只要还有一个空闲Region，ZGC就能完成收集，而Shenandoah需要等到引用
更新阶段结束以后才能释放回收集中的Region，这意味着堆中几乎所有对象都存活的极端情况，需要
1∶1复制对象到新Region的话，就必须要有一半的空闲Region来完成收集。
·染色指针可以大幅减少在垃圾收集过程中内存屏障的使用数量，设置内存屏障，尤其是写屏障的
目的通常是为了记录对象引用的变动情况，如果将这些信息直接维护在指针中，显然就可以省去一些
专门的记录操作。实际上，到目前为止ZGC都并未使用任何写屏障，只使用了读屏障（一部分是染色指针的功劳，一部分是ZGC现在还不支持分代收集，天然就没有跨代引用的问题）。能够省去一部分的内存屏障，显然对程序运行效率是大
有裨益的，所以ZGC对吞吐量的影响也相对较低。
染色指针的优势
染色指针可以使得一旦某个Region的存活对象被移走之后，这个Region立即就能够被释放和重用掉，而不必等待整个堆中所有指令向该Region的引用都被修正后才能清理。
染色指针可以大幅减少在垃圾收集过程中内存屏障的使用数量，设置内存屏障，尤其是在写屏障的目的通常是为了记录对象引用的变动情况，如果将这些信息直接维护在指针中，显然就可以省去一些专门的记录操作，不需要维护额外的数据结构，只需要在存储地址修改。
染色指针可以作为一种可扩展的存储结构用来记录更多与对象标记、重定位过程相关的数据，以便日后进一步提高性能。
不过，要顺利应用染色指针有一个必须解决的前置问题：Java虚拟机作为一个普普通通的进程，
这样随意重新定义内存中某些指针的其中几位，操作系统是否支持？处理器是否支持？这是很现实的
问题，无论中间过程如何，程序代码最终都要转换为机器指令流交付给处理器去执行，处理器可不会
管指令流中的指针哪部分存的是标志位，哪部分才是真正的寻址地址，只会把整个指针都视作一个内
存地址来对待。这个问题在Solaris/SPARC平台上比较容易解决，因为SPARC硬件层面本身就支持虚拟
地址掩码，设置之后其机器指令直接就可以忽略掉染色指针中的标志位。但在x86-64平台上并没有提
供类似的黑科技，ZGC设计者就只能采取其他的补救措施了，这里面的解决方案要涉及虚拟内存映射
技术，让我们先来复习一下这个x86计算机体系中的经典设计。
通过在线性虚拟空间的页与物理地址空
间的页之间建立的映射表，分页管理机制会进行线性地址到物理地址空间的映射，完成线性地址到物
理地址的转换[8]。
不同层次的虚拟内存到物理内存的转换关系可以在硬件层面、操作系统层面或者软件进程层面实
现，如何完成地址转换，是一对一、多对一还是一对多的映射，也可以根据实际需要来设计。
Linux/x86-64平台上的ZGC使用了多重映射（Multi-Mapping）将多个不同的虚拟内存地址映射到同一
个物理内存地址上，这是一种多对一映射，意味着ZGC在虚拟内存中看到的地址空间要比实际的堆内
存容量来得更大。把染色指针中的标志位看作是地址的分段符，那只要将这些不同的地址段都映射到
同一个物理内存空间，经过多重映射转换后，就可以使用染色指针正常进行寻址了，效果如图3-21所
示。
多重映射实际上是通过多个地址视图，对应不同的标记阶段，每次只会有一个生效，通过虚拟地址映射到同一块物理地址，因为是虚拟地址，所以可以实现垃圾回收大对象回收不用真正复制大对象实际地址，避免大的开销（个人理解）。
在某些场景下，多重映射技术确实可能会带来一些诸如复制大对象时会更容易这样的额外好处。
ZGC的运作过程大致可划分为以下四个大的阶
段。全部四个阶段都是可以并发执行的，仅是两个阶段中间会存在短暂的停顿小阶段，这些小阶段，
譬如初始化GC Root直接关联对象的Mark Start，与之前G1和Shenandoah的Initial Mark阶段并没有什么
差异。
·并发标记（Concurrent Mark）：与G1、Shenandoah一样，并发标记是遍历对象图做可达性分析的
阶段，前后也要经过类似于G1、Shenandoah的初始标记、最终标记（尽管ZGC中的名字不叫这些）的
短暂停顿，而且这些停顿阶段所做的事情在目标上也是相类似的。与G1、Shenandoah不同的是，ZGC
的标记是在指针上而不是在对象上进行的，标记阶段会更新染色指针中的Marked 0、Marked 1标志
位。
·并发预备重分配（Concurrent Prepare for Relocate）：这个阶段需要根据特定的查询条件统计得出
本次收集过程要清理哪些Region，将这些Region组成重分配集（Relocation Set）。重分配集与G1收集器
的回收集（Collection Set）还是有区别的，ZGC划分Region的目的并非为了像G1那样做收益优先的增量回收。相反，ZGC每次回收都会扫描所有的Region，用范围更大的扫描成本换取省去G1中记忆集的
维护成本。因此，ZGC的重分配集只是决定了里面的存活对象会被重新复制到其他的Region中，里面
的Region会被释放，而并不能说回收行为就只是针对这个集合里面的Region进行，因为标记过程是针对
全堆的。此外，在JDK 12的ZGC中开始支持的类卸载以及弱引用的处理，也是在这个阶段中完成的。
·并发重分配（Concurrent Relocate）：重分配是ZGC执行过程中的核心阶段，这个过程要把重分
配集中的存活对象复制到新的Region上，并为重分配集中的每个Region维护一个转发表（Forward
Table），记录从旧对象到新对象的转向关系。得益于染色指针的支持，ZGC收集器能仅从引用上就明
确得知一个对象是否处于重分配集之中，如果用户线程此时并发访问了位于重分配集中的对象，这次
访问将会被预置的内存屏障所截获，然后立即根据Region上的转发表记录将访问转发到新复制的对象
上，并同时修正更新该引用的值，使其直接指向新对象，ZGC将这种行为称为指针的“自愈”（Self
Healing）能力。这样做的好处是只有第一次访问旧对象会陷入转发，也就是只慢一次，对比
Shenandoah的Brooks转发指针，那是每次对象访问都必须付出的固定开销，简单地说就是每次都慢，
因此ZGC对用户程序的运行时负载要比Shenandoah来得更低一些。还有另外一个直接的好处是由于染
色指针的存在，一旦重分配集中某个Region的存活对象都复制完毕后，这个Region就可以立即释放用于
新对象的分配（但是转发表还得留着不能释放掉），哪怕堆中还有很多指向这个对象的未更新指针也
没有关系，这些旧指针一旦被使用，它们都是可以自愈的。
·并发重映射（Concurrent Remap）：重映射所做的就是修正整个堆中指向重分配集中旧对象的所
有引用，这一点从目标角度看是与Shenandoah并发引用更新阶段一样的，但是ZGC的并发重映射并不
是一个必须要“迫切”去完成的任务，因为前面说过，即使是旧引用，它也是可以自愈的，最多只是第
一次使用时多一次转发和修正操作。重映射清理这些旧引用的主要目的是为了不变慢（还有清理结束
后可以释放转发表这样的附带收益），所以说这并不是很“迫切”。因此，ZGC很巧妙地把并发重映射
阶段要做的工作，合并到了下一次垃圾收集循环中的并发标记阶段里去完成，反正它们都是要遍历所
有对象的，这样合并就节省了一次遍历对象图[9]的开销。一旦所有指针都被修正之后，原来记录新旧
对象关系的转发表就可以释放掉了。
相比G1、Shenandoah等先进的垃圾收集器，ZGC在实现细节上做了一些不同的权衡选择，譬如G1
需要通过写屏障来维护记忆集，才能处理跨代指针，得以实现Region的增量回收。记忆集要占用大量
的内存空间，写屏障也对正常程序运行造成额外负担，这些都是权衡选择的代价。ZGC就完全没有使
用记忆集，它甚至连分代都没有，连像CMS中那样只记录新生代和老年代间引用的卡表也不需要，因
而完全没有用到写屏障，所以给用户线程带来的运行负担也要小得多。可是，必定要有优有劣才会称
作权衡，ZGC的这种选择[11]也限制了它能承受的对象分配速率不会太高，可以想象以下场景来理解
ZGC的这个劣势：ZGC准备要对一个很大的堆做一次完整的并发收集，假设其全过程要持续十分钟以
上（请读者切勿混淆并发时间与停顿时间，ZGC立的Flag是停顿时间不超过十毫秒），在这段时间里
面，由于应用的对象分配速率很高，将创造大量的新对象，这些新对象很难进入当次收集的标记范
围，通常就只能全部当作存活对象来看待——尽管其中绝大部分对象都是朝生夕灭的，这就产生了大
量的浮动垃圾。如果这种高速分配持续维持的话，每一次完整的并发收集周期都会很长，回收到的内
存空间持续小于期间并发产生的浮动垃圾所占的空间，堆中剩余可腾挪的空间就越来越小了。目前唯一的办法就是尽可能地增加堆容量大小，获得更多喘息的时间。但是若要从根本上提升ZGC能够应对
的对象分配速率，还是需要引入分代收集，让新生对象都在一个专门的区域中创建，然后专门针对这
个区域进行更频繁、更快的收集。Azul的C4收集器实现了分代收集后，能够应对的对象分配速率就比
不分代的PGC收集器提升了十倍之多。
ZGC还有一个常在技术资料上被提及的优点是支持“NUMA-Aware”的内存分配。NUMA（Non
Uniform Memory Access，非统一内存访问架构）是一种为多处理器或者多核处理器的计算机所设计的
内存架构。由于摩尔定律逐渐失效，现代处理器因频率发展受限转而向多核方向发展，以前原本在北
桥芯片中的内存控制器也被集成到了处理器内核中，这样每个处理器核心所在的裸晶（DIE）[12]都有
属于自己内存管理器所管理的内存，如果要访问被其他处理器核心管理的内存，就必须通过Inter
Connect通道来完成，这要比访问处理器的本地内存慢得多。在NUMA架构下，ZGC收集器会优先尝
试在请求线程当前所处的处理器的本地内存上分配对象，以保证高效内存访问。在ZGC之前的收集器
就只有针对吞吐量设计的Parallel Scavenge支持NUMA内存分配[13]，如今ZGC也成为另外一个选择。
在性能方面，尽管目前还处于实验状态，还没有完成所有特性，稳定性打磨和性能调优也仍在进
行，但即使是这种状态下的ZGC，其性能表现已经相当亮眼，从官方给出的测试结果[14]来看，用“令
人震惊的、革命性的ZGC”来形容都不为过。
图3-23和图3-24是ZGC与Parallel Scavenge、G1三款收集器通过SPECjbb 2015 [15]的测试结果。在
ZGC的“弱项”吞吐量方面，以低延迟为首要目标的ZGC已经达到了以高吞吐量为目标Parallel Scavenge
的99%，直接超越了G1。如果将吞吐量测试设定为面向SLA（Service Level Agreements）应用
的“Critical Throughput”的话[16]，ZGC的表现甚至还反超了Parallel Scavenge收集器。
而在ZGC的强项停顿时间测试上，它就毫不留情地与Parallel Scavenge、G1拉开了两个数量级的差
距。不论是平均停顿，还是95%停顿、99%停顿、99.9%停顿，抑或是最大停顿时间，ZGC均能毫不费
劲地控制在十毫秒之内，以至于把它和另外两款停顿数百近千毫秒的收集器放到一起对比，就几乎显
示不了ZGC的柱状条（图3-24a），必须把结果的纵坐标从线性尺度调整成对数尺度（图3-24b，纵坐
标轴的尺度是对数增长的）才能观察到ZGC的测试结果。
个人认为zgc 与g1都是大堆收集器，但是zgc只有初始标记需要暂停其余都是并发（基于 染色指针和读屏障得知是旧对象，然后通过转发表获取新地址），他的停顿时间比g1短几十倍，效率也更高，没使用写屏障，使用染色指针，不需要维护记忆集，空间时间都有节省，其次内存分配和Parallel Scavenge一样针对核的内存分配，访问速率更快，吞吐量也比g1快，整体性能是高于g1的，使用g1的原因是因为停顿时间可预测，zgc发展暂不成熟，其次zgc不适合分配速度过快的场景，因为未使用分代，所以在并发清理过程中可能出现过的的浮动垃圾，并且每一次清理也是基于全堆去计算的，如果使用分代，可以让年轻代存储周期短的对象，清理频率高一点即可。未分代的原因是人力资源有限未做，节省工作量，而不是因为什么优化策略。
这里的“实验性质”特指ZGC目前尚未具备全部商用收集器应有的特征，如暂不提供全平台的支持（目前仅支持Linux/x86-64），暂不支持新的Graal编译器配合工作等，但这些局限主要是人力资源与工作量上的限制，可能读者在阅读到这部分内容的时候已经有了新的变化。
