提升tomcat并发吞吐需协同配置maxthreads（建议cpu核数×20～40，io密集型可至400～600）与acceptcount（推荐maxthreads的40%～60%），并同步调优protocol、maxconnections等参数，辅以阶梯压测验证。
要提升 Tomcat 连接器的并发吞吐能力，关键在于合理配置 maxThreads 和 acceptCount，二者需协同调整，不能孤立设置。它们共同决定了请求能否被及时接纳、排队和处理，直接影响 QPS、响应延迟与 503 拒绝率。
maxThreads：按硬件与业务特征设定上限
这个值不是越大越好——线程过多会加剧 CPU 上下文切换开销，反而降低吞吐。重点看两个维度：
- CPU 核心数：推荐初始值为 CPU 核心数 × 20～40（如 8 核服务器设为 160～320），高 IO 密集型应用（如大量数据库/远程调用）可上探至 400～600；纯计算型则应保守（≤100）
- 实际压力测试结果：观察 jstat GC 频率、线程状态（RUNNABLE / BLOCKED）、平均响应时间拐点。当 maxThreads > 500 后响应时间明显上升，大概率已超最优阈值
- 务必配合 prestartminSpareThreads="true"，让空闲线程提前就位，避免突发流量首请求延迟
acceptCount：匹配 maxThreads，避免队列失衡
它不是“缓冲池”，而是阻塞式等待队列长度。设得过大，请求堆积导致超时（如 connection timeout 触发前已在队列里等几十秒）；设得太小，轻微流量峰就触发 503。
- 推荐值 = maxThreads 的 40%～60%（如 maxThreads=400，则 acceptCount=160～240）
- 若业务允许短时排队且 SLA 容忍 2～3 秒延迟，可略提高（如 80%）；若强调低延迟（如实时接口），建议压到 30%～50%，靠扩容或限流兜底
- 注意：acceptCount + maxThreads ≈ 系统瞬时承载上限，该值不应超过操作系统 ulimit -n（文件描述符限制），否则连接直接失败
配套必须调优的连接器参数
单独调 maxThreads 和 acceptCount 效果有限，需同步优化底层支撑：
- protocol 改为 Http11Nio2Protocol：比默认 BIO 提升 3 倍吞吐，比 NIO 再高 15%，尤其适合万级连接场景
- maxConnections 设为 8000～12000：应 ≥ maxThreads + acceptCount，且 ≤ OS 文件描述符限制（Linux 一般默认 1024，需提前调高）
- connectionTimeout 设为 20000～30000ms：太短易误杀慢请求，太长占用线程资源；配合前端负载均衡的超时设置对齐
- enableLookups="false"：禁用 DNS 反查，每次请求节省几毫秒
验证与迭代建议
上线前必须做阶梯式压测（如用 JMeter 模拟 200→1000→3000 并发），重点关注：
- 503 错误率是否随并发上升而陡增（说明 acceptCount 或 maxThreads 不足）
- 平均响应时间是否在某并发点后快速劣化（提示线程争抢严重，需降 maxThreads）
- Tomcat 线程数监控（/manager/status）中 threadsCurrent 与 threadsBusy 是否长期接近 maxThreads（说明瓶颈不在 Tomcat 层，需查 DB/缓存/下游）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
