浅析Tomcat高并发之连接池，线程池

不念不忘少年蓝@ 2022-11-21 01:06 168阅读 0赞

JAVA互联. 砖工人 2020-10-27

记得大学的《网络工程》有一个课后作业：用Java实现一个web服务器，当时想的是为了提高吞吐量，可以用多线程实现，即对于每一个客户端请求连接，都启动一个线程来处理，处理逻辑大概就是从socket里面读取http请求，解析执行请求，执行完把response写回socket，线程结束销毁。

用多线程实现确实提高了吞吐量，但是也有一些问题：

1）不断的线程创建销毁需要耗费大量的开销；2）线程之间的切换需要耗费很多开销；3）Java有创建最多线程数量的限制，

具体可参考https://www.iteye.com/blog/jzhihui-1271122。

如果要优化上面的实现，可以怎么做呢？其实参考tomcat的发展进程，就是优化的方向。

**1**

Tomcat处理用户请求的入口组件叫做Connector，其有两个主要的实现：BIO（blocking io）和NIO（non-blocking io）。

![浅析Tomcat高并发之连接池，线程池][Tomcat]

简单讲，BIO的实现就是对上面多线程版本的一个改进，主要点在于把“每来一个连接启动一个线程处理”改成“每来一个连接都提交给线程池处理”。虽然线程池根据不同的配置，其工作行为会有所不同，但一般来讲，使用线程池的原则是：只需创建少量的线程就可以完成大量任务的执行，由于同时至多只有固定量的线程执行，剩余的任务会被放进queue里面缓冲起来，从这个角度看，这是一个典型的生产者-消费者模型。回到tomcat BIO，acceptor不断的接收连接，然后提交给线程池执行，acceptor就是生产者；线程池的每一个线程就是消费者，负责处理请求。

由于socket连接是长连接，连接的创建销毁也是很耗资源的，于是http协议增加了一个keep-alive header，这个header的意思是提示服务器端，在返回http response之后，不要断开socket，继续处理后续http请求，这样做的目的就是为了提高资源的可重用性。那么，对于tomcat BIO的实现，在keep-alive场景下，会有什么问题呢？如果一个线程处理的socket需要保持keep-alive，其在执行完一个http请求之后，需要阻塞在那里以等待下一个http请求，不能马上结束（直到timeout）；在某些情况下，这样就可能存在大量的阻塞线程，新的连接不能被处理。

基于此，NIO就可以解决这个问题。**NIO和BIO在请求处理部分的实现是一致的，都是基于线程池；不同的地方是：NIO的acceptor基于jdk nio实现，在收到一个连接之后，会把socketChannel注册到poller的selector上面，当socketChannel有数据可读时，poller就把此连接提交给线程池处理。**回到上面keep-alive的场景，当一个线程处理完一个http请求之后，就可以马上结束，当前连接则回到selector继续监听接下来的http请求。所以，基于NIO的执行线程就不会出现基于BIO的阻塞情况。

NIO的核心在于selector，selector可以识别到已经ready的连接和没有ready的连接；在之前的一篇多线程文章（对比Java和.NET多线程编程）里面提到过，jdk的concurrency API有一个CompletionService类，就有点类似于nio的原理。

由于NIO天生的优势，**tomcat从8.0版本开始就把NIO设成默认的Connector，而从8.5版本开始直接就把BIO去掉了。**

**2**

在tomcat的官网有下面一段关于如何高并发处理请求的描述：

*Each incoming request requires a thread for the duration of that request. If more simultaneous requests are received than can be handled by the currently available request processing threads, additional threads will be created up to the configured maximum (the value of the maxThreads attribute). If still more simultaneous requests are received, they are stacked up inside the server socket created by the Connector, up to the configured maximum (the value of the acceptCount attribute). Any further simultaneous requests will receive "connection refused" errors, until resources are available to process them.*

*- https://tomcat.apache.org/tomcat-7.0-doc/config/http.html*

个人觉得其没有反映出maxConnections这个参数的作用，所以应该是：如果maxConnections小于maxThreads，最大创建的线程数就是maxConnections的值，最大连接数也是maxConnections的值；但是如果maxConnections大于maxThreads，最大创建的线程数就是maxThreads的值，最大连接数则是maxConnections的值。

由于BIO和NIO底层实现的区别，配置maxConnections的值也需要区别考虑，这在maxConnections的默认值中就有所体现**（对于BIO，maxConnections的默认值是maxThreads的值；而对于NIO，maxConnections的默认值则是10000):**

![浅析Tomcat高并发之连接池，线程池][Tomcat 1]

**3**

上面有提到，tomcat接收处理请求的过程其实就是一个生产者-消费者模型，影响tomcat高并发的配置也可以首先分别从这两个方面考虑：

*生产者*

![浅析Tomcat高并发之连接池，线程池][Tomcat 2]

*消费者*

![浅析Tomcat高并发之连接池，线程池][Tomcat 3]

*Queue*

![浅析Tomcat高并发之连接池，线程池][Tomcat 4]

**4**

小结一下：

*  线程池的本质就是节省了不断创建销毁线程的开销；加上queue的使用，增加了一层缓冲，一定程度缓解了计算机的压力。当然线程池的配置，需要根据要处理的任务（CPU密集型还是io密集型）来仔细的考虑。
 *  Tomcat里面BIO和NIO的最大区别在于读取下一个请求时是否需要阻塞，这对于keep-alive的场景尤其重要，NIO可以大大提高吞吐量。
 *  基于queue的生成者-消费者模型，也常常应用在系统架构层面，以缓冲生产者和消费者之间处理速度的gap，比如秒杀系统。

本文分享自微信公众号 - 天马行空布鲁斯（gh\_2feda5c053bd）。  
如有侵权，请联系 删除。

[Tomcat]: /images/20221120/a26d591cb4e74d3baacfa0a68774e5b2.png
[Tomcat 1]: https://img-blog.csdnimg.cn/img_convert/76b9bf2802053f46964f432b54ddfc7e.png
[Tomcat 2]: https://img-blog.csdnimg.cn/img_convert/cd8baf8e67458856be885237ed50e7f2.png
[Tomcat 3]: https://img-blog.csdnimg.cn/img_convert/9c80c593cacae1000791bbfb6ba73891.png
[Tomcat 4]: https://img-blog.csdnimg.cn/img_convert/f95c1c5798eb7ab1783d42d90f9bc9f6.png