Spring Boot 3.0.0正式發布，Banner不再支持圖片&增強可觀測性

作者：YourBatman 2022-12-12 08:34:57

開發前端

今年剛發布的3.0版本直接上Java 17以及Jakarta EE 9起步，可謂站穩腳跟后的引領風騷。

前言

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，不管是技術架構師還是業務架構師，還是開發工程師！

責任編輯：姜華來源： YourBatman

Spring Java