其他分享
首页 > 其他分享> > tomcat线程池原理及参数释义

tomcat线程池原理及参数释义

作者:互联网

一、tomcat线程池介绍

一、tomcat线程池介绍

  Tomcat是使用最广的Java Web容器,功能强大,可扩展性强。最新版本的Tomcat(5.5.17)为了提高响应速度和效率,使用了Apache Portable Runtime(APR)作为最底层,使用了APR中包含Socket、缓冲池等多种技术,性能也提高了。APR也是Apache HTTPD的最底层。可想而知,同属于ASF(Apache Software Foundation)中的成员,互补互用的情况还是很多的,虽然使用了不同的开发语言。

Tomcat 的线程池位于tomcat-util.jar文件中,包含了两种线程池方案。

方案一:使用APR的Pool技术,使用了JNI;

方案二:使用Java实现的ThreadPool。这里介绍的是第二种。如果想了解APR的Pool技术,可以查看APR的源代码。
 

二、tomcat线程池工作原理

tomcat线程池有如下参数:

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

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

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

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

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

 

 

tomcat原理如上图

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

 Tomcat线程池在工作的时候,实际情况是:

ThreadPool默认创建了5个线程,保存在一个200的线程数组中,创建时就启动了这些线程,当然在没有请求时,它们都处理“等待”状态(其实就是一个while循环,不停的等待notify)。如果有请求时,空闲线程会被唤醒执行用户的请求。
具体的请求过程是: 服务启动时,创建一个一维线程数组(maxThread=200个),并创建空闲线程(minSpareThreads=5个)随时等待用户请求。 当有用户请求时,调用 threadpool.runIt(ThreadPoolRunnable)方法,将一个需要执行的实例传给ThreadPool中。其中用户需要执行的实例必须实现ThreadPoolRunnable接口。 ThreadPool 首先查找空闲的线程,如果有则用它运行要执行ThreadPoolRunnable;如果没有空闲线程并且没有超过maxThreads,就一次性创建 minSpareThreads个空闲线程;如果已经超过了maxThreads了,就等待空闲线程了。总之,要找到空闲的线程,以便用它执行实例。找到后,将该线程从线程数组中移走。 接着唤醒已经找到的空闲线程,用它运行执行实例(ThreadPoolRunnable)。 运行完ThreadPoolRunnable后,就将该线程重新放到线程数组中,作为空闲线程供后续使用。
 

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线程数总是超过最小空闲数,那么你的程序随时都处于繁忙状态,这时候出错的几率已经大大增加。是时候需要被重点关注了。

 

由此可以看出,Tomcat的线程池实现是比较简单的,ThreadPool.java也只有840行代码。用一个一维数组保存空闲的线程,每次以一个较小步伐(5个)创建空闲线程并放到线程池中。使用时从数组中移走空闲的线程,用完后,再“归还”给线程池。
 
ThreadPool提供的仅仅是线程池的实现,而如何使用线程池也是有很大学问的。让我们看看Tomcat是如何使用ThreadPool的吧。
 
Tomcat有两种EndPoint,分别是AprEndpoint和PoolTcpEndpoint。前者自己实现了一套线程池(其实这和Tomcat 老版本的方案是相同的,至今Tomcat中还保留着老版本的线程池,PoolTcpEndpoint也有类似的代码,通过“策略”可以选择不同的线程池方案)。我们只关注PoolTcpEndpoint如何使用ThreadPool的。
 
首先,PoolTcpEndpoint创建了一个ThreadPoolRunnable实例——LeaderFollowerWorkerThread,实际上该实例就是接收(Accept)并处理(Process)用户socket请求。接着将该实例放进ThreadPool中并运行,此时就可以接收用户的请求了。
 
当有Socket请求时,LeaderFollowerWorkerThread首先获得了Socket实例,注意此时LeaderFollowerWorkerThread并没有急着处理该Socket,而是在响应Socket消息前,再次将LeaderFollowerWorkerThread放进ThreadPool中,从而它(当然是另外一个线程了)可以继续处理其他用户的Socket请求;接着,拥有Socket的LeaderFollowerWorkerThread再来处理该用户的Socket请求。
 
整个过程与传统的处理用户Socket请求是不同的,也和Tomcat老版本不同。传统的处理方法是:有一个后台运行的监听线程负责统一处理接收(注意只是“接收”)Socket请求,当有新的Socket请求时,将它赋值给一个Worker线程(通常是唤醒该线程),并有后者处理Socket请求,监听线程继续等待其他Socket请求。所以整个过程中有一个从Listener到Worker切换的过程。
 
而新版本Tomcat很有创造性的使用了另外一种方法,正如前文所描述的,接收和处理某个用户Socket请求的始终是由一个线程全程负责,没有切换到其他线程处理,少了这种线程间的切换是否更有效率呢?我还不能确认。不过这种使用方式确实有别于传统模式,有种耳目一新的感觉。

参考: 

https://blog.csdn.net/li396864285/article/details/49331369

 

标签:Socket,tomcat,Tomcat,线程,释义,空闲,请求
来源: https://www.cnblogs.com/duanxz/p/14609153.html