Tomcat线程池详解：从默认实现原理到配置调优与故障排查

某天中午，我一个做物流查询系统的项目组同学打来电话，说线上两台实例出现了零星请求超时，监控上看到Tomcat活跃线程不高，队列却越积越长。我登上去一看，活跃线程稳定在60多，maxThreads配的300，队列却堆到了5000多。这个现象很典型，问题不在流量，而在Tomcat线程池的工作模型被配置文件里的某个参数悄悄改变了。今天就把“Tomcat线程池”这件看似简单、实则坑不少的事彻底讲清楚，从默认实现原理到自定义配置，再到调优和排查，一次性说透。

1. Tomcat线程池到底分几层：连接器、执行器和工作线程

1.1 一个请求从进入到真正被处理的完整链路

很多人习惯把“Tomcat线程池”当成一个黑盒，但真正遇到问题的时候，不知道黑盒里面是什么结构，根本无从排查。先说清楚Tomcat处理一个HTTP请求经历的三个角色。

第一个角色是Acceptor，它只做一件事：不断调用ServerSocket.accept()接收新建的TCP连接，接收完成后会把Socket交给Poller。第二个角色是Poller，它维护一个NIO事件轮询器，负责监听这些Socket上是否可读、可写，也就是网络IO事件。第三个角色才是我们嘴里常说的“Tomcat线程池”，在Tomcat里它被称作Connector的工作线程池，或者说Executor。Poller检测到某个Socket有数据可读时，会从线程池里取出一个工作线程，把Socket交给它，接下来servlet的service()就在这个线程上执行。

这里有个关键点容易被误解：工作线程处理的是业务逻辑，NIO读写本身不占工作线程。所以线程池里的线程数量，本质上决定的是“同时能跑多少个请求业务代码”，而不是“能同时建立多少个连接”。理解了这条线，下文所有参数才有意义。

1.2 默认线程池的真实类名和实现

Tomcat 8.5和9.x版本里，Connector在不配置Executor的情况下，底层使用的是一个内部默认线程池，核心实现类是org.apache.tomcat.util.threads.ThreadPoolExecutor，并不是JDK自带的java.util.concurrent.ThreadPoolExecutor。它内部组合了一个队列，这个队列也比较特殊，叫org.apache.tomcat.util.threads.TaskQueue。

TaskQueue继承自LinkedBlockingQueue，也就是无界队列，但它重写了offer方法。这个重写是整个Tomcat默认线程池行为模式的灵魂所在，也是后面会遇到各种奇怪现象的根本原因。先记住这个结论：Tomcat的默认线程池在达到maxThreads之前，几乎不会把任务放队列里排队，而是倾向直接创建新线程去处理。

线程工厂也值得一提，Tomcat默认通过org.apache.tomcat.util.threads.ThreadFactory创建线程，名字类似http-nio-8080-exec-N，默认是daemon线程，优先级是5。这些细节点在自定义线程池的时候都会成为对比标尺。

1.3 maxThreads、minSpareThreads、maxConnections、acceptCount各自管什么

这四个参数经常被混在一起，但它们服务的阶段完全不同。

• maxThreads：工作线程池的最大线程数，决定业务代码最多能被多少个线程同时执行。默认200。
• minSpareThreads：工作线程池的“核心线程数”概念，Tomcat默认10，表示即使空闲也会保留的线程数，用来应对突发流量。
• maxConnections：连接器能接受的TCP连接数量上限，在NIO模式下默认8192。超过这个数字的TCP连接会被拒绝，或者等待，具体看acceptCount。
• acceptCount：操作系统的accept队列长度，默认100。当maxConnections被打满后，后续连接会进入这个队列等待被accept；如果再超过acceptCount，客户端就会直接收到Connection refused。

继续往下看之前，可以把这样理解：acceptCount管内核里排队的连接，maxConnections管应用层能留住的连接，maxThreads管业务同时在跑的线程数。三者层层递进，任何一个先打满，对外表现都不同。

2. 默认线程池的行为逻辑：为什么maxThreads似乎“没生效”

2.1 TaskQueue的特殊offer机制

用JDK自带的ThreadPoolExecutor时，规则是：核心线程数满了，任务先入队列，队列满了才继续扩线程到max。每个学Java并发的人对这套逻辑都很熟，但Tomcat不是这样玩的。

