本文基于两个出发点，描述了业务平台于21年12月启动了对JDK版本升级的适配之路，并回顾了整个升级过程，对升级过程中的问题做了记录。

作者 | 郑波(岱泽)

来源 | 阿里开发者公众号

业务平台升级JDK11，基于两个出发点：一、jdk8于2019年1月停止维护，springboot2.1之后的版本已经兼容JDK11，springboot3.0完全放弃对JDK8的支持，未来属于更高版本的JDK；二、在试点国产化芯片的过程中，由于JDK8对Arm架构的优化不足，导致国产化芯片无法发挥自身的性能优势，为了更好的适配国产化，务必要求对JDK版本进行升级。基于上述两个出发点，业务平台于21年12月启动了对JDK版本升级的适配之路。这里回顾整个升级过程，对升级过程中的问题做一下记录

一、升级版本的选择

当时有两个JDK版本可供选择，JDK11、JDK17，从长远开来，JDK17更代表未来，但由于JDK11 相比JDK17的变化并不大，相比之下从JDK11升级到JDK17的挑战要相对小。由于升级的基本都是电商核心系统，基于风险的控制，从JDK8升级到JDK11，随后再从JDK11升级到JDK17是一个更合理的选择。

二、GC选择及功能适配

业务平台核心系统使用了非常多的定制化功能，比如GCIH、CMS GC、异步日志、Wisp、Jwarmup、UncommonNullCast、多租户，为了减少对业务的影响，同时保障JDK11相比JDK8不会产生性能的退化，相关的特性均需要在JDK11上进行适配。同时为了避免GC算法的调整对业务运维及稳定性的影响，升级初期决定依旧使用CMS GC，仅灰度少量的G1

三、升级JDK11相关组件的升级

在升级JDK11的过程中，业务代码的改造只是其中之一，还涉及到业务依赖的各种组件之间的升级适配，包括Pandora、Tomcat、星环容器、天启、Doom、天擎等测试工具的升级支持

四、灰度及上线流程的选择

业务平台核心应用很多都是伴随taobao业务成长起来的应用，具有历史代码多、依赖组件广的特点，核心系统中存在非常多的二三方包依赖，在升级之初考虑使用JDK提供的兼容性扫描工具进行分析，但在实操过程中，扫描到的不兼容代码过多，但实际上大部分并没有使用到的情况。如果按照扫描出来的结果推动相关二三方包的适配，整个工程量是完全无法评估的，整个升级节奏也无法把控。为了解决该问题，我们决定整体的升级节奏调整并不追求完全的代码兼容。只对实际影响业务运行的代码做兼容处理。因为整体的升级节奏也就变成了如下几步

1. 1) 代码使用JDK8进行编译，但要求代码可以同时在JDK8及JDK11上运行
2. 2) 上线过程中，先将日常及预发环境的版本切换成JDK11和JDK8同时运行，回归测试过程中同时测试JDK11、JDK8版本下的运行情况
3. 3) 线上逐步灰度JDK11运行环境的功能，做好监控及线上排查定位。随着几次大促下来后，逐步将所有的容器切换到JDK11，下线JDK8环境的容器。
4. 4) 利用运行态的JDK11特性，优化系统性能
5. 5) 将编译从JDK8切换到JDK11 ，同时充分JDK11本身的新的特性。
6. 基于上述的升级步骤，对业务代码的升级改造也做了调整，业务在使用过程中，同时安装JDK8和JDK11，业务利用脚本的方式控制线上的JDK11及JDK8的灰度比例。同时经过多轮大促： 38大促灰度10台容器、日常灰度100台、618灰度一个单元、99大促灰度所有机房

if [ -f /home/admin/logs/jdk11.enable ]; then
    export JAVA_HOME=/opt/taobao/install/ajdk11_11.0.14.13/
    export JDK11_ENABLE=true
    echo "enable jdk11 , use new JAVA_HOME : ${JAVA_HOME}"
fi


if [ "$JDK11_ENABLE" == "true" ]; then
    CATALINA_OPTS="${CATALINA_OPTS} -Xlog:gc*:${MIDDLEWARE_LOGS}/gc.log:time"
    CATALINA_OPTS="${CATALINA_OPTS} --add-exports=java.base/jdk.internal.loader=ALL-UNNAMED --add-exports=java.base/jdk.internal.loader=jdk.unsupported --patch-module jdk.unsupported=/home/admin/buy2/bin/java9-migration-helper-0.1.jar"
    CATALINA_OPTS="${CATALINA_OPTS} -Dio.netty.tryReflectionSetAccessible=true --add-opens=java.base/jdk.internal.misc=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED"
    CATALINA_OPTS="${CATALINA_OPTS} --add-exports=java.base/jdk.internal.util.jar=ALL-UNNAMED --add-exports=java.base/jdk.internal.util.jar=jdk.unsupported"
    CATALINA_OPTS="${CATALINA_OPTS} --add-opens=java.base/com.alibaba.wisp.engine=ALL-UNNAMED"
    CATALINA_OPTS="${CATALINA_OPTS} -XX:CompileCommand=stableif,*::*"
    test -z "$JPDA_ADDRESS" && export JPDA_ADDRESS=*:8000
    #gson兼容
    CATALINA_OPTS="${CATALINA_OPTS} -Djava.locale.providers=COMPAT,SPI"
else
    CATALINA_OPTS="${CATALINA_OPTS} -Xloggc:${MIDDLEWARE_LOGS}/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps"
    CATALINA_OPTS="${CATALINA_OPTS} -XX:-UncommonNullCast -XX:CompileCommand=stableif,*::*"
    test -z "$JPDA_ADDRESS" && export JPDA_ADDRESS=8000
fi

五、二三方包适配及改造

JDK11相比JDK8之间的关键的变化

参考：Oracle JDK Migration Guide

● 版本号格式的变化

● 本地化的优先级变化

● module化

● 废弃代码清理

● JDK日志架构变化

由于业务代码中旧的代码量较多，为了减少整个升级的复杂度，整体的升级策略，以兼容旧的代码逻辑为主，尽可能的升级到新的版本中（并不是使用jdk11的最佳实践进行直接升级）。

在实际的适配过程中，发现主要的兼容问题集中在版本号格式的变化带来的不兼容。对于这部分代码逻辑主要要求相关业务进行改进即可，对于一些无法找到维护者的二方包来说，直接通过反编译的方式进行整体改造。

点击查看原文，获取更多福利！

https://developer.aliyun.com/article/1162353?utm_content=g_1000368533

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。