1. 项目概述为什么需要动Spring Boot的内置Tomcat做Java Web开发尤其是用Spring Boot的几乎没人不知道它内置了Tomcat。这种“开箱即用”的便利性是Spring Boot快速风靡的重要原因之一。你新建一个项目SpringBootApplication一加main方法里SpringApplication.run()一调一个内嵌了Web容器的应用就跑起来了根本不用你操心去下载、安装、配置一个外部的Tomcat。这背后其实就是Spring Boot通过spring-boot-starter-web这个Starter帮你把Tomcat作为默认的嵌入式Servlet容器打包进来了。但是这个“默认”有时候就成了问题。我遇到过好几次不得不去修改这个内置Tomcat版本的情况。最常见的有这么几种安全漏洞修复这是最刚需、最紧急的场景。比如Apache官方发布了某个Tomcat版本的安全公告修复了一个高危的远程代码执行漏洞。你的线上服务用的Spring Boot版本锁定的Tomcat版本恰好中招了你等不及Spring Boot社区发布新版本这通常有滞后就必须手动升级Tomcat依赖。特性需求新版本的Tomcat可能支持了HTTP/2的某个关键特性、对WebSocket有性能优化或者提供了你急需的某个配置项。而项目因为其他依赖兼容性问题暂时无法整体升级Spring Boot版本就只能单独升级Tomcat。兼容性调整你的应用需要部署到一个已有环境中该环境标准化了某个特定版本的Tomcat比如Tomcat 8.5.x。为了保持环境一致性减少因容器版本差异导致的诡异问题需要将本地开发的Spring Boot内置Tomcat版本与之对齐。性能调优与问题规避某些Tomcat版本可能存在已知的性能瓶颈或Bug在特定流量模式下会触发。通过升级或降级到一个更稳定的版本是直接的解决方案。所以修改内置Tomcat版本不是一个炫技的操作而是一个Spring Boot开发者应该掌握的、应对实际生产问题的必备技能。它意味着你从框架的“使用者”向“掌控者”迈进了一步能更灵活地应对各种环境约束和突发状况。2. 核心原理Spring Boot如何管理Tomcat依赖在动手改之前我们必须先搞清楚Spring Boot是怎么把Tomcat“装”进去的这样改起来才能心中有数不至于盲目操作。2.1 依赖传递的链条一切始于spring-boot-starter-web。当你把它加到pom.xml里Maven或Gradle就会引入一串传递依赖。关键链条如下spring-boot-starter-web依赖于spring-boot-starter-tomcat。spring-boot-starter-tomcat依赖于tomcat-embed-core、tomcat-embed-el、tomcat-embed-websocket等几个核心的嵌入式Tomcat构件。这些tomcat-embed-*的版本由spring-boot-dependencies这个“超级POM”统一管理。这个文件定义了Spring Boot这个版本所兼容的所有第三方库的版本号。你可以通过一个命令来直观地查看这个依赖树mvn dependency:tree -Dincludesorg.apache.tomcat.embed执行后你会看到类似下面的输出[INFO] com.example:demo:jar:0.0.1-SNAPSHOT [INFO] \- org.springframework.boot:spring-boot-starter-web:jar:2.7.18:compile [INFO] \- org.springframework.boot:spring-boot-starter-tomcat:jar:2.7.18:compile [INFO] - org.apache.tomcat.embed:tomcat-embed-core:jar:9.0.83:compile [INFO] - org.apache.tomcat.embed:tomcat-embed-el:jar:9.0.83:compile [INFO] \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:9.0.83:compile这里清晰地显示当前项目假设Spring Boot 2.7.18使用的嵌入式Tomcat版本是9.0.83。这个9.0.83就是由spring-boot-dependencies-2.7.18.pom文件里定义的属性tomcat.version所控制的。2.2 版本控制的中心spring-boot-dependenciesSpring Boot采用“依赖管理”Dependency Management的方式而非直接声明依赖版本。在你的项目POM中spring-boot-starter-parent或者spring-boot-dependencies的importscope起到了一个“版本目录”的作用。它声明了诸如tomcat.version9.0.83/tomcat.version这样的属性。这意味着在你的项目里你直接引入tomcat-embed-core时不需要写版本号Maven会自动使用父POM或依赖管理中定义的版本。这种设计保证了Spring Boot生态内组件版本的统一性和兼容性。注意这里有一个常见的理解误区。有人以为改Tomcat版本就是去改spring-boot-starter-tomcat的版本这是不对的。spring-boot-starter-tomcat本身只是一个空壳Starter它的版本必须和你的spring-boot-starter-parent版本一致。真正要改的是它背后传递进来的那几个tomcat-embed-*构件的版本。2.3 替换为其他Servlet容器除了修改Tomcat版本有时你可能想彻底换掉Tomcat比如换成Jetty或Undertow。Spring Boot对此提供了无缝支持。原理很简单排除掉spring-boot-starter-tomcat然后引入spring-boot-starter-jetty或spring-boot-starter-undertow即可。Spring Boot的自动配置机制会检测到类路径下的容器类型并为其提供相应的配置。但本文聚焦于“修改版本”即我们仍然使用Tomcat只是改变其版本号。这是更精细化的操作。3. 实操指南三种方法修改Tomcat版本明白了原理我们来上实操。根据不同的构建工具和项目结构主要有以下三种方法。我会以将Tomcat 9.0.x升级到10.1.x为例进行说明降级或切换到其他小版本的操作逻辑完全相同。3.1 方法一Maven项目中使用属性覆盖推荐这是最标准、最清晰的方式适用于大多数使用Maven的Spring Boot项目。步骤确定目标版本首先去 Apache Tomcat官网 或 Maven中央仓库 查看Tomcat的可用版本。注意版本兼容性Tomcat 10.x 及以上版本对应 Servlet 5.0 和 Jakarta EE 9包名从javax.*改为了jakarta.*而 Tomcat 9.x 对应 Servlet 4.0。如果你的项目中有大量直接使用javax.servletAPI的代码盲目升级到10.x会导致编译错误。这里我们假设目标版本是10.1.20。在pom.xml中覆盖属性在你的项目pom.xml文件的properties标签内直接定义或覆盖tomcat.version属性。properties java.version11/java.version !-- 覆盖Spring Boot默认的Tomcat版本 -- tomcat.version10.1.20/tomcat.version /properties就是这么简单。当你声明了这个属性后Maven在解析依赖时会优先使用你项目中定义的属性值而不是父POM中的值。验证依赖运行mvn dependency:tree -Dincludesorg.apache.tomcat.embed命令检查输出。你应该看到所有的tomcat-embed-*依赖版本都变成了10.1.20。[INFO] - org.apache.tomcat.embed:tomcat-embed-core:jar:10.1.20:compile [INFO] - org.apache.tomcat.embed:tomcat-embed-el:jar:10.1.20:compile [INFO] \- org.apache.tomcat.embed:tomcat-embed-websocket:jar:10.1.20:compile处理潜在冲突升级大版本如9.x - 10.x后立即编译项目。如果出现javax.servlet相关类找不到的错误说明你的项目代码或某些第三方依赖尚未迁移到 Jakarta 命名空间。这时你有两个选择选择一推荐暂时放弃升级到Tomcat 10.x退回到Tomcat 9.x的最新版本如9.0.85。安全更新通常也会向后移植到9.x分支。选择二进行Jakarta EE迁移。这涉及修改代码和寻找替代依赖工作量较大需要评估。实操心得在团队项目中务必在pom.xml的变更处添加清晰的注释说明修改版本的原因例如CVE-2023-xxxxx 安全漏洞修复。这能极大提升代码的可维护性。3.2 方法二Gradle项目中的配置对于Gradle项目逻辑类似但配置语法不同。步骤在build.gradle或build.gradle.kts文件中通过ext设置或直接覆盖tomcat.version属性。Groovy DSL (build.gradle):ext { set(tomcat.version, 10.1.20) }Kotlin DSL (build.gradle.kts):extra[tomcat.version] 10.1.20或者你也可以使用更直接的依赖管理块dependencies { implementation(org.springframework.boot:spring-boot-starter-web) { exclude group: org.springframework.boot, module: spring-boot-starter-tomcat } implementation org.apache.tomcat.embed:tomcat-embed-core:10.1.20 implementation org.apache.tomcat.embed:tomcat-embed-el:10.1.20 implementation org.apache.tomcat.embed:tomcat-embed-websocket:10.1.20 }但第一种方式覆盖属性更优雅与Maven逻辑一致是推荐做法。运行./gradlew dependencies --configuration runtimeClasspath | findstr tomcat-embed(Windows) 或./gradlew dependencies --configuration runtimeClasspath | grep tomcat-embed(Linux/Mac) 来验证版本是否已更新。3.3 方法三直接声明依赖并排除默认项备选方案这种方法更“暴力”直接排除掉Starter带来的Tomcat然后显式引入指定版本的Tomcat依赖。它适用于一些复杂的、依赖管理混乱的多模块项目或者当你需要同时使用多个不同版本的同名依赖时这种情况极少。步骤在spring-boot-starter-web依赖中排除spring-boot-starter-tomcat。手动添加指定版本的tomcat-embed-*依赖。dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-web/artifactId exclusions !-- 排除掉默认的Tomcat Starter -- exclusion groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-tomcat/artifactId /exclusion /exclusions /dependency !-- 手动引入指定版本的嵌入式Tomcat -- dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-core/artifactId version10.1.20/version /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-el/artifactId version10.1.20/version /dependency dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-websocket/artifactId version10.1.20/version /dependency注意事项这种方法需要你把所有必要的tomcat-embed-*构件都声明齐全容易遗漏。而且它绕过了Spring Boot的依赖管理未来升级Spring Boot版本时可能需要再次手动调整Tomcat版本以避免冲突。因此除非有特殊情况否则优先推荐使用“属性覆盖法”。4. 版本变更后的验证与测试修改版本不是改个数字就完事了必须经过严格的验证确保应用行为符合预期。4.1 基础启动与功能测试启动应用直接运行SpringApplication的 main 方法或使用mvn spring-boot:run启动应用。观察控制台日志在Spring Boot的Banner之后你应该能看到类似Tomcat initialized with port(s): 8080 (http)的日志并仔细看其版本号是否已变为目标版本如Apache Tomcat/10.1.20。访问端点启动后访问你的应用健康端点如/actuator/health或任何一个业务接口确保HTTP请求能正常接收和响应。检查Actuator端点如果项目引入了spring-boot-starter-actuator可以访问/actuator/env搜索tomcat.version确认运行时使用的版本信息。4.2 深入兼容性测试版本升级尤其是跨大版本可能引入行为变更。需要重点测试以下场景SSL/TLS配置如果你自定义了SSL连接器server.ssl.*配置升级后需测试HTTPS连接是否正常。不同Tomcat版本对协议和密码套件的默认支持可能有差异。WebSocket如果应用使用了WebSocket需要进行完整的连接、通信、断开重连测试。Tomcat的WebSocket实现在不同版本间有改进。文件上传测试大文件上传检查max-http-form-post-size等配置是否依然生效。Tomcat 10对application/x-www-form-urlencoded的处理有优化。自定义Valve或Filter如果你向Tomcat注册了自定义的Valve、Filter或Listener需要验证它们在新的类加载器体系和API下是否正常工作。特别是涉及到javax到jakarta的包名变更。AJP连接器如果使用了AJP协议与前置代理如Nginx、Apache HTTPD通信需要测试AJP连接是否稳定。Tomcat 9以后对AJP的支持有变化。4.3 性能与压力观察在测试环境或预发布环境对修改版本后的应用进行一轮基本的压力测试。可以使用wrk、jmeter或Apache Benchmark工具模拟常规流量观察应用启动时间是否有显著变化。内存占用RSS、Heap趋势是否正常。接口的P99、P95响应时间是否在可接受范围内。查看GC日志确认没有因为版本升级引入异常的GC行为。踩坑记录我曾有一次将Tomcat从9.0.40升级到9.0.50一个看似微小的补丁版本。结果在压测时发现在特定并发下保持长连接的接口响应时间飙升。后来排查发现是该版本修改了NIO连接器处理keep-alive连接的某个超时逻辑与我们的客户端配置不匹配。通过调整server.tomcat.keep-alive-timeout参数解决了问题。所以即使是小版本升级也绝不能忽视测试。5. 常见问题排查与解决方案实录在实际操作中你可能会遇到下面这些问题。这里我把自己和团队踩过的坑及解决方案整理出来希望能帮你快速排雷。5.1 问题一版本覆盖不生效现象在pom.xml中明明定义了tomcat.version10.1.20/tomcat.version但dependency:tree显示的还是旧版本。排查思路检查父POM或依赖管理确认你的项目是否继承了其他的父POM或者通过dependencyManagement导入了其他的BOM如spring-cloud-dependencies。这些地方可能也定义了tomcat.version属性且优先级可能比你项目中的properties更高。Maven属性遵循“就近原则”但依赖管理导入的BOM定义非常强势。你需要找到所有定义该属性的地方。检查属性拼写确保属性名完全一致是tomcat.version不是tomcat-embed.version或其他。执行完整的Maven生命周期有时本地仓库缓存会导致问题。尝试执行mvn clean compile或mvn clean install -U-U强制更新快照和Release版本。使用Maven Help插件运行mvn help:effective-pom查看合并后的“有效POM”在生成的XML文件中搜索tomcat.version看最终生效的值是什么。解决方案如果发现是其他BOM覆盖了你的属性你可以在你的pom.xml中在引入该BOM的dependencyManagement部分之后再次声明tomcat.version属性。或者在该BOM的properties部分进行覆盖如果它是你项目自己的父POM。5.2 问题二类冲突或NoSuchMethodError现象应用启动失败报NoSuchMethodError、NoClassDefFoundError或ClassNotFoundException通常涉及javax.servlet或org.apache.tomcat下的类。原因分析这是典型的依赖冲突。可能的原因有你手动添加的Tomcat依赖版本与Spring Boot其他模块如spring-boot-starter-tomcat里未排除干净的部分传递过来的版本不一致。项目中其他依赖例如某些旧的第三方库自身捆绑了特定版本的Tomcat API如servlet-api.jar造成了冲突。排查与解决分析依赖树使用mvn dependency:tree -Dverbose命令。-Dverbose参数会显示冲突信息重点关注冲突的jar包。搜索omitted for conflict这样的字眼。定位冲突来源找到冲突的jar包后查看是哪个依赖引入的。使用mvn dependency:tree -Dincludes冲突的groupId:artifactId来追踪。排除冲突依赖在引入该冲突依赖的地方使用exclusions标签将其排除。dependency groupIdproblematic.group/groupId artifactIdproblematic-artifact/artifactId versionxxx/version exclusions exclusion groupIdorg.apache.tomcat/groupId artifactIdtomcat-embed-core/artifactId !-- 示例 -- /exclusion /exclusions /dependency统一版本终极方案如果项目结构复杂冲突众多可以在dependencyManagement中强制统一所有相关依赖的版本。但这需要全面测试确保强制指定的版本与其他组件兼容。5.3 问题三应用启动变慢或内存占用异常现象升级Tomcat后应用启动时间明显变长或者运行一段时间后内存持续增长。排查方向检查新版本默认配置不同Tomcat版本的线程池server.tomcat.threads.max等、连接器NIO, APR、Session超时等默认配置可能不同。查阅官方发行说明Release Notes看是否有相关变更。对比升级前后的application.yml/properties配置确保你的自定义配置在新版本下依然合理。分析线程堆栈使用jstack pid命令或在VisualVM等工具中查看线程状态检查是否有线程阻塞或死锁特别是与类加载、连接器初始化相关的线程。内存Dump分析如果内存持续增长使用jmap -dump:live,formatb,fileheap.bin pid生成堆转储文件然后用MAT或JProfiler等工具分析查看是否存在由新版本Tomcat类或对象引起的内存泄漏。回顾升级跨度如果你是从一个很旧的版本如Tomcat 8.5直接升级到9.x或10.x架构变化较大建议先升级到一个中间版本如8.5 - 9.0.x - 10.1.x分步测试更容易定位问题。5.4 问题四特定功能失效如WebSocket、JSP现象升级后WebSocket连接失败或者JSP页面无法编译渲染。解决方案对于WebSocket确保你引入了正确版本的tomcat-embed-websocketjar包。Tomcat 7及以后版本将WebSocket实现移到了独立的模块中。检查依赖树确认其版本与tomcat-embed-core一致。对于JSPSpring Boot默认不推荐使用JSP。如果你确实在使用需要确保引入了tomcat-embed-jasper依赖并且其版本与Tomcat核心版本匹配。同样在pom.xml中通过属性tomcat.version统一管理是最佳实践。dependency groupIdorg.apache.tomcat.embed/groupId artifactIdtomcat-embed-jasper/artifactId !-- 版本由 tomcat.version 属性控制 -- scopeprovided/scope !-- 通常建议用provided编译和测试时需要打包时容器提供 -- /dependency同时检查JSP编译引擎相关的配置如server.jsp-servlet.init-parameters.*是否仍然有效。6. 进阶考量版本策略与持续集成对于企业级项目修改基础组件版本不能是“一次性”的随意操作需要纳入研发流程进行管理。1. 版本锁定与BOM使用对于多模块的微服务项目建议建立一个统一的“基础设施BOM”Bill of Materials项目。在这个BOM的dependencyManagement中集中定义所有中间件和核心库的版本包括tomcat.version。所有业务服务都继承或导入这个BOM。这样升级Tomcat版本只需修改BOM一处所有服务在下次构建时自动同步确保了整个技术栈版本的一致性。2. 在CI/CD流水线中集成验证在持续集成CI阶段除了单元测试应增加针对Servlet容器版本的集成测试环节。可以编写简单的Smoke Test冒烟测试用例在构建完成后自动启动应用并对关键接口如健康检查、登录、核心业务API发起HTTP请求验证基本功能。这能第一时间发现因版本升级导致的启动失败或基础功能异常。3. 建立版本升级检查清单团队内部应维护一份《Tomcat及其他核心组件版本升级检查清单》每次升级时对照执行。清单内容应包括[ ] 查阅官方Release Notes和安全公告。[ ] 评估升级必要性安全漏洞、功能需求、性能提升。[ ] 在独立分支进行版本修改。[ ] 执行完整的自动化测试套件单元、集成、API。[ ] 进行基础性能基准测试与旧版本对比。[ ] 在预发布/沙箱环境进行至少一个业务周期的验证。[ ] 更新项目文档和BOM中的版本号。[ ] 制定和演练回滚方案。4. 关于“国产中间件替换”的思考网络热词中提到了“spring boot 中tomcat替换成国产中间件宝蓝德”。这引申出一个更深层次的话题替换内置容器。Spring Boot的抽象设计使得替换Tomcat为Jetty、Undertow或其他兼容Servlet规范的容器包括一些国产容器在技术上是可行的通常只需替换Starter依赖。但实际操作前必须进行极其详尽的兼容性测试和性能压测因为不同容器在实现细节、线程模型、内存管理、对特定协议如HTTP/2、WebSocket的支持上存在差异这些差异可能在高压或边缘场景下导致截然不同的行为。除非有强烈的信创或特定生态要求否则在成熟的开源容器中进行选择是风险更低的方案。如果确需替换建议将其作为一个独立的、周期较长的技术调研项目来推进而非简单的依赖替换。