優(yōu)質(zhì)博文：IT_BLOG_CN

一、Tomcat 頂層架構(gòu)

Tomcat中最頂層的容器是Server，代表著整個服務(wù)器，從上圖中可以看出，一個Server可以包含至少一個Service，用于具體提供服務(wù)。Service主要包含兩個部分：Connector和Container。從上圖中可以看出Tomcat的心臟就是這兩個組件，他們的作用如下：
【1】Connector用于處理連接相關(guān)的事情，并提供Socket與Request和 Response相關(guān)的轉(zhuǎn)化；
【2】Container用于封裝和管理Servlet，以及具體處理Request請求；

一個Tomcat中只有一個Server，一個Server可以包含多個Service，一個 Service只有一個Container，但是可以有多個Connectors，這是因為一個服務(wù)可以有多個連接，如同時提供Http和Https鏈接，也可以提供向相同協(xié)議不同端口的連接，示意圖如下（Engine、Host、Context下邊會說到）：

多個Connector和一個Container就形成了一個Service，有了Service就可以對外提供服務(wù)了，但是Service還要一個生存的環(huán)境，必須要有人能夠給她生命、掌握其生死大權(quán)，那就非Server莫屬了！所以整個Tomcat的生命周期由 Server控制。另外，上述的包含關(guān)系或者說是父子關(guān)系，都可以在tomcat的 conf目錄下的 server.xml 配置文件中看出。

二、簡要解釋下 server.xml 配置文件的信息

server.xml是Tomcat中最重要的配置文件，server.xml的每個元素都對應(yīng)了 Tomcat中的一個組件；通過對xml文件中元素的配置，可以實現(xiàn)對Tomcat中各個組件的控制。

<?xml version="1.0" encoding="UTF-8"?>
<Server port="8005" shutdown="SHUTDOWN"><Listener className="org.apache.catalina.startup.VersionLoggerListener"/><Listener SSLEngine="on" className="org.apache.catalina.core.AprLifecycleListener"/><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 auth="Container" description="User database that can be updated and saved"  factory="org.apache.catalina.users.MemoryUserDatabaseFactory" name="UserDatabase" pathname="conf/tomcat-users.xml" type="org.apache.catalina.UserDatabase"/></GlobalNamingResources><Service name="Catalina"><Connector port="8080" protocol="HTTP/1.1" connectionTimeOut="20000" redirectPort="8443"/><Connector port="8009" protocol="AJP/1.3" redirectPort="8443"/><Engine defaultHost="localhost" name="Catalina"><Realm className="org.apache.catalina.realm.LockOutRealm"><Realm className="org.apache.catalina.realm.UserDatabaseRealm" resourceName="UserDatabase"/></Realm><Host appBase="webapps" autoDeploy="true" name="localhost" unpackWARs="true"><Valve className="org.apache.catalina.valves.AccessLogValve" directory="logs" pattern="%h %l %u %t &quot;%r&quot; %s %b" prefix="localhost_access_log." suffix=".txt"/><Context docBase="cas-server-webapp" path="/cas" reloadable="true" source="org.eclipse.jst.j2ee.server:cas-server-webapp"/><Context docBase="portal" path="/portal" reloadable="true" source="org.eclipse.jst.jee.server:portal"/></Host></Engine></Service>
</Server>

server.xml的整體架構(gòu)（簡潔版）：

<Server><Service><Connector /><Connector /><Engine><Host><Context /><!-- 現(xiàn)在常常使用自動部署，不推薦配置Context元素，Context小節(jié)有詳細(xì)說明 --></Host></Engine></Service>
</Server>

【1】頂層元素：元素是整個配置文件的根元素，元素代表一個Engine元素以及一組與之相連的Connector元素。
【2】連接器： 代表了外部客戶端發(fā)送請求到特定Service的接口；同時也是外部客戶端從特定Service接收響應(yīng)的接口。
【3】容器：容器的功能是處理Connector接收進(jìn)來的請求，并產(chǎn)生對應(yīng)的響應(yīng)。Engine包含Host，Host包含Context。一個 Engine組件可以處理Service中的所有請求，一個Host組件可以處理發(fā)向一個特定虛擬主機的所有請求，一個Context組件可以處理一個特定Web應(yīng)用的所有請求。

