一、前言

就在 2025 年 11 月 2 號，Spring Boot 正式宣布 4.0.x 的維護時間從 2025 年 11 月 2 號至 2026 年 12 月。而 Spring Boot 4.0 RC1 早在十月份就已經正式發布。這一里程碑的版本帶來了巨大升級與變化。其中最為了人津津樂道的莫過于完全移除了對 Undertow Web 容器的支持。

其實早在 Spring Boot 官方在 2024 年發布的 3.3 版本路線圖中明確指出：將正式移除對 Undertow Web 服務器的自動配置支持，相關功能模塊（spring-boot-starter-undertow）將從核心依賴中剔除。

那為什么之前風靡一時的 Undertow 會在如今被棄用呢？

二、為何棄用 Undertow

Spring 在官方文檔中已經明確解釋了移除 Undertow 支持的主要技術原因：

Spring Boot 4.0 需要一個 Servlet 6.1 的基線，而 Undertow 目前尚不兼容。因此，我們放棄了對 Undertow 的支持。

在這份聲明中，明確指出了主要問題是版本依賴的兼容性問題。

Spring Boot 4.0 基于 Spring Framework 7，強制依賴S ervlet 6.1 規范。

而 Undertow 的維護方 Red Hat 未能及時適配。 說白了，Undertow 團隊連跟上 Jakarta EE 基本節奏的能力都沒有，Spring Boot 團隊不想再替人擦屁股。

其實出現這種情況也算是必然的一個結果。因為 Spring Boot 官方在 GitHub Issue（#38742）中已經說明了 Undertow 面臨的核心問題是維護團隊資源不足與迭代效率低下：

• 團隊規模問題：Undertow 核心維護者僅 3-5 人，且近年來存在人員流失情況，導致 2023-2024 年期間，核心功能迭代周期從平均 2 個月延長至 6 個月以上；
• 適配成本過高：為使 Undertow 兼容 Spring Boot 3.x 的 Jakarta EE 9+、AOT 編譯等新特性，Spring Boot 團隊額外投入了 30% 的兼容性測試資源，遠超 Tomcat（5%）與 Jetty（8%）的適配成本；
• 社區反饋差異：2024 年 Spring Boot 用戶調查顯示，Undertow 的 “問題反饋響應速度” 評分僅 2.8/5，遠低于 Tomcat 的 4.2/5 與 Jetty 的 3.7/5。
• 性能優勢縮水：通過 JMeter 對 Tomcat10.1.18 與 Undertow 2.3.10.Final 進行性能對比測試，結果相差無幾，可見，在現代 JVM 與服務器優化下，Undertow 的性能優勢已不足以彌補其生態與維護短板。

綜合上述的種種跡象，SpringBoot 4.0 棄用 Undertow 也是意料之中的事。

三、Servlet 6.1 技術特性

Servlet 6.1 作為 Jakarta EE 生態系統中的一次重要更新，該版本針對現代應用需求引入了多項重要且實用的改進。

1. 新增ByteBuffer支持與NIO增強

Servlet 6.1 在ServletInputStream和ServletOutputStream中引入了ByteBuffer支持。這一改進顯著優化了非阻塞I/O (NIO) 的處理能力，允許開發者更高效地處理二進制數據流。在高并發場景下，這能帶來顯著的性能提升，因為ByteBuffer可以更直接地與操作系統的I/O機制交互，減少不必要的數據拷貝。

2. HTTP重定向控制的精細化

開發者現在對 HTTP 重定向擁有了更精細的控制權。不再局限于使用默認的302狀態碼，可以根據業務需求（如永久移動使用301，臨時重定向使用307）設置特定的狀態碼，并且能夠控制重定向響應中是否包含響應體，為實現更符合規范的重定向邏輯提供了便利。

3. 敏感請求頭的安全處理

新增的HttpServlet.isSensitiveHeader方法用于識別如Authorization、Cookie、Forwarded等敏感請求頭。這些被標記為敏感的信息會在處理TRACE請求的響應中被自動排除，有效防止了敏感信息在錯誤跟蹤中意外泄露，提升了應用程序的安全性。

4. HTTP會話管理的擴展

Servlet 6.1 提供了一種新機制，允許應用程序在標準HTTP請求處理之外與HTTP會話進行交互。這對于需要維護會話狀態但又不完全依賴于HTTP請求-響應周期的應用（例如WebSocket端點、服務器推送事件）來說尤為重要，增強了會話管理的靈活性。

5. SecurityManager相關API的移除

為了順應Java SE安全模型的演進，Servlet 6.1 完全移除了對已棄用的Java SecurityManager及相關API的引用。這一變更移除了長期存在的歷史包袱，簡化了安全架構。

6. HTTP/2服務器推送的廢棄

Servlet 6.1 正式廢棄了HTTP/2 Server Push功能。這一決定主要源于該特性在現代Web應用中的實際使用率持續低迷，并且其帶來的復雜性超過了收益。開發者社區已經轉向其他性能優化策略，如資源提示（preload、preconnect）等。

總的來說，Servlet 6.1 是一次務實且面向未來的迭代。它沒有引入顛覆性的概念，而是專注于提升性能以及清理過時功能。

四、架構選型啟示

近 3 年，各種技術大 V 紛紛鼓吹 Undertow，并各種博人眼球，致使 Undertow 風靡一時，多數企業跟風決策，在生產環境上換下了使用多年的 Tomcat。

然后短短 3 年，Undertow 因各種原因跟不上時代的步伐，反而又成了升級的路上需要替換和解決的問題。

通過這一事件告訴我們，架構的選型更多的是在于長期穩定，而不是一時的好壞。生態的完整性與兼容性遠大于局部性能的優勢。