springboot3.1到springboot3.2升级

springboot3.1 -> springboot3.2

1、通过反射获取参数名称

Spring Boot 3.2使用的Spring Framework版本不再试图通过解析字节码来推断参数名。 如果遇到依赖注入或属性绑定问题，检查下是否正在使用 -parameters 选项进行编译

public class TestDemo {

    public String say(String message){
        return "hello world:"+message;
    }

    public static void main(String[] args) {
        Method method = ReflectionUtils.findMethod(TestDemo.class,"say",String.class);
        //通过springfromework的反射工具类 获取方法say参数名称
        ParameterNameDiscoverer discoverer = new DefaultParameterNameDiscoverer();
        String[] parameterNames = discoverer.getParameterNames(method);

        Stream.of(discoverer.getParameterNames(method)).forEach(System.out::println);
    }
}

springboot3.2之前的版本可以获取到方法say的参数名message，springboot3.2无法获取到。如果想获取到方法的参数名，如果是maven项目，需要在pom.xml中添加如下插件（不同的maven版本可能配置方式不一样）：

    <plugin>
        <groupId>org.apache.maven.plugins</groupId>
        <artifactId>maven-compiler-plugin</artifactId>
        <configuration>
            <compilerArgs>
                <arg>-parameters</arg>
            </compilerArgs>
        </configuration>
    </plugin>

2、自动配置

在 Spring Boot 3.2.2 及以后的版本中，如果你的项目类路径上包含了 spring-security-oauth2-client、spring-security-oauth2-resource-server 或 spring-security-saml2-service-provider 这些依赖，并且没有显式配置 spring.security.user.name 和 spring.security.user.password，那么 Spring Boot 的自动配置将不再尝试提供一个默认的基于用户名和密码的认证机制。

这一变化的原因是为了避免在引入 OAuth 2.0 客户端或资源服务器，或 SAML 2.0 服务提供商等高级安全特性时，产生混淆或冲突。这些高级特性通常有自己的认证和授权机制，因此不再需要或期望有一个基于用户名和密码的默认认证。

在响应式应用中，当类路径上存在 spring-security-oauth2-client 或 spring-security-oauth2-resource-server 时，也会发生类似的自动配置撤销。这是为了确保 OAuth 2.0 相关的配置能够正确地接管安全控制，而不是与基于用户名和密码的默认认证机制发生冲突。

如果你需要配置基于用户名和密码的认证，你需要显式地在你的 application.properties 或 application.yml 文件中进行配置，或者通过编程方式配置 Spring Security。

例如，在 application.properties 中，你可以这样配置：

spring.security.user.name=myuser  
spring.security.user.password=mypassword

3、H2 Version

Spring Boot现在默认使用H2的2.2版本。 要继续使用H2早期版本的数据库， 需要进行数据迁移

4、Oracle UCP数据源

Oracle UCP数据源不再默认设置 validateConnectionOnBorrow 为 true 。 如果沿用旧，可以将 spring.datasource.oracleucp.validate-connection-on-borrow 应用程序属性设置为 true 。

5、OTLP Tracing Endpoint

默认值 management.otlp.tracing.endpoint 已经删除。 OtlpHttpSpanExporter bean现在只有在 management.otlp.tracing.endpoint 有值时才自动配置。 沿用旧配置，需设置 management.otlp.tracing.endpoint=http://localhost:4318/v1/traces 。

6、jetty 12

支持Jetty 12。Jetty 12支持最新的Servlet 6.0 API。在升级过程中，请确保删除任何之前用于覆盖Servlet API版本的配置或依赖项。Jetty 11不再被支持作为嵌入式web服务器

7、RestClient支持

Spring Boot 3.2中的Spring Framework 6.1中引入了RestClient的支持。 这个接口提供了一个函数式的阻塞式HTTP API

8、支持虚拟线程

要使用虚拟线程，需要运行在Java 21上，并将属性 spring.threads.virtual.enabled 设置为 true

（1）Servlet Web服务器

启用虚拟线程后，Tomcat和Jetty将使用虚拟线程进行请求处理。处理web请求的应用程序代码，例如控制器中的方法，将在虚拟线程上运行。

（2）Task Execution

当启用虚拟线程时， applicationTaskExecutor bean将被配置为使用虚拟线程的 SimpleAsyncTaskExecutor 。 任何使用应用程序任务执行器的地方，例如 @EnableAsync 当调用 @Async 方法、Spring MVC的异步请求处理和Spring WebFlux的阻塞执行支持现在都将使用虚拟线程。 和之前一样，任何 TaskDecorator bean都会被应用到自动配置的执行器上，然后应用 spring.task.execution.thread-name-prefix 属性。 其他 spring.task.execution.* 属性会被忽略。

（3）Task Scheduling

当启用虚拟线程时， taskScheduler bean将被配置为使用虚拟线程的 SimpleAsyncTaskScheduler 。 应用了 spring.task.scheduling.thread-name-prefix 属性和 spring.task.scheduling.simple. 属性。 其他 spring.task.scheduling. 属性将被忽略。

（4）保持JVM处于活动状态

配置spring.main.keep-alive=true时，即使所有其他线程都是虚拟(或守护)线程，jvm也将保持活动状态

（5）技术特定的集成

在启用虚拟线程时，将应用以下特定于技术的集成:

RabbitMQ监听器会自动配置一个虚拟线程执行器。

为Kafka监听器自动配置了一个虚拟线程执行器

Spring Data Redis ClusterCommandExecutor 将使用虚拟线程

Apache Pulsar的Spring将使用 VirtualThreadTaskExector 来自动配置 ConcurrentPulsarListenerContainerFactory 和 DefaultPulsarReaderContainerFactory 。