對于正在使用 Undertow 的企業(yè)和開發(fā)者而言，這一變更意味著項目升級到 Spring Boot 4.0 時必須進行 Web 容器的遷移。這篇文章將深入分析這一變更背后的技術(shù)原因，以及相關(guān)的技術(shù)標準和生態(tài)演進。

在 Spring Boot 4.0 中，如果項目中包含以下依賴：

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-undertow</artifactId>
</dependency>

構(gòu)建過程將會失敗，因為 Spring Boot 4.0 已不再包含 Undertow 相關(guān)的自動配置和依賴管理。

Spring 團隊在 GitHub 上創(chuàng)建了專門的 Issue (#46917) 來跟蹤這一變更，確保決策過程的透明度和可追溯性。

Spring 團隊在官方文檔中明確說明了移除 Undertow 支持的技術(shù)原因：

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

這一聲明清晰地指出了問題核心：版本依賴的不匹配。這是一個技術(shù)兼容性問題，而非技術(shù)路線選擇或性能優(yōu)劣的判斷。

在相關(guān)討論中，Undertow 團隊成員表示 Servlet 6.1 的支持工作已經(jīng)啟動，但截至2025年10月，該工作仍處于早期階段。

作為 Undertow 的主要維護者，Red Hat 的開發(fā)進度相對緩慢，這對于需要升級到 Spring Boot 4.0 的企業(yè)而言，提供了有限的選擇空間。

Servlet 6.1 技術(shù)特性解析

發(fā)布背景

Servlet 6.1 于2024年4月作為 Jakarta EE 11 的核心子規(guī)范發(fā)布。相比 Servlet 6.0，這一版本帶來了多項重要改進和現(xiàn)代化更新，代表了 Java Web 開發(fā)標準的重要演進。

核心新特性

1. ByteBuffer 支持

在 ServletInputStream 和 ServletOutputStream 中新增了 ByteBuffer 支持，顯著改進了非阻塞 I/O (NIO) 能力。這一改進使開發(fā)者能夠更高效地處理二進制數(shù)據(jù)流，特別是在高并發(fā)場景下能夠獲得顯著的性能提升。

// 使用 ByteBuffer 讀取請求數(shù)據(jù)
ByteBuffer buffer = ByteBuffer.allocate(1024);
servletInputStream.read(buffer);

2. HTTP/2 推送功能廢棄

Servlet 6.1 正式廢棄了 HTTP/2 Server Push 支持。這一決定反映了該特性在現(xiàn)代 Web 應(yīng)用中使用率持續(xù)下降的現(xiàn)狀，開發(fā)者更傾向于使用其他優(yōu)化策略。HTTP/2 Server Push 成為了 HTTP 歷史上最短命的重要功能之一。

3. 移除 SecurityManager 相關(guān) API

完全刪除了對已廢棄的 Java SecurityManager 及相關(guān) APIs 的引用，以適應(yīng) Java SE 安全模型的演進。這一變更簡化了安全架構(gòu)，移除了歷史包袱。

4. HTTP 會話增強機制

提供了新機制，讓應(yīng)用程序能在標準 HTTP 請求處理之外與 HTTP 會話交互，特別是為 WebSocket 場景提供了更好的支持，增強了會話管理的靈活性。

5. HTTP 重定向控制增強

開發(fā)者現(xiàn)在對發(fā)出 HTTP 重定向時的狀態(tài)碼和響應(yīng)體擁有更精細的控制權(quán)，可以實現(xiàn)更符合業(yè)務(wù)需求的重定向邏輯。

// 自定義重定向響應(yīng)
response.setStatus(HttpServletResponse.SC_MOVED_PERMANENTLY);
response.setHeader("Location", newUrl);
response.getWriter().write("Resource has moved");

6. 敏感請求頭安全處理

新增 HttpServlet.isSensitiveHeader 方法，用于識別需要保護的敏感請求頭（如 Authorization、Cookie、Forwarded 等）。這些敏感信息會在 TRACE 方法響應(yīng)中被排除，顯著提高了應(yīng)用程序的安全性。

7. 條件 GET 優(yōu)化支持

改進了對條件 GET 操作的支持，通過 getLastModified 方法優(yōu)化網(wǎng)絡(luò)資源利用，減少不必要的數(shù)據(jù)傳輸，提升了網(wǎng)絡(luò)效率和響應(yīng)速度。

Jakarta EE 11 技術(shù)規(guī)范

規(guī)范背景

Jakarta EE 11 是企業(yè)級 Java 平臺的最新標準，其中 Servlet 6.1 是其核心子規(guī)范。Jakarta EE 11 代表了企業(yè)級 Java 應(yīng)用的標準化演進，為現(xiàn)代企業(yè)應(yīng)用開發(fā)提供了統(tǒng)一的技術(shù)框架。

Jakarta Data 規(guī)范詳解

Jakarta EE 11 通過引入 Jakarta Data 規(guī)范 來簡化企業(yè)應(yīng)用的持久化邏輯。Jakarta Data 為數(shù)據(jù)訪問層提供了標準化的抽象，顯著減少了樣板代碼的編寫。

核心特性

1. BasicRepository 基礎(chǔ)倉庫接口

public interface ProductRepository extends BasicRepository<Product, Long> {
    // 自動獲得基礎(chǔ) CRUD 操作：save(), findById(), findAll(), delete()
}

BasicRepository 提供了開箱即用的基本數(shù)據(jù)操作支持，大幅減少了樣板代碼的編寫和配置工作。

2. CrudRepository 完整 CRUD 功能

public interface UserRepository extends CrudRepository<User, String> {
    List<User> findByEmailContaining(String email);
    Page<User> findByStatus(UserStatus status, PageRequest page);
}

在 BasicRepository 的基礎(chǔ)上，CrudRepository 提供了完整的創(chuàng)建、讀取、更新、刪除功能，支持復(fù)雜的查詢方法。

3. Pagination 分頁支持

// 基于偏移量的分頁
Page<Product> findByCategory(String category, PageRequest pageRequest);

CursoredPage<Product> findByPriceGreaterThan(
    BigDecimal price, 
    PageRequest pageRequest
);

Jakarta Data 同時支持基于偏移量和基于游標的分頁方式，為不同場景提供了靈活的數(shù)據(jù)訪問模式。游標分頁在大數(shù)據(jù)集處理方面具有顯著的性能優(yōu)勢。

4. Query Language 查詢語言

public interface OrderRepository extends CrudRepository<Order, Long> {
    @Query("SELECT o FROM Order o WHERE o.status = ?1 AND o.total > ?2")
    List<Order> findHighValueOrders(OrderStatus status, BigDecimal minTotal);
}

引入的簡潔查詢語言簡化了方法級查詢的定義，比原生 SQL 更加簡潔，比方法名查詢更加清晰。

主流 Web 容器支持現(xiàn)狀對比

兼容性矩陣分析

以下表格展示了各主流 Web 容器和框架對 Servlet 6.1 和 Jakarta EE 11 的支持情況：

從兼容性矩陣中可以清晰看出，Undertow 是唯一尚未支持 Servlet 6.1 的主流 Web 容器，這也是 Spring Boot 4.0 移除對其支持的根本原因。

04ySqd

有趣的是,就在前兩年,技術(shù)社區(qū)還掀起過一股"用 Undertow 替代 Tomcat"的熱潮。各路技術(shù)大 V 紛紛發(fā)文推薦 Undertow,理由包括:

? 更輕量級的內(nèi)存占用：啟動更快,資源消耗更少

? 更優(yōu)秀的并發(fā)性能：基于 XNIO 的非阻塞 I/O 模型

? 更靈活的配置：可編程的服務(wù)器配置方式

許多企業(yè)和開發(fā)者響應(yīng)號召,在生產(chǎn)環(huán)境中大規(guī)模采用了 Undertow。Spring Boot 官方文檔也一直將 Undertow 列為與 Tomcat、Jetty 并列的三大推薦 Web 容器之一。

然而，時過境遷，當 Jakarta EE 和 Servlet 規(guī)范快速演進時,Undertow 的更新速度卻明顯跟不上節(jié)奏。昔日的"性能之選"如今卻成了"升級絆腳石"。

這個教訓(xùn)告訴我們：技術(shù)選型不應(yīng)該只看當下的性能指標,更要考慮生態(tài)的活躍度和長期演進能力。有時候,"穩(wěn)健的主流"比"激進的最優(yōu)"更值得信賴。