CPU/核心数与Tomcat线程数的关系及压测调优疑问

一、增加maxThreads参数对系统响应的影响 #

这个得分情况来看，不是单纯调得越高越好：

• 当当前线程数未达最优阈值时：如果你的系统当前并发请求已经出现排队（比如acceptCount数值持续增长），且CPU使用率还没到饱和状态，适当调高maxThreads能让Tomcat同时处理更多请求，减少请求在队列里等待的时间，系统响应速度会明显提升，吞吐量也会跟着上去。
• 当线程数超过最优阈值后：如果maxThreads调得过高，超过服务器承载的合理范围，麻烦就来了：Tomcat会创建大量线程，CPU需要频繁在这些线程之间做上下文切换——这个切换动作本身会消耗大量CPU资源，导致真正用来处理业务请求的CPU时间被挤压。结果就是系统响应变慢，甚至出现请求超时、CPU负载直接飙到100%，严重的话可能导致服务不稳定甚至宕机。

结合你当前的配置：两个Connector各设了300的maxThreads，总线程数600，服务器是32核。如果你的应用是IO密集型（比如频繁调用数据库、外部接口），这个线程数可能还在合理区间；但如果是CPU密集型（比如大量复杂计算），600线程就明显过高，很容易触发上下文切换的性能问题。

二、CPU核心数与Tomcat线程数的关联 #

线程数的合理设置，和CPU核心数、应用的业务类型（CPU密集/IO密集）直接挂钩：

• CPU密集型应用：这类应用的业务逻辑主要依赖CPU运算（比如复杂数据处理、算法计算），线程运行时几乎不等待IO，此时线程数设置接近CPU核心数就好，一般是核心数 * 1.2左右。因为每个线程都需要CPU来执行，多出来的线程只会徒增上下文切换开销，反而拖慢效率。比如你32核的服务器，CPU密集型场景下，单Connector的maxThreads设30-40左右就足够。
• IO密集型应用：绝大多数Web应用都属于这类，比如要查数据库、调用第三方接口、读写文件，线程在执行过程中会有大量时间在等待IO完成（此时CPU处于空闲状态）。这种情况下，线程数可以设得比核心数高很多，让CPU在等待IO的间隙去处理其他线程的请求。实践中常用的参考范围是核心数 * 2到核心数 * 8之间（具体数值要看IO等待的占比，等待时间越长，线程数可适当调高）。比如你32核的服务器，IO等待占比较高的话，单Connector设300线程是合理的，但最终还是要结合压测结果调整。

另外要注意：Tomcat的总线程数是所有Connector的maxThreads之和，还要预留一部分CPU资源给JVM本身的系统线程（比如GC线程、后台监控线程），所以实际设置时别把CPU资源占满。

最后建议你通过JMeter压测来验证：逐步调高maxThreads，同时监控CPU使用率、线程上下文切换次数、系统响应时间、吞吐量这些指标，找到能让系统达到最佳性能的阈值——这比理论计算更贴合你的实际场景。

内容的提问来源于stack exchange，提问作者Torikul Alam