在高版本的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的原始碼這麼多，我們到底要怎麼看這個程式碼呢？之前的[文章](https://www.cnblogs.com/54chensongxia/p/13236745.html)中總結了Tomcat的啟動流程，如下圖所示：  上面的時序圖給我們分析Connector元件的原始碼提供了思路：**從聯結器元件的init方法和start方法開始分析**。 ## Connector元件工作時序圖 **Spring Boot中內嵌 的Tomcat預設使用的都是NIO模式，想要研究BIO模式還要自己折騰一番**。Spring Boot中提供了`WebServerFactoryCustomizer`介面，我們可以實現這個介面來對Servlet容器工廠進行自定義配置。下面是我自己實現的一個配置類，只是簡單地將IO模型設定成了BIO模式，假如你還需要進行其他配置也可以在裡面進行額外配置。 ```java @Configuration public class TomcatConfig { @Bean public WebServerFactoryCustomizer tomcatCustomer() { return new TomcatCustomerConfig(); } public class TomcatCustomerConfig implements WebServerFactoryCustomizer { @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的埠繫結**。具體程式碼如下： ```java @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() + " :" + getPort(); else msg = orig.getMessage() + " " + getAddress().toString() + ":" + getPort(); BindException be = new BindException(msg); be.initCause(orig); throw be; } } } ``` 再來看JIoEndpoint的start方法。 ```java 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執行緒的具體實現。 ```java 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方法。 ```java 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連線。 ```xml

``` **執行緒池元件** Tomcat中的執行緒池是對JDK中執行緒池的簡單改裝。線上程建立策略上有點區別：Tomcat中的執行緒池線上程數大於coreSize後不會立馬將執行緒提交到佇列中，而是先判斷活動執行緒數是否已經達到maxSize，只有達到maxSize後才會將執行緒提交到佇列中。 Connector元件的Executor分為兩種型別：共享Executor和私有Executor。共享Executor的話是指在Service元件中定義的Executor。 **任務定義器SocketProcessor** 在將Socket扔進執行緒池之前我們需要定義任務怎麼處理這個Socket。SocketProcessor就是這個任務定義，這個類實現了Runnable介面。 ```java protected class SocketProcessor implements Runnable { //進行Debug除錯的時候可以從這個類的run方法開始除錯 @Override public void run() { //對套接字進行處理並輸出響應 //對連線限流器LimitLatch減一 //關閉套接字 } } ``` SocketProcessor的任務主要分為三個：處理套接字並響應客戶端，連線數計數器減1，關閉套接字。其中對套接字的處理是最重要也是最複雜的，它包括對底層套接字位元組流的讀取， HTTP協議請求報文的解析（請求行、請求頭部、請求體等資訊的解析），根據請求行解析得到的路徑去尋找相應虛擬主機上的Web專案資源，根據處理的結果組裝好HTTP協議響應報文輸出到客戶端。 這邊暫時先不分析對套接字的具體處理流程，因為這邊文章主要還是將聯結器的執行緒模型，涉及的東西太多容易搞混，關於Tomcat對socket的具體處理後面會寫文章