tomcat优化——并发和Tomcat线程数(1)

<Connector executor=“tomcatThreadPool” port=“8084” protocol=“org.apache.coyote.http11.Http11AprProtocol”

connectionTimeout=“60000”

keepAliveTimeout=“30000”

maxKeepAliveRequests=“8000”

maxHttpHeaderSize=“8192”

URIEncoding=“UTF-8”

enableLookups=“false”

acceptCount=“1000”

disableUploadTimeout=“true”

redirectPort=“8443” />

事后thread dump看其实真正处于RUNNABLE状态的线程很少，绝大部分线程都处于TIMED_WAITING状态：

于是大伙都开始纠结为什么线程会涨到3000，而且发现即使峰值过了线程数并不会降下来。

我们首先想到的是：后端应用的处理瞬间比较慢，“堵住了”导致前端线程数涨了起来。但是优化一个版本上线后发现虽然涨的情况有所好转，但是最终线程池还是会达到3000这个最大值。

==分割线=========

以上是大背景，中间的过程省略，直接跟各位说下目前我得到的结论：

1、首先是为什么线程不释放的问题？

---

简单说下我验证的Tomcat(7.0.54)线程池大概的工作机制

Tomcat启动时如果没有请求过来，那么线程数（都是指线程池的）为0；

一旦有请求，Tomcat会初始化minSapreThreads设置的线程数；

Tomcat会停止长时间闲置的线程。Tomcat还有一个参数叫maxIdleTime：

其实从这个参数解释也能看出来Tomcat会停止闲置了超过一定时间的线程的，这个时间就是maxIdleTime。但我之前的测试中确实没有发现线程释放的现象，这是为什么呢？我发现除了这个参数线程池线程是否释放？释放多少？还跟当前Tomcat每秒处理的请求数（从Jmeter或LoadRunner来看可以理解为TPS）有关系。通过下表可以清晰的看出来线程数，TPS和maxIdleTime之间的关系：

TPS	maxIdleTime（ms）	Thread Count
10	60,000	600
5	60,000	300
1	60,000	60

依次类推，当然Thread Count这一列是一个大约数，上下相差几个，但基本符合这样一个规则：

Thread Count = min(max((TPS * maxIdleTime)/1000,minSpareThreads),maxThreads)

当然这个Thread Count不会小于minSpareThreads，这个跟之前的结论还是一样的。我现在大胆猜测下（回头看源码验证下，或者哪位同学知道告诉我下，谢谢）：

Tomcat线程池每次从队列头部取线程去处理请求，请求完结束后再放到队列尾部，也就是说前后两次请求处理不会用同一个线程。某个线程闲置超过maxIdleTime就释放掉。

假设首先线程池在高峰时期暴涨到1000，高峰过后Tomcat处理一次请求需要1s（从Jmeter看TPS大约就为1），那么在maxIdleTime默认的60s内会用到线程池中60个线程，那么最后理论上线程池会收缩到60（假设minSpareThreads大于60）。另外：这个跟用不用Keep-Alive没关系（之前测试结论是因为用了Keep-Alive导致程序性能下降，TPS降低了很多导致的）

这就是为什么我之前的测试中、还有我们生产环境中线程数只增不减的原因，因为就算峰值过后我们的业务每秒请求次数仍然有100多，100*60=6000，也就是3000个线程每个线程在被回收之前肯定会被重用。

那么现在有另外一个问题，那么正常情况下为什么每秒100次的请求不会导致线程数暴增呢？也就是说线程暴增到3000的瓶颈到底在哪？这个我上面的结论其实也不是很准确。

最后

学习视频：

大厂面试真题：

最后

学习视频：

[外链图片转存中…(img-DKduuQfk-1719176811837)]

大厂面试真题：

[外链图片转存中…(img-vtKsaAO6-1719176811838)]