三、Tomcat 都有哪些核心組件

【1】Server：Server元素在最頂層，代表整個 Tomcat容器，因此他必須是server.xml中唯一一個最外層的元素。一個Server元素可以有一個或多個Service元素。

<Server port="8005" shutdown="SHUTDOWN">
</Server>

可以看到，最外層有一個 元素，shutdown屬性表示關(guān)閉Server的指令；port屬性表示Server接收shutdown指令的端口號，設(shè)置為-1可以禁掉該端口。Server 的主要任務(wù)，就是提供一個接口讓客戶端能夠訪問到這個 Service集合，同時維護(hù)它所包含的所有的 Service的生命周期，包含如何初始化，如何結(jié)束服務(wù)，如何找到客戶端要訪問的 Service。
【2】Service：在Connector和Engine外面包一層，把它們組合在一起，對外提供服務(wù)。一個Service可以包含多個Connector，但是只能包含一個Engine；其中Connector的作用是從客戶端接收請求，Engine的作用是處理接收進(jìn)來的請求。

<Server port="8005" shutdown="SHUTDOWN"><Service name="Catalina"></Service>
</Server>

如上圖，Server中包含一個名稱為Catalina的Service。實際上，Tomcat可以提供多個Service，不同的Service監(jiān)聽不同的端口。
【3】Connector：接收連接請求，創(chuàng)建Request和 Response對象用于和請求端交換數(shù)據(jù)；然后分配線程讓Engine來處理這個請求，并把產(chǎn)生的Request和Response對象傳給Engine。通過配置 Connector，可以控制請求 Service的協(xié)議及端口號。

<Server port="8005" shutdown="SHUTDOWN"><Service name="Catalina"><Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /><Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /></Service>
</Server>

通過配置第一個Connector，客戶端可以通過8080端口號協(xié)議訪問Tomcat。其中，protocol屬性規(guī)定了請求的協(xié)議，port規(guī)定了請求的端口號，redirectPort表示當(dāng)強制要求https而請求是 http時，重定向至端口號為8443的Connector，connectionTimeout表示連接的超時時間。

在這個例子中，Tomcat監(jiān)聽Http請求，使用的是8080端口，而不是正式的 80端口；實際上，在正式的生產(chǎn)環(huán)境中，Tomcat也常常監(jiān)聽8080端口。而不是80端口。這是因為在生產(chǎn)環(huán)境中，很少講Tomcat直接對外開放接收請求，而是在Tomcat和客戶端之間加一層代理服務(wù)器（如Nginx），用于請求的轉(zhuǎn)發(fā)、負(fù)載均衡、處理靜態(tài)文件等；通過代理服務(wù)器訪問Tomcat時，是在局域網(wǎng)中，因為一般仍使用8080端口。

第二個配置Connector，客戶端可以通過8009端口使用AJP協(xié)議訪問 Tomcat。AJP協(xié)議負(fù)責(zé)和其他的Http服務(wù)器（如Apache）建立連接；在把 Tomcat與其他服務(wù)器集成時，就需要用到這個連接器，之所以使用 Tomcat和其他服務(wù)器集成，是因為Tomcat可以用作Servlet/JSP容器，但是對靜態(tài)資源處理速度較慢，不如Apache和IIS等HTTP服務(wù)器；因此常常將 Tomcat和Apache等集成，前者做Servlet容器，后者處理靜態(tài)資源，而AJP協(xié)議便負(fù)責(zé)Tomcat與Apache的連接。Tomcat和Apache等集成的原理如下圖：

【4】Engine：Engine 組件在Service組件有且只有一個；Engine是Service組件中的請求處理組件。Engine組件從一個或多個Connector中接收并處理，并將完成的響應(yīng)返回給Connector，最終傳遞給客戶端。前面說到，Engine、Host和Context都是容器，但是它們不是平行關(guān)系，而是父子關(guān)系：Engine包含Host，Host包含Context。