看TaskQueue.offer方法的核心逻辑：当提交任务时，如果当前在工作线程数小于maximumPoolSize，offer直接返回false。返回false意味着什么样的行为？在ThreadPoolExecutor.execute方法里，workerCount < corePoolSize时addWorker，否则尝试offer入队；如果offer返回false，线程池会认为队列满了，于是尝试创建新线程，从而让线程数继续往上走。只有当线程数已经等于maximumPoolSize时，TaskQueue才调用super.offer，把任务真正放进队列。

所以Tomcat默认线程池的行为其实更像“先用满线程，再用队列”。线程会随着请求量增加一路增长到maxThreads=200，之后任务才开始在无界队列里排队。这个模型保证了业务请求在到达线程上限前都能直接被线程处理，不会因为队列占用导致延迟明显增大。

这里有一个细节值得做笔记：TaskQueue的offer判断的是“当前线程数”和maximumPoolSize的关系，不是普通JDK逻辑里的“队列是否满”。如果你自定义了一个Executor却用了原生LinkedBlockingQueue，行为会立刻变回JDK默认的“先排队、后扩线程”，压测时看到的表现就会大不一样。

2.2 线程创建的实际时机和触发条件

Tomcat启动时，线程池里只有minSpareThreads个线程，默认10。它不是启动就全部创建到200，而是请求量增大后，每来一个新任务，如果当前线程数小于maxThreads，就创建一个新线程去处理。

所以压测时你会发现一个现象：前几十个请求阶段，线程数从10慢慢往上爬，如果并发一直维持，线程数最终会爬升到maxThreads并稳定在那。如果并发撤掉，线程空闲超过maxIdleTime（默认60秒），线程数又会回落，最终稳定在minSpareThreads。很多人看到线程数“慢慢涨”就以为参数没生效，其实这是Tomcat设计好的伸缩策略，不是故障。

顺带说一句，由于默认队列是无界的，即便线程数到达200且请求继续堆积，任务也不会被拒绝。这意味着你永远不会看到RejectedExecutionException，但你会看到线程数恒定200、响应时间线性飙升、队列深度无限增长。这种情况其实比直接拒绝更难发现，因为日志里没有任何异常，只有监控图上RT曲线一路走高。

2.3 常见误解：maxThreads不等于并发上限

不少刚接触Tomcat调优的同学会问：maxThreads设成200，是不是意味着最多只能支撑200个并发？答案是否定的。因为一个TCP连接可以复用，一个连接上的多个请求会串行使用同一个或不同工作线程，但连接本身占用的是maxConnections，不是maxThreads。反过来，一个慢请求长时间占住一个工作线程，后续请求就必须等其他线程释放。

更准确的理解是：maxThreads是“业务处理并行度”的上限。假设业务RT（平均响应时间）是50ms，每个请求耗时很短，那200个线程可以扛住的QPS远大于200；但假设某个上游接口超时时间是5秒，每次调用都卡满5秒，那200个线程可能连200QPS都跑不动。这也是为什么线程池调优必须结合RT和QPS来算，而不是拍脑袋设一个数字。

2.4 线程数回落机制：minSpareThreads和maxIdleTime

默认线程池里，线程空闲超过maxIdleTime（默认60000ms）就会被回收，回收的下限就是minSpareThreads。这个回收机制保证低峰期不会白白占用线程资源，但如果你是性能敏感型服务，频繁伸缩线程本身也会有开销，所以有些团队会把minSpareThreads直接顶到接近maxThreads，用内存换毛刺。

从实际生产经验看，对于QPS波动很大的服务，建议不要保持默认10，可以按预估峰值的30%~50%设置minSpareThreads；对于QPS平稳的服务，直接设成和maxThreads一样反而省心。这里没有标准答案，只有你对自己请求模型的判断。

3. 哪些场景值得换成自定义线程池

3.1 默认线程池的局限：命名、策略和可观测性

默认线程池能覆盖大多数业务，但有几个限制在实际运维中会让人头疼。

第一是线程名不好识别。http-nio-8080-exec-123只能告诉你它在处理8080端口，看不出当前线程在处理什么业务模块。如果你在Tomcat里同时部署了多个应用，或者一个应用内部有不同类型的请求，排查问题时线程名几乎没有辅助价值。

第二是拒绝策略不可控。默认线程池在队列无界的情况下理论上不拒绝任务，但一旦你改用了自定义Executor并使用有界队列，接近队列上限时会发生什么完全依赖TaskQueue的实现逻辑，应用层想自定义RejectedExecutionHandler需要花一些功夫。

