Spring Boot 2.4.0正式發佈，全新的配置文件加載機制（不向下兼容）

千里之行，始於足下。關注公衆號【BAT的烏托邦】，有Spring技術棧、MyBatis、JVM、中間件等小而美的原創專欄供以免費學習。分享、成長，拒絕淺嘗輒止。本文已被 https://www.yourbatman.cn 收錄。

✍前言

你好，我是YourBatman。

北京時間2020-11-12，Spring Boot 2.4.0正式發佈。2.4.0是第一個使用新版本方案的Spring Boot發行版本。

注意：2.4.0版本號沒有.RELEASE後綴，沒有.RELEASE後綴，沒有.RELEASE後綴。使用的是Spring最新的版本發佈規則。此規則詳解請參考上篇文章：Spring改變版本號命名規則：此舉對非英語國家很友好

還記得Spring Boot 2.3.0.RELEASE版本發佈時那會麼？前後相差將好半年：

直達電梯：Spring Boot 2.3.0正式發佈：優雅停機、配置文件位置通配符新特性一覽

一般來說，次版本號的升級會有點料，根據之前的爆料此次升級據說是做了大量的更新和改進。那麼老規矩，作爲小白鼠的我先代你玩一玩，初體驗吧。

也可參見官方的更新日誌：Spring Boot 2.4.0 Release Notes

✍正文

除了剛發佈的Spring Boot 2.4.0，Spring Boot 2.3.x/2.2.x仍舊是活躍的維護的版本。Spring Boot遵循的是Pivotal OSS支持策略，從發佈日期起支持主要版本3年（注意：是主要版本）。下面是詳情：

• 2.3.x：支持的版本。2020.05發佈，是現在的活躍的主幹
• 2.2.x：支持的版本。2019.10發佈，是現在的活躍的主幹
• 2.1.x：2018.10發佈，支持到2020.10月底，建議儘快升級

EOL分支：

• 2.0.x：2018.3發佈，2019.4.3停止維護
• 1.5.x：生命已終止的版本。2017.1發佈，是最後一個1.x分支，2019.8.1停止維護

回憶2.3版本的新特性

可能大部分小夥伴都還沒用過2.3.x分支，沒想到2.4.x就已發佈。因此這裏先對2.3.x版本的新特性，來波簡單回憶：

1. 優雅停機。這是2.3.x主打的新特性：在關閉時，web服務器將不再允許新的請求，並將等待完成的請求給個寬限期讓它完成。這個寬限期是可以設置的：可以使用spring.lifecycle.timeout-per-shutdown-phase=xxx來配置，默認值是30s。
2. 配置文件位置支持通配符。簡單的說，如果你有MySql的配置和Redis配置的話，你就可以把他們分開來放置，這個新特性也是棒棒噠。隔離性更好目錄也更加清晰了（注意：此格式只支持放在classpath外部）：
   1. mysql：/config/mysql/application.properties
   2. redis：/config/redis/application.properties
3. 核心依賴升級。
   1. Spring Data Neumann。備註：很明顯這個還是舊的命名方式。在Spirng新的版本規則下，Spring Data最新版本爲Spring Data 2020.0.0
   2. Spring Session Dragonfruit（很明顯這個也還是舊的命名方式）
   3. Spring Security 5.3
   4. Spring Framework 沒有升級，使用的依舊是和Spring Boot 2.2相同的5.2.x版本
      1. 說明：小版本號的升級對於新特性來說一般選擇性忽略
   5. 關於Bean Validation：從此版本開始，spring-boot-starter-web不會再把validation帶進來，所以若使用到，你需要自己添加這個spring-boot-starter-validation依賴
      1. 一般來說建議你手動引入，畢竟Bean Validation的使用還是很廣泛，並且真的非常非常好用

做足功課後，就開始最新的Spring Boot 2.4.0之旅吧。

2.4.0主要新特性

全新的配置文件處理(properties/yaml)

這個改變最爲重磅，本次改變了配置文件的加載邏輯，旨在簡化和合理化外部配置的加載方式，它可能具有不向下兼容性。

Spring Boot 2.4改變了處理application.properties和application.yml文件的方式：

