为 Java 开疆扩土的 ZGC
点击上方“芋道源码”，选择“设为星标”
管她前浪，还是后浪？
能浪的浪，才是好浪！
每天 10:33 更新文章，每天掉亿点点头发...
源码精品专栏
一、JVM
JVM 是虚拟机，能够识别字节码，就是 class 文件或者你打包的 jar 文件，运行在操作系统上。
JVM 帮我们实现了跨平台，你只需要编译一次（Compile once，Running everywhere），就可以在不同的操作系统上运行，并且效果是一致的。
在 Java 中你使用对象，使用内存，不用担心回收，只管 new 对象就行了，不用管垃圾的回收。因为 Java 当中是自动化的垃圾回收机制。JVM有专门的垃圾回收器，把垃圾回收这件事给干了。
基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/ruoyi-vue-pro 视频教程：https://doc.iocoder.cn/video/
二、ZGC 出现的背景
简言之，ZGC 的出现就是为了解决传统垃圾回收 STW 时间长的问题。
2.1 STW 带来的问题
（1）安卓手机的卡顿问题：Google 主导的 Android 系统需要解决的一大问题就是显示卡顿问题，通过对 GC 算法的不断演进，停顿时间控制在几个ms 级别。所以这也是Android与苹果IOS系统竞争的一大利器。
（2）证券交易系统的实时性要求：证券交易系统主要就是买入、卖出，现在都是使用系统完成自动下单，如果因为STW时间过长，可能就会在错误的时间点买入卖出。
（3）大数据平台：集群性能问题。
基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能
项目地址：https://github.com/YunaiV/yudao-cloud 视频教程：https://doc.iocoder.cn/video/
三、垃圾回收器的发展
传统的 GC，如 CMS、G1 的停顿时间也跟随着堆大小的增长而同步增加，即堆大小指数级增长时，停顿时间也会指数级增长。特别是当触发 Full GC 时，停顿可达分钟级别(百GB级别的堆)。
为满足当前应用对于超低停顿、并应对大堆和超大堆带来的挑战，伴随着 2018 年发布的 JDK 11，A Scalable Low-Latency Garbage Collector - ZGC 应运而生。
四、ZGC 的特点
停顿时间不超过10ms（JDK16 已经达到不超过 1ms）； 停顿时间不会随着堆的大小，或者活跃对象的大小而增加； 支持8MB~4TB级别的堆，JDK15 后已经可以支持 16TB。
五、ZGC 的内存布局
为了细粒度地控制内存的分配，和 G1 一样，ZGC 将内存划分成小的分区，在 ZGC 中称为页面（page）。ZGC中没有分代的概念。
ZGC中支持三种页面，分别为小页面、中页面和大页面。其中小页面指的是 2MB 的页面空间，中页面指 32MB 的页面空间，大页面指受操作系统控制的大页。
当对象大小小于等于 256KB 时，对象分配在小页面。 当对象大小在 256KB 和 4M 之间，对象分配在中页面。 当对象大于 4M，对象分配在大页面。
ZGC 对于不同页面回收的策略也不同。简单地说，小页面优先回收，中页面和大页面则尽量不回收。
5.1 为什么这么设计？
标准大页（huge page）是 Linux Kernel 2.6 引入的，目的是通过使用大页内存来取代传统的 4KB 内存页面，以适应越来越大的系统内存，让操作系统可以支持现代硬件架构的大页面容量功能。
Huge pages 有两种格式大小：2MB 和 1GB ， 2MB 页块大小适合用于 GB 大小的内存， 1GB 页块大小适合用于 TB 级别的内存；2MB 是默认的页大小。
所以ZGC这么设置也是为了适应现代硬件架构的发展，提升性能。
六、ZGC 的核心概念
6.1 指针着色技术
颜色指针可以说是 ZGC 的核心概念。因为它在指针中借了几个位出来做事情，所以它必须要求在 64 位的机器上才可以工作。并且因为要求 64 位的指针，也就不能支持压缩指针。
ZGC 中低 42 位表示使用中的堆空间。ZGC 借几位高位来做GC相关的事情（快速实现垃圾回收中的并发标记、转移和重定位等）。
七、ZGC 流程
7.1 一次 GC 流程
一次 GC 主要包括两个流程：标记（标记垃圾）和转移（对象的复制和移动）。
7.2 根可达性算法
来判定对象是否存活的。这个算法的基本思路就是通过一系列的称为“GC Roots”的对象作为起始点，从这些节点开始向下搜索，搜索所走过的路径称为引用链（Reference Chain），当一个对象到 GC Roots 没有任何引用链相连时，则证明此对象是不可用的。
作为GC Roots的对象主要包括下面 4 种：
虚拟机栈（栈帧中的本地变量表） ：各个线程调用方法堆栈中使用到的参数、局部变量、临时变量等 方法区中类静态变量 ：Java 类的引用类型静态变量 方法区中常量 ：比如字符串常量池里的引用 本地方法栈中 JNI 指针 ：（即一般说的 Native 方法）
7.3 初始标记和并发标记
初始标记 ：从根集合（GC Roots）出发，找出根集合直接引用的活跃对象（根对象） 并发标记 ：根据初始标记找到的根对象，使用深度优先遍历对象的成员变量进行标记
7.4 并发标记算法
区分相邻两次GC中的标记：M0(mark-0)、M1(mark-1)。
（1）初始阶段
在 ZGC 初始化之后，此时地址视图为 Remapped，程序正常运行，在内存中分配对象，满足一定条件后垃圾回收启动。如下图所示：
（2）初始标记
这个阶段需要暂停（STW），初始标记只需要扫描所有 GC Roots，其处理时间和 GC Roots 的数量成正比，停顿时间不会随着堆的大小或者活跃对象的大小而增加。经过初始标记之后，直接引用 A 的指针变成了绿色。
（3）并发标记
这个阶段不需要暂停（没有 STW），扫描剩余的所有对象，这个处理时间比较长，所以走并发，业务线程与 GC 线程同时运行。但是这个阶段会产生漏标问题。经过并发标记之后，B 和 C 的指针都变成了绿色。
（4）再标记
这个阶段需要暂停（没有 STW），主要处理漏标对象，通过 SATB（原始快照）算法解决（G1 中的解决漏标的方案）。最后蓝色指针指向的对象就是垃圾。
7.5 并发转移算法
转移就是将标记之后的存活对象使用复制算法转移到另外一个页面。
（1）并发转移准备
分析最有价值 GC 分页<无 STW> 。
（2）初始转移
转移初始标记的存活对象同时做对象重定位<有 STW>。
对应的初始标记，只转移对象 A。并且指针颜色发生了变化，完成了重定位，变成蓝色指针 remapped。初始转移指针直接就修改了，而且初始转移是 STW 的，因此不存在新旧地址的说法。
（3）并发转移
对转移并发标记的存活对象做转移<无STW>，由于该阶段业务线程是运行的，因此需要通过转发表来记录新旧地址的映射。转移对象和转发表记录的插入是需要做原子操作的。
（4）复制完之后，清除小页面A
（5）进入下一次垃圾回收周期
假设在两次 GC 中间创建了一个对象 E。新创建的对象的指针是蓝色的。
（6）第二次初始标记，使用M1（ 红色 ）
（7）第二次并发标记，上一次并发转移的对象需要做重定位
也就是对象转移和删除转发表记录做原子操作。A 指向 B 的指针做修正，同时 A 指向E的指针也要变成 M1 红色。
八、ZGC的触发机制
（1）预热规则
JVM 启动预热，如果从来没有发生过 GC，则在堆内存使用超过 10%、20%、30% 时，分别触发一次 GC，以收集 GC 数据。
（2）基于分配速率的自适应算法
最主要的 GC 触发方式（默认方式），其算法原理可简单描述为”ZGC 根据近期的对象分配速率以及 GC 时间，计算出当内存占用达到什么阈值时触发下一次 GC”。通过 ZAllocationSpikeTolerance 参数控制阈值大小，该参数默认 2，数值越大，越早触发 GC。日志中关键字是“Allocation Rate”。
（3）基于固定时间间隔
通过 ZCollectionInterval 控制，适合应对突增流量场景。流量平稳变化时，自适应算法可能在堆使用率达到 95% 以上才触发 GC。流量突增时，自适应算法触发的时机可能会过晚，导致部分线程阻塞。我们通过调整此参数解决流量突增场景的问题，比如定时活动、秒杀等场景。
（4）主动触发规则
类似于固定间隔规则，但时间间隔不固定，是 ZGC 自行算出来的时机，我们的服务因为已经加了基于固定时间间隔的触发机制，所以通过 -ZProactive 参数将该功能关闭，以免 GC 频繁，影响服务可用性。
（5）阻塞内存分配请求触发
当垃圾来不及回收，垃圾将堆占满时，会导致部分线程阻塞。我们应当避免出现这种触发方式。日志中关键字是“Allocation Stall”。
（6）外部触发
代码中显式调用 System.gc() 触发。日志中关键字是“System.gc()”。
（7）元数据分配触发
元数据区不足时导致，一般不需要关注。日志中关键字是“Metadata GC Threshold”。
九、ZGC 参数设置
堆大小 ：Xmx。当分配速率过高，超过回收速率，造成堆内存不够时，会触发 Allocation Stall，这类 Stall 会减缓当前的用户线程。因此，当我们在 GC 日志中看到 Allocation Stall，通常可以认为堆空间偏小或者 concurrent gc threads 数偏小。 GC 触发时机 ：ZAllocationSpikeTolerance, ZCollectionInterval。ZAllocationSpikeTolerance 用来估算当前的堆内存分配速率，在当前剩余的堆内存下，ZAllocationSpikeTolerance 越大，估算的达到 OOM 的时间越快，ZGC 就会更早地进行触发 GC。ZCollectionInterval 用来指定 GC 发生的间隔，以秒为单位触发 GC。 GC 线程 ：ParallelGCThreads， ConcGCThreads。ParallelGCThreads 是设置 STW 任务的 GC 线程数目，默认为 CPU 个数的 60%；ConcGCThreads 是并发阶段 GC 线程的数目，默认为 CPU 个数的 12.5%。增加 GC 线程数目，可以加快 GC 完成任务，减少各个阶段的时间，但也会增加 CPU 的抢占开销，可根据生产情况调整。
欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：
已在知识星球更新源码解析如下：
最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。
提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。
获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。
文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
微信扫码关注该文公众号作者