一张图看懂Tomcat线程池
tomcat原理如上图。Tomcat线程池在工作的时候，实际情况是：以上述线程池为例，一开始就创建最小空闲数的线程在池里，20个，当同一时间请求数量大于最小空闲数20，比如来了50个并发请求，那么线程池还需要创建30个线程来处理请求。这时候当请求都处理完了，持续来的请求低于50个的时候，那么当时间过了60秒，并发数还是没有达到50，那么从第50个线程开始，线程池将按照，空闲时间达到60s的，开始逐个回收，49个，48个，47个，如此回收。如果并发请求小于20个，那么线程池会回收至20个的时候，停止回收，这就是最小空闲数的作用，即使一个请求都没有，那么线程池也得保证随时都有20个。所谓空闲回收是指：一个线程在60s的时间内，一直处于等待。那么就可以判定该线程是空闲。如果这个空闲线程是在最小空闲数以上，则会被回收。当请求并发高于500最大空闲数的时候，线程池是会继续创建线程的，来满足特大突发性并发。当并发请求数降下之后，线程池中有空闲，那么，无论线程空闲时间是否达到60s，线程池都会进行回收至500。500以类的线程也会根据空闲时间是否大于60s来判断是否需要进行回收。
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，这已经很夸张了吧！
但是这只是cpu执行时间，还要加上网络传输，创建线程时间，cpu切换线程所需时间，还有其他时间，总共加起来，就是一个很可怕的时间了。所以，即使tomcat有线程池，但最好不要总是超过最小空闲数，这是最优的情况，最次的情况就是tomcat线程池中线程数超过最大空闲数了，线程们总是繁忙地工作，宕机随时有可能。
而健康状态是：线程池保持最小空闲数才算是健康，如果你的tomcat线程数总是超过最小空闲数，那么你的程序随时都处于繁忙状态，这时候出错的几率已经大大增加。是时候需要被重点关注了。
网友评论