優(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é)有詳細說明 --></Host></Engine></Service>
</Server>

【1】頂層元素：元素是整個配置文件的根元素，元素代表一個Engine元素以及一組與之相連的Connector元素。
【2】連接器： 代表了外部客戶端發(fā)送請求到特定Service的接口；同時也是外部客戶端從特定Service接收響應(yīng)的接口。
【3】容器：容器的功能是處理Connector接收進來的請求，并產(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集合，同時維護它所包含的所有的 Service的生命周期，包含如何初始化，如何結(jié)束服務(wù)，如何找到客戶端要訪問的 Service。
【2】Service：在Connector和Engine外面包一層，把它們組合在一起，對外提供服務(wù)。一個Service可以包含多個Connector，但是只能包含一個Engine；其中Connector的作用是從客戶端接收請求，Engine的作用是處理接收進來的請求。

<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ā)、負載均衡、處理靜態(tài)文件等；通過代理服務(wù)器訪問Tomcat時，是在局域網(wǎng)中，因為一般仍使用8080端口。

第二個配置Connector，客戶端可以通過8009端口使用AJP協(xié)議訪問 Tomcat。AJP協(xié)議負責(zé)和其他的Http服務(wù)器（如Apache）建立連接；在把 Tomcat與其他服務(wù)器集成時，就需要用到這個連接器，之所以使用 Tomcat和其他服務(wù)器集成，是因為Tomcat可以用作Servlet/JSP容器，但是對靜態(tài)資源處理速度較慢，不如Apache和IIS等HTTP服務(wù)器；因此常常將 Tomcat和Apache等集成，前者做Servlet容器，后者處理靜態(tài)資源，而AJP協(xié)議便負責(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屬性指定了默認的host名稱，當(dāng)發(fā)往本機的請求指定的host名稱不存在時，一律使用defaultHost指定的host進行處理；因此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)用），并負責(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ù)器上注冊。

客戶端通常使用主機名來標識它們希望連接的服務(wù)器，該主機名也會包含在 HTTP請求頭中，Tomcat從HTTP頭中提取出主機名，尋找名字匹配的主機。如果沒有匹配，請求會發(fā)送至默認的主機。因此默認主機不需要再DNS服務(wù)器中注冊網(wǎng)絡(luò)名，因為任何與所有Host名稱不匹配的請求，都會路由至默認主機。
【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是虛擬主機的默認的Web應(yīng)用；當(dāng)請求的uri與所有的path都不匹配時，使用該默認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)用時虛擬主機默認的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ù)的默認值為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)用所在的目錄，默認值是webapps，這是一個相對路徑，代表 Tomcat根目錄下的webapps文件夾。xmlBase屬性指定Web應(yīng)用的XML配置文件所在的目錄，默認值為conf/<engine_name><engine_name>，例如上面例子中，主機localhost的xmlBase的默認值是$TOMCAT_HOME/conf/Catalina/localhost。

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

【1】appBase：這個目錄下面的子目錄將自動被部署為應(yīng)用，且war文件將被自動解壓縮并部署為應(yīng)用，默認為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對我們來說確實很遠，而我們開發(fā)中絕大部分進行配置的內(nèi)容是屬于Connector和 Container的，所以接下來介紹一下Connector和Container。

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

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

Connector最底層使用的是Socket來進行連接的，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中默認的配置下webapps下的每一個文件夾目錄都是一個Context，其中ROOT目錄中存放著主應(yīng)用，其他目錄存放著子應(yīng)用，而整個 webapps就是一個 Host站點。我們訪問應(yīng)用Context的時候，如果是ROOT下的則直接使用域名就可以訪問，例如：www.ledouit.com，如果是Host（webapps）下的其他應(yīng)用，則可以使用 www.ledouit.com/docs 進行訪問，當(dāng)然默認指定的根應(yīng)用ROOT是可以進行設(shè)定的，只不過Host站點下默認的主營用是ROOT目錄下的。

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

十、Container 如何處理請求的

Container處理請求是使用Pipeline-Valve管道來處理的！（Valve是閥門之意）Pipeline-Valve是責(zé)任鏈模式，責(zé)任鏈模式是指在一個請求處理的過程中有很多處理者依次對請求進行處理，每個處理者負責(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文件進行解析，并讀取servlet注冊信息。然后，將每個應(yīng)用中注冊的servlet類都進行加載，并通過反射的方式實例化。（有時候也是在第一次請求時實例化）在servlet注冊時加上如果為正數(shù)，則在一開始就實例化，如果不寫或為負數(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來進行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默認不包含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和端口。最后 選擇其中一臺機器進行訪問。下面為詳細過程：
【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的默認主機）；
【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容器、進程內(nèi)的Servlet容器和進程外的Servlet容器。進入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版本開始默認就是這種模式）
【3】apr： 以JNI的形式調(diào)用Apache HTTP服務(wù)器的核心動態(tài)鏈接庫來處理文件讀取或網(wǎng)絡(luò)傳輸操作，從而大大地提高Tomcat對靜態(tài)文件的處理性能；（企業(yè)中使用較多）

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

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

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

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