官宣：SpringBoot4 弃用 Undertow，Tomcat 笑了

一、前言

就在 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 因各种原因跟不上时代的步伐，反而又成了升级的路上需要替换和解决的问题。

通过这一事件告诉我们，架构的选型更多的是在于长期稳定，而不是一时的好坏。生态的完整性与兼容性远大于局部性能的优势。

架构设计之道在于在不同的场景采用合适的架构设计，架构设计没有完美，只有合适。
在代码的路上，我们一起砥砺前行。用代码改变世界！

• 工作 3 年还在写 CRUD，无法突破技术瓶颈？
• 想转技术管理但不会带团队？
• 想跳槽没有面试的机会？
• 不懂如何面试，迟迟拿不到 offer？
• 面试屡屡碰壁，失败原因无人指导？
• 在竞争激烈的大环境下，只有不断提升核心竞争力才能立于不败之地。

欢迎从事编程开发、技术招聘 HR 进群，欢迎大家分享自己公司的内推信息，相互帮助，一起进步！

—— 斩获心仪Offer，破解面试密码 ——