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

   tomcat线程池有如下参数：

   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密集，等等都会引起差异化。