The previous talk on the Block diagram of NIO, it can be seen that the NIO channel is currently TOMCAT7 after the default channel recommended configuration, in Tomcat6 and previous configuration, bio is the mainstream configuration:
You only need to modify the Protocol Protocol section, and the following is the APR protocol, NIO2.0 protocol, is to modify this field.
For the overall block diagram of bio, the basic and NiO remain similar and the overall process changes little:
1.http11protocolLike NiO, this http11protocol is the default BIO-http1.1 protocol Handler class, and Tomcat has two channels in addition to Nio,bio:
Apr is a high-performance channel, and NIO2 is a channel based on pure asynchronous IO, which is explained later in Tomcat.
The Http11protocol class still holds references to endpoint and handler:
Only, bio corresponds to the endpoint is Jioendpoint, the corresponding handler is Http11connectionhandler.
2.JIoEndpoint
Jioendpoint is the endpoint class for bio, which, like NIO, maintains the thread pool, Just because there is no selector.select, no Socketchannel channel registration, so compared to the NIO mode, no poller thread is very easy to understand, but the NIO three threads is not easy to understand, bio can be seen as a socket-based operation.
First, the initializedJioendpoint, you call theThe Bind method binds ServerSocket to the corresponding port:
The Bind method is the initialization of the constructJioendpoint's important step, his main role is to establish serversocketfactory. depending on the SSL channel or the normal HTTP channel, Tomcat implements the Serversocketfactory,of the normal HTTP channel.Serversocketfactory is the Defaultserversocketfactory class, its factory method is to create ServerSocket, very simple:
For SSL channels, theServersocketfactory is jsseserversocketfactory, and this class is created by Sslserversocket:
second, when the Jioendpoint is started, the acceptor thread and the work thread pool start up:
In addition, a dedicated thread is started, which is the timeout for checking for asynchronous requests, followed by an asynchronous request specifically for Tomcat.
The working thread pool, using the threadpoolexecutor that comes with the JDK:
You can see from the stack of threads that the corresponding http-bio-8443-exec-n threads are working thread pools:
If you do not specify a work thread pool setting in Tomcat, the default value for the Threadpoolexecutor that comes with the JDK is gone.
3.Acceptor Threads
The main role of the acceptor thread, like NIO, is that the thread will remain blocked serversocket.accept if there is no network IO data. When there is data, first set the Socekt data to some properties of the connector configuration, and then pass the baton to the worker thread pool:
The last step of the Processsocket method is very simple:
The worker thread pool is called directly, and Socketprocessor is passed as a work task into the worker pools for execution.
This step compared to the NIO architecture, the pollerevent in the NIO channel is missing a cached queue, there is such a queue in NIO because of the need from the acceptor to the poller thread, intermediate delivery needs a cache place, and can see the code in the above bio, If the working thread pool is fully loaded, it will be based on the JDKThreadpoolexecutor's strategy is to cache, to reject directly, or to wait for timeout, but Bio has given the decision toThreadpoolexecutor to do it.
Foracceptor thread also has an important role, is to control the number of connections, this is not explained in the analysis of the NIO channel, here to seeThe acceptor thread checks for the current maximum number of connections in the while polling at the beginning of the firstif it is exceeded, the sequence called Limitlatch is locked directly. we found that, in fact,Limitlatch also mimics the read-write lock in the JDK, which holds a sync class that inherits the Aqs queue of the hidden work and name in the JDK, whichAqs queue is still more famous, last year in the analysis of the JDK source code, many times in the N concurrent classes have seen his traces, the implementation of almost all of the CAS lock implementation.
4.SocketProcessor Work Tasks
Socketprocessor is a work task that is used to pass into the worker pool, and the input is the Socketwapper wrapper that acceptor passes over:
If it is SSL interaction, Tomcat opens the handshake, but there is no corresponding implementation, this is because the handshake under SSL is done in the sun's package, the Sslserversocket interface provided by the JDK has hidden this detail, We can see from the second step of handshake:
Tomcat can get sslsession directly, this class can get the equivalent of SSL is already a handshake succeeded, otherwise there will be failure. The two steps for why Beforehandshake and handshake are retained are to be compatible with interfaces that interact with Sslengine in the NIO channel. For the moment, the most important step is the 3rd step, which is handler.process, which handles the HTTP protocol through Http11conenctionhandler, and turns out the response and request two objects and passes them to the backend container.
Summary
The follow-up process is basically the same as the NIO channel, summed up, the structure of bio because of lack of selector and polling, compared to NiO less part of the content, the whole is the use of serversocket to communicate, the first-line Cheng request mode, the code looks clear and understandable, but, Since the bio model is relatively backward, in most scenarios it is not as NIO, and now the new version of Tomcat is also NIO is the default configuration.
From for notes (Wiz)
B.bio Connector monolithic block diagram
