这篇文章主要介绍了从连接器组件看Tomcat的线程模型——BIO模式,本文给大家介绍的非常详细，对大家的学习或工作具有一定的参考借鉴价值，需要的朋友可以参考下
正文
从连接器组件看Tomcat的线程模型——BIO模式(推荐)
在高版本的tomcat中，默认的模式都是使用nio模式，在tomcat 9中，bio模式的实现http11protocol甚至都已经被删除了。但是了解bio的工作机制以及其优缺点对学习其他模式有有帮助。只有对比后，你才能知道其他模式的优势在哪里。
http11protocol表示阻塞式的http协议的通信，它包含从套接字连接接收、处理、响应客户端的整个过程。它主要包含jioendpoint组件和http11processor组件。启动时，jioendpoint组件将启动某个端口的监听，一个请求到来后将被扔进线程池，线程池进行任务处理，处理过程中将通过协议解析器http11processor组件对http协议解析，并且通过适配器adapter匹配到指定的容器进行处理以及响应客户端。
这里我们结合spring boot中内嵌的tomcat来看看连接器的工作原理。建议使用低版本的spring boot，高版本的spring boot中，都已经使用tomcat 9了。tomcat 9已经删除了bio的实现模式。这边我选择的spring boot版本是2.0.0.release。
要怎么看connector组件的源代码
我们现在要开始通过connector组件的源代码来分析连接器组件的工作过程。但是tomcat的源代码这么多，我们到底要怎么看这个代码呢？之前的中总结了tomcat的启动流程，如下图所示：
上面的时序图给我们分析connector组件的源代码提供了思路：从连接器组件的init方法和start方法开始分析。
connector组件工作时序图
spring boot中内嵌 的tomcat默认使用的都是nio模式，想要研究bio模式还要自己折腾一番。spring boot中提供了webserverfactorycustomizer接口，我们可以实现这个接口来对servlet容器工厂进行自定义配置。下面是我自己实现的一个配置类，只是简单地将io模型设置成了bio模式，假如你还需要进行其他配置也可以在里面进行额外配置。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
@configurationpublic class tomcatconfig { @bean public webserverfactorycustomizer tomcatcustomer() { return new tomcatcustomerconfig(); } public class tomcatcustomerconfig implements webserverfactorycustomizer<tomcatservletwebserverfactory> { @override public void customize(tomcatservletwebserverfactory factory) { if (factory != null) { factory.setprotocol("org.apache.coyote.http11.http11protocol"); } } }} |
经过上面的配置后，tomcat的连接器组件就会以bio的模式处理请求。
由于tomcat整理的代码非常多，想要在一篇文章中分析所有的代码是不太现实的。这边，我梳理了连接器组件工作的时序图，根据这个时序图，我分析了几个关键的代码点，其他细节大家可以根据我的时序图自己看代码，这块代码也不是很复杂。
这边的重点代码是在jioendpoint的init()方法和start()方法。jioendpoint的init()方法主要是做了serversocket的端口绑定。具体代码如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
@overridepublic void bind() throws exception { // initialize thread count defaults for acceptor if (acceptorthreadcount == 0) { acceptorthreadcount = 1; } // initialize maxconnections if (getmaxconnections() == 0) { // user hasn't set a value - use the default setmaxconnections(getmaxthreadswithexecutor()); } if (serversocketfactory == null) { if (issslenabled()) { serversocketfactory = handler.getsslimplementation().getserversocketfactory(this); } else { serversocketfactory = new defaultserversocketfactory(this); } } //这边做了serversocket的端口绑定 if (serversocket == null) { try { if (getaddress() == null) { //没指定具体地址，tomcat会监听所有地址过来的请求 serversocket = serversocketfactory.createsocket(getport(), getbacklog()); } else { //指定了具体地址，tomcat只监听这个地址过来的请求 serversocket = serversocketfactory.createsocket(getport(), getbacklog(), getaddress()); } } catch (bindexception orig) { string msg; if (getaddress() == null) msg = orig.getmessage() + " <null>:" + getport(); else msg = orig.getmessage() + " " + getaddress().tostring() + ":" + getport(); bindexception be = new bindexception(msg); be.initcause(orig); throw be; } }} |
再来看jioendpoint的start方法。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public void startinternal() throws exception { if (!running) { running = true; paused = false; //创建线程池 if (getexecutor() == null) { createexecutor(); } //创建connectionlatch initializeconnectionlatch(); //创建accept线程，这个线程是请求处理的初始线程 startacceptorthreads(); // start async timeout thread thread timeoutthread = new thread(new asynctimeout(), getname() + "-asynctimeout"); timeoutthread.setpriority(threadpriority); timeoutthread.setdaemon(true); timeoutthread.start(); }} |
上面的代码中，需要我们重点关注的就是startacceptorthreads()方法。我们看下这个accept线程的具体实现。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
protected final void startacceptorthreads() { int count = getacceptorthreadcount(); acceptors = new acceptor[count]; //根据配置，设置一定数量的accept线程 for (int i = 0; i < count; i++) { acceptors[i] = createacceptor(); string threadname = getname() + "-acceptor-" + i; acceptors[i].setthreadname(threadname); thread t = new thread(acceptors[i], threadname); t.setpriority(getacceptorthreadpriority()); t.setdaemon(getdaemon()); t.start(); }} |
acceptor线程的具体处理实现，重点看run方法。
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
|
protected class acceptor extends abstractendpoint.acceptor { @override public void run() { int errordelay = 0; // loop until we receive a shutdown command while (running) { // loop if endpoint is paused while (paused && running) { state = acceptorstate.paused; try { thread.sleep(50); } catch (interruptedexception e) { // ignore } } if (!running) { break; } state = acceptorstate.running; try { //if we have reached max connections, wait //达到连接上限，acceptor线程进入等待状态，直到其他线程释放,这是一种简单的通过连接数量进行流量控制的手段 //通过实现aqs组件实现（limitlatch），思路是先初始化同步器的最大限制值，然后每接收一个套接字就将计数变量累加1，每关闭一个套接字将计数变量减1 countuporawaitconnection(); socket socket = null; try { //accept下个socket连接，如果一直没有连接过来这个方法阻塞 socket = serversocketfactory.acceptsocket(serversocket); } catch (ioexception ioe) { //有异常的话释放一个连接数 countdownconnection(); errordelay = handleexceptionwithdelay(errordelay); throw ioe; } // successful accept, reset the error delay errordelay = 0; //对socket进行适当配置 if (running && !paused && setsocketoptions(socket)) { // 处理这个socket请求，这边也是重点。 if (!processsocket(socket)) { countdownconnection(); // close socket right away closesocket(socket); } } else { countdownconnection(); // close socket right away closesocket(socket); } } catch (ioexception x) { if (running) { log.error(sm.getstring("endpoint.accept.fail"), x); } } catch (nullpointerexception npe) { if (running) { log.error(sm.getstring("endpoint.accept.fail"), npe); } } catch (throwable t) { exceptionutils.handlethrowable(t); log.error(sm.getstring("endpoint.accept.fail"), t); } } state = acceptorstate.ended; } } |
上面线程处理类中的processsocket(socket)是处理具体请求的方法，这个方法将请求进行了包装然后“扔进”了线程池进行处理。但是这个不是连接器组件的重点，后面会在介绍请求流转时介绍tomcat怎么处理请求的。
到这边，对tomcat的bio模式做了个简单的介绍。其实大家可以看出来，如果对bio模式进行简化的话就是对传统的serversocket的操作，还有就是对请求的处理加上了线程池优化。
bio模式总结
关于上图中的各个组件做下简要说明。
限流组件limitlatch
limitlatch组件是一个流量控制组件，目的是为了不让tomcat组件被大流量冲垮。limitlatch通过aqs机制实现，这个组件启动时先初始化同步器的最大限制值，然后每接收一个套接字就将计数变量累加1，每关闭一个套接字将计数变量减1。当连接数达到最大值时，acceptor线程就进入等待状态，不再accept新的socket连接。
需要额外说明的是，当到达最大连接数时（已经limitlatch组件最大值，acceptor组件阻塞了），操作系统底层还是会继续接收客户端连接，并将请求放入一个队列中（backlog队列）。这个队列是有一个默认长度的，默认值是100。当然，这个值可以通过server.xml的connector节点的acceptcount属性配置。假如在短时间内，有大量请求过来，连backlog队列都放满了，那么操作系统将拒绝接收后续的连接，返回“connection refused”。
在bio模式中，limitlatch组件支持的最大连接数是通过server.xml的connector节点的maxconnections属性设置的，如果设置成-1，则表示不限制。
接收器组件acceptor
这个组件的职责非常简单，就是接收socket连接，对socket做相应的设置，然后直接丢给线程池处理。accept线程的数量也可以进行配置。
套接字工厂serversocketfactory
acceptor线程在具体accept socket连接时是通过serversocketfactory组件获取的。tomcat中有两个serversocketfactory的实现：defaultserversocketfactory和jssesocketfactory。分别对应http和https的情况。
tomcat中存在一个变量sslenabled用于标识是否使用加密通道，通过对此变量的定义就可以决定使用哪个工厂类，tomcat提供了外部配置文件供用户自定义。下面的配置中sslenabled="true"表示使用加密方式，也就是使用jssesocketfactory来accept具体的socket连接。
|
1
2
3
4
5
6
7
|
<connector port="8443" protocol="org.apache.coyote.http11.http11nioprotocol" maxthreads="150" sslenabled="true"> <sslhostconfig> <certificate certificatekeystorefile="conf/localhost-rsa.jks" type="rsa" /> </sslhostconfig></connector> |
线程池组件
tomcat中的线程池是对jdk中线程池的简单改装。在线程创建策略上有点区别：tomcat中的线程池在线程数大于coresize后不会立马将线程提交到队列中，而是先判断活动线程数是否已经达到maxsize，只有达到maxsize后才会将线程提交到队列中。
connector组件的executor分为两种类型：共享executor和私有executor。共享executor的话是指在service组件中定义的executor。
任务定义器socketprocessor
在将socket扔进线程池之前我们需要定义任务怎么处理这个socket。socketprocessor就是这个任务定义，这个类实现了runnable接口。
|
1
2
3
4
5
6
7
8
9
|
protected class socketprocessor implements runnable { //进行debug调试的时候可以从这个类的run方法开始调试 @override public void run() { //对套接字进行处理并输出响应 //对连接限流器limitlatch减一 //关闭套接字 }} |
socketprocessor的任务主要分为三个：处理套接字并响应客户端，连接数计数器减1，关闭套接字。其中对套接字的处理是最重要也是最复杂的，它包括对底层套接字字节流的读取， http协议请求报文的解析（请求行、请求头部、请求体等信息的解析），根据请求行解析得到的路径去寻找相应虚拟主机上的web项目资源，根据处理的结果组装好http协议响应报文输出到客户端。
这边暂时先不分析对套接字的具体处理流程，因为这边文章主要还是将连接器的线程模型，涉及的东西太多容易搞混，关于tomcat对socket的具体处理后面会写文章分析。
总结
到此这篇关于从连接器组件看tomcat的线程模型——bio模式的文章就介绍到这了,更多相关tomcat线程模型内容请搜索’米米素材网’以前的文章或继续浏览下面的相关文章希望大家以后多多支持’米米素材网’！
原文链接：https://www.cnblogs.com/54chensongxia/p/13289055.html
发表评论