

线上接口开始超时，第一反应通常是线程数不够，于是把 **maxThreads** 从 200 调到 800，重启之后好了一阵，第二天同样的问题又回来了。翻监控，CPU 不忙，数据库响应也正常。

**调线程数只是动了排队链条里的一环，请求在这条链上其实要过三道关。**

## 一个请求进来要过几道关？

连接器收请求的顺序是固定的：先完成 TCP 握手建立连接，再从工作线程池里取一个线程去处理。中间还夹着两层缓冲。

| 关卡 | 控制参数 | 默认值 | 满了以后 |
| --- | --- | --- | --- |
| 工作线程 | maxThreads | 200 | 请求在连接器内部等线程 |
| 并发连接 | maxConnections | 非阻塞模式 10000 / 原生模式 8192 | 交给操作系统队列 |
| 系统接受队列 | acceptCount | 100 | 新连接被拒绝或超时 |

只有最里面那一层和业务代码的执行速度有关，外面两层是纯缓冲。缓冲填满不会让系统变快，只会把压力推回客户端。

## 为什么连接数和线程数不是一回事？

这是最容易被忽略的一点。一个 HTTP 长连接建立之后，只要没有请求数据在传，它就不占工作线程。非阻塞模式下连接由少量轮询线程看管，真正有数据要处理时才交给工作线程。

所以 **maxConnections** 管的是「同时挂多少条连接」，**maxThreads** 管的是「同时处理多少个请求」。前者通常远大于后者，默认 10000 对 200 就是这个比例。

反过来说，如果你的服务全是短连接，连接建立本身就是一笔 CPU 开销，这时候调高 **maxConnections** 没有意义，该检查的是客户端有没有用连接复用。

## 线程数调到多大才算合适？

线程不是越多越好。每个线程要占栈空间，默认 1MB 左右，200 个线程就已经是 200MB 的地址空间；更麻烦的是线程切换本身的开销。

估算方式是按业务耗时倒推，而不是拍一个整数。

```text
需要的线程数 ≈ QPS × 平均响应时间(秒) × 安全系数
例：峰值 QPS 300 × 0.2 秒 × 3 = 180
```

这条公式的前提是线程在等 I/O。如果线程都在跑复杂计算，或者卡在大查询上，加线程只会更快把下游压垮。

## executor 的队列为什么不建议留默认值？

在 server.xml 里配一个共享线程池，能让多个连接器共用一批线程，比每个连接器各配一套更省资源。这里有个参数经常被忽略：队列长度。

```xml
<Executor name="tomcatThreadPool" namePrefix="catalina-exec-"
          maxThreads="300" minSpareThreads="25"
          maxQueueSize="500" maxIdleTime="60000"/>
<Connector port="8080" protocol="HTTP/1.1"
           executor="tomcatThreadPool" acceptCount="100"/>
```

队列不设上限时，请求会一直排下去而不被拒绝。看着像好事，其实是坏事：客户端在等，服务端在堆积，超时之后重试又来一轮，真实流量被放大。把队列设成有限值、超出就快速失败，问题暴露得更早。

容量参数改完要有记录，否则下一个人不知道当初为什么这么配。

```bash
# 每轮压测记下 QPS、线程数、队列长度和拒绝数
# 这几组数我用墨衍同步到团队文档，下次扩容直接对表
```

## 连接被拒和请求超时，怎么区分？

这两种现象的处理方向完全不同，从日志和监控上就能分辨。

连接被拒说明系统接受队列也满了，客户端连握手都拿不到响应，问题在接入层，要看的是实例数、连接泄漏和 **acceptCount**。

请求超时说明连接建上了，但迟迟等不到响应，问题在工作线程层——线程被慢请求占满，或者下游把线程拖住。这时候该查的是慢接口，不是线程数。

## 怎么确认瓶颈真的在 Tomcat？

凭感觉调参没有意义，抓一份线程快照直接数。

```bash
jstack <pid> | grep -c "http-nio-8080-exec"
# 再看这些线程停在哪儿
jstack <pid> | grep -A3 "http-nio-8080-exec" | grep -B1 "SocketInputStream"
```

如果大量线程都停在同一个下游调用上，答案就清楚了：要改的是那个下游的超时和连接池，Tomcat 只是背了锅。

把容量当成一组相互制约的参数来看：线程数对齐下游能承受的并发，队列长度对齐能接受的排队时间，接受队列对齐实例数。任何一项单独调大，都只是把积压挪到下一层。


线上接口开始超时，第一反应通常是线程数不够，于是把 maxThreads 从 200 调到 800，重启之后好了一阵，第二天同样的问题又回来了。翻监控，CPU 不忙，数据库响应也正常。

Tomcat 线程池调大了还是扛不住，请求到底堵在哪一层？

后端

架构设计

运维

线上接口超时先调线程数只是表象，请求实际要过连接器、缓冲队列、工作线程三层关卡。连接数管并发连接，线程数管并发处理，二者不是一回事。线程数应按QPS×响应时间倒推，队列长度必须设上限，超时用jstack快照区分连接拒绝还是请求等待，别让Tomcat背慢接口的锅。

代码解释

数据库

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

Tomcat 线程池调大了还是扛不住，请求到底堵在哪一层？-腾讯云开发者社区-腾讯云

Tomcat 线程池调大了还是扛不住，请求到底堵在哪一层？

Tomcat 线程池调大了还是扛不住，请求到底堵在哪一层？

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