详解Tomcat线程池原理及参数释义

omcat线程池有如下参数:

   maxThreads, 最大线程数,tomcat能创建来处理请求的最大线程数

   maxSpareTHreads, 最大空闲线程数,在最大空闲时间内活跃过,但现在处于空闲,若空闲时间大于最大空闲时   间,则回收,小于则继续存活,等待被调度。

   minSpareTHreads,最小空闲线程数,无论如何都会存活的最小线程数

   acceptCount, 最大等待队列数 ,请求并发大于tomcat线程池的处理能力,则被放入等待队列等待被处理。

   maxIdleTime, 最大空闲时间,超过这个空闲时间,且线程数大于最小空闲数的,都会被回收   

1.一张图看懂tomcat线程池。


       tomcat原理如上图。Tomcat线程池在工作的时候,实际情况是:以上述线程池为例,一开始就创建最小空闲数的线程在池里,20个,当同一时间请求数量大于最小空闲数20,比如来了50个并发请求,那么线程池还需要创建30个线程来处理请求。这时候当请求都处理完了,持续来的请求低于50个的时候,那么当时间过了60秒,并发数还是没有达到50,那么从第50个线程开始,线程池将按照,空闲时间达到60s的,开始逐个回收,49个,48个,47个,如此回收。如果并发请求小于20个,那么线程池会回收至20个的时候,停止回收,这就是最小空闲数的作用,即使一个请求都没有,那么线程池也得保证随时都有20个。所谓空闲回收是指:一个线程在60s的时间内,一直处于等待。那么就可以判定该线程是空闲。如果这个空闲线程是在最小空闲数以上,则会被回收。当请求并发高于500最大空闲数的时候,线程池是会继续创建线程的,来满足特大突发性并发。当并发请求数降下之后,线程池中有空闲,那么,无论线程空闲时间是否达到60s,线程池都会进行回收至500。500以类的线程也会根据空闲时间是否大于60s来判断是否需要进行回收。

2.下面我们详细结合实际情况来阐述tomcat线程池在实际运用中,是如何工作的,如何处理并发的。


       可以结合这个来看,最高的线程如果是繁忙的话,那么说明tomcat线程已经被打满了。
在短时间周期内,如果线程数忽然持续走高,说明有突发性请求已经打过来,且正在创建更多的线程去执行,这时候创建线程的过程中,请求处于被等待,越是最后的请求被等待的时间越长。而过一段时间,线程数降下去很多的话,说明突发性请求已经过去了,线程池里的线程空闲时间达到了最大空闲时间,比如60s,那么即将被回收。


       我个人觉得,这种现象应该被归属于不健康状态。因为请求来了,如果等待的线程只有10个以下,那么等待时间不会太长。但是如果等待时间达到10个以上,等待时间就会呈几何方式上升的,且线程处理时间也会呈几何倍数上升,因为同一个线程池里的线程之间要相互竞争CPU资源,比如现在tomcat运行中有1000个线程,假如每个CPU的时间片为0.01秒,那么,轮到第1000个线程执行时,该线程实际已经等待了999个时间片*0.01=1秒了,这还只是一次时间片执行,0.01秒相当于10ms,而咱们的一个请求正常情况下的时间是:30ms,那一个请求要成功就需要等待3次cpu时间片来执行,如果tomcat线程池一直有1000个在运行,那正常情况下一个请求的执行时间应该是:0.03+999*0.01*3=3.03s,可想而知,执行一个请求只需要30ms,可是却要等待需要3s,这是相当不靠谱的且难以接受的。再假如,时间片是20ms,那么一个请求从进入等待到执行完毕的执行时间应该是多少?0.03+999*0.02*(0.03/0.02=取大于整数=2)+CPU切换时间a*999次=4.03s+999a,这已经很夸张了吧!

       咱们还可以理想一点,加入线程池里只有500个活跃线程,那么上面的公式应该是:当cpu时间片为0.01s时,最后一个请求需要处理成功,需要用时:0.03+500*0.01*3= 1.53s,当cpu时间片为0.02s时,最后一个请求需要处理成功,需要用时:0.03+500*0.02*2= 2.03s,当cpu时间片为0.03s时,最后一个请求需要处理成功,需要用时:0.03+500*0.03*1= 1.53s。

      但是这只是cpu执行时间,还要加上网络传输,创建线程时间,cpu切换线程所需时间,还有其他时间,总共加起来,就是一个很可怕的时间了。所以,即使tomcat有线程池,但最好不要总是超过最小空闲数,这是最优的情况,最次的情况就是tomcat线程池中线程数超过最大空闲数了,线程们总是繁忙地工作,宕机随时有可能。

      而健康状态是:线程池保持最小空闲数才算是健康,如果你的tomcat线程数总是超过最小空闲数,那么你的程序随时都处于繁忙状态,这时候出错的几率已经大大增加。是时候需要被重点关注了。

以上,仅个人观点,具体情况还得实际分析。还需要考虑Cpu个数性能,网络,操作系统,实例是否混部,应用类型是cpu密集还是IO密集,等等都会引起差异化。

原文地址:https://www.cnblogs.com/liuchuanfeng/p/6876645.html
原文地址:https://www.cnblogs.com/jpfss/p/11987599.html