导读：AJDK11(阿里内部基于openJDK11的定制版本)在19年3月左右发布，到现在也快1年了，不过目前整体使用的面还是比较窄，特性被了解的也不是很多，Java11作为OpenJDK发布的LTS版本，对我们来说，还是需要去拥抱和熟悉的，所以从目前的Java8升级到Java11，是一件不紧急但是重要的事情。

作者 | 江丹阳(Mario)

责编 | 屠敏

头图 | CSDN 下载自视觉中国

来源 | 淘系技术(ID：AlibabaMTT)

一说升级

运行环境升级

环境升级，主要是alios7(内部Linux 7u2的定制版) + ajdk11(当前比较稳定的版本是ajdk-11_0_4_5-b71)，这个升级通过修改应用APP-META目录中的dockerfile可以完成；

构建插件升级

构建插件的升级主要是maven compile插件的升级，需要升级到3.8.0版本，pandora-boot的maven插件升级到2.1.11.9，依赖如下：

同时将编译的目标文件和源文件的编译版本指定下：

框架升级

主要是springboot和pandoraboot的升级，同时还有pandora sar包的升级：

依赖升级

在Java11中移除了一些模块，所以在做升级的时候，需要看需求手动进行依赖，主要有如下几个：

运行脚本升级

这里的脚本升级主要是一些jvm的启动参数兼容问题，比如debug option，还有gc日志打印相关的option，主要修改appctl.sh和setenv.sh两个脚本。

比如java9以前的GC日志打印是：

-Xloggc:${MIDDLEWARE_LOGS}/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps"

Java9以后就是：

-Xlog:gc*:${MIDDLEWARE_LOGS}/gc.log:time"

release文件更新：

主要是指定新的ajdk的版本，以及maven的版本(3.5.0及以上)。

二诉“债务”

之前有和一些升级过的同学沟通过，这个Java11的升级还是比较平滑、顺利，没有太多成本，但是这次走起来其实还是克服了不少困难，不是本身Java11升级的问题，而是历史的债务在Java11升级的过程中都暴露了出来。

Linux版本

Linux 版本 7u2 出来已经5年多了，目前集团所有的线上和线下的宿主机的系统都是alios7，所以很难想象现有的系统在docker里面依赖的是5u7的linux基础镜像，这里面会有一个比较严重的性能问题：

因为7u2的glibc去掉了vsyscall改成vdso，5u7的glibc还是保留vsyscall，就需要有一个内核接口来模拟，这个模拟是有严重性能问题的，sys%会非常高。

所以没有升级的赶紧升级下吧，使用裁剪版本(alios7u2-min)，体积可以从原来的5u7 2G多到500M多，这个大小的优化能提升的东西不做赘述。

本地启动

本地启动，好多开发同学可能都没有用过，所以起不来也不是一件很难想象的事情，那问一个问题：为什么做pandoraboot升级？为什么做boot化？boot化带来了哪些价值？给我们带来了哪些改变？我觉得这些问题在最开始推微服务的时候，大家都是很关注的，但是当后面微服务成为趋势，pandoraboot或springboot成为微服务框架之后，之前的问题就没人关注了。

应用owner还是看看自己的boot化应用是否能启动吧，本地启动、本地调试可以节省的开发调试时间谁用谁知道吧。

autoconfig

老生常谈的问题，这个属于时代产物了，在架构演进过程中一直被容忍，一直被小心呵护兼容，因为动之成本有点高，协同比较大，说白了就是很难~~~

有理想追求的程序员大家可以聚一起看看怎么落地~~

三叙“危机”

“危”

面试的标准个人看来是越来越高，但是里面的人做事的标准是越来越低，“调包侠”、“拿来主义”、“翻译器”、“施工队”现象也是越来越常见，我只想说，我们是程序员，借用之前比较孤傲的定位，我们是“艺术家”，那什么时候落魄成了我们当初斥责的模样；从现在起，建立危机意识吧。

“机”

事情是升级Java11，获益是Java9到java11的所有的增强和新特性，下面是个人看到的一些利益点，欢迎大家补充。

内存优化

Java9中增强了string的底层存储，LATIN1编码的字符串底层存储从原来的char数组变成了byte数据，对于这样指定的字符串的内存使用节省一半，整体内存的节省大概10%(不同应用可能差别比较大)。

HotSpot增强

Java9中引入了HotSpotIntrinsicCandidate这个注释，主要是在使用CPU及OS层面的native方法替换java function，达到性能提升，效果会因为平台和硬件不同有差异，目前主要是在一些基础类的一些高频方法中出现该注解。

GC提升

我们目前使用的是CMS垃圾回收器，相当好，我们也用了很长一段时间了，不过CMS随着发展，也暴露出两个问题，一个是面向大内存的回收效率会下降比较明显，同时回收的时长不可控；在后续的Java9中的G1和Java11中ZGC相继出现，就是针对上述两个方向进行的优化。

升级了Java11，其实不一定要用ZGC，因为目前我们大部分应用的配置是4c8g，有人做过性能测试，在8G以下，CMS的回收性能会比ZGC还好一点，8G的情况下差不多，那么8G以上，ZGC会的性能会比较好，同时他的回收效率受内存大小的持续上升影响较小；目前我们有些核心应用的配置是8c16G的，所以这块GC的增强还是有收益的。

FaaS化

FaaS最近一段时间都是一个蛮热的话题，不过距离整体在现有业务场景中广泛应用，还有一段时间；那升级Java11和FaaS化有什么关联呢？

个人感觉是两个方面：

模块化；graalVM。FaaS要支持在线业务的核心关键在于Function的快速分发、运行环境快速拉起来达到低延迟反馈，所以模块化可以让应用足够小，graalVM可以提前将非动态Java代码编译成native image，提升启动速度同时减少整体App的大小；

趋势

从Java 11开始，OpenJDK major version的发布间隔差不多是半年，不用全部都要去关注，都是追赶，但是LTS版本，需要去追赶，去升级，Java11就是最新的LTS版本，下一个或者再一下major version，很可能又是一个LTS版本；虽然目前使用Java 8都挺好的，现实是Java 8的一些特性会被往后移植，但是后续版本的特性和优化不会再被集成到Java 8中了，势不可逆，跟不上就快要被淘汰了。

结语

Java 11的升级带来的收益还是可圈可点的，整体过程也还顺滑，没有兼容性问题，感兴趣的同学可以尝试升级，并且关注一些指标变化。