一、架構
下面談談我對Tomcat架構的了解
總體架構：
1、面向元件架構
2、基于JMX
3、事件偵聽
1）面向元件架構
tomcat代碼看似很龐大，但從結構上看卻很清晰和簡單，它主要由一堆元件組成，如Server、Service、Connector等，并基于JMX管理這些元件，另外實作以上接口的元件也實作了代表生存期的接口Lifecycle，使其元件履行固定的生存期，在其整個生存期的過程中通過事件偵聽LifecycleEvent實作擴充。Tomcat的核心類圖如下所示：
1、Catalina：與開始/關閉shell腳本互動的主類，是以如果要研究啟動和關閉的過程，就從這個類開始看起。
2、Server：是整個Tomcat元件的容器，包含一個或多個Service。
3、Service：Service是包含Connector和Container的集合，Service用适當的Connector接收使用者的請求，再發給相應的Container來處理。
4、Connector：實作某一協定的連接配接器，如預設的有實作HTTP、HTTPS、AJP協定的。
5、Container：可以了解為處理某類型請求的容器，處理的方式一般為把處理請求的處理器包裝為Valve對象，并按一定順序放入類型為Pipeline的管道裡。Container有多種子類型：Engine、Host、Context和Wrapper，這幾種子類型Container依次包含，處理不同粒度的請求。另外Container裡包含一些基礎服務，如Loader、Manager和Realm。
6、Engine：Engine包含Host和Context，接到請求後仍給相應的Host在相應的Context裡處理。
7、Host：就是我們所了解的虛拟主機。
8、Context：就是我們所部屬的具體Web應用的上下文，每個請求都在是相應的上下文裡處理的
9、Wrapper：Wrapper是針對每個Servlet的Container，每個Servlet都有相應的Wrapper來管理。
可以看出Server、Service、Connector、Container、Engine、Host、Context和Wrapper這些核心元件的作用範圍是逐層遞減，并逐層包含。
下面就是些被Container所用的基礎元件：
1、Loader：是被Container用來載入各種所需的Class。
2、Manager：是被Container用來管理Session池。
3、Realm：是用來處理安全裡授權與認證。
分析完核心類後，再看看Tomcat啟動的過程，Tomcat啟動的時序圖如下所示：
從上圖可以看出，Tomcat啟動分為init和start兩個過程，核心元件都實作了Lifecycle接口，都需實作start方法，是以在start過程中就是從Server開始逐層調用子元件的start過程。
2）基于JMX
Tomcat會為每個元件進行注冊過程，通過Registry管理起來，而Registry是基于JMX來實作的，是以在看元件的init和start過程實際上就是初始化MBean和觸發MBean的start方法，會大量看到形如：
這樣的代碼，這實際上就是通過JMX管理各種元件的行為和生命期。
3）事件偵聽
各個元件在其生命期中會有各種各樣行為，而這些行為都有觸發相應的事件，Tomcat就是通過偵聽這些時間達到對這些行為進行擴充的目的。在看元件的init和start過程中會看到大量如：
這樣的代碼，這就是對某一類型事件的觸發，如果你想在其中加入自己的行為，就隻用注冊相應類型的事件即可。
二、一次完整請求的裡裡外外
前幾天分析了一下Tomcat的架構和啟動過程，今天開始研究它的運轉機制。Tomcat最本質就是個能運作JSP/Servlet的Web伺服器 ，是以最典型的應用就是使用者通過浏覽器通路伺服器，Tomcat接收到請求後轉發給Servlet，由Servlet處理完後，把結果傳回給用戶端。今天就專門解析一下這麼一個完整的請求的内部機理。
通過DEBUG，一路跟下來，發現Tomcat處理請求的核心過程是以下幾點：
1、啟動的時候啟動預支援協定的Endpoint，Endpoint會起專門的線程監聽相應協定的請求，預設的情況下，會啟動JIoEndpoint，JIoEndpoint基于Java ServerSocket接收Http的請求
2、ServerSocket接收到用戶端請求的Socket後，一路包裝，并一路從Host一直傳遞到Wrapper，再請求到相應的Servlet
下面将重點解析以上兩個過程。
通過以前的分析（Tomcat源碼分析一）可知道當Tomcat啟動的時候會啟動Connector，此時Connector會通過ProtocolHandler把Endpoint啟動起來。預設情況下，Tomcat會啟動兩種Connector，分别是Http協定和AJP協定的，依次對應Http11Protocol和AjpProtocol，兩者都是啟動JIoEndpoint。下面看看JIoEndpoint的start方法：
以上代碼很清晰地表示啟動acceptorThreadCount個線程，每個線程由Acceptor代理，具體看看Acceptor的run方法：
由此可得到這麼一個結論：Tomcat就是通過ServerSocket監聽Socket的方式來接收用戶端請求的。具體代碼就無需我解析了，稍微了解Javanet的人都能看懂以上代碼，Tomcat就是用最标準和最基礎的Socket調用方法來處理網絡請求的。找到處理請求的源頭後下面要做的是事情就簡單了，打好斷點，在浏覽器裡請求一個最簡單的Hello world，一路debug下去。一路跟下來，主流程的時序圖如下所示：
從上圖可知，以上過程可分解成以下三個最主要的核心點：
1、基于Http1.1協定對Socket的解析和包裝
2、StandardEngineValve、StandardHostValve、StandardContextValve和StandardWrapperValve四種Valve的一路inoke。四種不同層次的Valve做了不同層次的處理和封裝
3、基于責任鍊模式ApplicationFilterChain實作Filter攔截和實際Servlet的請求
以上三個核心點都是内容非常豐富的可研究點，會在以後幾天逐一進行剖析。
三、可攜帶狀态的線程池
最近想實作一個可攜帶狀态的線程池，具體需求就是池中的線程被用來處理某種資訊，而此資訊可視為線程所依賴的外部狀态。如果用簡單的線程池來實作，線程初始化時就得賦予某些資訊，使得線程無法被再次利用。在看老版Tomcat的源碼時，找到了答案，其實作思路主要是利用了線程的等待和喚起，HttpProcessor的實作正好基于此思路，時序圖如下所示：
初始化HttpProcessor線程時，沒法賦予所需的Socket對象，因為如果在初始化階段就賦予Socket會導緻此線程沒法回收用來處理其他Socket。是以，在HttpProcessor的run階段，先把線程給wait住，具體在await方法裡展現，代碼如下所示：
當HttpConnector調用HttpProcessor.assign(socket)方法時，會給此線程賦予Socket對象，并喚起此線程，使其繼續執行，assign方法的源碼如下所示：
線程被喚起和賦予socket對象後，繼續執行核心的process方法，HttpProcessor.run的完整源碼如下所示：
四、Request和Response處理的全過程
從Tomcat源碼分析（二）可知，使用者的一個請求會經過n個環節的處理，最後到達開發人員寫的Servlet，傳給Servlet也就是HttpServletRequest和HttpServletResponse，是以可以認為這一路走下來無非就是把最原始的Socket包裝成Servlet裡用到的HttpServletRequest和HttpServletResponse，隻不過每個環節完成的包裝功能和部分不一樣而已，資訊流如下圖所示：
其中，Request與Response的類圖如下所示：
org.apache.coyote.Request和org.apache.coyote.Response是Tomcat内部使用的，不提供給開發者調用，類是final類型的。下面結合一次完整請求的時序圖來看看從Socket到org.apache.catalina.connector.Request的加工過程：
由上圖可見，Request的解析和加工過程不是在一個方法裡搞定，而是資訊流動過程中逐漸解析的，不同層次的處理器解析不同層次的資訊，在解析過程同時做了些判斷和攔截的工作，比如當發現是要通路WEB-INF的資源，會直接傳回錯誤給用戶端等等。