1. 项目缘起为什么SpringBoot内置Tomcat也需要调优很多刚接触SpringBoot的朋友可能会有个误解既然SpringBoot主打“约定大于配置”内置了Tomcat那是不是意味着我们完全不用管它让它自己跑就行了我刚开始也是这么想的直到线上服务在某个促销活动日流量稍微一上来就出现了响应缓慢、连接超时甚至直接抛出Connection refused的错误。一查日志满屏的java.net.SocketException: Too many open files和线程池耗尽的警告。这才让我意识到SpringBoot的“开箱即用”是为了让你快速启动但“用好”和“用稳”完全是另一回事。内置的Tomcat默认配置是为开发环境设计的它假设你的应用只是个简单的Demo并发低、数据量小。一旦部署到生产环境面对真实的用户请求和业务压力这些默认参数就成了性能瓶颈和稳定性的“定时炸弹”。所以今天我们就来彻底拆解一下SpringBoot内置Tomcat的参数调优。这不是一个简单的“抄参数”过程而是一个理解Tomcat在SpringBoot中如何工作、每个核心参数背后的意义以及如何根据你的实际业务场景是CPU密集型计算还是IO密集型等待是高并发短连接还是长连接保活进行针对性调整的系统性工程。调优的目标很明确在有限的硬件资源下让你的应用支撑更高的并发、拥有更快的响应速度、保持更稳定的服务状态。我们会从连接器Connector、线程池、JVM内存等多个维度结合配置、监控和压测把这件事讲透。2. 核心组件解析SpringBoot中的Tomcat是如何运作的在动手调参之前我们必须先搞清楚SpringBoot内置的Tomcat和我们独立部署的Tomcat有什么不同以及它的核心组件是如何被SpringBoot封装和管理的。这决定了我们调优的入口和方式。2.1 嵌入式Servlet容器从TomcatServletWebServerFactory说起当你使用spring-boot-starter-web依赖时SpringBoot会自动引入嵌入式Tomcat。这个“嵌入式”的关键在于TomcatServletWebServerFactory这个类。SpringBoot在启动时会通过这个工厂类来创建、配置并启动一个Tomcat实例。这意味着我们不再有一个外部的server.xml文件来配置Tomcat所有的配置都通过SpringBoot的配置属性application.properties或application.yml或编程式配置WebServerFactoryCustomizer来完成。这种模式带来了便利也带来了认知上的隔阂。你不需要关心Tomcat的安装目录、bin文件夹下的脚本但你必须知道SpringBoot将Tomcat的哪些核心概念映射成了哪些配置项。例如Tomcat中的Connector连接器、Executor线程池在SpringBoot中都有对应的配置前缀通常是server.tomcat。2.2 连接器Connector与协议HTTP/1.1、HTTP/2与APRTomcat处理请求的入口是连接器。SpringBoot默认会创建一个基于Java NIO的HTTP/1.1连接器。这里有几个关键点NIO vs BIO现在早已不是BIO阻塞式IO的时代了。NIO非阻塞IO是默认且唯一推荐的选择。它用一个或少量线程Acceptor处理连接接入用另一组线程Poller处理Socket的读写事件最后由工作线程Worker处理业务逻辑。这种模型可以轻松应对成千上万的并发连接而不会为每个连接都创建一个线程极大地节省了系统资源。HTTP/2如果你的应用主要服务于现代浏览器并且希望提升页面加载性能多路复用、头部压缩等可以考虑启用HTTP/2。在SpringBoot中配置server.http2.enabledtrue即可。但请注意HTTP/2通常需要TLSHTTPS并且对客户端有一定要求。APR/Native这是Tomcat的一种高性能运行模式通过Apache Portable Runtime库使用本地代码来处理连接和SSL性能理论上比纯Java NIO更高尤其是在处理静态资源和SSL握手时。但在SpringBoot嵌入式环境中集成和调试APR相对复杂且增益不一定在所有场景下都明显对于大多数Java应用优化好NIO模式已经足够。因此除非你有明确的性能瓶颈且经过测试证实APR能带来显著提升否则不建议在SpringBoot中折腾APR。理解这些基础我们就能明白接下来的调优主要就是针对这个NIO连接器及其相关组件进行“精细化手术”。3. 连接器Connector参数深度调优连接器参数直接决定了Tomcat处理网络请求的能力和方式。这些参数配置在application.yml中以server.tomcat为前缀。3.1 核心参数max-connections,accept-count,max-threads这是调优的“黄金三角”理解它们的关系是重中之重。我画一个简单的类比Tomcat就像一个银行。max-connections最大连接数相当于银行大厅的总容量。它表示Tomcat能同时接收并保持的TCP连接数包括正在处理的、以及排队等待的。超过这个数新的连接请求会被直接拒绝。对应配置server.tomcat.max-connections。这个值受限于操作系统文件描述符限制ulimit -n一定要设置得比系统限制小并留有余地。max-threads最大工作线程数相当于银行的柜台窗口数量。它决定了同一时刻最多有多少个请求可以被分配到工作线程进行业务处理比如执行你的RestController方法。对应配置server.tomcat.threads.max。accept-count等待队列长度相当于银行大厅里的等候座椅数量。当所有柜台max-threads都忙但大厅还没满max-connections未超时新来的请求会在这个队列里排队等待。对应配置server.tomcat.accept-count。它们的关系是max-connectionsmax-threadsaccept-count。通常max-connections会设置得比后两者之和大一些以容纳一些保持连接但暂时空闲的请求如HTTP Keep-Alive。如何设置max-threads这是核心。默认是200。设置太小CPU利用不足设置太大线程上下文切换开销剧增反而降低性能。一个经典的计算起点是线程数 CPU核心数 * (1 平均等待时间 / 平均计算时间)。对于典型的Web应用IO等待较多可以设置为CPU核心数的2~4倍。例如4核机器可以从800开始测试。务必通过压测工具如JMeter来寻找最佳值观察CPU利用率和响应时间曲线。server: tomcat: threads: max: 800 # 根据压测调整 min-spare: 50 # 最小空闲线程数避免突发流量时临时创建线程的开销accept-count默认是100。这个队列不宜过长。队列中的请求也在消耗连接资源且用户感知为等待。如果队列经常满说明你的max-threads可能不足或者业务处理太慢。通常设置为max-threads的1/2到1倍即可。server: tomcat: accept-count: 400max-connections默认值因版本而异如8192。你需要确保它大于max-threads accept-count并小于系统的文件描述符限制。可以设置为(max-threads accept-count) * 1.2。server: tomcat: max-connections: 1200 # (800400)*1.23.2 连接超时与Keep-Aliveconnection-timeout连接超时时间。这不是请求处理超时而是TCP连接建立后等待接收到请求数据的超时时间。默认值通常较大如20秒。对于公网服务可以适当调小比如5-10秒以避免恶意连接或网络异常占满连接资源。server: tomcat: connection-timeout: 10000 # 10秒单位毫秒Keep-AliveHTTP持久连接允许一个TCP连接上发送多个请求减少握手开销。但连接保持太久会占用max-connections。需要平衡。server: tomcat: # 保持连接的超时时间毫秒超时后关闭 keep-alive-timeout: 15000 # 15秒 # 一个连接上最多处理的请求数达到后关闭连接防止某些客户端滥用 max-keep-alive-requests: 2003.3 其他重要参数max-http-form-post-sizePOST表单内容的最大大小。默认2MB。如果你的应用有文件上传等大表单需求需要调大此值同时要结合Spring Boot的spring.servlet.multipart.max-file-size和max-request-size一起配置。server: tomcat: max-http-form-post-size: 10MB spring: servlet: multipart: max-file-size: 10MB max-request-size: 11MBredirect-context-root是否将对上下文根/的请求重定向到/。通常保持默认true即可。use-relative-redirects是否使用相对路径进行重定向。在某些代理环境下可能需要设置为false。4. 内存与资源泄漏防护调优Tomcat本身运行在JVM上因此JVM参数调优是基础。但除此之外Tomcat内部也有一些与内存和行为相关的配置需要关注特别是防止资源泄漏。4.1 JVM基础参数堆内存与垃圾回收这是老生常谈但至关重要的一步。SpringBoot应用通常需要调整JVM启动参数。-Xms和-Xmx设置堆内存初始值和最大值。必须设置为相同值以避免运行时堆内存扩容收缩带来的性能抖动。例如-Xms2g -Xmx2g。大小取决于你的应用内存需求和机器配置。垃圾回收器JDK 8以后G1GC是大多数Web应用的良好选择。可以添加参数-XX:UseG1GC。对于低延迟要求极高的场景可以研究ZGC或Shenandoah但它们通常需要更新的JDK版本。元空间-XX:MetaspaceSize和-XX:MaxMetaspaceSize。防止元空间无限增长导致Full GC。线程栈大小-Xss。默认1MB对于线程数多max-threads大的应用过大的栈大小会导致总内存消耗剧增。可以尝试减小到512k或256k但需测试是否会导致栈溢出。java -Xms2g -Xmx2g -XX:UseG1GC -XX:MetaspaceSize256m -XX:MaxMetaspaceSize256m -Xss512k -jar your-app.jar4.2 Tomcat会话Session管理HttpSession是内存泄漏的重灾区。特别是如果你使用了Tomcat的默认会话管理器。server.servlet.session.timeout设置会话超时时间。默认30分钟。根据业务需要调整不宜过长。server: servlet: session: timeout: 15m # 15分钟server.tomcat.max-swallow-size请求体被吞掉的最大大小当请求被取消时。默认2MB。对于可能上传大文件然后取消的场景可以适当调大防止连接被卡住。预防Session内存泄漏确保HttpSession中的对象是可序列化的并且及时调用session.invalidate()或移除不再需要的属性。在开发阶段可以启用Tomcat的泄漏检测功能虽然SpringBoot嵌入式模式下配置稍麻烦或者依靠代码审查和内存分析工具如Eclipse MAT来查找。4.3 文件描述符与连接泄漏文章开头提到的Too many open files错误根源往往是连接泄漏。除了调整系统级的ulimit在Tomcat层面确保你的代码中所有打开的InputStream、OutputStream、Socket、数据库连接等资源都在finally块或使用try-with-resources语法中正确关闭。监控Tomcat的连接数。可以使用Spring Boot Actuator的/actuator/metrics/tomcat.threads.busy和/actuator/metrics/tomcat.threads.current等端点或者通过JMX查看Tomcat:typeThreadPool,name*的connectionCount属性。5. 高级特性与生产就绪配置当基础调优完成后可以考虑一些高级特性来进一步提升稳定性或适配特定环境。5.1 使用外部Tomcat线程池Executor默认情况下每个连接器都有自己的内部线程池。你也可以配置一个共享的Executor供多个连接器使用虽然SpringBoot嵌入式通常只有一个连接器。但外部线程池可以提供更丰富的监控和管理接口。在SpringBoot中可以通过TomcatServletWebServerFactory自定义Configuration public class TomcatConfig { Bean public WebServerFactoryCustomizerTomcatServletWebServerFactory webServerFactoryCustomizer() { return factory - { factory.addConnectorCustomizers(connector - { ProtocolHandler handler connector.getProtocolHandler(); if (handler instanceof AbstractProtocol) { AbstractProtocol? protocol (AbstractProtocol?) handler; // 设置更详细的线程池参数 protocol.setMaxThreads(800); protocol.setMinSpareThreads(50); protocol.setAcceptCount(400); // 设置线程优先级 protocol.setThreadPriority(Thread.NORM_PRIORITY); } }); }; } }通过编程方式你可以设置线程名前缀、优先级、守护线程等更细粒度的参数。5.2 启用访问日志与请求转储访问日志Access Log对于问题排查和流量分析至关重要。Spring Boot可以轻松配置Tomcat的访问日志格式和输出位置。server: tomcat: accesslog: enabled: true directory: ./logs # 日志目录相对路径或绝对路径 pattern: %h %l %u %t %r %s %b %D # 日志格式%D是处理时间毫秒非常有用 prefix: access_log suffix: .log file-date-format: .yyyy-MM-dd rotate: true buffered: true%D请求处理时间这个字段强烈建议加上它能帮你直接定位慢请求。在极端调试情况下你还可以启用请求转储Request Dump但这会记录所有头部和部分内容性能开销大仅限调试环境。server: tomcat: accesslog: enabled: true # 通过JMX或特定条件触发不建议常开5.3 与监控系统集成Spring Boot Actuator调优不是一劳永逸的需要持续监控。Spring Boot Actuator提供了丰富的端点来监控Tomcat状态。引入依赖spring-boot-starter-actuator暴露相关端点在application.yml中配置management: endpoints: web: exposure: include: health,info,metrics,prometheus metrics: export: prometheus: enabled: true关键指标tomcat.threads.busy: 繁忙线程数接近max-threads说明线程池压力大。tomcat.threads.current: 当前线程数。tomcat.sessions.active.current: 当前活跃会话数。tomcat.global.sent: 发送的字节数。http.server.requests: HTTP请求的详细指标计数、耗时等这是最核心的。将这些指标集成到Prometheus Grafana中可以绘制出线程池使用率、请求延迟分布P50, P90, P99、错误率等关键图表为容量规划和故障排查提供数据支撑。6. 实战压测与参数验证以JMeter为例所有参数的调整都必须以压测结果为准。纸上谈兵没有意义。这里给出一个简单的JMeter压测思路和观察点。准备脚本使用JMeter录制或编写一个能代表你核心业务场景的测试计划例如登录、查询、下单。设置线程组模拟并发用户。可以设置一个线程数Ramp-Up Period内启动的线程总数可理解为并发用户数和一个循环次数。配置监听器添加聚合报告、响应时间图、每秒事务数等监听器。分阶段压测基准测试先用默认配置压测记录TPS每秒事务数、平均响应时间、错误率、服务器资源CPU、内存、网络IO作为基准。调整max-threads固定其他参数逐步增加max-threads如200, 400, 800, 1000观察TPS和响应时间的变化。当TPS不再增长甚至下降平均响应时间开始飙升时就找到了当前硬件和代码下的一个临界点。调整accept-count和max-connections在找到合适的max-threads后模拟突发流量场景如JMeter中设置大量线程瞬间启动观察调整accept-count对请求排队和拒绝率的影响。观察系统指标在压测过程中使用top、vmstat、jstat或更直观的VisualVM、Arthas等工具监控CPU使用率是否达到瓶颈如持续高于80%GC情况Young GC和Full GC的频率和耗时是否正常压测期间出现频繁Full GC说明内存配置或代码有问题。线程状态使用jstack或Arthas的thread命令查看大量线程是否阻塞在同一个地方如数据库连接池、某个锁这可能是比Tomcat参数更根本的性能瓶颈。一个常见的误区盲目增大max-threads。我遇到过有同事将max-threads设为2000结果压测时TPS上不去响应时间却很长。用jstack一看大量线程处于BLOCKED或WAITING状态等待数据库连接。原来数据库连接池如HikariCP的maximumPoolSize只有50。Tomcat线程再多到了数据库层也被卡住了。所以调优是一个系统工程需要端到端地看。Tomcat参数优化只是解决了请求接入和分配的问题真正的业务处理瓶颈可能在数据库、外部API、缓存或者你的业务代码逻辑本身。7. 常见陷阱与个性化场景配置最后分享几个我踩过的坑和针对特定场景的配置建议。7.1 文件上传下载场景对于需要处理大文件上传下载的应用除了前面提到的max-http-form-post-size还需要注意禁用Tomcat的请求体缓存默认情况下Tomcat会将请求体包括文件缓存在内存或磁盘上。对于超大文件这可能导致内存溢出或磁盘写满。可以通过自定义MultipartConfigElement或设置以下属性来限制或禁用spring: servlet: multipart: enabled: true location: /tmp # 指定临时目录确保有足够空间 max-file-size: 2GB max-request-size: 2GB file-size-threshold: 0 # 文件大小超过此值字节则写入磁盘0表示始终写入磁盘更优的方案是使用流式上传直接读取InputStream并写入目标存储如OSS避免在应用服务器上落盘。7.2 代理与SSL终结场景如果你的SpringBoot应用部署在Nginx或Apache等反向代理之后并且SSL在代理层终结即HTTPS请求到代理代理以HTTP协议转发给Tomcat需要配置Tomcat以正确识别原始协议和客户端IP。server: tomcat: # 使用代理传来的头部信息 remote-ip-header: X-Forwarded-For protocol-header: X-Forwarded-Proto # 信任所有代理生产环境应指定具体代理IP internal-proxies: .* # 或者更安全地 internal-proxies: 192\.168\.\d{1,3}\.\d{1,3}|10\.\d{1,3}\.\d{1,3}\.\d{1,3}同时在代理服务器如Nginx上需要正确设置这些头部proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme;7.3 优雅停机Graceful Shutdown在发布重启时如何让正在处理的请求完成而不被中断Spring Boot 2.3 提供了优雅停机支持。server: shutdown: graceful # 启用优雅停机 spring: lifecycle: timeout-per-shutdown-phase: 30s # 等待业务处理完成的最长时间当收到停机信号如kill -2时Tomcat将停止接收新请求并等待现有请求处理完成最多等待配置的时间。这对于避免数据不一致或用户请求失败非常重要。7.4 关于“内存不足”的思考搜索热词里有“tomcat报内存不足”。这不仅仅是调整Tomcat参数或JVM堆内存就能解决的。需要系统性地排查内存泄漏使用jmap -histo:live或内存分析工具查看哪个类的对象数量异常多。堆外内存如果堆内存设置合理但物理内存仍被吃光可能是堆外内存泄漏如Netty、某些Native库。使用Native Memory Tracking (NMT)来诊断。线程数量过多的线程每个线程有栈内存也会消耗大量内存。回顾你的max-threads、Xss设置以及应用中是否创建了大量自定义线程。操作系统限制检查ulimit -v虚拟内存等系统限制。调优没有银弹最好的参数永远是适合你自己应用业务特性和硬件环境的参数。从默认配置出发结合监控和压测小步快跑地迭代调整记录每次变更的结果才能构建出稳定高效的服务。
)
