Spring Boot 3.0.0正式发布，Banner不再支持图片&增强可观测性-51CTO.COM

前言

2014年发布Spring Boot 1.0； 2018年发布Spring Boot 2.0； 2022年发布Spring Boot 3.0；这节奏，是要跟世界杯/奥运会的频率杠上呀？

PS：本届世界杯三颗巨星已走俩，期待Messy。

Spring Boot 3.0.0是是首个支持Spring Framework 6以及支持GraalVM的版本。官方对各个版本支持时间表：

正文

如果把2014年发布1.0版比作Spring团队的再次创业，发布后火爆程度可谓风靡全球。到2018年发布2.0版本，已经完全没有对手了。今年刚发布的3.0版本直接上Java 17以及Jakarta EE 9起步，可谓站稳脚跟后的引领风骚。

what’s new（新特性）

老规矩，将我们关心的功能爽一遍。

最低版本要求

Spring Boot 3.0.0对外部依赖有最低版本要求：

JDK 17
Graal 22.3
Native Build Tools Plugin 0.9.17
Spring Framework 6

借助Micrometer大大提升可观测性

据说，Spring Boot内部有专门一个“团队”来做应用的可观性，本次的借助Micrometer的升级，使得可观测这件事在Spring Framework 6和Spring Boot 3.0.0内部都变得更加简单、易用！通过可观测性，能更好的了解系统内部的运行状态，做到胸有成竹。

Micrometer 1.10中引入的新的Observation API，它使得一个API就能搞定：metrics、tracing、logging指标观测，并且还能传递上下文、传播元数据等等，对使用者非常友好。

这个API的设计是降低使用门槛，希望用户使用单一API，就能从中获取到多种信息：metrics、tracing、logging

笔者窥探了一下Spring Boot针对Micrometer源代码级别的变化，觉得值得用专题来做较为完整的表述，结合自己的一些使用经验，尽量去说清楚在项目中如何使用它来方便的观测你的Application。

Log4j2增强

一句话：配置性更灵活、和Spring环境整合得更好了。

PS：一般情况下使用默认的logback即可。倘若你不是典型的高并发场景，不建议折腾Log4j2。

spring-web URL的匹配规则有变化

声明：这项特性更改和Spring Boot无关，属于Spring Framework 6的变更。

包含Spring MVC和WebFlux在内的URL 尾部斜杠匹配方式，本次有调整：可参见PathMatchConfigurer类。

为了下掉trailingSlashMatch这个属性，从Spring Framework 6开始将默认值由之前的true改为了fasle。虽然仅仅只是改了一个默认值，但这个变动其实还蛮大的，影响到了URL的匹配。

譬如，@GetMapping("/api/demo")之前版本即可匹配/api/demo亦可匹配上/api/demo/，自Spring Boot 3.0.0（其实是Spring Framework 6）版本后就不行了，只能匹配上前者，后者404。Spring Framework目前将此属性只标记为了@Deprecated(since = "6.0")过期，并未删除。因此若你从老项目里升级过来，那么请务必做好兼容，方式有两种：

局部式：将需要兼容的接口URL显示的写出多个，如：@GetMapping({"/api/demo", "/api/demo/"})。
全局式：若需要“兼容”的接口过多，又或者没法逐一排查，那么可以使用下面这种全局兼容的方式：

@Configuration
public class YourWebConfiguration implements WebMvcConfigurer {

    @Override
    public void configurePathMatch(PathMatchConfigurer configurer){
      configurer.setUseTrailingSlashMatch(true);
    }

}

删除对spring.factories自动配置的支持

在Spring Boot 2.7版本，引入了全新的INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件作为自动配置的文件，但那会依旧保留着对spring.factories的支持。

到了Spring Boot 3.0.0版本，删除掉了spring.factories作为自动配置文件的支持。这个差异在AutoConfigurationImportSelector文件里体现出来：

值得注意的是：只是删除了spring.factories作为自动配置文件的支持，而不是不再支持这种SPI语法了。毕竟像什么EnvironmentPostProcessor、AutoConfigurationImportFilter、FailureAnalyzer等加载实现类的方式用spring.factories还是非常方便的。