第三是监控指标不直观。虽然可以通过JMX看到线程数，但要拿到“活跃线程数、队列积压、任务等待时间”这些细粒度信息，默认实现并不方便。对于需要精细化容量管理的团队，这远远不够。

3.2 典型场景一：高并发网关类服务需要精确控制并行度

网关类服务的特点是请求量特别大，但单个请求在网关内做的事情有限，通常只是路由、鉴权、转发。这种服务如果线程池上限过高，反而会导致CPU上下文切换成本激增，整体吞吐量不升反降。

此时更合理的做法是把工作线程数控制在CPU核数的2~3倍，同时配合有界队列，让超过容量的请求尽快返回，而不是积压在队列里等待超时。下面会给出具体的替换方式，这里先说结论：网关场景，默认的200上限偏高，自定义线程池收益很明显。

3.3 典型场景二：请求内调用第三方接口或数据库的IO密集型业务

另一个更常见的场景是业务代码里大量调用外部接口、数据库、缓存。假设一个请求内部串行调用了4个下游，每个下游耗时100ms，那这个请求本身至少400ms起步。如果某个下游有慢连接问题，线程很快就会被拖住。这时候如果不限制线程数，线程池会被外部抖动拖垮，进而影响整个Tomcat。

对这种服务，自定义线程池的意义在于：你能给线程池加更细致的完善逻辑，比如给线程池配一个监控线程，实时打印池大小、活跃线程数、队列长度；或者结合线程名把不同业务的口子区分开。更重要的是，可以控制“当所有线程都被外部慢调用占用时，新请求是应该等待还是快速失败”，默认的无界队列很难帮你实现这个策略。

3.4 大多数情况其实没必要换

说句实在话，如果你们的服务只是普通CRUD、QPS几百、下游接口稳定，默认线程池完全够用，把它换成自定义线程池反而增加了重启出错的风险。

我在实践中判断“要不要自定义”就三个问题：第一，是否经常需要从线程栈里分辨业务归属，答不上来就换；第二，是否需要对线程池做指标监控和告警，需要就换；第三，业务请求的平均RT是不是明显偏长，是就换。三个问题如果都是否，老老实实用默认。

4. 替换线程池的完整配置与代码实现

4.1 最简单的方案：server.xml里配置Executor并绑定Connector

如果你只是想把maxThreads调大、线程名前缀改一下、空闲回收时间改短，完全不需要写代码，直接在conf/server.xml里增加Executor节点，然后在Connector里通过executor属性指定它。

<Server> <Service name="Catalina"> <Executor name="api-exec" namePrefix="api-thread-" maxThreads="400" minSpareThreads="40" maxIdleTime="30000" maxQueueSize="4096" prestartminSpareThreads="true" threadPriority="5"/> <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol" executor="api-exec" maxConnections="8192" acceptCount="512" connectionTimeout="5000" keepAliveTimeout="30000"/> </Service> </Server>

这里面有几个容易被忽视的点。

namePrefix就是新线程池里线程名的一部分，比如api-thread-1、api-thread-2。用jstack抓线程栈的时候一眼就能认出这些线程来自哪个Connector的哪套池子。相比默认exec-前缀，这个改动对排障的体感提升非常明显。

maxQueueSize是8.5版本之后Executor节点上支持的参数，对应TaskQueue的容量。如果设置了它，TaskQueue会变成有界队列，队列满了之后再来的请求就会触发线程池的拒绝策略。要小心，对有界队列来说，Tomcat默认的拒绝策略在任务被拒时可能会记录WARNING日志并直接丢弃请求，对用户来说就是个500。生产环境用有界队列，务必配合自己的任务拒绝策略或者可靠性兜底。

prestartminSpareThreads如果在Executor上设为true，Tomcat启动时就会提前创建minSpareThreads个线程，而不是等请求来了才慢慢补。这对高峰期启动服务很有用，可以避免刚上线时线程数从10开始爬导致的前几十个请求变慢。

4.2 给Connector独立配置还是给全局Executor配置

很多人会问：不配Executor的时候，直接在Connector里写maxThreads不也行吗？确实可以，Connector本身也支持maxThreads、minSpareThreads等参数，但那只是Connector内部默认池的参数，不能对线程命名做定制，也不能被多个Connector共享。

