深入理解 Tomcat（八）源码剖析之连接器
這是我們分析tomcat的第八篇文章，這次我們分析連接器，我們早就想分析連接器了，因為各種原因拖了好久。不過也確實復雜。
首先我們之前定義過連接器：
Tomcat都是在容器里面處理問題的， 而容器又到哪里去取得輸入信息呢？ Connector就是專干這個的。 他會把從socket傳遞過來的數據， 封裝成Request, 傳遞給容器來處理。 通常我們會用到兩種Connector,一種叫http connectoer， 用來傳遞http需求的。 另一種叫AJP， 在我們整合apache與tomcat工作的時候，apache與tomcat之間就是通過這個協議來互動的。 （說到apache與tomcat的整合工作， 通常我們的目的是為了讓apache 獲取靜態資源， 而讓tomcat來解析動態的jsp或者servlet。）
簡單來說，連接器就是接收http請求并解析http請求，然后將請求交給servlet容器。
那么在 Tomcat中 ，那個類表示連接器呢？ 答案是 org.apache.catalina.connector.Connector，該類繼承自 LifecycleMBeanBase， 也就是說，該類的生命周期歸屬于容器管理。而該類的父容器是誰呢？ 答案是 org.apache.catalina.core.StandardService，也就是我們的Service 組件，StandardService是該接口的標準實現。StandardService 聚合了 Connector 數組和一個Container 容器，也就驗證了我們之前說的一個Service 組件中包含一個Container和多個連接器。
那么連接器什么時候初始化被放入容器和JMX呢?這是個大問題，也是我們今天的主要問題。
1. Tomcat 解析 server.xml 并創建對象
我們之前扒過啟動源碼，我們知道，在Catalina 的 load 方法中是初始化容器的方法，所有的容器都是在該方法中初始化的。Connector 也不例外。我們還記得 Tomcat 的conf 目錄下的server.xml 文件嗎？
xml version='1.0' encoding='utf-8'<Server port="8005" shutdown="SHUTDOWN"><Listener className="org.apache.catalina.startup.VersionLoggerListener" /><Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" /><Listener className="org.apache.catalina.core.JasperListener" /><Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" /><Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" /><Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" /><GlobalNamingResources><Resource name="UserDatabase" auth="Container"type="org.apache.catalina.UserDatabase"description="User database that can be updated and saved"factory="org.apache.catalina.users.MemoryUserDatabaseFactory"pathname="conf/tomcat-users.xml" /></GlobalNamingResources><Service name="Catalina"><Connector port="8061" protocol="HTTP/1.1"connectionTimeout="20000"redirectPort="8443" /><Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /><Engine name="Catalina" defaultHost="localhost"><Realm className="org.apache.catalina.realm.LockOutRealm"><Realm className="org.apache.catalina.realm.UserDatabaseRealm"resourceName="UserDatabase"/></Realm><Host name="localhost" appBase="webapps"unpackWARs="true" autoDeploy="true"><Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs"prefix="localhost_access_log." suffix=".txt"pattern="%h %l %u %t "%r" %s %b" /></Host></Engine></Service> </Server> 復制代碼可以看到該配置文件中有2個Connector 標簽，有就是說默認有2個連接器。一個是HTTP協議，一個AJP協議。
我們的Connector是什么時候創建的呢？就是在解析這個xml文件的時候，那么是怎么解析的呢？我們平時在解析 xml 的時候經常使用dom4j（真的不喜歡xml，最愛json），而tomcat 使用的是 Digester 解析xml，我們來看看 Catalina.load（） 關于解析并創建容器的關鍵代碼：
public void load() {// Create and execute our DigesterDigester digester = createStartDigester();digester.parse(inputSource);} 復制代碼首先創建一個 Digester， 其中的關鍵代碼我們看看：
Digester digester = new Digester();digester.addRule("Server/Service/Connector",new ConnectorCreateRule()); digester.addRule("Server/Service/Connector",new SetAllPropertiesRule(new String[]{"executor"})); digester.addSetNext("Server/Service/Connector","addConnector","org.apache.catalina.connector.Connector"); 復制代碼上面的代碼的意思是將對應的字符串創建成對應的角色，以便后面和xml對應便解析。
我們再看看它是如何解析的，由于 digester.parse(inputSource) 這個方法調用層次太深，而且該方法只是解析xml，因此樓主把就不把每段代碼貼出來了，我們看看IDEA生成的該方法的方法調用棧：這些方法都是在 rt.jar 包中，因此我們不做分析了。主要就是解析xml。
上圖是樓主在 Digester.startDocument 的方法中打的斷點。該方法作用為開始解析 xml 做準備。
上圖是樓主在 Digester.startElement 的方法中打的斷點，startDocument 和 startElement 是多次交替執行的，確定他們執行邏輯的是什么方法呢？從堆棧圖中我們可以看到：是 com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse（）這個方法，代碼我就不貼出來了，很長沒有意義，該方法在 819行間接調用 startDocument，在841行間接調用startElement。上下執行，并且回執行多次。因為 xml 會解析多次嘛。
我們重點說說 startElement 方法：
public void startElement(String namespaceURI, String localName,String qName, Attributes list) {List<Rule> rules = getRules().match(namespaceURI, match);matches.push(rules);if ((rules != null) && (rules.size() > 0)) {for (int i = 0; i < rules.size(); i++) {try {Rule rule = rules.get(i);if (debug) {log.debug(" Fire begin() for " + rule);}rule.begin(namespaceURI, name, list);} catch (Exception e) {log.error("Begin event threw exception", e);throw createSAXException(e);} catch (Error e) {log.error("Begin event threw error", e);throw e;}}} } 復制代碼樓主只貼了關鍵代碼，就是for循環中的邏輯，便利 Rule 集合，Rule 是什么呢？是我們之前 createStartDigester 方法里創建的。而 Rule 是一個接口，tomcat 中有很多不同的實現。然后循環調用他們的 begin 方法。我們看看有哪些實現：
我們從上圖中看到了有很多的實現，而我們今天只關注連接器：也就是 ConnectorCreateRule 的 begin 方法：
public void begin(String namespace, String name, Attributes attributes)throws Exception {Service svc = (Service)digester.peek();Executor ex = null;if ( attributes.getValue("executor")!=null ) {ex = svc.getExecutor(attributes.getValue("executor"));}Connector con = new Connector(attributes.getValue("protocol"));if ( ex != null ) _setExecutor(con,ex);digester.push(con);}復制代碼方法不長，我們看看該方法邏輯，該方法首先從List中取出一個Service，然后會分別創建2個連接器，一個是HTTP， 一個是AJP，也就是我們配置文件中寫的。
現在，我們已經剖析了tomcat 是如何解析xml的，并如何創建對象的，接下來，我們就看看創建對象的邏輯。
2. 創建連接器對象
我們來到我們的Connector類的構造方法：
public Connector() {this(null);}public Connector(String protocol) {setProtocol(protocol);// Instantiate protocol handlertry {Class<?> clazz = Class.forName(protocolHandlerClassName);this.protocolHandler = (ProtocolHandler) clazz.newInstance();// 反射創建protocolHandler 默認 http1.1 協議實現 （org.apache.coyote.http11.Http11Protocol）} catch (Exception e) {log.error(sm.getString("coyoteConnector.protocolHandlerInstantiationFailed"), e);}}復制代碼我記得阿里規約里說，構造器不要太復雜，復雜的邏輯請放在init里，不知道tomcat這么寫算好還是不好呢？嘿嘿。我們還是來看看我們的邏輯吧。
既然是反射創建，那么我們就要看看完整的類名是什么了，所以需要看看設置 protocolHandlerClassName 方法的細節：
public void setProtocol(String protocol) {if (AprLifecycleListener.isAprAvailable()) {if ("HTTP/1.1".equals(protocol)) {setProtocolHandlerClassName("org.apache.coyote.http11.Http11AprProtocol");} else if ("AJP/1.3".equals(protocol)) {setProtocolHandlerClassName("org.apache.coyote.ajp.AjpAprProtocol");} else if (protocol != null) {setProtocolHandlerClassName(protocol);} else {setProtocolHandlerClassName("org.apache.coyote.http11.Http11AprProtocol");}} else {if ("HTTP/1.1".equals(protocol)) {setProtocolHandlerClassName("org.apache.coyote.http11.Http11Protocol");} else if ("AJP/1.3".equals(protocol)) {setProtocolHandlerClassName("org.apache.coyote.ajp.AjpProtocol");} else if (protocol != null) {setProtocolHandlerClassName(protocol);}}}復制代碼此方法會直接進入下面的else塊，我們知道，該處可能會傳 HTTP 或者 AJP ，根據不同的協議創建不同的協議處理器。也就是連接器，我們看到這里的全限定名是 org.apache.coyote.http11.Http11Protocol 或者 org.apache.coyote.ajp.AjpProtocol，這兩個類都是在 coyote 包下，也就是連接器模塊。
好了，到現在，我們的 Connector 對象就創建完畢了，創建它的過程同時也根據配置文件創建了 protocolHandler， 他倆是依賴關系。
3. Http11Protocol 協議處理器構造過程
創建了 Http11Protocol 對象，我們有必要看看他的構造過程是什么樣的。按照tomcat的性格，一般構造器都很復雜，所以，我們找到該類，看看他的類和構造器：
該類的類說明是這樣說的：
抽象協議的實現，包括線程等。處理器是單線程的，特定于基于流的協議，不適合像JNI那樣的Jk協議。
我們看看構造方法
public Http11Protocol() {endpoint = new JIoEndpoint();cHandler = new Http11ConnectionHandler(this);((JIoEndpoint) endpoint).setHandler(cHandler);setSoLinger(Constants.DEFAULT_CONNECTION_LINGER);setSoTimeout(Constants.DEFAULT_CONNECTION_TIMEOUT);setTcpNoDelay(Constants.DEFAULT_TCP_NO_DELAY);}復制代碼我就說嘛，肯定和復雜。復雜也要看啊。
那么我們來看看 JIoEndpoint 這個類，這個類是什么玩意，如果大家平時調試tomcat比較多的話，肯定會熟悉這個類，樓主今天就遇到了，請看：
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:121)at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:502)at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:100)at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1041)at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:603)at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)at java.lang.Thread.run(Thread.java:748) 復制代碼異常信息，我們看倒數第四行，就是 JIoEndpoint 的內部類 SocketProcessor 的 run 方法報錯了，我們今天就親密接觸一下這個類，順便扒了它的衣服：
赤裸裸的在我們面前。所有錯誤的根源都在該方法中。
不扯了，我們繼續看 JIoEndpoint 的構造器，該構造器很簡單，就是設置最大連接數。默認是0，我們看代碼：
上圖中什么看到該方法將 maxConnections 設置為0，本來是10000，然后進入else if（maxCon > 0） 的邏輯。這里也就完成了 JIoEndpoint 對象的創建過程。
我們回到 Http11Protocol 的構造方法中，執行完了 JIoEndpoint 的創建過程，下面就執行 Http11ConnectionHandler 的構造。參數是Http11Protocol自己，Http11ConnectionHandler 是 Http11Protocol 的靜態內部類，該類中有一個屬性就是Http11Protocol，一個簡單的創建過程，然后設置 Http11Protocol 的 Handler 屬性為 Http11ConnectionHandler。可以感覺的到，Http11Protocol， JIoEndpoint ， Http11ConnectionHandler 這三個類是互相依賴關系。
至此，完成了 Http11Protocol 對象的創建。同時也完成了 Connector 對象的創建。 創建完對象干嘛呢。。。。不要想歪了，不是啪啪啪，而是初始化。
4. Connector 連接器的初始化 init 方法
我們知道 Connector 的父容器是 Service ,Service 執行 initInternal 方法初始化的時候會同時初始化子容器，也就是 Connector，在一個 for 循環重啟動。
該段代碼抽取自 StandardService.initInternal 方法，也就是Service 組件。通過debug我們知道了該連接器數組中只有2個連接器，就是我們的HTTP和AJP，剛剛創建的。并調用他們的 init 方法。我們看看該方法，該方法同所有容器一樣，執行了LifecycleBase 的模板方法，重點在子類重寫的抽象方法 initInternal 中。
這既是 Connector 的 initInternal 方法實現，該方法有幾個步驟：
我們重點關注 CoyoteAdapter 和 Http11Protocol 的初始化，CoyoteAdapter 是連接器的一種適配，構造參數是 Connector ，很明顯，他是要適配 Connector，這里的設計模式就是適配器模式了，所以，寫設計模式的時候，一定要在類名上加上設計模式的名字。方便后來人讀代碼。接下就是設置 Http11Protocol 的適配器為 剛剛構造的 CoyoteAdapter ，也就是說，tomcat 的設計者為了解耦或者什么將 Http11Protocol 和 Connector 中間插入了一個適配器。最后來到我們的 Http11Protocol 的初始化。
這個 Http11Protocol 的初始化很重要。Http11Protocol 不屬于 Lifecycle 管理，他的 init 方法在他的抽象父類 org.apache.coyote.AbstractProtocol 中就已經寫好了，我們來看看該方法的實現（很重要）：
上圖就是 AbstractProtocol 的 init 方法，我們看看紅框中的邏輯。
設置JMX的邏輯我們就不講了，之前講生命周期的時候講過了，設置名字也沒生命好講的。最后講最重要的 endpoint 的初始化。我們來看看他的 init 方法。該方法是 JIoEndpoint 抽象父類 AbstractEndpoint 的模板方法。該類被3個類繼承：AprEndpoint, JIoEndpoint， NioEndpoint，我們今天只關心JIoEndpoint。我們還是先看看 AbstractEndpoint 的 init 方法吧：
其中 bind（）是抽象方法，然后設置狀態為綁定已經初始化。我們看看 JIoEndpoint 的 bind 方法。有興趣也可以看看其他 Endpoint 的 bind 方法，比如NIO。我們看看JIo的：
這個方法很重要，我們仔細看看邏輯：
至此，我們完成了 Connector， Http11Protocol，JIoEndpoint 的初始化。
接下來就是啟動了
5. 連接器啟動
如我們所知，Connector 啟動肯定在 startInternal 方法中，因此我們直接看此方法。
該方法步驟如下：
我們感興趣的是 org.apache.coyote.http11.Http11Protocol 的 srart 方法。該方法由其抽象父類 AbstractProtocol.start 執行，我們看看該方法：
該方法主要邏輯是啟動 endpoint 的 start 方法。說明干事的還是 endpoint 啊 ，我們看看該方法實現，該方法調用了抽象父類的模板方法 AbstractEndpoint.start：
其主要邏輯是調用子類重寫的 startInternal 方法，我們來看 JIoEndpoint 的實現：
該方法可以說是 Tomcat 中 真正做事情的方法，絕對不是摸魚員工。說說他的邏輯：
讓我們看看他的詳細實現：
6. JIoEndpoint startInternal（Tomcat socket 管理） 方法的詳細實現
先看第一步：創建一個線程阻塞隊列，和一個線程池。我們進入該方法：
該方法步驟：
再看第二步：初始化最大連接數，默認200.
該方法很簡單，就是設置最大連接數為200；
第三步：用抽象父類 AbstractEndpoint 的 startAcceptorThreads 方法，默認創建一個守護線程。他的任務是等待客戶端請求，并將請求（socket 交給線程池）。AbstractEndpoint 中有一個 Acceptor 數組，作用接收新的連接和傳遞請求。我們看看該方法：
步驟：
該方法也不是很復雜，獲取的這個連接數，在完美初始化的時候，調用bind 方法的時候設置的，請看：
設置為1.
復雜的是 Acceptor 中的邏輯，Acceptor 是一個抽象靜態內部類，實現了 Runnable 接口，JIoEndpoint 類中也繼承了該類，其中 run 方法如下(高能預警，方法很長)。
public void run() {int errorDelay = 0;// Loop until we receive a shutdown commandwhile (running) {// Loop if endpoint is pausedwhile (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, waitcountUpOrAwaitConnection();Socket socket = null;try {// Accept the next incoming connection from the server// socketsocket = serverSocketFactory.acceptSocket(serverSocket);} catch (IOException ioe) {countDownConnection();// Introduce delay if necessaryerrorDelay = handleExceptionWithDelay(errorDelay);// re-throwthrow ioe;}// Successful accept, reset the error delayerrorDelay = 0;// Configure the socketif (running && !paused && setSocketOptions(socket)) {// Hand this socket off to an appropriate processorif (!processSocket(socket)) {countDownConnection();// Close socket right awaycloseSocket(socket);}} else {countDownConnection();// Close socket right awaycloseSocket(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;} 復制代碼其實邏輯也還好，不是那么復雜，我們化整為零，一個一個分析，首先判斷狀態，進入循環，然后設置一些狀態，最后進入一個 try 塊。
我們看看第一個方法 countUpOrAwaitConnection：
主要是 latch.countUpOrAwait() 這個方法，我們看看該方法內部實現：
這個 Sync 類 變量是 繼承了java.util.concurrent.locks.AbstractQueuedSynchronizer 抽象類（該類是JDK 1.8 新增的），說實話，樓主不熟悉這個類。再一個今天的主題也不是并發，因此放過這個類，給大家一個鏈接 深度解析Java 8：AbstractQueuedSynchronizer的實現分析（下）; 我們暫時知道這個方法作用是什么就行了，就像注釋說的：如果已經達到最大連接，就等待。我們繼續我們的分析。
我們跳過設置 tcp 優化，重點查看 processSocket 方法，這個方法是 JIoEndpoint 的，我們看看該方法實現：
該方法邏輯是：
到這里，我們必須停下來，因為如果繼續追蹤 SocketProcessor 這個類，這篇文章就停不下來了，樓主想留在下一篇文章慢慢咀嚼。慢慢品味。
第四步：好了，回到我們的 JIoEndpoint.startInternal 方法，我們已經解析完了 startAcceptorThreads 方法，那么我們繼續向下走，看到一個 timeoutThread 線程。創建一個管理超時socket 的線程。設置為了守護線程，名字叫 “http-bio-8080-AsyncTimeout”，優先級為5.
我們看看該程序的實現，還好，代碼不多：
我們看看主要邏輯：
那么什么時候會往該 waitingRequests 里添加呢？我們看過之前的 SocketProcessor. run 方法， 如果 SocketState 的狀態是LONG，就設置該 socket 的訪問時間為當前時間，并添加進超時隊列。而這個超時的判斷也非常的復雜，想想也對，任何一個連接都不能隨意丟棄。所以需要更嚴謹的對待，萬一是個支付請求呢？
好了，JIoEndpoint 的 startInternal 方法已經執行完畢，總結一下該方法：創建線程池，初始化最大連接數，啟動接收請求線程，設置超時線程。可以說tomcat 考慮的很周到。很完美。不過還有更完美的NIO還沒有體驗。
7. 總結
今天的文章真是超長啊，誰叫連接器是tomcat中最重要的組件呢？其實還沒有講完呢；我們講了連接器的如何根據server.xml 創建對象，如何初始化connector 和 endpoint ，如何啟動connector，如何啟動 endpoint中各個線程。樓主能力有限，暫時先講這么多，還有很多的東西我們都還沒講，沒事，留著下次講。
天色已晚，樓主該回家了。各位再見！！！！
good luck ！！！！
總結
以上是生活随笔為你收集整理的深入理解 Tomcat（八）源码剖析之连接器的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 十年磨一剑是危险的
- 下一篇： 用shell打印下面这句话中字母数小于6