一文帮你搞定JDK8升级11_阿里开发者的专栏文章_微信文章

阿里妹导读

本文记录了作者从JDK8升级到11的实践过程和升级后的效果以及JDK11新玩法。

一、背景

为什么要升级JDK11

性能

JDK11的G1的GC性能高很多，对比JDK8无论是性能还是内存占比都有很大的提升，业内各项数据指标也都表明JDK11的G1在应对突发流量的下的效果惊人；

版本兼容

Spring Boot 2.7.x及以后的版本将不再支持Java 8作为最低版本。Spring Boot 2.6.x是最后一个正式支持Java 8的主线版本，一些新的中间件与组件也不再支持JDK8了；

必然趋势

JDK11（LTS）已经成为业界主流，在Java开发社区和工业界中得到了广泛的接受和使用；

二、升级前你要知道的点

JDK11版本改动较大，且不会向下兼容。所以当你的业务代码越复杂，调用的链路越多，升级的难度越大。你会遇到很多兼容性问题，比如二方包不支持新版本JDK；
JDK11移除了部分在Java 8就已经标记为过时的API例如sun.misc.Unsafe的部分方法，所以你的升级可能还涉及到代码的改动；
验证是个漫长而又耗时的过程，很多问题可能在运行时阶段才会暴露，你需要验证系统整体功能来保证系统稳定；

三、升级过程

本地升级，让你的JDK11跑起来

本地JDK11下载

这里不过多阐述，需要注意区分JDK的arm版本与x64版本。

IDEA选择JDK11启动

框架升级

修改pom文件

<maven.compiler.target>11maven.compiler.target><maven.compiler.source>11maven.compiler.source><java.version>11java.version><spring-boot.version>2.1.6.RELEASEspring-boot.version><lombok.version>1.18.12lombok.version>

软件	最低版本
spring-boot	2.1.x 开始支持jdk11
spring	5.1.x
idea	2018.2
maven	3.5.0
lombok	1.18.x
netty	需要升级到 4.1.33.Final 或之后的版本，否则会引起堆外内存增长
apache common lang3	3.12.0

jdk11已移除，需手工依赖二方库

<dependency>    <groupId>javax.xml.soapgroupId>    <artifactId>javax.xml.soap-apiartifactId>    <version>1.4.0version>dependency><dependency>    <groupId>com.sun.xml.wsgroupId>    <artifactId>jaxws-riartifactId>    <version>2.3.3version>    <type>pomtype>dependency><dependency>    <groupId>com.sun.xml.bindgroupId>    <artifactId>jaxb-implartifactId>    <version>2.3.0version>dependency><dependency>    <groupId>javax.xml.bindgroupId>    <artifactId>jaxb-apiartifactId>    <version>2.3.0version>dependency><dependency>    <groupId>javax.annotationgroupId>    <artifactId>javax.annotation-apiartifactId>    <version>1.3.2version>dependency><dependency>    <groupId>com.sun.activationgroupId>    <artifactId>javax.activationartifactId>    <version>1.2.0version>dependency><dependency>    <groupId>com.sun.xml.bindgroupId>    <artifactId>jaxb-coreartifactId>    <version>2.3.0version>dependency><dependency>    <groupId>com.alibaba.jvmgroupId>    <artifactId>java-migration-jdk-patchartifactId>    <version>0.3.1version>    <type>pomtype>dependency><dependency>    <groupId>javax.transactiongroupId>    <artifactId>javax.transaction-apiartifactId>    <version>1.2version>dependency>

遇到的问题

Deprecated: A global security auto-configuration is now provided

在Spring Boot 2.0及以上版本中，这个配置项已经被废弃并移除。如果你要关闭端点的安全性，需要在Spring Security的配置中对Actuator端点进行配置。该配置项是默认开启安全检测。

Dependency 'org.hibernate:hibernate-validator:' not found

需要指定版本号

<dependency>    <groupId>org.hibernategroupId>    <artifactId>hibernate-validatorartifactId>    <version>6.2.4.Finalversion>dependency>

应用不能进行远程调试

