tomcat优化——并发和Tomcat线程数

小咪咪 2021-09-07 06:20 432阅读 0赞

最近一直在解决线上一个问题，表现是：  
Tomcat每到凌晨会有一个高峰，峰值的并发达到了3000以上，最后的结果是Tomcat线程池满了，日志看很多请求超过了1s。  
服务器性能很好，Tomcat版本是7.0.54，配置如下：

事后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之间的关系：

<table> 
 <tbody> 
  <tr> 
   <td><strong>TPS　</strong></td> 
   <td><strong>maxIdleTime（ms）</strong></td> 
   <td><strong>Thread Count</strong></td> 
  </tr> 
  <tr> 
   <td>10</td> 
   <td>60,000</td> 
   <td>600</td> 
  </tr> 
  <tr> 
   <td>5</td> 
   <td>60,000</td> 
   <td>300</td> 
  </tr> 
  <tr> 
   <td>1</td> 
   <td>60,000</td> 
   <td> <p>60</p> </td> 
  </tr> 
 </tbody> 
</table>

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

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

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

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b3J1aV9qYXZh_size_16_color_FFFFFF_t_70][]

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

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

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

真正决定Tomcat最大可能达到的线程数是maxConnections这个参数和并发数，当并发数超过这个参数则请求会排队，这时响应的快慢就看你的程序性能了。

这里没说清楚的是并发的概念，不管什么并发肯定是有一个时间单位的（一般是1s），准确的来讲应该是当时Tomcat处理一个请求的时间内并发数，比如当时Tomcat处理某一个请求花费了1s，那么如果这1s过来的请求数达到了3000，那么Tomcat的线程数就会为3000，maxConnections只是Tomcat做的一个限制。

## 2、为什么线程池会满？ ##

这是我现在纠结的核心。到底是不是应用的性能慢导致的，我现在的结论是有关系，但关键是并发。

Tomcat的线程池的线程数跟你的瞬间并发有关系，比如maxThreads设置为1000，当瞬间并发达到1000那么Tomcat就会起1000个线程来处理，这时候跟你应用的快慢关系不大。  
那么是不是并发多少Tomcat就会起多少个线程呢？这里还跟Tomcat的这几个参数设置有关系，看官方的解释是最靠谱的：

我简单理解就是：maxThreads:Tomcat线程池最多能起的线程数；maxConnections:Tomcat最多能并发处理的请求（连接）；acceptCount:Tomcat维护最大的对列数；minSpareThreads:Tomcat初始化的线程池大小或者说Tomcat线程池最少会有这么多线程。

比较容易弄混的是maxThreads和maxConnections这两个参数：maxThreads是指Tomcat线程池做多能起的线程数，而maxConnections则是Tomcat一瞬间做多能够处理的并发连接数。比如maxThreads=1000，maxConnections=800，假设某一瞬间的并发时1000，那么最终Tomcat的线程数将会是800，即同时处理800个请求，剩余200进入队列“排队”，如果acceptCount=100，那么有100个请求会被拒掉。

注意：根据前面所说，只是并发那一瞬间Tomcat会起800个线程处理请求，但是稳定后，某一瞬间可能只有很少的线程处于RUNNABLE状态，大部分线程是TIMED\_WAITING，如果你的应用处理时间够快的话。所以真正决定Tomcat最大可能达到的线程数是maxConnections这个参数和并发数，当并发数超过这个参数则请求会排队，这时响应的快慢就看你的程序性能了。

往期精彩内容：

[Java知识体系总结（2021版）][Java_2021]

[Java多线程基础知识总结（绝对经典）][Java]

[超详细的springBoot学习笔记][springBoot]

[常见数据结构与算法整理总结][Link 1]

[Java设计模式：23种设计模式全面解析（超级详细）][Java_23]

[Java面试题总结（附答案）][Java 1]

原创不易，转载自：[https://blog.csdn.net/hunhun1122/article/details/78818337][https_blog.csdn.net_hunhun1122_article_details_78818337]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2d1b3J1aV9qYXZh_size_16_color_FFFFFF_t_70]: /images/20210813/657685e4faf74db481610a08350e4322.png
[Java_2021]: https://blog.csdn.net/guorui_java/article/details/112391105
[Java]: https://blog.csdn.net/guorui_java/article/details/107599455
[springBoot]: https://blog.csdn.net/guorui_java/article/details/104137262
[Link 1]: https://blog.csdn.net/guorui_java/article/details/106217472
[Java_23]: https://blog.csdn.net/guorui_java/article/details/104026988
[Java 1]: https://blog.csdn.net/guorui_java/article/details/107803283
[https_blog.csdn.net_hunhun1122_article_details_78818337]: https://blog.csdn.net/hunhun1122/article/details/78818337