這是我們分析tomcat的第八篇文章，這次我們分析連接器，我們早就想分析連接器了，因為各種原因拖了好久。不過也確實復(fù)雜。

首先我們之前定義過連接器：

Tomcat都是在容器里面處理問題的， 而容器又到哪里去取得輸入信息呢？ Connector就是專干這個的。 他會把從socket傳遞過來的數(shù)據(jù)， 封裝成Request, 傳遞給容器來處理。 通常我們會用到兩種Connector,一種叫http connectoer， 用來傳遞http需求的。 另一種叫AJP， 在我們整合apache與tomcat工作的時候，apache與tomcat之間就是通過這個協(xié)議來互動的。 （說到apache與tomcat的整合工作， 通常我們的目的是為了讓apache 獲取靜態(tài)資源， 而讓tomcat來解析動態(tài)的jsp或者servlet。）

簡單來說，連接器就是接收http請求并解析http請求，然后將請求交給servlet容器。

那么在 Tomcat中 ，那個類表示連接器呢？ 答案是 org.apache.catalina.connector.Connector，該類繼承自 LifecycleMBeanBase， 也就是說，該類的生命周期歸屬于容器管理。而該類的父容器是誰呢？ 答案是 org.apache.catalina.core.StandardService，也就是我們的Service 組件，StandardService是該接口的標(biāo)準(zhǔn)實現(xiàn)。StandardService 聚合了 Connector 數(shù)組和一個Container 容器，也就驗證了我們之前說的一個Service 組件中包含一個Container和多個連接器。

那么連接器什么時候初始化被放入容器和JMX呢?這是個大問題，也是我們今天的主要問題。

1. Tomcat 解析 server.xml 并創(chuàng)建對象

我們之前扒過啟動源碼，我們知道，在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 &quot;%r&quot; %s %b" />

      </Host>
    </Engine>
  </Service>
</Server>

可以看到該配置文件中有2個Connector 標(biāo)簽，有就是說默認(rèn)有2個連接器。一個是HTTP協(xié)議，一個AJP協(xié)議。

我們的Connector是什么時候創(chuàng)建的呢？就是在解析這個xml文件的時候，那么是怎么解析的呢？我們平時在解析 xml 的時候經(jīng)常使用dom4j（真的不喜歡xml，最愛json），而tomcat 使用的是 Digester 解析xml，我們來看看 Catalina.load（） 關(guān)于解析并創(chuàng)建容器的關(guān)鍵代碼：

    public void load() {
        // Create and execute our Digester
        Digester digester = createStartDigester();
        digester.parse(inputSource);
    }

首先創(chuàng)建一個 Digester， 其中的關(guān)鍵代碼我們看看：

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");

上面的代碼的意思是將對應(yīng)的字符串創(chuàng)建成對應(yīng)的角色，以便后面和xml對應(yīng)便解析。

我們再看看它是如何解析的，由于 digester.parse(inputSource) 這個方法調(diào)用層次太深，而且該方法只是解析xml，因此樓主把就不把每段代碼貼出來了，我們看看IDEA生成的該方法的方法調(diào)用棧：這些方法都是在 rt.jar 包中，因此我們不做分析了。主要就是解析xml。

上圖是樓主在 Digester.startDocument 的方法中打的斷點。該方法作用為開始解析 xml 做準(zhǔn)備。

上圖是樓主在 Digester.startElement 的方法中打的斷點，startDocument 和 startElement 是多次交替執(zhí)行的，確定他們執(zhí)行邏輯的是什么方法呢？從堆棧圖中我們可以看到：是 com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse（）這個方法，代碼我就不貼出來了，很長沒有意義，該方法在 819行間接調(diào)用 startDocument，在841行間接調(diào)用startElement。上下執(zhí)行，并且回執(zhí)行多次。因為 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;
                }
            }
        } 
}

樓主只貼了關(guān)鍵代碼，就是for循環(huán)中的邏輯，便利 Rule 集合，Rule 是什么呢？是我們之前 createStartDigester 方法里創(chuàng)建的。而 Rule 是一個接口，tomcat 中有很多不同的實現(xiàn)。然后循環(huán)調(diào)用他們的 begin 方法。我們看看有哪些實現(xiàn)：

