探讨 Tomcat 的并发量不能简单地给出一个固定的数字因为Tomcat 的理论并发上限和实际业务能支撑的并发量QPS/TPS是两个完全不同的概念。在当前的架构环境下截至 2026 年Tomcat 10.1/11 及 Java 21 已广泛普及我们可以从核心配置、计算模型、最新技术虚拟线程以及全链路优化四个维度来彻底搞透 Tomcat 的并发量。一、 决定 Tomcat 并发上限的核心参数在server.xml的Connector标签中有三个核心参数决定了 Tomcat 的“物理”并发上限maxThreads最大工作线程数含义Tomcat 能同时处理请求的最大线程数。默认值通常是200。作用决定了同时能处理多少个业务请求。如果请求数超过此值多余的请求将进入等待队列。建议值根据 CPU 核数和业务类型调整。CPU 密集型建议CPU核数 1IO 密集型如查数据库、调外部接口建议200 ~ 800。maxConnections最大连接数含义Tomcat 同时能接受的最大 TCP 连接数。NIO 模式下默认10000APR 模式下默认8192。作用决定了 Tomcat 能“挂起”多少个客户端连接。连接建立后会被分配给工作线程处理如果线程满了连接会保持在已连接状态等待线程释放。acceptCount等待队列长度含义当maxConnections也满了时操作系统层面等待 TCP 握手的队列长度。默认100。作用如果超过maxConnections acceptCountTomcat 将直接拒绝连接客户端收到 Connection Refused。 避坑指南很多新手以为把maxThreads调到 2000 并发就能翻倍这是错误的。线程过多会导致 CPU 频繁上下文切换反而让系统崩溃。二、 实际并发量QPS的计算公式在实际业务中Tomcat 的并发处理能力遵循利特尔法则Little’s Law最大 QPS maxThreads/ 平均响应时间秒举个例子假设maxThreads 200。场景 A纯内存计算极快平均响应时间10ms (0.01s)。理论 QPS 200 / 0.01 20,000 QPS。场景 B涉及复杂 SQL 和外部 RPC较慢平均响应时间200ms (0.2s)。理论 QPS 200 / 0.2 1,000 QPS。结论Tomcat 的并发瓶颈往往不在 Tomcat 本身而在于后端应用的处理速度尤其是数据库和第三方接口的 IO 耗时。三、 2026年最新突破虚拟线程Virtual Threads如果你使用的是Tomcat 10.1 或 Tomcat 11并且运行在Java 21环境下Tomcat 的并发模型发生了革命性的变化。传统的 NIO 模型受限于 OS 物理线程数通常几百到一千而虚拟线程让 Tomcat 可以轻松应对数万级别的并发阻塞 IO。开启虚拟线程的配置server.xml!-- 定义虚拟线程执行器 --ExecutornametomcatThreadPoolVirtualtypeorg.apache.catalina.core.StandardVirtualThreadExecutor/!-- 在 Connector 中使用 --Connectorport8080protocolorg.apache.coyote.http11.Http11NioProtocolexecutortomcatThreadPoolVirtualmaxConnections20000acceptCount500/优势在虚拟线程模式下maxThreads的限制被打破。当请求遇到数据库 IO 阻塞时虚拟线程会自动让出底层载体线程Carrier ThreadTomcat 可以轻松维持数万个并发连接而不耗尽内存或导致 CPU 上下文切换风暴。四、 如何提升 Tomcat 的实际并发量全链路优化要提升系统的真实并发量单改 Tomcat 配置是没用的必须进行“木桶效应”的全链路优化1. 操作系统层面 (OS)文件描述符限制执行ulimit -n确保其值大于 Tomcat 的maxConnections建议设置为65535或更高。TCP 队列优化修改/etc/sysctl.conf。net.core.somaxconn 2048必须大于 Tomcat 的acceptCountnet.ipv4.tcp_max_syn_backlog 2048net.ipv4.tcp_tw_reuse 1允许复用 TIME-WAIT sockets2. 应用与数据库层面最核心的瓶颈数据库连接池Tomcat 有 500 个线程但 HikariCP/Druid 只有 50 个数据库连接那么实际并发上限就是 50。必须合理配置数据库连接池大小通常CPU核数 * 2 磁盘数是个不错的经验值。异步化改造对于非核心链路如发短信、写日志、发 MQ使用Async或消息队列异步处理快速释放 Tomcat 线程。引入缓存使用 Redis 拦截大量读请求避免请求穿透到数据库耗尽 Tomcat 线程。3. JVM 层面并发量上来后GC 压力会剧增。建议升级至G1 GC或ZGCJava 21 中 ZGC 已默认分代停顿时间可控制在 1ms 以内避免因 GC Stop-The-World 导致 Tomcat 线程堆积超时。五、 如何测试你的 Tomcat 并发量不要靠猜使用压测工具在测试环境摸底JMeter最常用适合模拟复杂的业务链路和混合场景。wrk / wrk2基于 C 语言的轻量级压测工具适合测试纯 API 的极限 QPS 和延迟分布。Apache Bench (ab)最简单适合单机快速验证。压测观察指标TPS/QPS是否达到预期。RT (响应时间)随着并发增加RT 是否出现断崖式上升。Tomcat 线程池状态通过 JMX 或 Spring Boot Actuator (/actuator/metrics/tomcat.threads.busy) 观察线程是否被打满。错误率是否出现Connection refused或Timeout。总结理论上限由maxConnections和acceptCount决定通常上万。处理上限由maxThreads决定通常 200~800。实际业务并发由maxThreads / 接口平均响应时间决定。未来趋势拥抱Java 21 Tomcat 10.1/11 的虚拟线程彻底解决传统线程池模型下的 IO 阻塞瓶颈。