Spring Boot此举，笔者觉得目的就想将自动配置文件的配置，和其它SPI配置分离（顺便做做简化），仅此而已。

@ConstructingBinding不能再标注在类上

从源代码的角度看，改注解已经不能再被标注在类上了（编译不通过）：

至于Spring Boot为何这么做？下面继续说完就懂了。

改进的@ConstructorBinding检测能力

现在，当使用@ConfigurationProperties注解进行属性绑定时，如果类只有1个构造器，则可以省略注解@ConstructorBinding，不需要标注在构造器上。

PS：如果您有多个构造器，则仍然需要使用@ConstructorBinding来告诉 Spring Boot 使用哪一个。

这样一句话描述体感还是不强，还是来个demo跑一跑。标注有@ConfigurationProperties注解的属性类（一般有称作属性类，不叫配置类），如下：

注：如下例中，此时笔者并未在这个唯一构造器里标注@ConstructorBinding注解。

/**
 * 在此处添加备注信息
 *
 * @author YourBatman
 * @since 0.0.1
 */
@ToString
@ConfigurationProperties("demo")
public class DemoProperties {

    public DemoProperties(String name, Integer age){
        this.name = name;
        this.age = age;
        System.out.println("DemoConfiguration初始化成功：" + this);
    }
    private String name;
    private Integer age;

}

配置文件里写好属性的k-v：

demo.name = YourBatman
demo.age = 18

通过@ConfigurationPropertiesScan将@ConfigurationProperties属性文件加载进容器：

/**
 * 在此处添加备注信息
 *
 * @author YourBatman
 * @since 0.0.1
 */
@ConfigurationPropertiesScan
@Configuration(proxyBeanMethods = false)
public class PropertiesConfiguration {

}

文件结构如下：

以上示例代码，在Spring Boot 2.7.x里运行结果为：报错

在Spring Boot 3.0.0版本运行结果为：正常

见识到了Spring Boot 3.0.0升级的威力。

令我，对于有多个构造器的case，笔者这里就不试了，建议有兴趣者自行动手跑跑Demo，加强理解比看文章100遍都强。

题外话：@ConfigurationProperties使用最佳实践

先说一个数据：据笔者所见所闻，至少**95%**程序员使用@ConfigurationProperties的姿势是错的，并且不知道怎么做才是对的。

关于这个话题，在笔者之前有篇文章之前花大篇幅聊过，这里可再简单提一提，避免你在使用时候还出现些七七八八的问题。

比如上例中，如果我这么使用：如下截图，如果笔者没猜错的话，这大概率是你的使用方式吧。

当然你可能不用构造器而是用get/set方法去处理，问题或许不会暴露出来，但不影响你继续往下看哈。

从IDEA飘红提示来看，这种用法就不对嘛。再次运行容器：

在Spring Boot 2.7.x里运行结果为：报错

在Spring Boot 3.0.0版本运行结果为：报错

我在网上看到一篇写Spring Boot 3.0.0新特性的文章说到：改进的@ConstructorBinding检测能力这项新特性部分支持，不建议使用！嗨，这个误导性就比较强了。

说白了不是Spring Boot 3.0.0部分支持，而是使用者对属性类Bean的使用姿势不对：这从Spring Boot 3.0.0的报错提示能看出端倪，明显比2.7.x版本的报错指向性更好，明确告诉了你原因依旧修复方式。

值得一提的是，如果编码时这么使用，连IntelliJ IDEA都不同意：非常明显的指出了问题所在：

PS：想要获取IDEA这样温暖的提示，需要升级到最新版2022.3版本哦。

在属性类Bean上标注@Configuration注解（或者@Component及其所有派生注解），是大多数程序员的错误使用方式。因为这里其实犯了几大错误：

@ConfigurationProperties它并非一个Configuration配置类，因此不能直接走Spring Bean的初始化逻辑。
@ConfigurationProperties类如果直接被实例化为Bean，将绕过了其特有的前置处理逻辑，造成逻辑缺失，也就会造成隐患bug。
Spring Boot专门提供有@EnableConfigurationProperties和@ConfigurationPropertiesScan(since 2.2)注解来将@ConfigurationProperties类正确的放入容器内。

