ZGC初体验——新一代低延迟收集器

可能有人不知道ZGC是什么，他是新一代实验性质的垃圾收集器，我们知道GC的评价标准有三个：内存占用、吞吐量、延迟，没有哪个收集器能三者兼备，只能根据场景选择合适的收集器，而ZGC最大的特点就是超低的延迟，引用官方的说法，无论你的堆有多大，几百G还是几个T，都能在10ms以内完成垃圾回收，远远超越了G1、cms（延迟方面），代价是吞吐量的下降（约10%）和额外的内存占用。

开启

zgc目前最低支持的jdk版本为11，无法在8上使用。我们安装好openjdk11，使用jinfo pid来查看当前jvm的信息：

此处默认使用的是 SerialGC ，这个回收器是最历史悠久的回收器了，单线程工作，gc时会挂起用户线程，但也不是没优点，那就是“简单而高效”，内存消耗小，在单核、少核的情景下性能也很好（无上下文切换开销），这也提示我们没有万能的收集器，只有最合适的搭配。
我们重新启动jvm，这次带上参数：-XX:+UnlockExperimentalVMOptions -XX:+UseZGC

nohup java -XX:+UnlockExperimentalVMOptions -XX:+UseZGC -jar halo-1.4.13.jar &

前者表示开启实验配置，后者表示开启ZGC。ZGC目前还不成熟，所以是实验性质。这里的halo是一个java的开源博客系统。
开启后再通过jinfo查看配置信息：

看到ZGC已经开启了。

对比

服务器1核2g，cpu20%基线阿里云。

serialGc：内存占用16%

使用jmeter压测文章页面（模拟20s内共20个用户，每个用户请求10次）：

看看压测前后gc信息：

因为内存很小，这次压测直接触发了2次YGC，耗时78ms

换上ZGC后：
内存占用直接到了71%（可能是我的2g内存太小了）

同样的配置压测：

基本没区别
看看gc情况：

zgc目前是没有分代概念的，也没有ygc、fullgc。

总结

其实这次测试算是失败了，原因还是出在服务器上，单核体现不出zgc并行收集的优势，反而有利于serial这样的单线程收集器，内存也比较紧缺，没办法，没钱用配置好的服务器测试……
zgc的初次体验就这样了，以后有机会追更哈~

80%的人都看过的文章

• Java内存回收机制（状态、引用、GC）
• 深入浅出JVM&GC问题排查