jdk 14 基础架构部的zgc垃圾收集实测

1 https://www.jianshu.com/u/1c4e0c78a1f7  新一代垃圾回收器ZGC设计与实现

2 https://stackoverflow.com/questions/61923094/getting-allocation-stall-when-enabling-zgc

3 江南白衣 https://weibo.com/calvin1978

“基础架构部的zgc垃圾收集实测”，jdk 11开始的zgc有多强，文章说太多了。同事用ES7.7 + jdk 14测试了下实际效果。

结果是，关注和调优的重心，都聚焦在万一垃圾回收的速度跟不上分配的速度，发生的allocation stall停顿上，有点像以前操心cms，full gc的stw。

allocation stall不能说是stop the world，它可能是按region 按线程去停的，实际每条线程停顿的时间不一，有的停几毫秒，有的停几百毫秒。

jmx暴露的监控指标只有zgc count和zgc time，没有allocation stall的，只能自己分析gc log， gceasy.io欢迎你。

好了，铺垫完，zgc从jdk 11到14，废弃了一些参数（所以螃蟹吃太早会有点亏），就剩下几个值得调的：

-XX:ConcGCThreads

与应用一起在跑的垃圾回收线程数，默认是1/8总cpu核数。

但在我们的压测场景24核机器三条线程不够用，会出现application stall，又多翻了一倍变六条后大大改善。

这就是个throughout 换 latency的生意。

-XX:SoftMaxHeapSize

这个jdk13新增参数比较有趣，就是分配内存尽量只到这个阈值，与-Xmx之间的gap作为不得已情况下的缓冲，细节没有了解，但设了的确对allocation stall有效果。

也不用可惜心痛，因为cms gc也设了75%老生代就触发cms gc，同样有25%的浪费

转载请标明链接：https://blog.csdn.net/wabiaozia/article/details/107134004

-XX+AlwaysPreTouch

以前也建议的参数，在jvm启动时就把堆内存啃一遍，把它实际的，连续的分配下来。jdk 13开始会多线程并发的啃，加快了启动速度。

总体参数很少很少了，以后面试官可能会无聊。

zgc还有其他一些有趣的地方，比如numa，大页，向操作系统归还不用的内存，下篇讲。

via：江南白衣 https://weibo.com/calvin1978

 

1. zgc用哪个版本的jdk最好。

坦白说，两个月之后的jdk15才是zgc规划生产可用(JEP 377 production ready)的时候。 而jdk12,13,14上做的大量优化，暂时也没有移植jdk11 lts上，不知日后如何。

zgc的wiki上可以看到包括jdk15在内的change log。O网页链接

2. 花不完的内存可以还给操作系统了。

以前设置-Xms 和-Xmx不一致没有任何意义，因为内存一旦冲上去之就不会再还给操作系统。

但现在不一样了，高于-Xms，低于-Xmx的内存，超过默认300秒不用，就会还给操作系统。配合我们容器做的vpa 内存实时扩容（改cgroup），就可以讲出比较好听的故事。

G1也支持。

3.numa的支持

以前有的应用为了让cpu只访问自己的内存，避免跨cpu访问，需要把自己绑定到某一半的cpu 核上。

java以前号称支持numa，但只有ps gc支持，而cms并不。 现在zgc支持了，jdk 13的g1也支持了。不过zgc号称在jdk15能支持得更好。

G1也支持。

4.巨页的支持

打开linux的巨页，号称有百利无一害，除了多了些配置。我们的压测里，开和不开，QPS总有惊喜，可能达10%。

G1也支持。

5. 64 bit的color point

在cms时代，我们总是小心的把堆内存限制在32g以内，以使用压缩指针。

到了zgc，因为要预留4bit做color point，压缩指针没戏了，无论堆大小全都是64bit了。

好的方面看，终于突破了32g的限制。坏的方面看，压缩指针没了。

除了原理，allocation stall，面试官主要就问问这些了。

Chateau de Gudanes by Sonia Szóstak