原因分析

JDK 8 中 jdwp 默认绑定的 host/ip 是 0.0.0.0，初于安全考虑在 JDK 9 后改成了 localhost（127.0.0.1），导出如果开发者在配置调试选项时只指定端口时，在升级后无法进行远程调试。

解决方案

指定调试选项时设置 host/ip 为 *，如：

agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:8000

或者 0.0.0.0，如：

agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=0.0.0.0:8000

其他问题

1、maven-compiler-plugin：此插件建议直接升级到最新版，同时在父Pom和每个你需要额外确定版本的包（比如说打给别人用的JDK8版本的包）里的Pom，指定版本：

11 11

2、Springboot和Spring版本：Spring从5.1开始支持11，Springboot从2.1.X开始支持11，我们的推荐是支持升级到当前的最新版；

3、Netty因为堆外内存的释放问题，请升级到4.1.33以上的版本；

4、lombok因为会在编译期插入自己的编译逻辑，所以升级到11之后，需要将lombok升级到最新版，（编辑文档时的最新版本是1.18.24）；

5、可能大部分应用都需要进行Spring或者Springboot升级，请务必做好回归；

6、security-spring-boot-starter分为1.x.x和2.x.x版本，对应springboot1和springboot2，请升级到2.x.x版本；

应用部署发布

使用G1垃圾回收器

去除#SERVICE_OPTS="${SERVICE_OPTS} -XX:+UseConcMarkSweepGC -XX:+UseCMSCompactAtFullCollection -XX:CMSMaxAbortablePrecleanTime=5000"#SERVICE_OPTS="${SERVICE_OPTS} -XX:+CMSClassUnloadingEnabled -XX:CMSInitiatingOccupancyFraction=80 -XX:+UseCMSInitiatingOccupancyOnly"#SERVICE_OPTS="${SERVICE_OPTS} -XX:+ExplicitGCInvokesConcurrent -Dsun.rmi.dgc.server.gcInterval=2592000000 -Dsun.rmi.dgc.client.gcInterval=2592000000"#SERVICE_OPTS="${SERVICE_OPTS} -XX:ParallelGCThreads=4"#SERVICE_OPTS="${SERVICE_OPTS} -Xloggc:${MIDDLEWARE_LOGS}/gc.log -XX:+PrintGCDetails -XX:+PrintGCDateStamps"
SERVICE_OPTS="${SERVICE_OPTS} -XX:+UseG1GC -XX:+UseVtableBasedCHA -XX:+UseCompactObjectHeaders"SERVICE_OPTS="${SERVICE_OPTS} -XX:G1HeapRegionSize=8m"SERVICE_OPTS="${SERVICE_OPTS} -XX:+G1BarrierSkipDCQ"SERVICE_OPTS="${SERVICE_OPTS} -Xlog:gc*:/home/admin/logs/gc.log:time"SERVICE_OPTS="${SERVICE_OPTS} -XX:G1HeapWastePercent=2"SERVICE_OPTS="${SERVICE_OPTS} -XX:+ExplicitGCInvokesConcurrent -Dsun.rmi.dgc.server.gcInterval=2592000000 -Dsun.rmi.dgc.client.gcInterval=2592000000"if [ -n "$AJDK_MAX_PROCESSORS_LIMIT" ]; then    SERVICE_OPTS="${SERVICE_OPTS} -XX:ActiveProcessorCount=$AJDK_MAX_PROCESSORS_LIMIT"fi

GC调优的注意事项（数据来源JVM团队）

通常G1 GC是一个免调参的GC，并不需要额外的参数调整。老的一些的八股文Java GC调参经验并不适用。

-Xmn参数一般不需要设置

G1预设了-XX:NewSize和-XX:MaxNewSize的值（不一致），会根据实际运行来计算设置每次GC的young区的size，实现GC暂停的软可控。

-XX:NewRatio同理不需要设置

-XX:SurvivorRatio一般也不设置

通常绝大部分使用者并不清楚这个参数的含义以及对GC带来的影响，G1会自适应处理这个参数相关的GC行为。