<Server port="8005" shutdown="SHUTDOWN"><Service name="Catalina"><Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /><Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /><Engine name="Catalina" defaultHost="localhost"></Engine></Service>
</Server>

其中name屬性用于日志和錯誤信息，在整個Server中應(yīng)該是唯一的。defalutHost屬性指定了默認(rèn)的host名稱，當(dāng)發(fā)往本機的請求指定的host名稱不存在時，一律使用defaultHost指定的host進(jìn)行處理；因此defaulthost的值，必須與Engine中的一個Host組件的name屬性值匹配。
【5】Engine和Host：Host是Engine的子容器。Engine組件中可以內(nèi)嵌1個或者多個Host組件，每個Host組件代表Engine中的一個虛擬主機。Host組件至少有一個，且其中一個的name必須與 Engine組件中的defaultHost屬性相匹配。
【6】Host的作用：Host虛擬主機的作用，是運行多個Web應(yīng)用（一個Context代表一個Web應(yīng)用），并負(fù)責(zé)安裝、展開、啟動、結(jié)束每個Web應(yīng)用。Host組件代表的虛擬主機，對應(yīng)服務(wù)器中一個網(wǎng)絡(luò)名實體（如www.test.com](https://links.jianshu.com/go?to=http%3A%2F%2Fwww.test.com)"或IP地址"116.25.25.25）；為了使用戶可以通過網(wǎng)絡(luò)名連接Tomcat服務(wù)器，這個名字應(yīng)該在DNS服務(wù)器上注冊。

客戶端通常使用主機名來標(biāo)識它們希望連接的服務(wù)器，該主機名也會包含在 HTTP請求頭中，Tomcat從HTTP頭中提取出主機名，尋找名字匹配的主機。如果沒有匹配，請求會發(fā)送至默認(rèn)的主機。因此默認(rèn)主機不需要再DNS服務(wù)器中注冊網(wǎng)絡(luò)名，因為任何與所有Host名稱不匹配的請求，都會路由至默認(rèn)主機。
【7】Host的配置：name屬性指定虛擬主機的主機名，一個Engine有且只有一個Host組件的name屬性和Engine組件的 defaultHost屬性相匹配；一般情況下，主機名需要是在DNS服務(wù)器中注冊網(wǎng)絡(luò)名，但是Engine指定的defaultHost不需要。

<Server port="8005" shutdown="SHUTDOWN"><Service name="Catalina"><Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" /><Connector port="8009" protocol="AJP/1.3" redirectPort="8443" /><Engine name="Catalina" defaultHost="localhost"><Host name="localhost" appBase="webapps" unpackWARs="true" autoDeploy="true"></Host></Engine></Service>
</Server>

unpackWARs指定了是否將代表Web應(yīng)用的WAR文件解壓；如果是true，通過解壓后的文件結(jié)構(gòu)運行該Web應(yīng)用，如果是false，直接使用WAR文件運行Web應(yīng)用。
【8】Context：Context元素代表在虛擬主機上運行的一個Web應(yīng)用。在后文中，提到Context、應(yīng)用或Web應(yīng)用，他們都代指Web應(yīng)用，每個Web應(yīng)用基于WAR文件，或WAR文件解壓后對應(yīng)的目錄（這里稱為應(yīng)用目錄）Context是Host的子容器，每個Host都可以定義任意多的Context元素。元素的配置：Context元素最重要的屬性是 docBase和path，此外reloadable屬性也比較常用。

docBase指定了該Web應(yīng)用使用war包路徑，或應(yīng)用目錄。需要注意的是：在自動部署場景下（配置文件位于xmlBase中），docBase不在appBase目錄中，才需要指定；如果docBase指定的war包或應(yīng)用目錄就在appBase中，則不需要指定。因為Tomcat會自動掃描appBase中的war包和應(yīng)用目錄，制定了反而造成問題。

path指定了訪問該Web應(yīng)用上下文路徑，當(dāng)請求到來時，Tomcat根據(jù)Web應(yīng)用的path屬性與 URL匹配程度來選擇Web應(yīng)用處理相應(yīng)請求。例如：Web 應(yīng)用app1的path屬性是/app1，Web應(yīng)用app2的path屬性是"/app2"，那么請求/app1/index.html會交由app1來處理；而請求/app2/index.html會交由 app2來處理。如果一個Context元素的path屬性為""，那么這個Context是虛擬主機的默認(rèn)的Web應(yīng)用；當(dāng)請求的uri與所有的path都不匹配時，使用該默認(rèn)Web應(yīng)用來處理。

但是，需要注意的是，在自動部署場景（配置文件位于xmlBase中），不能指定path屬性，path屬性由配置的文件的文件名，WAR文件的文件名或應(yīng)用目錄的名稱自動推導(dǎo)出來。如掃描Web應(yīng)該時，發(fā)現(xiàn)xmlBase目錄下的app1.xml，或appBase目錄下的app1.WAR或app1應(yīng)用目錄，則該Web用于的path屬性是app1。如果名稱不是app1而是ROOT，則該Web應(yīng)用時虛擬主機默認(rèn)的Web應(yīng)用，此時path屬性推導(dǎo)為""。

reloadable屬性指示tomcat是否在運行時監(jiān)控在WEB-INF/classes和WEB-INF/lib目錄下class文件的改動。如果值為true，那么當(dāng)class文件改動時，會重新web應(yīng)用的重新加載。在開發(fā)環(huán)境下，reloadable設(shè)置為ture便于調(diào)試；但是在生產(chǎn)環(huán)境中設(shè)置為true會給服務(wù)器帶來性能壓力，因此reloadable參數(shù)的默認(rèn)值為false。在該例子中，docBase位于Host的appBase目錄之外；path屬性沒有指定，而是根據(jù)app1.xml自動推導(dǎo)為app1。

<Context docBase="D:\Program Files\app1.war" reloadable="true"></Context>

若是自動部署（即autoDeploy="true"），那么server.xml配置文件中沒有Context元素的配置。這是因為Tomcat開啟了自動部署，Web應(yīng)用沒有在 server.xml中配置靜態(tài)部署，而是由Tomcat通過特定的規(guī)則自動部署。

四、Web 的自動部署

要開啟Web應(yīng)用的自動部署，需要配置所在的虛擬主機；配置的方式就是在配置Host元素的 deployOnStartup和autoDeploy屬性。如果deployOnStartup和autoDeploy設(shè)置為true，則tomcat啟動自動部署：當(dāng)檢測到新的Web應(yīng)用或Web應(yīng)用更新時，會觸發(fā)應(yīng)用的部署（或重新部署）。

二者的主要區(qū)別在于
【1】deployeOnStartup為true時，Tomcat在啟動時檢查Web應(yīng)用，且檢測到所有的Web應(yīng)用都試做新應(yīng)用；
【2】autoDeploy為true時，Tomcat在運行時定期檢查新的Web應(yīng)用或Web應(yīng)用的更新；

通過配置deployOnStartup和autoDeploy可以開啟虛擬主機自動部署Web應(yīng)用；實際上，自動部署依賴于檢查是否有新的或更改過的Web應(yīng)用，而Host元素中的appBase和xml配置設(shè)置了檢查Web應(yīng)用更新的目錄。

其中，appBase屬性指定Web應(yīng)用所在的目錄，默認(rèn)值是webapps，這是一個相對路徑，代表 Tomcat根目錄下的webapps文件夾。xmlBase屬性指定Web應(yīng)用的XML配置文件所在的目錄，默認(rèn)值為conf/<engine_name><engine_name>，例如上面例子中，主機localhost的xmlBase的默認(rèn)值是$TOMCAT_HOME/conf/Catalina/localhost。

五、appBase 和 docBase的區(qū)別

【1】appBase：這個目錄下面的子目錄將自動被部署為應(yīng)用，且war文件將被自動解壓縮并部署為應(yīng)用，默認(rèn)為tomcat下webapps目錄。
【2】docBase：指定需要關(guān)聯(lián)的項目自動解壓并部署到appBase目錄下。項目的名稱由path屬性決定。
先部署 需要注意，docBase所在的文件或者war包必須存在。否則項目啟動找不到對應(yīng)的目錄。此時文件解壓到appBase目錄下，根據(jù)path屬性，決定解壓后的文件名。
若采用了<Host name="localhost" appBase="webapp" autoDeploy="true"> 配置，那么appBase目錄下的應(yīng)用目錄將會再次部署。此時項目是部署了兩遍。解決辦法，設(shè)置autoDeploy="false"。

六、Tomcat 頂層架構(gòu)小結(jié)

【1】Tomcat中只有一個Server，一個Server可以有多個Service，一個Service可以有多個 Connector和一個Container；
【2】Server掌管著整個Tomcat的生死大權(quán)；
【3】Service是對外提供服務(wù)的；
【4】Connector用于接受請求并將請求封裝成Request和Response來具體處理；
【5】Container用于封裝和管理Servlet，以及具體處理Request請求；

知道了整個Tomcat頂層的分層架構(gòu)和各個組件之間的關(guān)系以及作用，對于絕大多數(shù)的開發(fā)人員來說 Server和Service對我們來說確實很遠(yuǎn)，而我們開發(fā)中絕大部分進(jìn)行配置的內(nèi)容是屬于Connector和 Container的，所以接下來介紹一下Connector和Container。

七、Connector 和 Container的微妙關(guān)系

由上述內(nèi)容我們大致可以知道一個請求發(fā)送到Tomcat之后，首先經(jīng)過Service然后會交給我們的 Connector，Connector用于接收請求并將接收的請求封裝為Request和Response來具體處理，Request和Response封裝完之后再交由Container進(jìn)行處理，Container處理完請求之后再返回給 Connector，最后在由Connector通過Socket將處理的結(jié)果返回給客戶端，這樣整個請求的就處理完了！

Connector最底層使用的是Socket來進(jìn)行連接的，Request和Response是按照HTTP協(xié)議來封裝的，所以Connector同時需要實現(xiàn)TCP/IP協(xié)議和HTTP協(xié)議。Tomcat既然處理請求，那么肯定需要先接收到這個請求，接收請求這個東西我們首先就需要看一下Connector。

八、Container 架構(gòu)分析

Container用于封裝和管理Servlet，以及具體處理Request請求，在Connector內(nèi)部包含了4個子容器，結(jié)構(gòu)圖如下：

4個子容器的作用分別是：
【1】Engine：引擎，用來管理多個站點，一個Service最多只能有一個Engine；
【2】Host：代表一個站點，也可以叫虛擬主機，通過配置Host就可以添加站點；
【3】Context：代表一個應(yīng)用程序，對應(yīng)著平時開發(fā)的一套程序，或者一個WEB-INF目錄以及下面的web.xml文件；
【4】Wrapper：每一Wrapper封裝著一個Servlet；

下面找一個Tomcat的文件目錄對照一下，如下圖所示：

Context和Host的區(qū)別是Context表示一個應(yīng)用，我們的Tomcat中默認(rèn)的配置下webapps下的每一個文件夾目錄都是一個Context，其中ROOT目錄中存放著主應(yīng)用，其他目錄存放著子應(yīng)用，而整個 webapps就是一個 Host站點。我們訪問應(yīng)用Context的時候，如果是ROOT下的則直接使用域名就可以訪問，例如：www.ledouit.com，如果是Host（webapps）下的其他應(yīng)用，則可以使用 www.ledouit.com/docs 進(jìn)行訪問，當(dāng)然默認(rèn)指定的根應(yīng)用ROOT是可以進(jìn)行設(shè)定的，只不過Host站點下默認(rèn)的主營用是ROOT目錄下的。

看到這里我們知道Container是什么，但是還是不知道Container是如何進(jìn)行處理的以及處理完之后是如何將處理完的結(jié)果返回給Connector的。

十、Container 如何處理請求的

Container處理請求是使用Pipeline-Valve管道來處理的！（Valve是閥門之意）Pipeline-Valve是責(zé)任鏈模式，責(zé)任鏈模式是指在一個請求處理的過程中有很多處理者依次對請求進(jìn)行處理，每個處理者負(fù)責(zé)做自己相應(yīng)的處理，處理完之后將處理后的請求返回，再讓下一個處理著繼續(xù)處理。

但是！Pipeline-Valve使用的責(zé)任鏈模式和普通的責(zé)任鏈模式有些不同！區(qū)別主要有以下兩點：
【1】每個Pipeline都有特定的Valve，而且是在管道的最后一個執(zhí)行，這個Valve叫做BaseValve，BaseValve是不可刪除的；
【2】在上層容器的管道的BaseValve中會調(diào)用下層容器的管道。

我們知道Container包含四個子容器，而這四個子容器對應(yīng)的BaseValve分別在：StandardEngineValve、StandardHostValve、StandardContextValve、StandardWrapperValve。Pipeline的處理流程圖如下：

【1】Connector在接收到請求后會首先調(diào)用最頂層容器的Pipeline來處理，這里的最頂層容器的 Pipeline就是EnginePipeline（Engine的管道）；
【2】在Engine的管道中依次會執(zhí)行EngineValve1、EngineValve2等等，最后會執(zhí)行 StandardEngineValve，在StandardEngineValve中會調(diào)用Host管道，然后再依次執(zhí)行Host的 HostValve1、HostValve2等，最后在執(zhí)行StandardHostValve，然后再依次調(diào)用Context的管道和 Wrapper的管道，最后執(zhí)行到StandardWrapperValve。
【3】當(dāng)執(zhí)行到StandardWrapperValve的時候，會在StandardWrapperValve中創(chuàng)建FilterChain，并調(diào)用其 doFilter方法來處理請求，這個FilterChain包含著我們配置的與請求相匹配的Filter和Servlet，其 doFilter方法會依次調(diào)用所有的Filter的doFilter方法和Servlet的service方法，這樣請求就得到了處理！
【4】當(dāng)所有的Pipeline-Valve都執(zhí)行完之后，并且處理完了具體的請求，這個時候就可以將返回的結(jié)果交給Connector了，Connector在通過Socket的方式將結(jié)果返回給客戶端。

十一、tomcat 容器是如何創(chuàng)建 servlet類實例？用到了什么原理？

當(dāng)容器啟動時，會讀取在webapps目錄下所有的web應(yīng)用中的web.xml文件，然后對xml文件進(jìn)行解析，并讀取servlet注冊信息。然后，將每個應(yīng)用中注冊的servlet類都進(jìn)行加載，并通過反射的方式實例化。（有時候也是在第一次請求時實例化）在servlet注冊時加上如果為正數(shù)，則在一開始就實例化，如果不寫或為負(fù)數(shù)，則第一次請求實例化。

十二、共享 session處理

目前的處理方式有如下幾種：
【1】使用Tomcat本身的Session復(fù)制功能。參考http://ajita.iteye.com/blog/1715312（Session復(fù)制的配置）方案的有點是配置簡單，缺點是當(dāng)集群數(shù)量較多時，Session復(fù)制的時間會比較長，影響響應(yīng)的效率；
【2】使用第三方來存放共享Session：目前用的較多的是使用memcached來管理共享Session，借助于memcached-sesson-manager來進(jìn)行Tomcat的Session管理。參考http://ajita.iteye.com/blog/1716320（使用MSM管理Tomcat集群session）
【3】使用黏性session的策略：對于會話要求不太強（不涉及到計費，失敗了允許重新請求下等）的場合，同一個用戶的session可以由nginx或者apache交給同一個Tomcat來處理，這就是所謂的 session sticky策略，目前應(yīng)用也比較多。參考：http://ajita.iteye.com/blog/1848665（tomcat session sticky）Nginx默認(rèn)不包含session sticky模塊，需要重新編譯才行（windows下我也不知道怎么重新編譯）優(yōu)點是處理效率高多了，缺點是強會話要求的場合不合適。

十三、關(guān)于 Tomcat 的 session數(shù)目

這個可以直接從Tomcat的web管理界面去查看即可，或者借助于第三方工具Lambda Probe來查看，它相對于Tomcat自帶的管理稍微多了點功能，但也不多 ；

十四、Tomcat 一個請求的完整過程

首先DNS解析機器，一般是ng服務(wù)器ip地址，然后ng根據(jù)server的配置，尋找路徑為yy/的機器列表，ip和端口。最后 選擇其中一臺機器進(jìn)行訪問。下面為詳細(xì)過程：
【1】請求被發(fā)送到本機端口8080，被在那里偵聽的Coyote HTTP/1.1 Connector獲得；
【2】Connector把該請求交給它所在的Service的Engine來處理，并等待來自Engine的回應(yīng)；
【3】Engine獲得請求localhost/yy/index.jsp，匹配它所擁有的所有虛擬主機Host；
【4】Engine匹配到名為 localhost 的 Host（即使匹配不到也把請求交給該 Host處理，因為該Host被定義為該 Engine的默認(rèn)主機）；
【5】localhost Host獲得請求/yy/index.jsp，匹配它所擁有的所有Context；
【6】Host匹配到路徑為/yy的Context（如果匹配不到就把該請求交給路徑名為”“的Context去處理）；
【7】path=”/yy”的Context獲得請求/index.jsp，在它的mapping table中尋找對應(yīng)的servlet；
【8】Context匹配到URL PATTERN為*.jsp的servlet，對應(yīng)于JspServlet類；
【9】構(gòu)造HttpServletRequest對象和HttpServletResponse對象，作為參數(shù)調(diào)用JspServlet的doGet或 doPost方法；
【10】Context把執(zhí)行完了之后的HttpServletResponse對象返回給Host；
【11】Host把HttpServletResponse對象返回給Engine；
【12】Engine把HttpServletResponse對象返回給Connector；
【13】Connector把HttpServletResponse對象返回給客戶browser；

十五、Tomcat 工作模式

Tomcat是一個JSP/Servlet容器。其作為Servlet容器，有三種工作模式：獨立的Servlet容器、進(jìn)程內(nèi)的Servlet容器和進(jìn)程外的Servlet容器。進(jìn)入Tomcat的請求可以根據(jù)Tomcat的工作模式分為如下兩類：
【1】Tomcat作為應(yīng)用程序服務(wù)器：請求來自于前端的web服務(wù)器，這可能是Apache, IIS, Nginx等；
【2】Tomcat作為獨立服務(wù)器：請求來自于web瀏覽器；

Tomcat的工作一般分為三種：
【1】bio： 傳統(tǒng)的Java I/O操作，同步且阻塞I/O，一個線程處理一個請求，并發(fā)量高時，線程數(shù)較多，浪費資源；（已經(jīng)很少有人在使用）
【2】nio： JDK1.4開始支持，同步阻塞或同步非阻塞IO，可以通過少量的線程來處理大量的請求；（從Tomcat 8版本開始默認(rèn)就是這種模式）
【3】apr： 以JNI的形式調(diào)用Apache HTTP服務(wù)器的核心動態(tài)鏈接庫來處理文件讀取或網(wǎng)絡(luò)傳輸操作，從而大大地提高Tomcat對靜態(tài)文件的處理性能；（企業(yè)中使用較多）

十六、如何對 Tomcat 進(jìn)行優(yōu)化

【1】關(guān)閉Manager管理頁面；（默認(rèn)已經(jīng)關(guān)閉）
【2】關(guān)閉host-mangent管理頁面；（默認(rèn)已經(jīng)關(guān)閉）
【3】對Tomcat日志進(jìn)行分割；
【4】定義Tomcat 404錯誤返回的頁面；
【5】對JVM進(jìn)行優(yōu)化；
【6】對Tomcat線程池進(jìn)行優(yōu)化；

十七、如何對 Tomcat 進(jìn)行優(yōu)化

【1】關(guān)閉Manager管理頁面；（默認(rèn)已經(jīng)關(guān)閉）
【2】關(guān)閉host-mangent管理頁面；（默認(rèn)已經(jīng)關(guān)閉）
【3】對Tomcat日志進(jìn)行分割；
【4】定義Tomcat 404錯誤返回的頁面；
【5】對JVM進(jìn)行優(yōu)化；
【6】對Tomcat線程池進(jìn)行優(yōu)化；
【7】更改Tomcat的工作的模式；