Tomcat并发数配置没有一套通用数值，核心是围绕线程池、连接器（Connector）和JVM内存三者联动调整，并且必须经过压测验证，直接改参数只会让系统更快崩溃。多数情况下，默认配置在几百并发时就会出现连接拒绝或请求堆积，问题往往不在Tomcat本身,而在你没搞懂它的工作模型。
Tomcat并发数配置怎么调：先搞懂线程池与连接器的关系
很多人上来就改maxThreads，结果发现并发没上去，内存先爆了，这是因为Tomcat处理一个请求，要经历“接受连接”和“处理请求”两个阶段,分别由连接器和线程池负责。
连接器负责“接客”，线程池负责“干活”
以最常见的BIO（阻塞IO）和NIO（非阻塞IO）举例，BIO模式下，一个连接就要占用一个线程；NIO模式下，连接可以复用少量线程来处理大量请求，现在主流版本默认都是NIO,但很多人还在按BIO的思路调参数。
核心参数在conf/server.xml里的<Connector>节点中：
maxThreads：处理请求的最大线程数，相当于“服务员”数量。acceptCount：当线程池满了，还能排队的请求数量，相当于“等位区”座位。maxConnections：Tomcat能接受的最大连接数，包含正在处理和等待处理的，相当于“餐厅容量”。
这三者的关系是：maxConnections >= acceptCount + maxThreads 时，连接器才能顺畅地把任务交给线程池，行业内较常见的经验值是maxThreads=200、acceptCount=100，但这只是起跑线,不是标准答案。
Tomcat并发数配置的核心参数
讨论参数怎么改，不如先讨论你的业务到底属于什么类型，是CPU密集型（大量计算），还是IO密集型（大量数据库读写、接口调用）？这直接决定线程池大小。
业内专家指出（此处不具名）,线程池大小与CPU核数存在一个被广泛引用的经验公式：
- CPU密集型：线程数约等于CPU核心数+1。
- IO密集型：线程数可以设为CPU核心数乘以2，甚至更高,因为线程大部分时间在等待IO。
实操：修改server.xml的具体步骤
进入$CATALINA_HOME/conf目录，编辑server.xml，找到<Connector>标签,重点调整以下属性：
<Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" maxThreads="400" minSpareThreads="50" acceptCount="200" maxConnections="800" connectionTimeout="20000" enableLookups="false" URIEncoding="UTF-8"/>
注意上面用了Http11NioProtocol，这是在明确告诉Tomcat使用NIO模型，如果你的应用是长连接（比如WebSocket），可以换成NIO2（
Http11Nio2Protocol）,它能进一步减少线程上下文切换的开销。
线程池参数与连接池参数的联动
很多人在调优时只盯着Tomcat，却忽略了JDBC连接池，假设你的maxThreads调到500，每个请求都需要数据库连接，而数据库连接池只有50，那么501个请求进来时，有451个线程会阻塞等待数据库连接,Tomcat线程被白白占满。
一个较稳妥的配比原则是：JDBC连接池大小不高于Tomcat maxThreads的20%，如果业务比较敏感，比如支付接口、秒杀活动,这个比例还要更保守。
Tomcat高并发优化参数：不止改数字这么简单
光调大maxThreads不叫优化，真正的高并发优化，是从请求进入系统的那一刻起,每一层都减少不必要的损耗。
启用压缩减少传输体积
对于文本类响应（JSON、HTML、JS），开启gzip压缩能显著降低带宽压力，在<Connector>中加上：
compression="on" compressionMinSize="2048" compressableMimeType="text/html,text/xml,text/plain,text/javascript,application/json"
尤其对于移动端弱网场景，压缩后的数据量能减少60%以上（这是一个基于HTTP压缩机制的常识性数据，具体大小视内容而定），代价是CPU会多消耗一些,但通常这是划算的。
禁用DNS查询
enableLookups="false"这个参数千万别忽略，如果为true，Tomcat会对每个连接做反向DNS解析，在并发高的时候，DNS解析会拖住线程,导致请求处理速度肉眼可见地变慢。
调整JVM堆内存，给线程池留口粮
每个线程默认栈大小约1MB（在64位JVM上，Xss参数可调），如果maxThreads=400，意味着光线程栈就要占掉约400MB的JVM内存，如果你的-Xmx只给了1GB,那么能用于实际业务的内存所剩无几。
建议-Xmx和-Xms设置相同的值，避免运行时动态扩容带来抖动，同时在catalina.sh中调整：
JAVA_OPTS="-Xms2g -Xmx2g -Xss512k -XX:+UseG1GC"
这里把每个线程栈降到512KB，能在不牺牲性能的情况下,容纳更多线程。
如何确定佳线程数：压测步骤
别人给的参数只能作为参考，要找到你业务场景下的最佳并发数,必须自己压。
使用压测工具模拟真实流量
常用的工具有ab（Apache Bench）、jmeter、wrk，以ab为例，在对系统没有明显副作用的前提下,可以用以下命令做一次快速摸底：
ab -n 10000 -c 200 -k http://yourdomain.com/api/test
这条命令模拟200个并发连接，发送1万个请求,关注两个核心指标：
- Requests per second（吞吐量）：服务器每秒能处理多少请求。
- Time per request（平均响应时间）：单个请求的平均耗时，注意区分
across all concurrent requests和mean两个值。
如何判断压测结果是否健康
健康的系统，随着并发从100升到300，吞吐量应该成正比例增长，响应时间保持稳定，当你发现并发继续提升，吞吐量反而下降，或者响应时间陡增,说明已经到达拐点。
此时观察Tomcat的线程状态,命令是：
jstack <tomcat_pid> | grep "http-nio" | wc -l
如果绝大多数线程的状态是RUNNABLE且卡在数据库或远程接口调用上，说明线程池配置偏大，系统资源被无效等待耗尽，如果大量线程是WAITING状态，说明线程数不足,请求在排队。
Tomcat连接数满了怎么办：排查与应急
线上环境总会遇到突发流量，当maxConnections被占满，新请求会直接被拒绝，表现为Connection refused或请求长时间无响应，此时不要急着改配置重启,先做以下三步。
第一步：确认瓶颈在哪里
使用top -Hp <pid>查看CPU和线程占用，如果CPU没有跑满，大概率是线程阻塞在外部IO（数据库、Redis、第三方API），如果CPU跑满，说明线程数已经超出CPU能承载的范围,增加线程数只会让情况更糟。
第二步：快速降级，保住核心业务
如果服务是多应用混合部署，考虑把非核心接口迁移走，或者对核心接口单独设置一个专用的<Connector>实例，监听不同端口，这样即使某个端口被流量淹没,另一个端口上的核心服务依然可用。
第三步：调整acceptCount做缓冲
acceptCount相当于排队长度，适当调大它，让请求在TCP层排队，而不是直接被内核丢包，但要注意，acceptCount调得太大，用户端会频繁超时，体验更差，行业经验值通常控制在maxThreads的一半左右。
Tomcat并发数配置中的常见误区
相当一部分Java开发者把“调大线程数”当成性能调优的万能药，结果适得其反,以下几个误区比配置文件本身更值得留意。
- 同步接口，却使用NIO2协议。 NIO2适合异步IO场景，如果你的业务代码是同步阻塞的，NIO2的优势发挥不出来,反而增加编码复杂度。
- 线程数设置大于数据库连接数。 上面提过联动关系，这里不再赘述，重复出现50%线程阻塞在数据库等待时,加线程等于加灾难。
- 忽略操作系统文件句柄限制。 Linux下每个TCP连接都是一个文件句柄，默认
ulimit -n
maxConnections=2000根本没意义，因为操作系统先拒绝了，调优前务必执行ulimit -n 65535并写入/etc/security/limits.conf。 - 不看JVM GC日志。 高并发下如果
GC频繁，尤其是Full GC，会触发Stop The World，所有线程瞬间冻结，此时压测结果惨不忍睹，问题根源在内存分配,而不是线程配置。
两类最常见场景的配置对照
不同业务类型对Tomcat的参数要求差异很大，这里给出一个可以直接参考的配置思路,具体数字仍需压测校准。
| 场景 | 典型特征 | maxThreads | acceptCount | JVM堆内存 |
|---|---|---|---|---|
| 内部管理系统 | 低并发（<100）、接口耗时长 | 100-200 | 50-100 | 2GB |
| 面向C端的高并发API | 高并发（>1000）、单请求响应快 | 400-600 | 200-300 | 4GB以上 |
第一类场景的核心矛盾是响应速度，线程多了反而造成上下文切换，第二类场景的核心矛盾是吞吐量，需要较大的线程池来吸收瞬时流量，可以看到，这不是简单的数字游戏,而是对业务形态的映射。
Q&A：关于Tomcat并发数配置的常见疑问
Tomcat的maxThreads设置成1000可以吗？
硬件允许的情况下可以设置，但不建议这么干，线程从100增加到500，系统还能维持较好的吞吐；线程从500增加到1000，CPU在上下文切换上的开销会覆盖掉并发带来的收益，按照Tomcat官方对性能的通用建议，在单机部署、常规配置下，并发处理能力通常在数百到千级之间浮动，具体取决于请求复杂度，超过这个量级，应该考虑引入负载均衡或微服务拆分,而不是单机硬扛。
本地压测效果很好，上线后并发上不去是为什么？
本地压测环境与生产环境的网络链路差异巨大，本地请求走的是loopback接口，没有真实的网络延迟、防火墙过滤、DNS解析耗时，生产环境还存在其他应用争抢CPU和内存资源的问题，较稳妥的做法是，在预发环境模拟生产流量的比例，例如按照核心接口占比70%、次要接口占比30%构造压测脚本,得出的数据才具有参考价值。
Tomcat并发数和Nginx并发数要如何配合？
两者完全是不同层级的组件，Nginx是反向代理，负责接收外部连接并转发给Tomcat，通常Nginx设置的worker_processes与CPU核心数一致，worker_connections设置较大值（比如10240），Tomcat的maxConnections应该低于Nginx的转发能力，否则Nginx把大量请求转给Tomcat，Tomcat直接拒绝连接会形成雪崩，较常见的做法是，让Nginx的proxy_read_timeout小于Tomcat的connectionTimeout，这样上游超时后Nginx能快速断开,避免后端线程被无效占用。