说不定它更好用！新一代垃圾回收器ZGC，带你探索并实践下( 六 ) 很多低延迟高可用Java服务的系

以本文开头提到的案例为例，假设GC次数不变（10次/分钟) ，且单次GC时间从40ms降低10ms 。通过计算，一分钟内有100/60000 = 0.17%的时间在进行GC ，且期间所有请求仅停顿10ms ， GC期间影响的请求数和因GC增加的延迟都有所减少。
评估成本
这里主要指升级所需要的人力成本。此项相对比较成熟，根据新技术的使用手册判断改动点。跟做其他项目区别不大，不再具体细说。
在我们的实践中，两周时间完成线上部署，达到安全稳定运行的状态。后续持续迭代3个月，根据业务场景对ZGC进行了更契合的优化适配。
评估风险
升级JDK的风险可以分为三类：

兼容性风险：Java程序JAR包依赖很多，升级JDK版本后程序是否能运行起来。例如我们的服务是从JDK 7升级到JDK 11 ，需要解决较多JAR包不兼容的问题。
功能风险：运行起来后，是否会有一些组件逻辑变更，影响现有功能的逻辑。
性能风险：功能如果没有问题，性能是否稳定，能稳定的在线上运行。

经过分类后，每类风险的应对转化成了常见的测试问题，不再属于未知风险。风险是指不确定的事情，如果不确定的事情都能转化成可确定的事情，意味着风险已消除。
升级JDK 11选择JDK 11 ，是因为在JDK 11中首次支持ZGC ，而且JDK 11属于长期支持（Long Term Support ， LTS）版本，至少会被维护三年，普通版本（如JDK 12、JDK 13和JDK 14）只有6个月的维护周期，不建议使用。
本地测试环境安装
从两个源OpenJDK和OracleJDK 下载JDK 11 ，二个版本的JDK主要区别是长时期的免费和付费，短期内都免费。注意JDK 11版本中的ZGC不支持Mac OS系统，在Mac OS系统上使用JDK 11只能用其他垃圾回收器，如G1 。
生产环境安装
升级JDK 11不仅仅是升级自己项目的JDK版本，还需要编译、发布部署、运行、监控、性能内存分析工具等项目支持。美团内部的实践：
编译打包：美团发布系统支持选择JDK 11进行编译打包。线上运行 & 全量部署：要求线上机器已安装JDK11 ，有3种方式：
1.新申请默认安装JDK 11的虚拟机：试用JDK 11时可用这种方式；全量部署时，如果新申请机器数量过多，可能没有足够机器资源。2.通过手写脚本给存量虚拟机安装JDK 11：不推荐，业务同学过多参与到运维当中。3.使用容器提供的镜像部署功能，在打包镜像时安装JDK 11：推荐方式，不需要新申请资源。
监控指标：主要是GC的时间和频率，我们通过美团的CAT监控系统支持ZGC数据的收集（CAT已开源）。性能内存分析：线上遇到性能问题时，还需要借助Profiling工具，美团的性能诊断优化平台Scalpel已支持JDK 11的性能内存分析。如果你的公司没有相关工具，推荐使用JProfier 。
解决组件兼容性
我们的项目包含二十多万行代码，需要从JDK 7升级到JDK 11 ，依赖组件众多。虽然看起来升级会比较复杂，但实际只花了两天时间即解决了兼容性问题。具体过程如下：
1.编译，需要修改pom文件中的build配置，根据报错作修改，主要有两类：
a.一些类被删除：比如“sun.misc.BASE64Encoder” ，找到替换类java.util.Base64即可。
b.组件依赖版本不兼容JDK 11问题：找到对应依赖组件，搜索最新版本，一般都支持JDK 11 。
2.编译成功后，启动运行，此时仍有可能组件依赖版本问题，按照编译时的方式处理即可。
升级所修改的依赖：

javax.annotationjavax.annotation-api1.3.2javax.validationvalidation-api2.0.1.Finalorg.projectlomboklombok1.18.4org.hibernate.validatorhibernate-validator-parent6.0.16.Finalcom.sankuai.infpatriot-sdk1.2.1org.apache.commonscommons-lang33.9commons-langcommons-lang2.6io.nettynetty-all4.1.39.Finaljunitjunit4.12

JDK 11已经出来两年，常见的依赖组件都有兼容性版本。但是，如果是公司内部提供的公司级组件，可能会不兼容JDK 11 ，需要推动相关组件进行升级。如果对方升级较为困难，可以考虑拆分功能，将依赖这些组件的功能单独部署，继续使用低版本JDK 。随着JDK11的卓越性能被大家悉知，相信会有更多团队会用JDK 11解决GC问题，使用者越多，各个组件升级的动力也会越大。