ZGC(Z Garbage Collector)彻底指南

ZGC是从JDK11中引入的一种新的支持弹性伸缩和低延迟垃圾收集器，ZGC能够工做在KB~TB的内存之下，做为一种并发的垃圾收集器，ZGC保证应用延迟不会超过10毫秒(即使在堆内存很大的状况下)，在JDK11中是以实验阶段的特性被发布出来的，到JDK13时，ZGC能够支持到16TB的堆内存，而且能够将未提交的内存归还给操做系统。

为何引入ZGC

JVM的自动垃圾收集虽然减小了开发人员的工做，在必定程度上减小了内存泄漏的风险，可是因为GC是自动进行的，一些没法预知的事情有时候可能产生对应用有害的影响。

• 延迟增长致使应用的吞吐量和性能

随着时代发展，硬件会逐渐便宜，应用使用的内存将会愈来愈大，可是又不能增长延迟，下降吞吐量

ZGC保证，无论在什么状况下，延迟不会超过10毫秒。

The Z Garbage Collector, also known as ZGC, is a scalable low latency garbage collector designed to meet the following goals:

• Pause times do not exceed 10ms
• Pause times do not increase with the heap or live-set size
• Handle heaps ranging from a few hundred megabytes to multi terabytes in size

ZGC特性

ZGC最典型的特性是它是一款并发(concurrent)的GC，其它的特性以下：

• 它能够标记内存，复制和迁移(relocate)内存，全部的操做都是并发的，同时它有一个并发的引用处理器
• 其它的垃圾收集器都是使用store barriers，ZGC使用load barriers，用于跟踪内存
  • lock->unlock->read->load 读内存
  • use->assign->store->write 写内存
• ZGC能够更加灵活的配置大小和策略，相比于G1，它能够更好的处理很是大(very large)对象的释放
• ZGC只有一代，没有新生代，老年代什么的，可是ZGC能够支持局部压缩，在内存恢复和迁移(reclaim and relocate)时，ZGC仍然有很高的性能
• ZGC依赖NUMA-aware(非均衡存储器访问)，须要咱们的内存支持这种特色

特性进度表

• JDK11，2018年 9月
  • ZGC发布
  • 不支持类的卸载。-XX:+ClassUnloading 不生效
• JDK12 2019年 3月
  • 支持并发的类卸载
  • 暂停时间进一步缩短
• JDK13 2019年 9月
  • 最大堆内存从4TB -> 16TB
  • 支持归还未使用的内存 uncommitting unused memory
  • 支持Linux与/AArch64平台
  • 减小时间到一个固定的时间点之下 (Reduced Time-To-Safepoint)
  • 支持 -XX:SoftMaxHeapSize ，当设置这个参数的时候，ZGC会尽可能在指定的内存大小之下，除非为了不内存溢出：参考：bugs.openjdk.java.net/browse/JDK-…
• JDK 14 计划在2020年3月
  • 增长稳定性
  • 支持不连续的地址空间
  • ...

ZGC支持的平台：

平台	是否支持	当前进度
Linux/x64	Y	Since JDK 11
Linux/AArch64	Y	Since JDK 13
macOS		In Progress
Windows		In Progress

垃圾收集原理

几个术语：

• parallel 多个垃圾收集线程在一块儿工做，应用可能会中止
• serial 垃圾收集器只有一个线程在工做
• stop the world 应用程序中止
• concurrent 垃圾收集器在后台运行，应用程序同时也在运行
• incremental 在垃圾收集工做结束以前，先中止垃圾收集，等一会再过来完成剩下的工做

ZGC引入了两个新的概念，pointer coloring和load barriers.

Point Coloring

这个特性让ZGC可以发现，标记，定位和从新映射对象，它只能工做在64位的操做系统上，实现colored pointer须要虚拟地址(virtual address masking)。

• finalizable 对象能够被finalizer到达
• marked0 和marked1 标记可达的对象
• remap 引用指针到当前对象的地址，对象可能会被relocate，这个地址表示对象被relocate

Load Barrier

load barrier是一段代码，当线程从堆中加载引用的时候被运行。例如，当咱们访问对象的一个非主要类型的属性。

在ZGC中，load barrier检查引用的元数据位，根据元数据位对引用的对象作一些处理，所以可能在咱们获取对象的时候对象的引用会被修改掉，可是不影响咱们的使用。

实战

能够从jdk官网下载最新版本的JDK，下载地址：

www.oracle.com/technetwork…

快速开始

GC日志标记格式以下：

-Xlog:<tag set>,[<tag set>, ...]:<log file>
复制代码

只是想要查看ZGC是否生效：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc
复制代码

想要查看更加详细的ZGC日志信息：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc*
复制代码

将更详细的日志信息记录在文件中：

-XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xmx<size> -Xlog:gc*:gc.log
复制代码

GC调参

通用GC选项	ZGC选项	ZGC 诊断选项-XX:+UnlockDiagnosticVMOptions
-XX:MinHeapSize, -Xms -XX:InitialHeapSize, -Xms -XX:MaxHeapSize, -Xmx -XX:SoftMaxHeapSize -XX:SoftRefLRUPolicyMSPerMB	-XX:ZAllocationSpikeTolerance -XX:ZCollectionInterval -XX:ZFragmentationLimit -XX:ZMarkStackSpaceLimit -XX:ZPath -XX:ZUncommit -XX:ZUncommitDelay	-XX:ZProactive -XX:ZStatisticsInterval -XX:ZVerifyForwarding -XX:ZVerifyMarking -XX:ZVerifyObjects -XX:ZVerifyRoots -XX:ZVerifyViews

是否启用NUMA支持：

# 启用NUMA
-XX:+UseNUMA 

# 停用NUMA
-XX:-UseNUMA 
复制代码

调整并发的线程数：

-XX:ConcGCThreads=
复制代码

返回未提交的内存到操做系统，堆内存不会地址设置的最小堆内存-Xms

# 多久未提交的内存会返回给系统
-XX:+ZUncommit  -XX:ZUncommitDelay=<seconds>
复制代码

开启大分页，通常会带来更好的性能提高，吞吐量，延迟和启动时间都有所改善。并无看到明显的缺点

• 大分页在Linux系统中通常为2MB的大小，若是有16G的堆内存，那么意味着须要16GB/2MB = 8192个大分页，如下命令须要 Linux kernel >= 4.14

# 配置操做系统中的分页池数量
echo 9216 > /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages

# 查看系统中如今的分页数量
cat /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages


-XX:+UseLargePages
复制代码

• 若是Linux kernel < 4.14，那么以下方式

mkdir /hugepages
mount -t hugetlbfs -o uid=123 nodev /hugepages 
java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -Xms16G -Xmx16G -XX:+UseLargePages
复制代码

开启透明分页，透明分页可能致使延迟上的一些问题，有时候不推荐使用，开启透明分页须要Linux kernel < 4.7

# 开启透明分页
echo madvise > /sys/kernel/mm/transparent_hugepage/enabled
echo advise > /sys/kernel/mm/transparent_hugepage/shmem_enabled


-XX:+UseTransparentHugePage
复制代码

最后

ZGC仍然是处于试验特性阶段，但其保证延迟时间不低于10ms的特性，以及当前对堆内存大小的支持力度，仍是值得一试，让咱们期待ZGC成为一款更加优越的垃圾收集器吧。

参考

• OpenJDK Wiki
• ZGC 介绍
• JDK11 之ZGC