$R_$UQLJE)Z0{F~C0(KVWIG.png

我們從上圖中看到了有很多的實現(xiàn)，而我們今天只關(guān)注連接器：也就是 ConnectorCreateRule 的 begin 方法：

@Override
    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，然后會分別創(chuàng)建2個連接器，一個是HTTP， 一個是AJP，也就是我們配置文件中寫的。

現(xiàn)在，我們已經(jīng)剖析了tomcat 是如何解析xml的，并如何創(chuàng)建對象的，接下來，我們就看看創(chuàng)建對象的邏輯。

2. 創(chuàng)建連接器對象

我們來到我們的Connector類的構(gòu)造方法：

   public Connector() {
        this(null);
    }

    public Connector(String protocol) {
        setProtocol(protocol);
        // Instantiate protocol handler
        try {
            Class<?> clazz = Class.forName(protocolHandlerClassName);
            this.protocolHandler = (ProtocolHandler) clazz.newInstance();// 反射創(chuàng)建protocolHandler 默認(rèn) http1.1 協(xié)議實現(xiàn) （org.apache.coyote.http11.Http11Protocol）
        } catch (Exception e) {
            log.error(sm.getString(
                    "coyoteConnector.protocolHandlerInstantiationFailed"), e);
        }
    }

我記得阿里規(guī)約里說，構(gòu)造器不要太復(fù)雜，復(fù)雜的邏輯請放在init里，不知道tomcat這么寫算好還是不好呢？嘿嘿。我們還是來看看我們的邏輯吧。

1. 根據(jù)傳進(jìn)來的字符串設(shè)置協(xié)議處理器類名（setProtocol 方法中調(diào)用了setProtocolHandlerClassName 方法）。
2. 根據(jù)剛剛設(shè)置好的 protocolHandlerClassName 反射創(chuàng)建 ProtocolHandler 類型的對象。

既然是反射創(chuàng)建，那么我們就要看看完整的類名是什么了，所以需要看看設(shè)置 protocolHandlerClassName 方法的細(xì)節(jié)：

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);
            }
        }

    }

此方法會直接進(jìn)入下面的else塊，我們知道，該處可能會傳 HTTP 或者 AJP ，根據(jù)不同的協(xié)議創(chuàng)建不同的協(xié)議處理器。也就是連接器，我們看到這里的全限定名是 org.apache.coyote.http11.Http11Protocol 或者 org.apache.coyote.ajp.AjpProtocol，這兩個類都是在 coyote 包下，也就是連接器模塊。

好了，到現(xiàn)在，我們的 Connector 對象就創(chuàng)建完畢了，創(chuàng)建它的過程同時也根據(jù)配置文件創(chuàng)建了 protocolHandler， 他倆是依賴關(guān)系。

3. Http11Protocol 協(xié)議處理器構(gòu)造過程

創(chuàng)建了 Http11Protocol 對象，我們有必要看看他的構(gòu)造過程是什么樣的。按照tomcat的性格，一般構(gòu)造器都很復(fù)雜，所以，我們找到該類，看看他的類和構(gòu)造器：

該類的類說明是這樣說的：

抽象協(xié)議的實現(xiàn)，包括線程等。處理器是單線程的，特定于基于流的協(xié)議，不適合像JNI那樣的Jk協(xié)議。

我們看看構(gòu)造方法

    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);
    }

我就說嘛，肯定和復(fù)雜。復(fù)雜也要看啊。

1. 創(chuàng)建以了一個 JIoEndpoint 對象。
2. 創(chuàng)建了一個 Http11ConnectionHandler 對象，參數(shù)是 Http11Protocol；
3. 設(shè)置處理器為 Http11ConnectionHandler 對象。
4. 設(shè)置一些屬性，比如超時，優(yōu)化tcp性能。

那么我們來看看 JIoEndpoint 這個類，這個類是什么玩意，如果大家平時調(diào)試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)

異常信息，我們看倒數(shù)第四行，就是 JIoEndpoint 的內(nèi)部類 SocketProcessor 的 run 方法報錯了，我們今天就親密接觸一下這個類，順便扒了它的衣服：

赤裸裸的在我們面前。所有錯誤的根源都在該方法中。

不扯了，我們繼續(xù)看 JIoEndpoint 的構(gòu)造器，該構(gòu)造器很簡單，就是設(shè)置最大連接數(shù)。默認(rèn)是0，我們看代碼：

上圖中什么看到該方法將 maxConnections 設(shè)置為0，本來是10000，然后進(jìn)入else if（maxCon > 0） 的邏輯。這里也就完成了 JIoEndpoint 對象的創(chuàng)建過程。