• 若你只是簡單的文件application.properties/yaml，那麼升級對你是無縫的，你感受不到任何變化
• 若你使用了比較複雜的文件，如application-profile.properties/yaml這種（或者使用了Spirng Cloud的配置中心、（帶有分隔符----的）多yaml文件），那麼默認是不向下兼容的，需要你顯式的做出些更改

因爲配置文件隸屬於程序的一部分，特別是我們現在幾乎都會使用到配置中心。因此下面針對於老版本升級到Spring Boot 2.4.0做個簡單的遷移指導。

說明：因配置文件加載邏輯完全進行了重寫，因此詳細版本我放到了下文專文講解，有興趣可保持關注

老版本版本配置屬性遷移指南

老版本：2.4.0之前的版本都叫老版本。

Spring Boot 2.4對application.poperties/yaml的處理做了更新/升級。旨在簡化和合理化外部配置的加載方式。它還提供了新功能：spring.config.import支持。所以呢，對於Spring Boot 2.4.0之前的版本（老版本）若升級到2.4.0需要做些修改，指導建議如下：

方式一：恢復舊模式（不推薦）

如果你還未準備好做配置遷移的修改，Spring Boot也幫你考慮到了，提供了一鍵切換到舊模式的“按鈕”。具體做法是：只需要在Environment裏增加一個屬性spring.config.use-legacy-processing = true就搞定。最簡的方式就是把這個屬性放在application.poperties/yaml裏即可。

spring.config.use-legacy-processing = true

增加此配置後，Spring Boot對配置文件的解析恢復到原來模式：仍舊使用ConfigFileApplicationListener去解析。

ConfigFileApplicationListener屬於Spring Boot非常核心的底層代碼，這次做了不向下兼容的改進，可見它對進擊雲原生的決心

值得注意的是：此API在2.4.0已被標記爲過期：

// @since 1.0.0
// @deprecated since 2.4.0 in favor of {@link ConfigDataEnvironmentPostProcessor}
@Deprecated
public class ConfigFileApplicationListener implements EnvironmentPostProcessor, SmartApplicationListener, Ordered {
	...
}

按照Spring Boot的版本策略，此類將在Spring Boot 2.6.0版本被移除。因此：若不是迫不得已（時間緊急），並不建議你用兼容手法這麼去做，因爲這將成爲技術債，遲早要還的。

說明：很多RD其實只會看到當前的方便，獲得利益（比如快速上線獲獎），坑交給後人。我個人認爲作爲程序員應該有一定自我修養，自我追求，不爲一時的爽而持續給團隊積累債務，畢竟積重難返。

方式二：按新規則遷移（推薦）

若你對配置文件的使用有如下情行，那麼你需要做遷移：

1. 多文檔的yaml文件（帶有----分隔符的文件）
2. 在Jar外使用配置文件，或者使用形如application-{xxx}.properties/yaml這種配置
3. 若在多文檔yaml中使用到了spring.profiles配置項
4. ...

Spring Boot 2.4.0升級對配置文件的改動是最大的，並且還不具備向下兼容性，簡單的說就是從此版本開始要把Spring Boot的配置文件加載機制重學一遍（比如還增加了spring.config.import，增加了對kubernetes配置的支持等等），並且還要學會如何遷移。

爲了更好的描述好這個非常非常重要的知識點，下篇文章我會用專文來全面介紹 Spring Boot這套全新的配置文件加載機制，並且輔以原理，以及和過去方式的比較，幫助你更全面、更快速、更勞的掌握它，歡迎持續關注。

說明：Spring Boot的配置文件加載機制非常非常重要，因爲你也知道你平時開發中很大程度實際上是在跟它的配置項打交道。新的配置加載方式比老的更加優秀，適應發展，敬請期待

從spring-boot-starter-test中刪除Vintage Engine

Spring Boot 2.2.0版本開始就引入JUnit 5作爲單元測試默認庫，在此之前，spring-boot-starter-test包含的是JUnit 4的依賴，Spring Boot 2.2.0版本之後替換成了Junit Jupiter（Junit5）。

Vintage Engine屬於Junit5的一個模塊，它的作用是：允許用JUnit 5運行用JUnit 4編寫的測試，從而提供了向下兼容的能力。