倘若走捷径只需程序Run起来即可，那么这种问题积累多了，必将反噬。

如何发现最佳实践？对于Spring内部的组件，参考Spring Boot内置实现即可，它自己的东西自己的使用姿势就是绝对的权威。当然本质还是对实现原理的理解（但理解曲线比较长），有兴趣的可以看笔者之前的文章哈。

Apache Kafka启用异步确认配置项

在KafkaProperties.Listener属性配置类里，新增了asyncAcks属性：

注意：此属性只在当KafkaProperties.Listener.ackMode = MANUAL/MANUAL_IMMEDIATE的时候才生效。

异步ack可对应Kafka中间件的同步(sync)、异步(async)、oneway三种发送方式理解。

@SpringBootTest支持“调用”main方法

我们的Spring Boot应用入口是main方法，而@SpringBootTest测试时它并没有执行我main方法，而是自己启的容器。这对于有些在main方法还写了些代码逻辑（比如设置个系统属性啥的）的时候就比较难受了。

这次在@SpringBootTest注解上新增了一个属性：

它的含义为：

下面我们来体验一把：在main函数上输出一行日志

测试类：

运行测试类，日志为：

可以看到完完整整的执行了main方法（启动了应用），因此只要main方法能够执行到的代码、扫到的配置、加载到的Bean，都会被放入到测试上下文里。

程序启动期间，不再查找主机名

2.7.x版本：启动日志包含主机名。

3.0.0版本：启动日志不再包含主机名。

代码差异体现在：

为何要干掉这段逻辑呢？看下这段代码的实现就知道了，还是比较耗时的：

这段逻辑干掉后，Spring Boot应用的启动速度应该会有比较明显的提升，收获比较大。

不再使用JDK的SecurityManager

Java 17中，SecurityManager遭到弃用。同理，最低要求Java 17的Spring Boot 3.0.0也无理由再使用它了。

以Spring Boot的TomcatEmbeddedWebappClassLoader类举例：上下对比可看出区别。

Banner不再支持图片

先看看代码差异（上为2.7.x版本，下为3.0.0版本）：可以看到，Spring Boot 3.0.0直接干掉了ImageBanner这个实现类。因此现在类路径下的banner.gif、banner.jpg、banner.png等图片文件都将被忽略，反馈归真，只支持文本类Banner了！

PS：有兴趣的同学可以看看ImageBanner的实现，很高级且很复杂，当然也很耗时。看完就明白这个版本为啥要干掉它了~

JMX默认也只暴露Health端点了

从Spring Boot 2.7开始，web端点默认只暴露health，这次JMX也来跟着保持一致了。

如若需要显示控制其它端点，你可通过management.endpoints.jmx.exposure.include和management.endpoints.jmx.exposure.exclude属性来自定义控制。

Actuator内置端点的返回JSON序列化统一使用ObjectMapper

在直线版本中，端点返回的序列化方式和MVC接口的并不一致，因此可能出现一些怪异现象。现在好了：所有端点的返回值序列化，统一使用ObjectMapper来完成。

这个标准是通过：统一实现OperationResponseBody接口实现的。

值得注意的事：若你有自定义的endpoint，那么也可通过实现OperationResponseBody接口，来保持和内置端点序列化的一致性。

spring.data属性前缀改变

由于spring.data这个前缀保留给了Spring Data项目，因此之前Spring Boot上的有些配置需要做修改。

spring.data.cassandra. -> spring.cassandra.

解释：由于使用cassandra不需要引入spring data项目，因此它“不配”用spring.data前缀。

spring.redis. -> spring.data.redis.
解释：由于使用redis会自动引入spring data项目依赖，因此需要统一到spring.data前缀

其它升级/改版

@AutoConfigureMetrics -> @AutoConfigureObservability。
@ConstructorBinding注解迁移到org.springframework.boot.context.properties.bind包了（之前版本在外层）。