如果你同时配置了多个Connector，比如一个8080给HTTP用，一个8443给HTTPS用，默认情况下它们各自维护一套线程池，互不共享。如果想让多个Connector共用一个线程池，就必须显式声明一个全局Executor，并把这个Executor挂在多个Connector上。从线程池利用率角度看，共享方式是更高效的，但这也会带来另一个问题：某个Connector流量异常时会拖累另外一个Connector。按连接器类型拆分Executor是更稳的方式。

4.3 深度定制方案：自定义Executor实现类

如果连TaskQueue的行为都要改，或者想完整接入JDK线程池的更多配置，就需要写一个自定义Executor类，在server.xml里通过className属性指定它。

一个可行的做法是继承org.apache.catalina.core.StandardThreadExecutor，并在里面封装一个自定义的JDKThreadPoolExecutor实例。标准思路是：

1. 写一个类，比如CustomExecutor，继承StandardThreadExecutor。
2. 重写startInternal和stopInternal，创建自己的ThreadPoolExecutor。
3. 在线程池创建时，使用org.apache.tomcat.util.threads.TaskQueue作为队列，这样能保留Tomcat“先扩线程后排队”的语义。
4. 可以实现一个自定义的RejectedExecutionHandler，在拒绝时记录指标而非直接丢弃。
5. 把类打成jar放入Tomcat的lib目录，然后在server.xml的Executor节点上写className。

public class CustomExecutor extends StandardThreadExecutor { @Override protected void startInternal() throws LifecycleException { TaskQueue taskqueue = new TaskQueue(); ThreadPoolExecutor executor = new ThreadPoolExecutor( getMinSpareThreads(), getMaxThreads(), getMaxIdleTime(), TimeUnit.MILLISECONDS, taskqueue, new MyThreadFactory(getNamePrefix()), new MyRejectedExecutionHandler()); taskqueue.setParent(executor); this.executor = executor; super.startInternal(); } }

实际写的时候还要处理线程工厂和拒绝策略等细节，这里示意一下。很多团队这么做的目的只有一个：让线程池的拒绝行为、线程命名、监控埋点完全符合自己平台的规范。如果你暂时不需要这么深，使用4.1节的标准Executor配置就已经覆盖了80%的需求。

4.4 队列类型选择的对比：LinkedBlockingQueue、SynchronousQueue、TaskQueue

自定义Executor时，最容易被坑的就是队列类型。

从我的经验看，除非你有特别的理由，否则自定义线程池时继续用TaskQueue是最省心的。它保留了Tomcat本身的伸缩语义，你只是在外面加监控和拒绝策略，而不改变线程池的核心脾气。如果换成普通有界队列，你会发现压力上来后线程数可能停在很低的值不涨，整体RT却开始攀升——那是因为任务都被队列吸收掉了，这不是错误，但可能和你原本预判的“先满线程”不一致。

4.5 通过JMX调整或查看线程池状态

Tomcat的线程池暴露在JMX中，对象名一般是Catalina:type=ThreadPool,name=api-exec。用JConsole或者jvisualvm连上后，能看到maxThreads、currentThreadCount、currentThreadsBusy这几个核心属性。其中currentThreadsBusy就是当前正在处理请求的线程数，也就是监控里常看的活跃线程数。

生产环境即便不做深度定制，也建议把currentThreadsBusy和队列大小接到监控平台，配置一个“连续5分钟活跃线程数超过maxThreads*0.8”的告警。等事故真的发生再jstack肯定是来不及的，提前把指标做出来才是正经事。

5. 参数调优的思考路径与参考配置

5.1 用QPS和RT估算线程数：流量×耗时模型

调线程池参数之前，先要回答一个问题：我的服务到底需要多少个线程同时工作？这里有一个很朴素的计算思路，就是排队论里的利特尔法则的变体：并发中的请求数约等于QPS乘以平均响应时间。

比如一个接口平均QPS是1000，平均RT是80ms，那么在同一时刻处于处理中的请求大约就是1000×0.08=80个。也就是说，给这个接口所在的服务配80个工作线程基本能满足需求，再考虑峰值波动，留上30%~50%余量，120~140是合理区间。

反之，如果QPS只有100，但RT高达2000ms，那么同时处理中的请求也有100×2=200个。这就解释了为什么有些低QPS服务反而需要配更大的线程池——每个请求占用的时间太长。

