一篇讲了Spring Boot上线前必改的5项配置第1项提了句Tomcat线程数默认200不够评论区炸了——光调maxThreads根本救不了。Tomcat线程池是一个由8个参数组成的联动系统任何一个参数用默认出厂值高并发下都会成为瓶颈。上个月帮一个团队做压测复盘他们的Tomcat只改了maxThreads其他7个全是默认值。大促第1天还能扛第3天连接数堆积、线程全部阻塞整个集群的平均响应时间从200ms飙到8秒上游全部超时熔断。下面8个参数是Tomcat线程池的完整清单每一项都标了出厂默认值Tomcat 9.0.120和为什么不能留默认。1maxThreads默认200QPS过千就排队出厂默认值200事故场景某电商峰值QPS 3000200个线程每个请求平均处理100ms理论吞吐上限仅2000 QPS。超出部分全部进入等待队列排队超过2秒直接超时。监控显示Tomcat线程池使用率100%新请求在队列里干等。正确配置按业务估算# 峰值QPS × 平均响应时间(秒) × 1.5倍buffer # 3000 QPS × 0.1s × 1.5 450至少配到500 server: tomcat: threads: max: 500经验公式maxThreads 峰值QPS × 平均RT × 1.5。开发机200够用生产环境拍脑袋留200就是埋雷。2minSpareThreads默认10冷启动直接卡死出厂默认值10事故场景流量突增时Tomcat需要从10个空闲线程扩容到maxThreads。扩容过程要新建线程对象、分配栈内存瞬时几百个请求同时进来10个空闲线程瞬间耗尽后面的请求全部阻塞在扩容等待上冷启动期RT从200ms飙到3秒。正确配置server: tomcat: threads: min-spare: 50 # 常驻50个空闲线程避免扩容抖动minSpareThreads建议设为maxThreads的10%~20%。maxThreads500时min-spare配50~100让线程池永远有热线程待命。3maxConnections默认8192够了但别瞎改出厂默认值8192NIO模式为什么要注意8192对绝大多数应用是够的。但有人照着老教程把maxConnections改成200结果超过8192的连接被操作系统直接拒绝connection refused客户端大面积报连接失败。正确配置server: tomcat: max-connections: 8192 # NIO模式默认就够不要低于maxThreads太多maxConnections应≥maxThreads。如果maxThreads500但maxConnections200多出300个线程永远拿不到连接等于白配。4acceptCount默认100队列太长等于慢性自杀出厂默认值100事故场景达到maxConnections后新连接进入操作系统accept队列。队列长度100意味着最多缓冲100个连接。但有人听信队列越大越能扛把acceptCount改成10000——结果连接全部堆积在队列里客户端不报错但请求永远不处理用户看到的是页面一直转圈。正确配置server: tomcat: accept-count: 200 # 略大于maxThreads的buffer不要无限大acceptCount过大是隐蔽灾难连接不拒绝、请求不处理、监控不报警。队列应该短到能快速失败fail fast而不是无限缓冲。5connectionTimeout默认20000ms慢连接拖垮线程出厂默认值20000msserver.xml里的值属性本身默认60000ms事故场景客户端网络慢或恶意保持连接不发送请求一个连接占着线程20秒不动。200个线程里如果有50个被慢连接占着实际可用线程只剩150个吞吐量直接腰斩。正确配置server: tomcat: connection-timeout: 5000 # 5秒不发送请求直接断释放线程对外服务connection-timeout配5000~10000ms足够。内部微服务可以更短2000ms快速暴露网络问题。6keepAliveTimeout默认继承connectionTimeout长连接浪费出厂默认值不单独设置时继承connectionTimeout的值事故场景HTTP/1.1默认keep-alive复用连接。如果connectionTimeout20000mskeep-alive也会保持20秒。高并发下大量空闲keep-alive连接占着线程不释放线程池被假繁忙的连接填满。正确配置# Spring Boot未直接暴露该属性需用TomcatServletWebServerFactory Bean public TomcatServletWebServerFactory tomcatFactory() { TomcatServletWebServerFactory factory new TomcatServletWebServerFactory(); factory.addConnectorCustomizers(connector - { connector.setAttribute(keepAliveTimeout, 5000); // 5秒后关闭空闲keep-alive connector.setAttribute(maxKeepAliveRequests, 100); // 单连接最多100请求 }); return factory; }keepAliveTimeout建议设为connectionTimeout的1/2~1/4如connection-timeout5000则keepAliveTimeout2000让空闲连接尽快释放。7maxKeepAliveRequests默认100频繁重建连接出厂默认值100为什么要注意单条keep-alive连接最多处理100个请求后关闭重建。对频繁短请求的场景如API网关每100个请求就要重建一次TCP连接TLS握手额外开销不可忽视。但设成-1无限又会导致连接永不释放。正确配置# 通过TomcatServletWebServerFactory设置 connector.setAttribute(maxKeepAliveRequests, 1000); // 内部服务可放到1000对外公网服务保持100即可客户端连接不可控内网微服务可放到500~1000减少连接重建开销。8maxQueueSize默认Integer.MAX_VALUE最隐蔽的雷出厂默认值Integer.MAX_VALUE约21亿等于无限排队事故场景这是Tomcat内部线程池的任务队列上限。默认无限意味着当maxThreads耗尽任务会无限堆积在内存队列里。某团队大促时任务队列堆积到200万个Old GC频繁、Full GC每次8秒最终OOM。正确配置# 通过自定义Executor限制队列推荐用共享Executor Bean public TomcatExecutorCustomizer executorCustomizer() { return executor - { // 队列上限 maxThreads的2倍超出直接拒绝fail fast executor.setMaxQueueSize(1000); }; }这是8个参数里最容易被忽略也最危险的。无限队列把拒绝压力转成内存压力最终结果是OOM而不是快速失败。队列必须有上限让溢出请求快速报错而非悄悄堆积。8个参数速查表参数出厂默认建议值不配的后果maxThreads200峰值QPS×RT×1.5高并发排队超时minSpareThreads10maxThreads的10%~20%冷启动扩容抖动maxConnections8192≥maxThreads勿低于过低直接拒绝连接acceptCount100≤200勿无限大队列过长慢性堆积connectionTimeout20000ms5000~10000ms慢连接拖垮线程keepAliveTimeout继承connectionTimeoutconnectionTimeout的1/4长连接占满线程maxKeepAliveRequests100内网500~1000频繁重建连接maxQueueSizeInteger.MAX_VALUEmaxThreads×2无限堆积→OOM8个参数不是孤立的是一个联动系统maxThreads决定并发处理能力minSpareThreads决定冷启动表现maxConnectionsacceptCount决定连接缓冲策略connectionTimeoutkeepAliveTimeout决定连接生命周期maxQueueSize决定拒绝策略。只改maxThreads而留其他默认值等于给漏水的船补了一个洞。Tomcat线程池检查清单打印贴工位□ maxThreads按峰值QPS×RT×1.5估算不小于500 □ minSpareThreads设为maxThreads的10%~20% □ maxConnections ≥ maxThreads不盲目调低 □ acceptCount ≤ 200禁止无限队列 □ connectionTimeout配5000~10000ms非默认20秒 □ keepAliveTimeout设为connectionTimeout的1/4 □ maxKeepAliveRequests内网可放到500~1000 □ maxQueueSize必须有上限maxThreads×2禁止无限Tomcat线程池参数检查飞算JavaAI一键扫描这8个参数在Spring Boot项目里分散在application.yml、TomcatServletWebServerFactory、server.xml多个地方人工Code Review极容易漏掉maxQueueSize这种隐蔽项。飞算JavaAI的代码审查器可以自动扫描项目中的Tomcat相关配置检查线程池参数是否合理maxThreads是否够用、acceptCount是否过大、connectionTimeout是否过长、maxQueueSize是否设了上限并给出具体的修改建议和配置示例。30秒跑完8项检查比人工翻server.xml快10倍。你的Tomcat线程池这8个参数里有几个还是出厂默认值