SpringBoot4.0弃用Undertow：性能王者的落幕

前言Tomcat笑麻了Jetty默默上位Undertow用户哭了最近在帮一个团队做Spring Boot 4.0升级评估的时候发现了一个让他们措手不及的问题。“我们项目里用的Undertow升级到Spring Boot 4.0之后直接启动不了了报错说找不到Undertow的实现类。这是什么情况”我一看报错信息心里就有数了——Spring Boot 4.0正式移除了对Undertow的支持。这个小伙伴当场就懵了。“Undertow不是号称性能最好的嵌入式容器吗Spring为什么要抛弃它”这个问题问得很到位。今天这篇文章我就把Spring Boot 4.0弃用Undertow的前因后果、底层原因、迁移方案从头到尾给你拆解一遍。希望对你会有所帮助。一、Undertow是怎么“上位”的在聊弃用之前我们先花2分钟回顾一下Undertow是怎么进入Spring Boot生态的。Spring Boot从很早就支持三种嵌入式Web容器Tomcat默认——Apache出品生态最成熟Spring Boot的亲儿子Jetty——Eclipse基金会出品轻量灵活在某些场景下表现优异Undertow——Red Hat出品号称低内存占用、高并发吞吐、天然支持持久连接Undertow之所以能进入Spring Boot的可选列表靠的是它的性能优势。在高并发场景下Undertow的内存占用比Tomcat低、吞吐量更高因此吸引了不少追求极致性能的企业项目。但是成也性能败也规范。二、为什么Spring Boot 4.0要弃用Undertow有些小伙伴可能会说“Undertow性能这么好Spring团队为什么要抛弃它这不是自断一臂吗”这个问题的答案不在Spring团队身上在Servlet规范身上。2.1 根本原因Servlet 6.1不兼容Spring Boot 4.0基于Spring Framework 7构建强制依赖Servlet 6.1规范。而Undertow尚未适配Servlet 6.1。Spring团队在官方文档中明确说明了移除Undertow支持的技术原因“Spring Boot 4.0需要一个Servlet 6.1的基线而Undertow目前尚不兼容。因此我们放弃了对Undertow的支持。”这不是Spring团队的主观决策而是技术生态演进的必然结果。2.2 深层次原因Red Hat投入有限Undertow的主要维护方是Red Hat。而Red Hat对该项目的投入相对有限导致Undertow无法及时跟进新规范。在相关讨论中Undertow团队成员表示Servlet 6.1的支持工作已经启动但截至2025年10月该工作仍处于早期阶段。Spring Boot团队在GitHub上创建了专门的Issue#46917来跟踪这一变更。在Issue中团队指出Undertow尚未适配Servlet 6.1且其维护团队资源不足、迭代效率低Spring Boot团队已无法承担过高的适配成本。简单说就是我等了你很久但你一直跟不上我只能先走了。2.3 还有一些“隐情”社区活跃度差距除了技术兼容性问题还有一些不那么“官方”的原因Undertow社区相对较小文档、学习资料等方面都不如Tomcat、Jetty丰富对传统Servlet模型的支持不够完善Red Hat的资源重心可能在其他项目上三、Servlet 6.1到底带来了什么变化有些小伙伴可能会问“Servlet 6.1到底有什么新东西值得Spring Boot这么大动干戈”Servlet 6.1于2024年4月作为Jakarta EE 11的核心子规范发布。相比Servlet 6.0它带来了多项重要改进① ByteBuffer支持在ServletInputStream和ServletOutputStream中新增了ByteBuffer支持显著改进了非阻塞I/O能力。// 使用 ByteBuffer 读取请求数据 ByteBuffer buffer ByteBuffer.allocate(1024); servletInputStream.read(buffer);② HTTP/2推送功能废弃Servlet 6.1正式废弃了HTTP/2 Server Push支持。这个功能在现代Web应用中使用率持续下降。③ 移除SecurityManager相关API完全删除了对已废弃的Java SecurityManager及相关API的引用。④ HTTP会话增强机制提供了新机制让应用程序能在标准HTTP请求处理之外与HTTP会话交互特别是为WebSocket场景提供了更好的支持。⑤ HTTP重定向控制增强开发者现在对发出HTTP重定向时的状态码和响应体拥有更精细的控制权。⑥ 敏感请求头安全处理新增了HttpServlet.isSensitiveHeader方法用于识别需要保护的敏感请求头。四、对现有项目的影响升级必看如果你的项目当前使用了Undertow升级到Spring Boot 4.0后会遇到什么问题4.1 典型报错如果项目中包含以下依赖dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-undertow/artifactId /dependency升级到Spring Boot 4.0后项目将无法启动并抛出类似错误Caused by: java.lang.IllegalStateException: Unable to find Undertow-based WebServer implementation.4.2 三大风险点风险项说明启动失败缺少Undertow实现类应用无法启动配置失效server.undertow.*配置被完全忽略性能回退切换容器后需要重新压测和调优五、迁移方案如何平滑过渡别慌。Spring Boot 4.0仍然支持两种嵌入式Web容器迁移并不复杂。5.1 方案一切换回Tomcat最推荐Tomcat是Spring Boot的默认容器生态成熟、文档丰富且在Spring Boot 4中已全面适配Servlet 6.1。步骤1移除Undertow依赖!-- 删除以下依赖 -- !-- dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-undertow/artifactId /dependency --步骤2显式添加Tomcat通常无需添加spring-boot-starter-web已经默认包含了Tomcatdependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /dependency步骤3转换配置将server.undertow.*配置转换为server.tomcat.*# 旧配置Undertow server: undertow: io-threads: 4 worker-threads: 20 buffer-size: 1024 # 新配置Tomcat server: tomcat: threads: max: 200 min-spare: 10 max-connections: 81925.2 方案二改用JettyJetty同样支持Servlet 6.1在某些I/O密集型场景下表现优异。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-jetty/artifactId /dependency注意需要排除Tomcat依赖避免冲突dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency5.3 Spring Boot 4.0支持的容器版本Spring Boot 4.0对嵌入式Web容器的支持如下容器版本要求Servlet规范支持状态Tomcat11.0.xServlet 6.1✅ 支持Jetty12.1.xServlet 6.1✅ 支持Undertow——❌已移除六、一张图看懂完整的变更七、优缺点Spring Boot 4.0移除Undertow的“好处”1. 规范对齐技术栈更清晰Spring Boot 4.0强制依赖Servlet 6.1只保留兼容的容器减少了技术栈的混乱。2. 减少维护负担Spring Boot团队不再需要为Undertow维护兼容层可以集中精力在核心功能上。3. 推动生态向前这一决策倒逼Undertow社区加快适配Servlet 6.1的步伐。4. 与Jakarta EE 11对齐Spring Boot 4.0全面升级至Jakarta EE 11只保留兼容的容器是合理的架构决策。对开发者的“代价”1. 迁移成本使用Undertow的项目需要切换到Tomcat或Jetty并重新配置和调优。2. 性能不确定性如果之前是因为Undertow的性能优势才选择的它切换到其他容器后可能需要重新压测和调优。3. 配置需要重写server.undertow.*配置全部失效需要转换为Tomcat或Jetty的配置格式。4. 短期内的阵痛对于深度依赖Undertow特性的项目迁移可能需要一定的开发时间。八、适用场景与建议如果你在用Undertow场景建议正准备升级到Spring Boot 4.0先切换到Tomcat或Jetty再执行升级尚未升级还在Spring Boot 3.x可以继续用Undertow但建议开始规划迁移新项目从零开始直接用Tomcat默认或Jetty别碰Undertow选Tomcat还是Jetty对比维度TomcatJetty生态成熟度⭐⭐⭐⭐⭐⭐⭐⭐⭐文档丰富度⭐⭐⭐⭐⭐⭐⭐⭐⭐默认支持✅ 默认❌ 需手动引入I/O密集型⭐⭐⭐⭐⭐⭐⭐⭐⭐企业级特性⭐⭐⭐⭐⭐⭐⭐⭐⭐我的建议大部分项目直接切回Tomcat就行因为它是Spring Boot的默认容器生态最成熟、文档最丰富。如果你的应用是I/O密集型的可以考虑Jetty。九、写在最后回到最初的问题Spring Boot 4.0为什么要弃用Undertow答案很清晰——不是Spring团队不待见Undertow而是Undertow跟不上Servlet规范的演进速度。Spring Boot 4.0强制依赖Servlet 6.1而Undertow尚未适配。Red Hat对Undertow的投入有限导致其无法及时跟进新规范。Spring Boot团队已经等了很久但等不下去了。Undertow会被永久抛弃吗不一定。只要Undertow未来支持Servlet 6.1Spring Boot仍有可能恢复对其支持。Undertow团队已经在2025年10月发布了2.4.0.Alpha1开始实现Jakarta Servlet 6.1。但问题是——什么时候能正式支持没有人知道确切的时间表。对于正在做技术选型或准备升级的团队来说等待Undertow适配不是一个明智的选择。我的建议是如果你正在使用Undertow建议尽快规划迁移到Tomcat或Jetty。尤其是新项目直接用TomcatSpring Boot默认是最省心的选择。