从这点能看出框架对职责边界的强要求，日常点滴才能确保长久的不腐化。

DiskSpaceHealthIndicator详情里增加path的显示。

jakarta.validation.Configuration现在可借助ValidationConfigurationCustomizer定制化器进行定制了。
YamlJsonParser类被删除。原因为：SnakeYAML的JSON解析与其它JSON库的解析行为不一致，为了避免用错而导致问题，干脆删除掉。推荐使用JsonParser代替之。

新增管理的组件：

EhCache 3
RxJava 3
移除管理的组件：
Apache ActiveMQ（可谓终于放弃了）
Atomikos（分布式事务管理器，支持XA协议）
EhCache 2（毕竟3.x已为主流）
Hazelcast 3
Apache Solr（因为它基于Jetty的客户端Http2SolrClient与Jetty 11不兼容）
RxJava 1.x和2.x
ANTLR 2

Spring体系的其它依赖升级

基本上都是大版本号升级，毕竟命名空间从javax.* -> jakarta.*这一步影响还是蛮大的。

Spring Data 2022.0
Spring Kafka 3.0
Spring REST Docs 3.0
Spring Security 6.0
Spring AMQP 3.0
Spring Batch 5.0
Spring GraphQL 1.1
Spring HATEOAS 2.0
Spring Integration 6.0
Spring LDAP 3.0
Spring Retry 2.0
Spring Session 3.0
Spring WS 4.0

Jakarta依赖升级

Spring Boot管理上的为基于Jakarta EE 10（基线是Jakarta EE 9）

Jakarta Persistence 3.1
Jakarta Servlet 6.0
Jakarta Validation 3.0
Jakarta WebSocket 2.1
Jakarta Activation 2.1
Jakarta JMS 3.1
Jakarta JSON 2.1
Jakarta JSON Bind 3.0
Jakarta Mail 2.1
Jakarta Servlet JSP JSTL 3.0
Jakarta Transaction 2.0
Jakarta WS RS 3.1
Jakarta XML SOAP 3.0
Jakarta XML WS 4.0

主要三方依赖升级

自从用上Spring Boot，程序员基本很少再需要关心三方依赖的版本号了，交给Spring Boot既省心又放心。

早期程序员，应该有使用过spirng-bom的，深有体会。原来，Spring早就在筹划帮我们解决业务逻辑之外的痛点了。

Tomcat 10
Jetty 11
Undertow 2.2.20.Final
Elasticsearch Client 8.5
Hibernate Validator 8.0（实现了Jakarta Validation 3.0）
Jackson 2.14
Micrometer 1.10
SLF4J 2.0（org.slf4j:slf4j-api:2.0.0）
OkHttp 4.10（com.squareup.okhttp3:okhttp:4.10, 使用了kotlin封装）
Netty 4.1.77.Final
Couchbase Client 3.4
Flyway 9
Groovy 4.0
Hibernate 6.1
Jersey 3.1
jOOQ 3.16
Kotlin 1.7.20
Liquibase 4.13
Lettuce 6.2
Log4j 2.18
Logback 1.4
Micrometer Tracing 1.0
Neo4j Java Driver 5.2
R2DBC 1.0
Reactor 2022.0
SnakeYAML 1.32
Thymeleaf 3.1.0.M2

总结

Spring Boot已然成为Java开发的基石，本次大版本升级，并且还是明确的阻断式的，因此可以看到大多建议都是清一色：正确的废话，所以笔者也来几句废话建议：

生产环境非常确定的：不要用，不要用，不要用。至少等下一个中型版本出来后再考虑，也就是Spring Boot 3.1.x。

因为不少依赖组件升级还没跟上（特别是国产的），比如典型的mybatis-plus、druid等。
配置有较大变动，隐藏的坑多。如springsecurity、spring-data等。
Spring Cloud对应的版本（2022.0.0）还未Release。

个人自己：把玩，把玩，把玩。看10篇相关文章介绍，抵不上自己把玩一次！

技术向前的大船，浩浩荡荡不可逆。作为技术人，我们能做的是keep moving，不管是技术架构师还是业务架构师，还是开发工程师！