我們回到 Http11Protocol 的構(gòu)造方法中，執(zhí)行完了 JIoEndpoint 的創(chuàng)建過程，下面就執(zhí)行 Http11ConnectionHandler 的構(gòu)造。參數(shù)是Http11Protocol自己，Http11ConnectionHandler 是 Http11Protocol 的靜態(tài)內(nèi)部類，該類中有一個屬性就是Http11Protocol，一個簡單的創(chuàng)建過程，然后設(shè)置 Http11Protocol 的 Handler 屬性為 Http11ConnectionHandler?？梢愿杏X的到，Http11Protocol， JIoEndpoint ， Http11ConnectionHandler 這三個類是互相依賴關(guān)系。

至此，完成了 Http11Protocol 對象的創(chuàng)建。同時也完成了 Connector 對象的創(chuàng)建。 創(chuàng)建完對象干嘛呢。。。。不要想歪了，不是啪啪啪，而是初始化。

4. Connector 連接器的初始化 init 方法

我們知道 Connector 的父容器是 Service ,Service 執(zhí)行 initInternal 方法初始化的時候會同時初始化子容器，也就是 Connector，在一個 for 循環(huán)重啟動。

該段代碼抽取自 StandardService.initInternal 方法，也就是Service 組件。通過debug我們知道了該連接器數(shù)組中只有2個連接器，就是我們的HTTP和AJP，剛剛創(chuàng)建的。并調(diào)用他們的 init 方法。我們看看該方法，該方法同所有容器一樣，執(zhí)行了LifecycleBase 的模板方法，重點在子類重寫的抽象方法 initInternal 中。

這既是 Connector 的 initInternal 方法實現(xiàn)，該方法有幾個步驟：

1. 調(diào)用父類的 initInternal 方法，將自己注冊到JMX中。
2. 創(chuàng)建一個 CoyoteAdapter 對象，參數(shù)是自己。
3. 設(shè)置 Http11Protocol 的適配器為剛剛創(chuàng)建的 CoyoteAdapter 適配器。
4. 設(shè)置解析請求的請求方法類型，默認(rèn)是 POST。
5. 初始化 Http11Protocol（不要小看這個類，Connector就是一個虛的，真正做事的就是這個類和 JIoEndpoint）；
6. 初始化 mapperListener；

我們重點關(guān)注 CoyoteAdapter 和 Http11Protocol 的初始化，CoyoteAdapter 是連接器的一種適配，構(gòu)造參數(shù)是 Connector ，很明顯，他是要適配 Connector，這里的設(shè)計模式就是適配器模式了，所以，寫設(shè)計模式的時候，一定要在類名上加上設(shè)計模式的名字。方便后來人讀代碼。接下就是設(shè)置 Http11Protocol 的適配器為 剛剛構(gòu)造的 CoyoteAdapter ，也就是說，tomcat 的設(shè)計者為了解耦或者什么將 Http11Protocol 和 Connector 中間插入了一個適配器。最后來到我們的 Http11Protocol 的初始化。

這個 Http11Protocol 的初始化很重要。Http11Protocol 不屬于 Lifecycle 管理，他的 init 方法在他的抽象父類 org.apache.coyote.AbstractProtocol 中就已經(jīng)寫好了，我們來看看該方法的實現(xiàn)（很重要）：

上圖就是 AbstractProtocol 的 init 方法，我們看看紅框中的邏輯。

1. 將 endpoint 注冊到JMX中。
2. 將 Http11ConnectionHandler（Http11Protocol 的 內(nèi)部類）注冊到JMX中。
3. 設(shè)置 endpoint 的名字，Http 連接器是 http-bio-8080;
4. endpoint 初始化。

設(shè)置JMX的邏輯我們就不講了，之前講生命周期的時候講過了，設(shè)置名字也沒生命好講的。最后講最重要的 endpoint 的初始化。我們來看看他的 init 方法。該方法是 JIoEndpoint 抽象父類 AbstractEndpoint 的模板方法。該類被3個類繼承：AprEndpoint, JIoEndpoint， NioEndpoint，我們今天只關(guān)心JIoEndpoint。我們還是先看看 AbstractEndpoint 的 init 方法吧：

其中 bind（）是抽象方法，然后設(shè)置狀態(tài)為綁定已經(jīng)初始化。我們看看 JIoEndpoint 的 bind 方法。有興趣也可以看看其他 Endpoint 的 bind 方法，比如NIO。我們看看JIo的：

這個方法很重要，我們仔細(xì)看看邏輯：

1. 設(shè)置最大線程數(shù)，默認(rèn)是200；
2. 創(chuàng)建一個默認(rèn)的 serverSocketFactory 工廠（就是一個封裝了ServerSocket 的類）；
3. 使用剛剛工廠創(chuàng)建一個 serverSocket。因此，JIoEndpoint 也就有了 serverSocket。

至此，我們完成了 Connector， Http11Protocol，JIoEndpoint 的初始化。