從2.2.0到現在經過了2個版本的迭代，到Spring Boot 2.4.0這個版本決定了把Vintage Engine從spring-boot-starter-test正式移除。因此：若你的工程仍需要對JUnit4支持，那麼請手動引入依賴項（如果工程量不大，強烈建議使用JUnit5，比4好用太多）：

<dependency>
    <groupId>org.junit.vintage</groupId>
    <artifactId>junit-vintage-engine</artifactId>
    <scope>test</scope>
    <exclusions>
        <exclusion>
            <groupId>org.hamcrest</groupId>
            <artifactId>hamcrest-core</artifactId>
        </exclusion>
    </exclusions>
</dependency>

說明：其實在2.4.0之前，若你是從https://start.spring.io生成的項目其實也是不會帶有vintage-engine的。只不過它是通過顯式的在pom裏通過exclusion標籤來排除的

嵌入式數據庫檢測

改進嵌入式數據庫檢測機制：僅當數據庫在內存中時纔將其視爲嵌入式數據庫。所以如果使用H2、HSQL等產品，但是你是基於文件的持久性或使用的是服務器模式，那麼將不會檢測爲內存數據庫。而對於非內存數據庫，你可能需要額外做如下動作：

1. sa用戶名將不會再被主動設置。所以如果你的數據庫需要用戶名，請增加配置項：spring.datasource.username = sa
2. 這種數據庫將不會再被自動初始化，若要使用請根據需要更改spring.datasource.initialization-mode的值

Logback配置屬性

Logback一些配置項改名了，更加表名了它是logback的配置項。

新增了配置類LogbackLoggingSystemProperties用於對應，它繼承自之前的LoggingSystemProperties

之前的配置項有些被廢棄（此版本還未刪除，後續版本肯定會刪除的），對應關係如下：

老(已廢棄)	新
logging.pattern.rolling-file-name	logging.logback.rollingpolicy.file-name-pattern
logging.file.clean-history-on-start	logging.logback.rollingpolicy.clean-history-on-start
logging.file.max-size	logging.logback.rollingpolicy.max-file-size
logging.file.total-size-cap	logging.logback.rollingpolicy.total-size-cap
logging.file.max-history	logging.logback.rollingpolicy.max-history

一些屬性是被放到system environment裏面的：

老(已廢棄)	新
~~ROLLING_FILE_NAME_PATTERN ~~	LOGBACK_ROLLINGPOLICY_FILE_NAME_PATTERN
LOG_FILE_CLEAN_HISTORY_ON_START	LOGBACK_ROLLINGPOLICY_CLEAN_HISTORY_ON_START
LOG_FILE_MAX_SIZE	LOGBACK_ROLLINGPOLICY_MAX_FILE_SIZE
LOG_FILE_TOTAL_SIZE_CAP	LOGBACK_ROLLINGPOLICY_TOTAL_SIZE_CAP
LOG_FILE_MAX_HISTORY	LOGBACK_ROLLINGPOLICY_MAX_HISTORY

不再註冊DefaultServlet

從Spring Boot 2.4開始，默認將不會再註冊DefaultServlet。因爲在絕大多數的應用中，Spring MVC提供的DispatcherServlet是唯一需要被註冊的Servlet。從源碼處感受下這次改動：

AbstractServletWebServerFactory：

// 2.4.0之前版本，默認值是true
private boolean registerDefaultServlet = true;
// 2.4.0以及之後版本，默認值是false
private boolean registerDefaultServlet = false;

當然嘍，若你的工程強依賴於此Servelt，那麼可以通過此配置項server.servlet.register-default-servlet = true把它註冊上去。

補課：什麼是DefaultServlet？

它是Java EE提供的標準技術，如Tomcat、Jetty等都提供了這個類。簡而言之它的作用就是兜底（攔截/），當別的servlet都沒匹配上時就交給它來處理，一般用於處理靜態資源如.jpg,.html,.js這類的靜態文件。

DefaultServlet在傳統web容器裏，會被配置在tomcat目錄（此處以tomcat爲例）下的conf/web.xml裏：

