背景
同时在 ops-job 上应用积累经验，可在其他项目如 Apollo 、xxljob 上继续落地
ps：本次升级项目原依赖是 JDK17，Spring Boot 2.6.5
关键结果（收益）
升级改动
Maven 依赖调整
调整 Spring Boot 的依赖
<parent>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-parent</artifactId>
<version>3.2.1</version>
<relativePath/> <!-- lookup parent from repository -->
</parent>
调整 Spring Cloud 、JDK 的依赖
<properties>
<java.version>21</java.version>
<spring-cloud.version>2021.0.1</spring-cloud.version>
</properties>
代码兼容性改动
1、包名变动
javax 更名为 jakarta，相关的资源都需要改动。比如：
@PostConstruct 注解包名拜改变路径：javax.annotation.PostConstruct 变到 jakarta.annotation.PostConstruct
2、Spring 的 @Bean 注解只能用于有返回值的方法。
比如下面代码，想在 Bean 初始化生命周期中运行一些逻辑，升级后就不支持了。被 @Bean 注解的方法需要有返回值了
@Bean
public void initSenTry() {
String dsn = xx
Sentry.init(options -> {
options.setDsn(dsn);
options.setEnvironment(env);
});
SentryAppender sentryAppender = new SentryAppender();
sentryAppender.setContext(ctx);
ThresholdFilter filter = new ThresholdFilter();
filter.setLevel(Level.ERROR.levelStr);
filter.start();
sentryAppender.addFilter(filter);
sentryAppender.start();
ctx.addTurboFilter(new TurboFilter() {
@Override
public FilterReply decide(Marker marker, ch.qos.logback.classic.Logger logger, Level level, String format, Object[] params, Throwable t) {
logger.addAppender(sentryAppender);
return FilterReply.NEUTRAL;
}
});
}
3、Spring 日志系统变化
slf4j 的 StaticLoggerBinder 类没有了，想要获取 LoggerContext 对象实现日志级别的动态调整，需要使用
LoggerFactory.getILoggerFactory 取而代之。比如：
private final LoggerContext ctx = (LoggerContext) LoggerFactory.getILoggerFactory();
4、Apollo 功能受限
Apollo 配置中心的 @ApolloConfig 注解失效了（内部配置加载逻辑是正常的，不影响应用启动）。比如：
@ApolloConfig
private Config config;
原因是：![]()
Spring Boot 3 milestone 5 EnableAutoConfiguration spring.factories · Issue #32566 · spring-projects/spring-boot
从 Spring Boot 3 M5 开始，来自 spring.factories 文件的“org.springframework.boot.autoconfigure.EnableAutoConfiguration”自动配置注册不再起作用
基于此，预计有很多 start 都会受到影响，比如 mybatis-plus 、xxl-job
在类路径下创建META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，把 Apollo 的自动加载类放进去，如：
com.ctrip.framework.apollo.spring.boot.ApolloAutoConfiguration com.taptap.xxl.job.spring.XxlJobAutoConfiguration
其他有影响的框架，都可以复制下自动加载类，放到这个文件里
可以尝试用最新版本，看官方是否解决了 Spring Boot3.x 的兼容性问题。
1、apollo-client : 升级到 2.1.0(![]()
apollo-client support spring boot 3.0 by nobodyiam · Pull Request #4 · apolloconfig/apollo-java )
2、xxl-job-spring-boot-starter : 更新到 2.3.2-183
问题记录
1、日志框架冲突
服务启动，会输出如下的日志
Standard Commons Logging discovery in action with spring-jcl: please remove commons-logging.jar from classpath in order to avoid potential conflicts
这个是 Spring Boot 的依赖冲突检查输出的，在 Maven 里排除 commons-logging.jar 就好了，如：
<dependency>
<groupId>ru.yandex.clickhouse</groupId>
<artifactId>clickhouse-jdbc</artifactId>
<version>0.3.2</version>
<exclusions>
<exclusion>
<artifactId>commons-logging</artifactId>
<groupId>commons-logging</groupId>
</exclusion>
</exclusions>
</dependency>
2、Server VM warning
当加载 agent 时，会出现如下的警告日志。
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
[otel.javaagent 2024-01-23 17:38:45:581 +0800] [main] INFO io.opentelemetry.javaagent.tooling.VersionLogger - opentelemetry-javaagent - version: 1.12.1
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
OpenJDK 64-Bit Server VM warning: Sharing is only supported for boot loader classes because bootstrap classpath has been appended
可通过 JVM 参数 -Xshare:off 关闭 CDS 相关的逻辑
大功告成
如果一切顺利，启动成功后会在控制台看到如下输出
![]()
开启 Virtual Thread
启用并验证
通过如下配置，可以一键开启 spring 的 Virtual Thread 特性。
spring.threads.virtual.enabled=true
验证是否开启了
@RequestMapping("/")
@RestController
public class VirtualController {
@GetMapping("/test")
public String virtual() {
System.out.println(Thread.currentThread());
return "test";
}
}
上面代码将会在控制台输出
VirtualThread[#70,tomcat-handler-0]/runnable@ForkJoinPool-1-worker-1
性能测试
@RequestMapping("/")
@RestController
public class VirtualController {
final StringRedisTemplate redisTemplate;
public VirtualController(StringRedisTemplate redisTemplate) {
this.redisTemplate = redisTemplate;
}
@GetMapping("/test")
public String virtual() {
redisTemplate.opsForValue().set("test", "test");
return redisTemplate.opsForValue().get("test");
}
}
我在本地通过 wrk 压测上面的代码 (读写了下 Redis )，发现在不做任何参数调优的情况下，结果如下
tomcat 默认的线程池配置：
server.tomcat.threads.max=200
server.tomcat.threads.min-spare=10
从两次测试结果可以看出，在不做任何优化的前提下：
在 Platform threads 模式下，尝试调大 tomcat 的线程参数
server.tomcat.threads.max=300
server.tomcat.threads.min-spare=50
分别使用
压 Platform threads 的服务。
![]()
从 tomcat 调参后的测试结果看，至少我本地这个环境，这个场景没法在通过加大 threads 数加大性能了。也在一次印证了 Platform threads 模式下，负载高过一个临界值后，性能会下降。
三方测试
开启 CRaC
说明（还不成熟）
CRaC 当前只是初步支持，有些场景：比如内存里维护了复杂状态的应用，可能会遇到问题，启用前请谨慎做好全场景的测试。
参考文档：![]()
Spring Boot Reference Documentation \ ![]()
JVM Checkpoint Restore :: Spring Framework
启用并验证
集成步骤
-
1、JVM 层面（指定内存 dump 路径）：启动时添加 -XX:CRaCCheckpointTo=PATH 参数，指定 CRaC 的输出加载路径
-
2、Spring 层面（找个合适的时机触发内存 dump）：启动时添加 -Dspring.context.checkpoint=onRefresh 参数。该阶段启动时会自动创建检查点LifecycleProcessor.onRefresh。此阶段完成后，所有非延迟初始化的单例都已实例化，并且 InitializingBean#afterPropertiesSet回调已被调用；但生命周期尚未开始，且 ContextRefreshedEvent尚未发布。
-
3、JVM层面（加载内存恢复状态）：启动时添加 -XX:CRaCRestoreFrom=PATH 参数，指定加载的 CRaC 的路径
从集成步骤看，第 1、2 步应该都发生在 CI 阶段，且 Spring 的触发内存 dump 的意图很明显，等 onRefresh 完成后再出发，相当于初始 Bean 的时间就可以节省出来了。当然还可以使用 jcmd 指令触发 dump，比如：
jcmd target/example-spring-boot-0.0.1-SNAPSHOT.jar JDK.checkpoint
这个可以在任意时候触发，这就可以在 dump 前做完所有的预热逻辑，然后 dump 出来的状态就是性能峰值状态了
遇到的问题
1、JDK依赖问题
CRaC 特性依赖 JDK 特性支持，目前 openjdk 发行版只支持到 JDK17：![]()
Releases · CRaC/openjdk-builds 。如果在不支持的 JDK 下启用 CRaCCheckpointTo，则会输出：
Unrecognized VM option 'CRaCCheckpointTo'
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
CRaC 最早是 Azul 发起的一个项目，可以用 Azul 的社区发行版来验证 CRaC 特性，如：
docker image：azul/zulu-openjdk:21-jdk-crac
2、GC 算法问题
ZGC 算法下，不支持 CRaC，在 ZGC 启用时，会输出：
Error: Could not create the Java Virtual Machine.
Error: A fatal exception has occurred. Program will exit.
-XX:+UseZGC is currently unsupported for -XX:CRaCCheckpointTo.
为了验证 CRaC 功能，只好先移除 -XX:+UseZGC
3、打开的 FD & Socket 问题
CRaC 要求应用程序关闭所有打开的文件、网络连接等。在 Linux 上，这些内容表示为文件描述符。但是，可能很难更改应用程序以与检查点正确协调，例如，由于无法修改库中的代码。在这些情况下，CRaC 通过配置提供有限的处理。
理论上所有的资源都需要向 JVM 注册资源的 Checkpoint 前后的资源状态，Spring 内置的依赖都处理好了这一步，但是三方依赖，比如 Opentelemetry 、Apollo 等没有做这一步，就会出现一些异常。
Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenFileException: FD fd=35 type=regular path=/tmp/opentelemetry-temp-jars2649059754140254392/jartqV3k80l.jar (deleted)
at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:114) ~[na:na]
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore1(Core.java:188) ~[na:na]
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:286) ~[na:na]
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:265) ~[na:na]
at jdk.crac/jdk.crac.Core.checkpointRestore(Core.java:72) ~[jdk.crac:na]
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) ~[na:na]
at java.base/java.lang.reflect.Method.invoke(Method.java:580) ~[na:na]
at org.crac.Core$Compat.checkpointRestore(Core.java:141) ~[crac-1.4.0.jar!/:na]
... 17 common frames omitted
Suppressed: java.nio.channels.IllegalSelectorException
at java.base/sun.nio.ch.EPollSelectorImpl.beforeCheckpoint(EPollSelectorImpl.java:401)
at java.base/jdk.internal.crac.mirror.impl.AbstractContext.invokeBeforeCheckpoint(AbstractContext.java:43)
at java.base/jdk.internal.crac.mirror.impl.AbstractContext.beforeCheckpoint(AbstractContext.java:58)
at java.base/jdk.internal.crac.mirror.impl.BlockingOrderedContext.beforeCheckpoint(BlockingOrderedContext.java:64)
at java.base/jdk.internal.crac.mirror.impl.AbstractContext.invokeBeforeCheckpoint(AbstractContext.java:43)
at java.base/jdk.internal.crac.mirror.impl.AbstractContext.beforeCheckpoint(AbstractContext.java:58)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore1(Core.java:153)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:286)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestoreInternal(Core.java:299)
Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenSocketException: Socket[addr=apollo-config.dev.tapsvc.com/172.20.12.187,port=80,localport=47004]
at java.base/jdk.internal.crac.JDKSocketResourceBase.lambda$beforeCheckpoint$0(JDKSocketResourceBase.java:68)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore1(Core.java:169)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:286)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestoreInternal(Core.java:299)
解决
可通过 ![]()
File Descriptor Policies来有限的处理。
新建文件 crac.yaml ，配置内容如下：
type: socket
localAddress: *
action: ignore
---
type: file
path: /opt
action: ignore
---
type: file
path: /tmp
action: ignore
---
type: pipe
action: ignore
在 Java 应用启动系统参数里设置 -Djdk.crac.resource-policies = /{path}/crac.yaml
4、遗留的问题
遗留了一个问题，怎么都处理不了。刚好这个问题我认识的一个好友（Apollo 的作者）也遇到了，issue 如下：
Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenResourceException: FD fd=12 type=unknown path=anon_inode:[eventpoll]
at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:117)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore1(Core.java:188)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:286)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestoreInternal(Core.java:299)
Suppressed: jdk.internal.crac.mirror.impl.CheckpointOpenResourceException: FD fd=13 type=unknown path=anon_inode:[eventfd]
at java.base/jdk.internal.crac.mirror.Core.translateJVMExceptions(Core.java:117)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore1(Core.java:188)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestore(Core.java:286)
at java.base/jdk.internal.crac.mirror.Core.checkpointRestoreInternal(Core.java:299)
关于CRaC 的结论
基于如下：
-
Openjdk 发行版并未全部覆盖支持，目前支持的最高版本是 JDK17。更高版本的支持只能用 Azul 的 JDK
-
当前还有非常多的集成问题，且大量第三方包并没有做适配，Azul 官方给的 resource-policies 解决方案还属于初步阶段
-
Spring Boot 3.2 也是初步支持，Issue 区有大量集成的问题
综上，CRaC 距离生产可用还有很长的路要长，至少，当前解决应用启动问题，预热峰值问题，GraalVM 的 Native 方案比 CRaC 要更成熟。当然，未来哪个方向会成为标准还不好说，CRaC 的优势是保留了 JIT 的优化。
