JVM中ZG的深度剖析

JVM简介

对于Java 程序员来说，JVM 帮助我们做了很多事情。

JVM是虚拟机，能够识别字节码，就是class文件或者你打包的jar文件，运行在操作系统上。

JVM帮我们实现了跨平台，你只需要编译一次，就可以在不同的操作系统上运行，并且效果是一致的。

在Java中你使用对象，使用内存，不用担心回收，只管new对象就行了，不用管垃圾的回收。

因为Java当中是自动化的垃圾回收机制。JVM有专门的垃圾回收器，把垃圾回收这件事给干了。

ZGC出现背景

        但是对于Java的项目来说，JVM进行垃圾回收会有一个很大的问题，就是STW。

什么是STW，STW的全称是StopTheWorld。

Java项目中，如果JVM要进行垃圾回收，会暂停所有的业务线程，也就是项目中的线程，这样会导致业务系统暂停。

STW带来的问题

手机系统(Android) 显示卡顿

        Google 主导的 Android 系统需要解决的一大问题就是显示卡顿问题，通过对 GC 算法的不断演进，停顿时间控制在几个ms 级别。

        所以这也是Android与苹果IOS系统竞争的一大利器。

证券交易系统实时性要求

        证券交易系统主要就是买入、卖出，现在都是使用系统完成自动下单，如果用Java系统来做，遇到了STW，假如STW的时间是3秒。

        刚收到市场行情是比较低的买入的，但是因为STW卡顿了3秒，3秒后的市场行情可能完全不同。所以如果使用Java来做证券系统，一定是要求STW时间越短越好！

大数据平台(Hadoop集群性能)

        同样，58同城的大数据系统，单集群5000+的Hadoop集群，日万亿级实时数据分发。如果遇到STW也是不行的。

垃圾回收器的发展

        为了满足不同的业务需求，Java 的 GC 算法也在不停迭代，对于特定的应用，选择其最适合的 GC 算法，才能更高效的帮助业务实现其业务目标。对于这些延迟敏感的应用来说，GC 停顿已经成为阻碍 Java 广泛应用的一大顽疾，需要更适合的 GC 算法以满足这些业务的需求。

        近些年来，服务器的性能越来越强劲，各种应用可使用的堆内存也越来越大，常见的堆大小从 10G 到百 G 级别，部分机型甚至可以到达 TB 级别，在这类大堆应用上，传统的 GC，如 CMS、G1 的停顿时间也跟随着堆大小的增长而同步增加，即堆大小指数级增长时，停顿时间也会指数级增长。特别是当触发 Full GC 时，停顿可达分钟级别(百GB级别的堆)。当业务应用需要提供高服务级别协议（Service Level Agreement，SLA），例如 99.99% 的响应时间不能超过 100ms，此时 CMS、G1 等就无法满足业务的需求。

        为满足当前应用对于超低停顿、并应对大堆和超大堆带来的挑战，伴随着 2018 年发布的 JDK 11，A Scalable Low-Latency Garbage Collector - ZGC 应运而生。

ZGC介绍

        ZGC（The Z Garbage Collector）是JDK 11中推出的一款追求极致低延迟的垃圾收集器，它曾经设计目标包括：

• 停顿时间不超过10ms（JDK16已经达到不超过1ms）；
• 停顿时间不会随着堆的大小，或者活跃对象的大小而增加；

• 支持8MB~4TB级别的堆，JDK15后已经可以支持16TB。

这么去想，如果使用ZGC来做Java项目，像对STW敏感的证券系统，游戏的系统都可以去用Java来做（以前都是C或者C++的市场），所以ZGC的出现就是为了抢占其他语言的市场（卷！）。

ZGC中的内存布局

        为了细粒度地控制内存的分配，和G1一样，ZGC将内存划分成小的分区，在ZGC中称为页面（page）。

        ZGC中没有分代的概念（新生代、老年代）

        ZGC支持3种页面，分别为小页面(object<256kb)、中页面(256kb<object<4M)和大页面