所以不要拿“我们QPS很高所以线程数要大”这种直觉来设定参数，QPS高但RT极短的服务，线程数未必需要多大。真正决定线程数的是正在执行过程中、还没结束的并发请求数。

5.2 CPU密集型和IO密集型的差异化配置

在知道并发请求数之后，再结合任务的CPU密集程度来定最终线程数。

• CPU密集型：线程数一般建议在CPU核数的1~2倍之间。比如8核的机器，16个线程差不多。设多了只会增加上下文切换损耗。
• IO密集型：一次请求里大部分时间在等待外部资源，CPU空闲，可以多配线程。经验区间是CPU核数的4~16倍，具体取决于IO等待比例。如果下游RT很不稳定，还要关注线程是否会被大量拖死。

实际项目里往往是混合型，建议按主要瓶颈来定，再通过压测修正。大方向是：在线程池没有排队、CPU使用率又比较健康的区间内，找到能撑住目标QPS的最小线程数，然后留20%缓冲。

5.3 一份可参考的参数组合

这份配置不是万能公式，但适合多数中等规模的业务服务，可以当作起步模板。

• 普通业务Web服务：maxThreads=200，minSpareThreads=20，acceptCount=200，maxConnections=8192。
• 高并发网关或短RT服务：maxThreads=50~100，minSpareThreads=20，maxQueueSize=512，acceptCount=512。
• 长RT外部依赖多的服务：maxThreads=400~600，minSpareThreads=50，maxQueueSize=1024，配合下游超时控制在2秒以内。
• 容器环境配置了CPU limits时：按limits核数计算，maxThreads不超过核数的4倍，避免线程过多导致容器频繁调度。

调参最重要的原则是：一次只改一个变量，压测对比后再改下一个。很多人喜欢同时改掉maxThreads、acceptCount、maxConnections，一旦性能变化根本说不清是哪个参数起了作用。

5.4 acceptCount与maxConnections的配合，防止连接堆积

我一直强调，线程池不是唯一瓶颈，连接队列同样值得关注。

maxConnections默认8192，对绝大多数服务完全够用。但要注意慢连接攻击或者大流量场景下，如果TCP连接建立后长时间不发数据，这些连接会占据maxConnections额度。此时即便线程池很空闲，新连接也可能被拒绝。预防手段是把connectionTimeout和keepAliveTimeout调到一个不算苛刻但也不放纵的水平，比如connectionTimeout=5000、keepAliveTimeout=30000。

acceptCount的作用则更偏内核层。连接数超过maxConnections后，多余连接会在系统层的accept队列中等待。acceptCount默认100，在高并发短连接场景下很容易被填满，导致客户端偶发Connection refused。如果压测机和服务端在同一个网段且连接建立速度非常快，把acceptCount提高到512或1024通常是安全的，但要配合前面说的连接超时限制，不然队列里堆一堆半吊子连接反而拖垮内核。

6. 线程池耗尽的完整排查链路

6.1 从外部表现判断问题方向

线程池出问题时的表现有几种，先看症状才能少走弯路。

第一种表现是偶发的Connection refused。这通常不是线程池本身的问题，而是acceptCount或者maxConnections被打满了，连接根本没进到应用层。第二种表现是请求超时，但服务端CPU不高。这大概率是线程都被占住，任务在队列里排队，网络层连接正常，但迟迟无人处理。第三种表现是CPU持续飙高，伴随RT上升。这时要考虑的是线程数设置过大、业务死循环或者JVM频繁GC，不一定是线程池容量不够。

还有一种被忽视的表现是错误日志中偶尔出现RejectedExecutionException。默认无界队列是不会拒绝的，如果看到这个异常，说明你已经在使用有界队列的自定义Executor，任务到达上限后被丢弃了。

6.2 现场取证：jstack、jstat和日志三板斧

遇到线程池疑似耗尽，第一件事不是改配置，而是留证据。

用jps找到Tomcat的PID，然后执行jstack PID > threaddump.txt。打开线程转储文件，优先看处于RUNNABLE状态的线程，再看处于BLOCKED和WAITING状态的线程。如果是Tomcat默认线程，名字一般是http-nio-8080-exec-xxx，如果自定义过Executor，线程名就是你在namePrefix里写的业务标识。

