溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
小編這次要給大家分享的是詳解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模式，假如你還需要進行其他配置也可以在里面進行額外配置。
@Configuration
public 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的端口綁定。具體代碼如下：
@Override
public 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方法。
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線程的具體實現。
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方法。
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連接。
<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接口。
protected class SocketProcessor implements Runnable {
//進行Debug調試的時候可以從這個類的run方法開始調試
@Override
public void run() {
//對套接字進行處理并輸出響應
//對連接限流器LimitLatch減一
//關閉套接字
}
}SocketProcessor的任務主要分為三個：處理套接字并響應客戶端，連接數計數器減1，關閉套接字。其中對套接字的處理是最重要也是最復雜的，它包括對底層套接字字節流的讀取， HTTP協議請求報文的解析（請求行、請求頭部、請求體等信息的解析），根據請求行解析得到的路徑去尋找相應虛擬主機上的Web項目資源，根據處理的結果組裝好HTTP協議響應報文輸出到客戶端。
看完這篇關于詳解Tomcat的線程模型中BIO模式的文章，如果覺得文章內容寫得不錯的話，可以把它分享出去給更多人看到。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
