JDK11 升级 JDK17 最全实践干货来了( 四 ) _JDK

【JDK11 升级 JDK17 最全实践干货来了】移除 - XX:ConcGCThreads，行云部署下 JVM 参数配置需要清除

文章插图
6.5.2、不同中间件所需启动参数
升级 JDK17 后，项目启动时可能会遇到如下两种类型的异常：
1、cannot access class sun.util.calendar.ZoneInfo (in module java.base) because module java.base does not export sun.util.calendar to unnamed module @0x2611f533
2、Unable to make field final int java.math.BigInteger.signum accessible: module java.base does not "opens java.math" to unnamed module @525f1e4e
异常原因：
自从 JDK9 中引入了模块化功能后，再到 JDK17 ，对于包扫描和反射的权限控制更加的严格。常见的库比如（Spring）大量用到包扫描和反射，所以常出现此错误。
解决方案：
一个粗暴的解决办法是将没开放的 module 强制对外开放，即保持和 Java9 之前的版本一致。

--add-exports 导出包，意味着其中的所有公共类型和成员都可以在编译和运行时访问。
--add-opens 打开包，意味着其中的所有类型和成员（不仅是公共类型）都可以在运行时访问。

主要区别在于 --add-opens 允许 “深度反射”，即非公共成员的访问，才可以调用 setAccessible(true)
参考： https://stackoverflow.com/questions/44056405/whats-the-difference-between-add-exports-and-add-opens-in-java-9
SGM 需要加入：
--add-opens java.management/java.lang.management=ALL-UNNAMED
--add-opens jdk.management/com.sun.management.internal=ALL-UNNAMED
--add-opens java.management/sun.management=ALL-UNNAMED
R2M 需要加入：
--add-opens java.base/java.time=ALL-UNNAMED
Ducc 需要加入：
--add-opens java.base/java.util.concurrent=ALL-UNNAMED
--add-opens java.base/java.util.concurrent.locks=ALL-UNNAMED
--add-opens java.base/java.security=ALL-UNNAMED
--add-opens java.base/jdk.internal.loader=ALL-UNNAMED
--add-opens java.management/com.sun.jmx.mbeanserver=ALL-UNNAMED
--add-opens java.base/java.net=ALL-UNNAMED
--add-opens java.base/sun.nio.ch=ALL-UNNAMED
AKS 需要加入：
--add-exports java.base/sun.security.action=ALL-UNNAMED
--add-opens java.base/java.lang=ALL-UNNAMED
--add-opens java.base/java.math=ALL-UNNAMED
--add-opens java.base/java.util=ALL-UNNAMED
--add-opens java.base/sun.util.calendar=ALL-UNNAMED
6.6、启动后的验证
1. 推荐先升级 JDK11 ，再到 JDK17 ，一边升级一边进行验证观察
2. 观察日志是否有异常，特别是上面说到的启动时异常
3. 观察监控类软件，比如 SGM、UMP 等监控是否正常
4. 推荐逐步有序切量，并做好常态化压测，防止影响核心业务
5. 升级完成后，最好能做个全流程的功能测试，防止功能异常
7、总结