重点观察两类东西：一是线程栈里大量出现同一个类库的调用，比如都在等待某个数据库连接、都在调同一个第三方接口，说明下游有阻塞；二是大量线程处于TIMED_WAITING但等待时间异常长，可能是KeepAlive或连接池获取卡住了。

同时用jstat -gcutil PID 1000观察GC，如果Full GC频繁到每秒多次，那CPU高和响应慢都可能是GC引发的，线程池只是个背锅侠。

还有一类证据在Tomcat的catalina.out里。当线程池的队列被用完时，日志可能记录类似“All threads are busy, queued tasks are increasing”的警告，这些都是判断系统压力的重要信号。

6.3 根因定位：流量突增、下游阻塞、SQL慢、死锁，分别怎么排查

拿到线程栈后，按概率从高到低排，一般就几类原因。

流量突增：对比同一时段QPS、UV曲线和线程池活跃线程曲线，如果活跃线程数和QPS同步上涨且线程数顶到maxThreads，基本可以确定是流量超过了预设容量。对策要么扩容，要么把maxThreads调大。

下游阻塞：线程栈里大量线程停在HTTPClient的socketRead或者数据库驱动的socketRead，说明线程全在等外部接口响应。此时加大maxThreads只会让更多线程一起等，解决不了根本问题，真正要做的是给下游调用加超时、加熔断，把外部故障隔离掉。

慢SQL：线程栈停在数据库驱动里，同时数据库侧慢查询日志有长时间执行的SQL。这种问题优先优化SQL和索引，线程池只是受了牵连。线上遇到过最极端的例子，一条全表扫描把连接池占满，Tomcat线程也跟着全堵在获取连接的环节。

死锁：线程栈里出现互相持有的锁，或者大量BLOCKED线程都在等同一个锁。这时候加线程数没用，只能尽快发布修复，把锁粒度和获取顺序处理干净。

6.4 整改措施与效果验证

定位到根因之后，改动要克制，验证要彻底。

如果是容量不够，就按上面的公式先算一个理论值，修改后跑一轮全链路压测，分别观察线程活跃数、队列深度和RT的P99。一次压测后如果活跃线程始终到不了maxThreads，说明线程数设置偏大，接下来压力继续加大，找到到达上限的临界点。如果活跃线程到了maxThreads而CPU仍然很低，说明瓶颈在外部依赖，线程池调大只是掩盖问题。

验证时还有一个简单但有效的动作：对比压测前后相同QPS下的线程池活跃线程数曲线。正常情况下，活跃线程数应该稳定在一个区间内，而不是扶摇直上顶到上限。如果稳定住了，再观察队列是否常态化清空，做到了这两点，这次调优才算闭环。

7. 实践中的几个隐藏体会

7.1 线程命名比想象中更重要

第一次给线程池做线程命名的时候，我觉得这只是个“体面”问题，直到有一次线上告警，我们抓线程栈后按线程名前缀一过滤，几十个线程全停在同一个第三方文件的解析逻辑上，三分钟定位到了根因。从那以后，凡是自定义Executor，我一定要求namePrefix包含业务标识和端口，例如order-api-8080-thread-，这是成本最低的排障投资。

7.2 不要照搬别人的配置，要围绕请求模型自己算

网上很多文章给出的线程池参数，其实都是针对写作者自己场景的经验值。我见过把maxThreads设成1000导致机器频繁GC的案例，也见过8核容器里只放16个线程结果高峰期排队严重的案例。正确的做法永远是自己根据RT、QPS、下游耗时去估算，然后用压测修正。别人的配置只能当参考起点，不能当标准答案。

7.3 容器环境下线程数要主动适配CPU限制

在Docker或K8s环境里，如果Tomcat没有正确感知容器的CPU限额，availableProcessors可能读到的是宿主机核数，而不是容器限额核数。此时按“宿主机核数×4”去设线程池，很容易在高并发下把容器CPU打满。处理办法有两种：要么在启动参数里显式限制线程相关配置，要么根据部署平台的能力给JVM传参让availableProcessors返回正确值。这个问题现在遇到得越来越多，建议在容器化改造时专门做一轮验证。

把Tomcat线程池当回事之后，你会发现很多线上“奇怪现象”其实都有清晰的解释路径。线程池不是越大越好，也不是越小越省，它是业务请求模型在操作系统线程上的一个映射。下次再遇到Tomcat相关的高延时或连接异常，先抓线程栈，再对照本文的链路一步步走，大概率不会空手而归。