一、前言就在 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 会在如今被弃用呢二、为何弃用 UndertowSpring 在官方文档中已经明确解释了移除 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% 的兼容性测试资源远超 Tomcat5%与 Jetty8%的适配成本**社区反馈差异**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 因各种原因跟不上时代的步伐反而又成了升级的路上需要替换和解决的问题。通过这一事件告诉我们架构的选型更多的是在于长期稳定而不是一时的好坏。生态的完整性与兼容性远大于局部性能的优势。 福利时间如果你正在备战大厂面试我整理了一个开发者的知识库涵盖 Java 程序员需要掌握的核心知识。知识库地址https://farerboy.com/
官宣：SpringBoot4 弃用 Undertow，Tomcat 笑了
发布时间：2026/5/19 10:16:11
一、前言就在 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 会在如今被弃用呢二、为何弃用 UndertowSpring 在官方文档中已经明确解释了移除 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% 的兼容性测试资源远超 Tomcat5%与 Jetty8%的适配成本**社区反馈差异**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 因各种原因跟不上时代的步伐反而又成了升级的路上需要替换和解决的问题。通过这一事件告诉我们架构的选型更多的是在于长期稳定而不是一时的好坏。生态的完整性与兼容性远大于局部性能的优势。 福利时间如果你正在备战大厂面试我整理了一个开发者的知识库涵盖 Java 程序员需要掌握的核心知识。知识库地址https://farerboy.com/