<servlet>
    <servlet-name>default</servlet-name>
    <servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
    <init-param>
        <param-name>debug</param-name>
        <param-value>0</param-value>
    </init-param>
    <init-param>
        <param-name>listings</param-name>
        <param-value>false</param-value>
    </init-param>
    <load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
    <servlet-name>default</servlet-name>
    <url-pattern>/</url-pattern>
</servlet-mapping>

說明：tomcat下的web.xml對其加載的所有的Application都生效，並且最終和Application自己的web.xml內容合併，遇相同的話後者優先級更高

在Spring Boot 嵌入式容器裏配置是這樣的（完全等價於xml配置）：

private void addDefaultServlet(Context context) {
	Wrapper defaultServlet = context.createWrapper();
	defaultServlet.setName("default");
	defaultServlet.setServletClass("org.apache.catalina.servlets.DefaultServlet");
	defaultServlet.addInitParameter("debug", "0");
	defaultServlet.addInitParameter("listings", "false");
	defaultServlet.setLoadOnStartup(1);
	// Otherwise the default location of a Spring DispatcherServlet cannot be set
	defaultServlet.setOverridable(true);
	context.addChild(defaultServlet);
	context.addServletMappingDecoded("/", "default");
}

值得注意的是：Spring Boot註冊的DispatcherServlet的path也是/（覆蓋掉了DefaultServelt）。在Spring MVC環境下倘若是靜態資源，也不用DefaultServelt費心，Spring MVC專門提供了一個DefaultServletHttpRequestHandler用於處理靜態資源（雖然最終還是Dispatcher給defaultServlet去搞定）。

現在的Spring Boot服務大都是REST服務，並無靜態資源需要提供，因此就沒有必要啓用DefaultServletHttpRequestHandler和註冊DefaultServlet來增加不必要的開銷嘍。

HTTP traces不再包含cookie頭

Http traces默認將不再包含請求頭Cookie以及響應頭Set-Cookie。源碼處感受一下：

org.springframework.boot.actuate.trace.http.Include：

// 2.4.0版本之前：包含COOKIE_HEADERS這個頭
static {
	Set<Include> defaultIncludes = new LinkedHashSet<>();
	defaultIncludes.add(Include.REQUEST_HEADERS);
	defaultIncludes.add(Include.RESPONSE_HEADERS);
	defaultIncludes.add(Include.COOKIE_HEADERS);
	defaultIncludes.add(Include.TIME_TAKEN);
	DEFAULT_INCLUDES = Collections.unmodifiableSet(defaultIncludes);
}
// 2.4.0版本以及之後：不包含COOKIE_HEADERS這個頭
static {
	Set<Include> defaultIncludes = new LinkedHashSet<>();
	defaultIncludes.add(Include.REQUEST_HEADERS);
	defaultIncludes.add(Include.RESPONSE_HEADERS);
	defaultIncludes.add(Include.TIME_TAKEN);
	DEFAULT_INCLUDES = Collections.unmodifiableSet(defaultIncludes);
}

若你仍舊想保留老的習慣，那麼請用配置項management.trace.http.include = cookies, errors, request-headers, response-headers自行控制。

Neo4j

這個版本對Neo4j的支持進行了重大調整。直接用源碼來說明差異：

Spring Boot 2.4.0之前版本：

@ConfigurationProperties(prefix = "spring.data.neo4j")
public class Neo4jProperties implements ApplicationContextAware { ... }
// 無Neo4jDataProperties配置類

Spring Boot 2.4.0以及之後版本：

@ConfigurationProperties(prefix = "spring.neo4j")
public class Neo4jProperties { ... }
@ConfigurationProperties(prefix = "spring.data.neo4j")
public class Neo4jDataProperties { ... }

其它升級關注點

• Spring Framework 5.3：Spring Boot 2.4.0使用的是5.3.0主線分支（之前使用的5.2.x或更低）
  • Spring Framework 5.3的新特性應該重點關注，請移步我上篇文章：Spring Framework 5.3.0正式發佈，在雲原生路上繼續發力
