JVM从入门到放弃之ZGC垃圾收集器精讲

　　Z Garbage Collector，也称为ZGC，在 jdk 11 中引入的一种可扩展的低延迟垃圾收集器，在 jdk 15 中发布稳定版。在旨在满足以下目标：
　　< 1ms 最大暂停时间(jdk < 16 是 10ms，jdk >=16 是 <1ms )。  暂停时间不会随着堆、live-set 或 root-set 的大小而增加。  使用内存大小从 8MB 到16TB 地堆。
　　ZGC 具有以下特征：  并发  基于 region  压缩  NUMA 感知  使用彩色指针  使用负载屏障
　　ZGC 的核心是一个并发垃圾收集器，这意味着所有繁重的工作都在Java 线程继续执行的同时完成。这极大地限制了垃圾收集对应用程序响应时间的影响。  ZGC 特征
　　ZGC 收集器是一款基于 Region 内存布局的，(暂时) 不设分代的，使用了读屏障、染色指针和内存多重映射等技术来实现可并发的标记-整理算法的，以低延迟为首要目标的一款垃圾收集器。  内存布局ZGC 没有分代的概念
　　ZGC 的内存布局说起。与 Shenandoah 和 G1一样，ZGC 也采用基于 Region 的堆内存布局，但与它们不同的是 ， ZGC 的 Region 具 有 动 态 性 (动态创建和销毁 ， 以及动态的区域容量大小)。在 x64硬件平台下 ， ZGC 的 Region 可以具有大、中、小三类容量(如下图所示):  小型 Region (Small Region )：   容量固定为 2M， 存放小于 256K 的对象。  中兴 Region (Medium Region)：   容量固定为 32M，放置大于等于256K但小于4M的对象。  大型 Region (Large Region):   容量不固定，可以动态变化，但必须为2MB 的整数倍，用于放置 4MB或以上的大对象。
　　NUMA-aware
　　NUMA 对应的有 NMA 、UMA 即 Uniform Memory Access Architecture， NUMA 就是 Non Uniform Memory Access Architecture. UMA 表示内存只有一块，所有的 CUU 都要去访问这些内存，那么会存在竞争问题(竞争内存总线访问权)，有竞争就要去加锁，有锁效率就会受到影响，而且 CPU 核心数越多，竞争就越激烈。NUMA 的话每个 CPU 对应有一个内存块，且这块内存在主板上离这个 CPU 是最近的，每个 CPU 优先访问这块内存，那效率就自然提高了。
　　服务器的 NUMA 架构在中大型系统上非常流行，也就是高性能的解决方案，尤其在系统延迟方面表现非常优秀，ZGC 是能自动感知 NUMA 架构并且充分利用 NUMA 架构的特征。  染色指针(Colored Pointer)
　　Colored Pointer， 即染色指针，如图所示， ZGC 的核心设计之一。以前的垃圾收集器的 GC 信息都保存在对象口中，而 ZGC 的 GC 信息保存在指针中(直接把标记信息记录在对象的引用指针上)。
　　每个对象有一个64位指针，这64位被分为：  18位：预留给以后使用。  1位：Finalizable标识，此位与并发引用处理有关，它表示这个对象只能通过finalizer才能访问(finalizer:object基类的一个空方法，如果被重写则会在GC之前调用该方法，该方法会且只会被调用一次)。  1位：Remapped 标识，设置此位的值后，对象未指向relocation set中(relocation set表示需要GC的Region集合)。  1位：Marked1标识。  1位：Marked0标识，和上面的Marked1都是标记对象用于辅助GC。  42位：对象的地址(所以它可以支持2^42=4T内存)：  为什么会有两个 mark 标记?
　　每一个GC周期开始时，会交换使用的标记位，使上次GC周期中修正的已标记状态失效，所有引用都变成未标记。GC周期1：使用mark0, 则周期结束所有引用mark标记都会成为 01。GC周期2：使用mark1, 与周期1相同，所有的mark标记都会成为 10。  ZGC不能做指针压缩?
　　指针压缩指的是压缩为32位，寻址位数不能超过35，也就是JVM内存最大为32G(2^35=32GB)，这里的寻址位数已经达到了42位。  颜色指针的三大优势 ?在一个Region中的所有存活对象都被移走后(复制走后)，这个Region就可以被立即释放掉，因为它还有转发表记录着原始地址和新地址，这样的话，理论上，只要还有一个Region对象空闲，ZGC就能完成垃圾收集。  颜色指针有指针的＂自愈＂(Self-Healing)能力，这样子就减少了写屏障(例如三色标记中的增量更新或原始快照)，只需要一个读屏障就可以解决问题，减少了内存屏障的使用数量。  颜色指针有着极大的扩展性，因为还有18位未使用，这样更有利于后续功能的扩展。  多重映射寻址
　　不同的虚拟机内存到物理内存的转换关系可以在硬件层面，操作系统层面或者软件层面来实现。在 Linux 平台上 ZGC 采用了多重映射(Mult-Mapping)将多个不同的虚拟内存地址映射到同一个物理内存地址上，着是一种多对一映射，一位着 ZGC 在虚拟内中看到的地址空间要比时机的堆内存容量来得更大。把染色指针中的标志位看作是地址分段符，那只要将这些不同的地址分段符都映射到同一个福利内空间，经过多重映射转换后，就可以直接使用染色指针进行寻址了，如下图所示：
　　多重映射技术确实可能带来一些诸如复制大对象时会更容易这样额外的好处，但是从源头上来说，ZGC 的多重映射只是采用染色指针的衍生品，并不是为了专门的为实现其他某种特征需求而做的。  读屏障
　　ZGC采用的读屏障的方式来修正指针引用，由于ZGC采用的是复制整理的方式进行GC，很有可能在对象的位置改变之后指针位置尚未更新时程序调用了该对象，那么此时在程序需要并行的获取该对象的引用时，ZGC就会对该对象的指针进行读取，判断Remapped标识，如果标识为该对象位于本次需要清理的region区中，该对象则会有内存地址变化，会在指针中将新的引用地址替换原有对象的引用地址，然后再进行返回。
　　如此，使用读屏障便解决了并发GC的对象读取问题。  Object o = obj.fieldA;    // Loading an object reference from heap  Object p = o;             // No barrier, not a load from heap o.doSomething();          // No barrier, not a load from heap int i = obj.fieldB;       // No barrier, not an object reference
　　LoadBarriers的存在，所以会导致配置ZGC的应用的吞吐量会变低。官方的测试数据是需要多出额外4%的开销：  ZGC 工作过程
　　ZGC 的运作过程主要可以分为以下四个阶段：
　　ZGC 处理过程.png
　　并发标记(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 很巧妙地把并发重映射阶段要做的工作，合并到了下一次垃圾收集循环中的并发标记阶段里去完成，反正它们都是要遍历所有对象的，这样合并就节省了一次遍历对象的开销。一旦所有指针都被修正之后，原来记录新旧对象关系的转发表就可以释放掉了。  ZGC 核心参数
　　ZGC 触发时机
　　ZGC 中的几种触发 GC场景：  定时触发：   默认为不使用，可以通过 ZCollectionInterval 参数配置。GC 日志中的关键字 ＂Timer＂。  预热触发：   最多三次，在堆内存空间达到 10%、20%、30% 时机触发、主要是通过 GC 的时间、为其他的 GC 触发准备。GC日志关键字 ＂Warmup＂。  分配速率：   基于正态分布统计，计算内存 99% 可能的最大分配速率，以及此速率下内存将要耗尽的时间点，在耗尽之前触发 GC (耗尽时间，一次 GC 最大持续时间-一次 GC 检测周期时间)。GC日志关键字 ＂Allocation Rate＂。  主动触发：   (默认开启，可以通过 ZProactictive 参数配置)距上一次 GC 堆内存增长 10%，超过 5 分钟时，对比上次 GC的间隔时间限(一次 GC 最大持续时间)，超过则触发。GC 日志关键字 ＂Proactive＂。  元数据分配触发：   元数据区不足导致，GC 日志关键中是 ＂Metadata GC Threshold＂  直接触发：   代码中显示调用 System.gc() 触发，GC 日志关键字是 ＂System.gc()＂。  阻塞内存分配请求触发：   垃圾对象来不及挥手，占满整个堆空间，导致部分线程阻塞，GC 日志关键字是 ＂Allocation Stall＂。  ZGC 日志分析
　　我们将对下面的一个简单的程序做一个 ZGC LOG 做一个分析，下面是具体的代码和分析。  示例代码
　　下面是一段简单的代码：  /**  * VM Args：-XX:+UseZGC -Xmx8m -Xlog:gc*  */ public class HeapOOM {      public static void main(String[] args) {         List list = new ArrayList<>();         while (true) {             list.add(new byte[2048]);         }     } }  GC 日志分析
　　GC 日志如下(运行环境 JDK 17)，举个例子：GC 日志中每一行都标注了对 GC 过程中的信息，关键信息如下：
　　Start：   开始GC，并标明的GC触发的原因。上图中触发原因是自适应算法。  Phase-Pause Mark Start：   初始标记，会STW。  Phase-Pause Mark End：   再次标记，会STW。  Phase-Pause Relocate Start：   初始转移，会STW。
　　Heap信息：记录了GC过程中Mark、Relocate前后的堆大小变化状况。High和Low记录了其中的最大值和最小值，我们一般关注High中Used的值，如果达到100%，在GC过程中一定存在内存分配不足的情况，需要调整GC的触发时机，更早或者更快地进行GC。
　　GC信息统计：可以定时的打印垃圾收集信息，观察10秒内、10分钟内、10个小时内，从启动到现在的所有统计信息。利用这些统计信息，可以排查定位一些异常点。  ZGC 总结
　　本文主要是从概念上描述了 ZGC 的特征和工作过程。
　　目前大多数互联网公司还是使用 jdk 8、jdk 11 主流使用的还是 ParNew + CMS 组合或者 G1。
　　对于我们一线 Java 开发者应该具备新技术的学习热情和关注度，才能在激烈的社会竞争中保持优势。
　　原文 https://developer.51cto.com/article/706899.html