升级G1后可能需要关注的参数

-XX:MaxGCPauseMillis=N，G1暂停的目标时间（毫秒）

默认为200，很多用户会刻意设小，通常情况下意义不大。G1实际的GC暂停任务，并不会随着暂停时间缩小而变少，可以设小会导致更频繁的GC影响吞吐。一般不需要设置，如果需要更好的吞吐，通常是设置更大，保持young区不会缩减的太小。也可以咨询JVM答疑专家考虑调整-XX:NewSize和-XX:MaxNewSize，来保持young 区的Size，维持合适的吞吐性能。

-XX:InitiatingHeapOccupancyPercent=N -XX:-G1UseAdaptiveIHOP （电商核心使用）

这两个参数通常同时使用。JDK11引入了G1UseAdaptiveIHOP来提升老区的利用率（大堆，通常大几十G，或者100G以上）。在我们容器规格中等规模的heap（通常5-20g）的size中，有时会出现old gc过于频繁或者young gc过于频繁的现象。因此考虑一个合适的静态IHOP（老区使用占全堆比例触发GC的阈值），会更加合适。

-XX:G1HeapRegionSize，（电商核心通常使用8m-32m）

设置G1 region的大小，应对humongous对象（超过heap region size一半独占一个或多个region）引起的GC异常。Heap region size默认为Heap size/2048，如果默认值过小，humongous对象分配过多，容易引起To-space exhausted的异常暂停时间：

[2024-01-05T14:14:31.817+0800] GC(266) To-space exhausted

-XX:G1HeapWastePercent，(默认5，部分电商核心应用设置为2)

G1在回收老区对象时，可以允许5% heap size的垃圾对象不回收，来减少mixed GC的暂停开销。当Xmx10G时，5%就有500m的空间，对于Java heap是一种浪费，因此可以考虑减少heap空间浪费设置成2。不建议设置成0，可能会极大增加mixed GC的暂停。

-XX:G1MixedGCCountTarget，Mixed GC目标次数，默认为8

实际的Mixed GC次数通常会小于G1MixedGCCountTarget，如果Concurrent mark/mixed gc的周期并不频繁，单次mixed gc的暂停过长，通常可以考虑增大这个参数，例如16，来分散单次mixed GC暂停的工作量，减少暂停时间。

升级G1的常见问题

CMS升级G1后，容器和Java进程内存占用变高

很多应用在升级JDK11，出现容器和Java进程内存整体变高的现象，主要源自Heap的使用率差异。CMS的Old generation为非移动式，由 CMSInitiatingOccupancyFraction 来控制使用比例来触发gc，因此应用启动后短时间内，heap old区使用率不会上升。而G1的heap region是松散管理，整体利用heap，所以显得内存使用率高。本质是一个heap利用率的问题，cms初始留着部分heap不用。这个问题可以通过调低Xmx来解决（部分电商核心使用这个方案）。

GC日志中To-space exhausted引起的异常暂停

绝大部分是由于大对象分配过多，GC日志中频繁出现

Pause Young (Concurrent Start) (G1 Humongous Allocation)

大对象分配过多，会导致堆空间快速被占满，GC是出现To-space exhausted/evacuation failure，需要额外的暂停时间处理，甚至出现更耗时的Full GC全堆整理。

GC过于频繁

相比传统的CMS/Parallel GC，固定的young 区size。G1的young区size是自动调整的，当为了满足暂停要求时，会缩小young区，导致GC频率过高。一般的情况是避免MaxGCPauseMillis设置过小，参考上面参数的介绍。或者增大MaxGCPauseMillis的配置，同时有必要的话咨询答疑专家，调整-XX:NewSize和-XX:MaxNewSize。

Mixed GC暂停过长

G1除了整理清除young区对象的young GC，还有在Concurrent mark之后，包含整理老区对象的mixed gc。因此通常mixed GC会有更长的暂停时间。如果单次mixed GC暂停过长，考虑增大上面介绍的参数G1MixedGCCountTarget，来进一步分散老区对象整理的任务，降低暂停

四、升级效果

日常运行