• Spring Data 2020.0：Spring Boot 2.4.0使用的是最新發布的Spring Data 2020.0
  • 此版本的命名方式不同於之前，是因爲使用了Spirng最新的release train命名方式。Spring在2020年4月份發佈了最新的版本命名方式，可參考前面這篇文章：Spring改變版本號命名規則：此舉對非英語國家很友好
• 支持Java 15：此版本的Spring Boot完全支持Java 15，最小支持依舊是Java 8
• 自定義屬性名支持：當使用構造函數綁定時，屬性的名稱需要和參數名稱保持一樣。如果您想使用Java保留關鍵字，這可能是一個問題。如下例子：

@ConfigurationProperties(prefix = "sample")
public class SampleConfigurationProperties {

  private final String importValue;

  // import是Java關鍵字
  public SampleConfigurationProperties(@Name("import") String importValue) {
    this.importValue = importValue;
  }

}

@Name註解是Spring Boot 2.4.0新增的註解，能標註在ElementType.PARAMETER上

• 支持導入無擴展名的配置文件：如果您有這樣的需求，現在就可以通過向Spring Boot引導提供關於內容類型的提示來導入這些文件
  • 此版本對Spring Boot的配置文件加載進行了完全重新改造，並且不向下兼容，具體參見下篇文章
• 新增StartupEndpoint：顯示有關應用程序啓動的信息。此端點可以幫助您識別啓動時間超過預期的bean
  • 此端點依賴於Spring Framework 5.3.0新提供的應用啓動追蹤新特性。具體可參考ApplicationStartup和StartupStep這個兩個API是如何做追蹤的
• 新增RedisCacheMetrics：用於監控使用redis時的puts、gets、deletes以及緩存命中率等信息
  • 此指標信息默認不開啓，需你增加配置spring.cache.redis.enable-statistics = true
• 新增些Web配置項：spring.web.locale、spring.web.locale-resolver、spring.web.resources.*、management.server.base-path，這些屬性既支持Servlet也支持WebFlux
  • 對應的只能用於 Spring MVC或servelt下配置項spring.mvc.locale/spring.mvc.locale-resolver/spring.resources.*/management.server.servlet.context-path均以標註爲過期
• 支持Flyway 7：這個版本升級到Flyway 7，帶來了一些額外的屬性。如：spring.flyway.url/user/password（開源版本）；spring.flyway.cherry-pick/jdbc-properties...（團隊版本）
• H2數據庫控制檯支持配置密碼：可通過spring.h2.console.settings.web-admin-password屬性配置通過密碼訪問H2控制檯
• 增強的錯誤分析器FailureAnalizers：現在即使你還沒有創建ApplicationContext，FailureAnalizers都會生效來幫你定位錯誤位置
• 處理/標註Spring Boot 2.2和2.3中過期項：按照Spring Boot的版本兼容性政策，在2.2版本已被標記爲@Deprecated的在2.4.0版本會被刪除，在2.3版本中被標記爲@Deprecated的計劃在2.5.0版本中將其移除

✍總結

這是A哥奉給大家的，對Spring Boot2.4.0版本新特性的介紹，希望對你有些幫助。

Spring Boot 2.4.0版本的升級目標，基本和Spring Framework 5.3.0保持一致：爲雲原生做努力。表現在除了刪除些無用類，禁止不需要的類的加載外，重點還會體現在它對配置文件加載機制的重構上，這將是下文的內容，也是本次升級的重頭戲，敬請關注。

Spring Boot重寫了對配置文件的加載機制，並且新引入了近40個類來處理（老方式僅有區區幾個類），可見其重視、重要程度。因此，爲了適應未來的發展，你一定要掌握，並且越早越好，下篇將爲你揭曉。

---

✔推薦閱讀：

• 如果程序員和產品經理都用凡爾賽文學對話......
• Spring Framework 5.3.0正式發佈，在雲原生路上繼續發力
• Spring改變版本號命名規則：此舉對非英語國家很友好
• JDK15正式發佈，劃時代的ZGC同時宣佈轉正
• IntelliJ IDEA 2020.2正式發佈，諸多亮點總有幾款能助你提效
• Spring Boot 2.3.0正式發佈：優雅停機、配置文件位置通配符新特性一覽
• 搞事情？Spring Boot今天一口氣發佈三個版本