ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

tomcat线程池原理及参数释义

2021-04-02 09:34:07  阅读:237  来源: 互联网

标签:Socket 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

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有