接下來就是啟動了

5. 連接器啟動

如我們所知，Connector 啟動肯定在 startInternal 方法中，因此我們直接看此方法。

該方法步驟如下：

1. 設(shè)置啟動中狀態(tài)。狀態(tài)更新會觸發(fā)事件監(jiān)聽機制。
2. 啟動 org.apache.coyote.http11.Http11Protocol 的 srart 方法。
3. 啟動 org.apache.catalina.connector.MapperListener 的 start 方法。

我們感興趣的是 org.apache.coyote.http11.Http11Protocol 的 srart 方法。該方法由其抽象父類 AbstractProtocol.start 執(zhí)行，我們看看該方法：

該方法主要邏輯是啟動 endpoint 的 start 方法。說明干事的還是 endpoint 啊 ，我們看看該方法實現(xiàn)，該方法調(diào)用了抽象父類的模板方法 AbstractEndpoint.start：

其主要邏輯是調(diào)用子類重寫的 startInternal 方法，我們來看 JIoEndpoint 的實現(xiàn)：

該方法可以說是 Tomcat 中 真正做事情的方法，絕對不是摸魚員工。說說他的邏輯：

1. 創(chuàng)建一個線程阻塞隊列，和一個線程池。
2. 初始化最大連接數(shù)，默認(rèn)200.
3. 調(diào)用抽象父類 AbstractEndpoint 的 startAcceptorThreads 方法，默認(rèn)創(chuàng)建一個守護(hù)線程。他的任務(wù)是等待客戶端請求，并將請求（socket 交給線程池）。AbstractEndpoint 中有一個 Acceptor 數(shù)組，作用接收新的連接和傳遞請求。
4. 創(chuàng)建一個管理超時socket 的線程。

讓我們看看他的詳細(xì)實現(xiàn)：

6. JIoEndpoint startInternal（Tomcat socket 管理） 方法的詳細(xì)實現(xiàn)

先看第一步：創(chuàng)建一個線程阻塞隊列，和一個線程池。我們進(jìn)入該方法：

該方法步驟：

1. 創(chuàng)建一個 “任務(wù)隊列”，實際上是一個繼承了 LinkedBlockingQueue<Runnable> 的類。該隊列最大長度為 int 最大值 0x7fffffff。
2. 創(chuàng)建一個線程工廠，TaskThreadFactory 是一個繼承 ThreadFactory 的類，默認(rèn)創(chuàng)建最小線程 10， 最大線程200， 名字為 “http-bio-8080-exec-” 拼接線程池編號，優(yōu)先級為5。
3. 使用上面的線程工廠創(chuàng)建一個線程池，預(yù)先創(chuàng)建10個線程，最大線程200，線程空閑實際60秒.
4. 將線程池設(shè)置為隊列的屬性，方便后期判斷線程池狀態(tài)而做一些操作。

再看第二步：初始化最大連接數(shù)，默認(rèn)200.

該方法很簡單，就是設(shè)置最大連接數(shù)為200；

第三步：用抽象父類 AbstractEndpoint 的 startAcceptorThreads 方法，默認(rèn)創(chuàng)建一個守護(hù)線程。他的任務(wù)是等待客戶端請求，并將請求（socket 交給線程池）。AbstractEndpoint 中有一個 Acceptor 數(shù)組，作用接收新的連接和傳遞請求。我們看看該方法：

步驟：

1. 獲取可接收的連接數(shù)，并創(chuàng)建一個連接線程數(shù)組。
2. 循環(huán)該數(shù)組，設(shè)置優(yōu)先級為5，設(shè)置為守護(hù)線程。
   3.啟動該線程。

該方法也不是很復(fù)雜，獲取的這個連接數(shù)，在完美初始化的時候，調(diào)用bind 方法的時候設(shè)置的，請看：

設(shè)置為1.

復(fù)雜的是 Acceptor 中的邏輯，Acceptor 是一個抽象靜態(tài)內(nèi)部類，實現(xiàn)了 Runnable 接口，JIoEndpoint 類中也繼承了該類，其中 run 方法如下(高能預(yù)警，方法很長)。

        @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
                    countUpOrAwaitConnection();

                    Socket socket = null;
                    try {
                        // Accept the next incoming connection from the server
                        // socket
                        socket = serverSocketFactory.acceptSocket(serverSocket);
                    } catch (IOException ioe) {
                        countDownConnection();
                        // Introduce delay if necessary
                        errorDelay = handleExceptionWithDelay(errorDelay);
                        // re-throw
                        throw ioe;
                    }
                    // Successful accept, reset the error delay
                    errorDelay = 0;

                    // Configure the socket
                    if (running && !paused && setSocketOptions(socket)) {
                        // Hand this socket off to an appropriate processor
                        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;
        }

