JDK 11发布的日子临近了，最近一个让人欣喜的消息就是，JDK 11中将会加入实验性质的ZGC，相关JEP见：JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental
我们知道，ZGC项目需要完成的目标是：控制Java的垃圾回收时长在10ms以内，绝对不超过10ms，并且使用了该垃圾回收策略之后，吞吐对比当前Java缺省的垃圾回收策略G1，下降不超过15%
所谓实验性质是指该策略在JDK 11中只会支持Linux，其他平台暂不支持，还有Graal等也需要等后续版本才会支持
首先我们来了解一下G1，G1是新一代Java的垃圾回收策略，据快手大佬说，自从用了G1，他们的JVM就不再tune了，从一个侧面说明了G1垃圾回收策略的能耐，但是对于一些延迟敏感的场景，G1还是有些不太能满足需求，比如常见的游戏，尤其是实时类的网游
那ZGC出现后就针对该问题予以优化，那优化到什么程度呢？JEP 333的wiki上给出了第一份benchmark，不得不说，这一份benchmark的表现让人惊叹，牛逼得不要不要的，牛逼到什么程度呢？来看数据：
128G内存
ZGC
avg: 1.091ms (+/-0.215ms)
95th percentile: 1.380ms
99th percentile: 1.512ms
99.9th percentile: 1.663ms
99.99th percentile: 1.681ms
max: 1.681ms
G1
avg: 156.806ms (+/-71.126ms)
95th percentile: 316.672ms
99th percentile: 428.095ms
99.9th percentile: 543.846ms
99.99th percentile: 543.846ms
max: 543.846ms
平均gc时长在1.091毫秒，方差为0.215毫秒，最长gc时长是1.681毫秒，不到2毫秒，就算是2毫秒吧，这意味着什么呢？
意味着，几乎所有的民用场合，都可以用java来写了，而且随心所欲滴造对象，想弄多少个就弄多少个，老一点的Java用户都知道，早期的Java代码书写的时候，会建议用户用什么StringBuffer而不是用+来连接String，因为String是immutable的，所以用+的话，会有大量临时的String对象出现，导致string pool暴涨，增加gc的压力
但是如果一个full gc，才不到2毫秒的话，你就是拼命造对象，又怎么样呢？一个人要穷到什么程度的人，才会去在意这区区2毫秒的暂停呢？这就犹如2018年了，还在跟深圳路边的小摊小贩讨价还价2分钱一样，毫无意义，更不要说Java的编译的时候，会自动将一些常见的+优化成StringBuffer
解决了这个问题之后，这也为下一步fp编程应用打开了大门，我们都知道，fp语言特别喜欢用immutable，以前immutable用多了，性能就下来了，这也是为什么lisp早期无法跟c竞争的原因，性能上达不到，但是如果是2ms的gc停顿的话，那性能上的差异就非常小了，几乎可以忽略不计，那lisp等fp语言在算法表达上的优势就会体现出来，所以ZGC对于fp语言生态来说，意义也十分重大，fp大规模应用的基础已经初具雏形了
当然要想利用上JVM，我们还需要一个能够连接起不同语言和JVM的一个利器，那这个就是Graalvm，也就是Openjdk的一个插件，有了Graal之后，就能够将Lisp，Haskell等fp语言运行在JVM上，并且可以通过aot，jlink等技术，将其打包成size很小的可执行文件，并发布出去，但是目前Graal还处于研发阶段，还没正式release，虽然也快了，但是第一版重点是支持JS/Node，Ruby，Python(scipy)和R这几个语言；学术气息比较重的Lisp还有Haskell的支持还需要等社区贡献或者后续开发
一些参考：
JEP 333: ZGC: A Scalable Low-Latency Garbage Collector (Experimental)
OpenJDK Wiki(zgc)
ZGC
GraalVM
bye
