升级 JDK21、 Spring Boot 3.2并开启 Virtual Thread、CRaC

【直播预告】DBA 会被云淘汰吗？

背景

JDK21 已发布一段时间，是 JDK17 后的的又一个长期维护版本，支持了 Virtual Thread、CRaC 特性，并带来了新的分代 ZGC 算法
Spring Boot 3.2.1 (Runtime efficiency with Spring (today and tomorrow) )版本发布后，框架层面原生的支持了 Virtual Thread、CRaC 特性

同时在 ops-job 上应用积累经验，可在其他项目如 Apollo 、xxljob 上继续落地

ps：本次升级项目原依赖是 JDK17，Spring Boot 2.6.5

关键结果（收益）

在不影响程序逻辑情况下，大幅缩短启动时间
内存使用降低，性能更好
CPU 资源使用率降低（因 GC 导致的 CPU 使用降低）

升级改动

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>

代码兼容性改动

Spring Boot3 升级是个比较大的变动，有很多的不兼容性。这里只记录 ops-job 这个项目遇到的问题。更多问题参考：Spring Boot 3.0 Migration Guide (官网升级指南必看)

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

性能测试

环境：Redis 为本地的实例

@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

wrk -t80 -c100 -d 10s --latency http://127.0.0.1:8040/test

wrk -t150 -c200 -d 10s --latency http://127.0.0.1:8040/test

从两次测试结果可以看出，在不做任何优化的前提下：

低负载（-t80 -c100）：性能相当，差别不大
高负载（-t150 -c200）：Virtual threads 依然保持高性能，Platform threads 出现了性能下降的问题。且两者 QPS 差距非常明显，Virtual threads 比 Platform threads 多 19%~29% 的性能。

在 Platform threads 模式下，尝试调大 tomcat 的线程参数

server.tomcat.threads.max=300
server.tomcat.threads.min-spare=50

分别使用

wrk -t150 -c200 -d 10s --latency http://127.0.0.1:8040/test
wrk -t80 -c100 -d 10s --latency http://127.0.0.1:8040/test

压 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 等没有做这一步，就会出现一些异常。

Opentelemetry 的问题

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

Apollo

        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 如下：

CheckpointOpenFileException occurred with spring boot log files · Issue #31680 · spring-projects/spring-framework

 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 的优化。