其實邏輯也還好，不是那么復(fù)雜，我們化整為零，一個一個分析，首先判斷狀態(tài)，進(jìn)入循環(huán)，然后設(shè)置一些狀態(tài)，最后進(jìn)入一個 try 塊。

1. 執(zhí)行 countUpOrAwaitConnection 方法，該方法注釋說：如果已經(jīng)達(dá)到最大連接，就等待。
2. 阻塞獲取socket。
3. setSocketOptions(socket) 設(shè)置 tcp 一些屬性優(yōu)化性能，比如緩沖字符大小，超時等。
4. 執(zhí)行 processSocket(socket) 方法，將請求包裝一下交給線程池執(zhí)行。

我們看看第一個方法 countUpOrAwaitConnection：

主要是 latch.countUpOrAwait() 這個方法，我們看看該方法內(nèi)部實現(xiàn)：

這個 Sync 類 變量是 繼承了java.util.concurrent.locks.AbstractQueuedSynchronizer 抽象類（該類是JDK 1.8 新增的），說實話，樓主不熟悉這個類。再一個今天的主題也不是并發(fā)，因此放過這個類，給大家一個鏈接 深度解析Java 8：AbstractQueuedSynchronizer的實現(xiàn)分析（下）;
我們暫時知道這個方法作用是什么就行了，就像注釋說的：如果已經(jīng)達(dá)到最大連接，就等待。我們繼續(xù)我們的分析。

我們跳過設(shè)置 tcp 優(yōu)化，重點查看 processSocket 方法，這個方法是 JIoEndpoint 的，我們看看該方法實現(xiàn)：

該方法邏輯是：

1. 封裝一個 SocketWrapper。
2. 設(shè)置長連接時間為100，
   3.然后封裝成 SocketProcessor(還記得這個類嗎，就是我們剛開始異常信息里出現(xiàn)的類，原來是在這里報錯的，哈哈) 交給線程池執(zhí)行。

到這里，我們必須停下來，因為如果繼續(xù)追蹤 SocketProcessor 這個類，這篇文章就停不下來了，樓主想留在下一篇文章慢慢咀嚼。慢慢品味。

第四步：好了，回到我們的 JIoEndpoint.startInternal 方法，我們已經(jīng)解析完了 startAcceptorThreads 方法，那么我們繼續(xù)向下走，看到一個 timeoutThread 線程。創(chuàng)建一個管理超時socket 的線程。設(shè)置為了守護(hù)線程，名字叫 “http-bio-8080-AsyncTimeout”，優(yōu)先級為5.

我們看看該程序的實現(xiàn)，還好，代碼不多：

我們看看主要邏輯：

1. 獲取當(dāng)前時間；
2. waitingRequests 的類型是 ConcurrentLinkedQueue<SocketWrapper<Socket>>，一個并發(fā)安全的阻塞對壘，里面有包裝過的 SocketWrapper。
3. 判斷如果該隊列中有，則取出，判斷如果該socket 設(shè)定的超時時間大于0（默認(rèn)-1），且當(dāng)前時間大于訪問時間，則交給線程池處理。

那么什么時候會往該 waitingRequests 里添加呢？我們看過之前的 SocketProcessor. run 方法， 如果 SocketState 的狀態(tài)是LONG，就設(shè)置該 socket 的訪問時間為當(dāng)前時間，并添加進(jìn)超時隊列。而這個超時的判斷也非常的復(fù)雜，想想也對，任何一個連接都不能隨意丟棄。所以需要更嚴(yán)謹(jǐn)?shù)膶Υ?，萬一是個支付請求呢？

好了，JIoEndpoint 的 startInternal 方法已經(jīng)執(zhí)行完畢，總結(jié)一下該方法：創(chuàng)建線程池，初始化最大連接數(shù)，啟動接收請求線程，設(shè)置超時線程?？梢哉ftomcat 考慮的很周到。很完美。不過還有更完美的NIO還沒有體驗。

7. 總結(jié)

今天的文章真是超長啊，誰叫連接器是tomcat中最重要的組件呢？其實還沒有講完呢；我們講了連接器的如何根據(jù)server.xml 創(chuàng)建對象，如何初始化connector 和 endpoint ，如何啟動connector，如何啟動 endpoint中各個線程。樓主能力有限，暫時先講這么多，還有很多的東西我們都還沒講，沒事，留著下次講。

天色已晚，樓主該回家了。各位再見！?。?！

good luck ！?。?！