1、Tomcat 的缺省端口是多少，怎么修改？
1）找到 Tomcat 目錄下的 conf 文件夾
2）進(jìn)入 conf 文件夾里面找到 server.xml 文件
3）打開 server.xml 文件
4）在 server.xml 文件里面找到下列信息
<Connector connectionTimeout="20000" port="8080" protocol="HTTP/1.1" redirectPort="8443" uriEncoding="utf-8"/>
port="8080"改成你想要的端口
2、tomcat 有哪幾種 Connector 運(yùn)行模式(優(yōu)化)？
bio：傳統(tǒng)的 Java I/O 操作，同步且阻塞 IO。
maxThreads=”150”//Tomcat 使用線程來處理接收的每個(gè)請(qǐng)求。這個(gè)值表示Tomcat 可創(chuàng)建的最大的線程數(shù)。默認(rèn)值 200?？梢愿鶕?jù)機(jī)器的時(shí)期性能和內(nèi)存大小調(diào)整，一般可以在 400-500。最大可以在 800 左右。
minSpareThreads=”25”—Tomcat 初始化時(shí)創(chuàng)建的線程數(shù)。默認(rèn)值 4。如果當(dāng)前沒有空閑線程，且沒有超過 maxThreads，一次性創(chuàng)建的空閑線程數(shù)量。
Tomcat 初始化時(shí)創(chuàng)建的線程數(shù)量也由此值設(shè)置。
maxSpareThreads=”75”–一旦創(chuàng)建的線程超過這個(gè)值，Tomcat 就會(huì)關(guān)閉不再需要的 socket 線程。默認(rèn)值 50。一旦創(chuàng)建的線程超過此數(shù)值，Tomcat 會(huì)關(guān)閉不再需要的線程。線程數(shù)可以大致上用 “同時(shí)在線人數(shù)每秒用戶操作次數(shù)系統(tǒng)平均操作時(shí)間” 來計(jì)算。
acceptCount=”100”—-指定當(dāng)所有可以使用的處理請(qǐng)求的線程數(shù)都被使用時(shí)，可以放到處理隊(duì)列中的請(qǐng)求數(shù)，超過這個(gè)數(shù)的請(qǐng)求將不予處理。默認(rèn)值10。如果當(dāng)前可用線程數(shù)為 0，則將請(qǐng)求放入處理隊(duì)列中。這個(gè)值限定了請(qǐng)求隊(duì)列的大小，超過這個(gè)數(shù)值的請(qǐng)求將不予處理。
connectionTimeout=”20000” –網(wǎng)絡(luò)連接超時(shí)，默認(rèn)值 20000，單位：毫秒。設(shè)置為 0 表示永不超時(shí)，這樣設(shè)置有隱患的。通?？稍O(shè)置為 30000 毫秒。
nio：JDK1.4 開始支持，同步阻塞或同步非阻塞 IO。
指定使用 NIO 模型來接受 HTTP 請(qǐng)求protocol=”org.apache.coyote.http11.Http11NioProtocol” 指定使用 NIO 模型來接受 HTTP 請(qǐng)求。默認(rèn)是 BlockingIO，配置為protocol=”HTTP/1.1” acceptorThreadCount=”2” 使用 NIO 模型時(shí)接收線程的數(shù)目aio(nio.2)：JDK7 開始支持，異步非阻塞 IO。
apr：Tomcat 將以 JNI 的形式調(diào)用 Apache HTTP 服務(wù)器的核心動(dòng)態(tài)鏈接庫(kù)來處理文件讀取或網(wǎng)絡(luò)傳輸操作，從而大大地 提高 Tomcat 對(duì)靜態(tài)文件的處理性能。
<Connector port="8080"
protocol="org.apache.coyote.http11.Http11NioProtocol"
connectionTimeout="20000"
redirectPort="8443
maxThreads=“500”
minSpareThreads=“100”
maxSpareThreads=“200”
acceptCount="200"
enableLookups="false"
/>
其他配置
maxHttpHeaderSize="8192" http 請(qǐng)求頭信息的最大程度，超過此長(zhǎng)度的部分不予處理。一般 8K。
URIEncoding="UTF-8" 指定 Tomcat 容器的 URL 編碼格式。
disableUploadTimeout="true" 上傳時(shí)是否使用超時(shí)機(jī)制
enableLookups="false"--是否反查域名，默認(rèn)值為 true。為了提高處理能力，應(yīng)設(shè)置為 false
compression="on" 打開壓縮功能compressionMinSize="10240" 啟用壓縮的輸出內(nèi)容大小，默認(rèn)為 2KB noCompressionUserAgents="gozilla, traviata" 對(duì)于以下的瀏覽器，不啟用壓縮
compressableMimeType="text/html,text/xml,text/javascript,text/css,text/plain"
哪些資源類型需要壓縮
3、Tomcat 有幾種部署方式？
1）直接把 Web 項(xiàng)目放在 webapps 下，Tomcat 會(huì)自動(dòng)將其部署
2）在 server.xml 文件上配置<Context>節(jié)點(diǎn)，設(shè)置相關(guān)的屬性即可
3）通過 Catalina 來進(jìn)行配置:進(jìn)入到conf\Catalina\localhost 文件下，創(chuàng)建一個(gè)xml 文件，該文件的名字就是站點(diǎn)的名字。
編寫 XML 的方式來進(jìn)行設(shè)置。
4、tomcat 容器是如何創(chuàng)建 servlet 類實(shí)例？用到了什么原理？
當(dāng)容器啟動(dòng)時(shí)，會(huì)讀取在 webapps 目錄下所有的 web 應(yīng)用中的 web.xml 文件，然后對(duì) xml 文件進(jìn)行解析，并讀取 servlet 注冊(cè)信息。然后，將每個(gè)應(yīng)用中注冊(cè)的 servlet 類都進(jìn)行加載，并通過反射的方式實(shí)例化。
（有時(shí)候也是在第一次請(qǐng)求時(shí)實(shí)例化）在 servlet 注冊(cè)時(shí)加上如果為正數(shù)，則在一開始就實(shí)例化，如果不寫或?yàn)樨?fù)數(shù)，則第一次請(qǐng)求實(shí)例化。
5.tomcat 如何優(yōu)化？
1、優(yōu)化連接配置.這里以 tomcat7 的參數(shù)配置為例，需要修改 conf/server.xml文件，修改連接數(shù)，關(guān)閉客戶端 dns 查詢。
參數(shù)解釋：
URIEncoding=”UTF-8″ :使得 tomcat 可以解析含有中文名的文件的 url，真方便，不像 apache 里還有搞個(gè) mod_encoding，還要手工編譯maxSpareThreads : 如果空閑狀態(tài)的線程數(shù)多于設(shè)置的數(shù)目，則將這些線程中止，減少這個(gè)池中的線程總數(shù)。
minSpareThreads : 最小備用線程數(shù)，tomcat 啟動(dòng)時(shí)的初始化的線程數(shù)。
enableLookups : 這個(gè)功效和 Apache 中的 HostnameLookups 一樣，設(shè)為關(guān)閉。
connectionTimeout : connectionTimeout 為網(wǎng)絡(luò)連接超時(shí)時(shí)間毫秒數(shù)。
maxThreads : maxThreads Tomcat 使用線程來處理接收的每個(gè)請(qǐng)求。這個(gè)值表示 Tomcat 可創(chuàng)建的最大的線程數(shù)，即最大并發(fā)數(shù)。
acceptCount : acceptCount 是當(dāng)線程數(shù)達(dá)到maxThreads 后，后續(xù)請(qǐng)求會(huì)被放入一個(gè)等待隊(duì)列，這個(gè) acceptCount 是這個(gè)隊(duì)列的大小，如果這個(gè)隊(duì)列也滿了，就直接 refuse connection maxProcessors 與 minProcessors : 在 Java 中線程是程序運(yùn)行時(shí)的路徑，是在一個(gè)程序中與其它控制線程無關(guān)的、能夠獨(dú)立運(yùn)行的代碼段。它們共享相同
的地址空間。多線程幫助程序員寫出 CPU 最 大利用率的高效程序，使空閑時(shí)間保持最低，從而接受更多的請(qǐng)求。
通常 Windows 是 1000 個(gè)左右，Linux 是 2000 個(gè)左右。
useURIValidationHack:
我們來看一下 tomcat 中的一段源碼：
【security】
if (connector.getUseURIValidationHack()) {
String uri = validate(request.getRequestURI());
if (uri == null) {
res.setStatus(400);
res.setMessage(“Invalid URI”);
throw new IOException(“Invalid URI”);
} else {
req.requestURI().setString(uri);
// Redoing the URI decoding
req.decodedURI().duplicate(req.requestURI());
req.getURLDecoder().convert(req.decodedURI(), true);
可以看到如果把 useURIValidationHack 設(shè)成”false”，可以減少它對(duì)一些 url的不必要的檢查從而減省開銷。
enableLookups=”false” ： 為了消除 DNS 查詢對(duì)性能的影響我們可以關(guān)閉DNS 查詢，方式是修改 server.xml 文件中的 enableLookups 參數(shù)值。
disableUploadTimeout ：類似于 Apache 中的 keeyalive 一樣
給 Tomcat 配置 gzip 壓縮(HTTP 壓縮)功能
compression=”on” compressionMinSize=”2048″
compressableMimeType=”text/html,text/xml,text/JavaScript,text/css,text/plain”
HTTP 壓縮可以大大提高瀏覽網(wǎng)站的速度，它的原理是，在客戶端請(qǐng)求網(wǎng)頁(yè)后，從服務(wù)器端將網(wǎng)頁(yè)文件壓縮，再下載到客戶端，由客戶端的瀏覽器負(fù)責(zé)解壓縮并瀏覽。相對(duì)于普通的瀏覽過程 HTML,CSS,javascript , Text ，它可以節(jié)省 40%左右的流量。更為重要的是，它可以對(duì)動(dòng)態(tài)生成的，包括 CGI、PHP ,JSP , ASP , Servlet,SHTML 等輸出的網(wǎng)頁(yè)也能進(jìn)行壓縮，壓縮效率驚人。
1)compression=”on” 打開壓縮功能
2)compressionMinSize=”2048″ 啟用壓縮的輸出內(nèi)容大小，這里面默認(rèn)為2KB
3)noCompressionUserAgents=”gozilla, traviata” 對(duì)于以下的瀏覽器，不啟用壓縮
4)compressableMimeType=”text/html,text/xml” 壓縮類型
最后不要忘了把 8443 端口的地方也加上同樣的配置，因?yàn)槿绻覀冏?https 協(xié)議的話，我們將會(huì)用到 8443 端口這個(gè)段的配置，對(duì)吧？
<!–enable tomcat ssl–>
<Connector port=”8443″ protocol=”HTTP/1.1″
URIEncoding=”UTF-8″ minSpareThreads=”25″ maxSpareThreads=”
75″
enableLookups=”false” disableUploadTimeout=”true”
connectionTimeout=”20000″
acceptCount=”300″ maxThreads=”300″ maxProcessors=”1000″
minProcessors=”5″
useURIValidationHack=”false”
compression=”on” compressionMinSize=”2048″
compressableMimeType=”text/html,text/xml,text/javascript,text/css,text/plain”
SSLEnabled=”true”
scheme=”https” secure=”true”
clientAuth=”false” sslProtocol=”TLS”
keystoreFile=”d:/tomcat2/conf/shnlap93.jks” keystorePass=”aaaaaa”
/>
好了，所有的 Tomcat 優(yōu)化的地方都加上了。
6.內(nèi)存調(diào)優(yōu)
內(nèi)存方式的設(shè)置是在 catalina.sh 中，調(diào)整一下 JAVA_OPTS 變量即可，因?yàn)楹竺娴膯?dòng)參數(shù)會(huì)把JAVA_OPTS 作為 JVM 的啟動(dòng)參數(shù)來處理。
具體設(shè)置如下：
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -
XX:NewRatio=4 -XX:SurvivorRatio=4"
其各項(xiàng)參數(shù)如下：
-Xmx3550m：設(shè)置 JVM 最大可用內(nèi)存為 3550M。
-Xms3550m：設(shè)置 JVM 促使內(nèi)存為 3550m。此值可以設(shè)置與-Xmx 相同，以避免每次垃圾回收完成后 JVM 重新分配內(nèi)存。
-Xmn2g：設(shè)置年輕代大小為 2G。整個(gè)堆大小=年輕代大小 + 年老代大小 +持久代大小。持久代一般固定大小為 64m，所以增大年輕代后，將會(huì)減小年老代大小。此值對(duì)系統(tǒng)性能影響較大，Sun 官方推薦配置為整個(gè)堆的 3/8。
-Xss128k：設(shè)置每個(gè)線程的堆棧大小。JDK5.0 以后每個(gè)線程堆棧大小為 1M，以前每個(gè)線程堆棧大小為 256K。更具應(yīng)用的線程所需內(nèi)存大小進(jìn)行調(diào)整。在相同物理內(nèi)存下，減小這個(gè)值能生成更多的線程。但是操作系統(tǒng)對(duì)一個(gè)進(jìn)程內(nèi)的線程數(shù)還是有限制的，不能無限生成，經(jīng)驗(yàn)值在 3000~5000 左右。
-XX:NewRatio=4:設(shè)置年輕代（包括 Eden 和兩個(gè) Survivor 區(qū)）與年老代的比值（除去持久代）。設(shè)置為 4，則年輕代與年老代所占比值為 1：4，年輕代占整個(gè)堆棧的 1/5
-XX:SurvivorRatio=4：設(shè)置年輕代中 Eden 區(qū)與 Survivor 區(qū)的大小比值。設(shè)置為 4，則兩個(gè) Survivor 區(qū)與一個(gè) Eden 區(qū)的比值為 2:4，一個(gè) Survivor 區(qū)占整個(gè)年輕代的 1/6
-XX:MaxPermSize=16m:設(shè)置持久代大小為 16m。
-XX:MaxTenuringThreshold=0：設(shè)置垃圾最大年齡。如果設(shè)置為 0 的話，則年輕代對(duì)象不經(jīng)過 Survivor 區(qū)，直接進(jìn)入年老代。對(duì)于年老代比較多的應(yīng)用，可以提高效率。如果將此值設(shè)置為一個(gè)較大值，則年輕代對(duì)象會(huì)在 Survivor 區(qū)進(jìn)行多次復(fù)制，這樣可以增加對(duì)象再年輕代的存活時(shí)間，增加在年輕代即被回收的概論。
7.垃圾回收策略調(diào)優(yōu)
垃圾回收的設(shè)置也是在 catalina.sh 中，調(diào)整JAVA_OPTS 變量。
具體設(shè)置如下：
JAVA_OPTS="$JAVA_OPTS -Xmx3550m -Xms3550m -Xss128k -XX:+UseParallelGC -XX:MaxGCPauseMillis=100"
具體的垃圾回收策略及相應(yīng)策略的各項(xiàng)參數(shù)如下：
串行收集器（JDK1.5 以前主要的回收方式）
-XX:+UseSerialGC:設(shè)置串行收集器
并行收集器（吞吐量?jī)?yōu)先）
示例：
java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -XX:+UseParallelGC -
XX:MaxGCPauseMillis=100
-XX:+UseParallelGC：選擇垃圾收集器為并行收集器。此配置僅對(duì)年輕代有效。即上述配置下，年輕代使用并發(fā)收集，而年老代仍舊使用串行收集。
-XX:ParallelGCThreads=20：配置并行收集器的線程數(shù)，即：同時(shí)多少個(gè)線程一起進(jìn)行垃圾回收。此值最好配置與處理器數(shù)目相等。
-XX:+UseParallelOldGC：配置年老代垃圾收集方式為并行收集。JDK6.0 支持對(duì)年老代并行收集
-XX:MaxGCPauseMillis=100:設(shè)置每次年輕代垃圾回收的最長(zhǎng)時(shí)間，如果無法滿足此時(shí)間，JVM 會(huì)自動(dòng)調(diào)整年輕代大小，以滿足此值。
-XX:+UseAdaptiveSizePolicy：設(shè)置此選項(xiàng)后，并行收集器會(huì)自動(dòng)選擇年輕代區(qū)大小和相應(yīng)的 Survivor 區(qū)比例，以達(dá)到目標(biāo)系統(tǒng)規(guī)定的最低相應(yīng)時(shí)間或者收集頻率等，此值建議使用并行收集器時(shí)，一直打開。
并發(fā)收集器（響應(yīng)時(shí)間優(yōu)先）
示例：java -Xmx3550m -Xms3550m -Xmn2g -Xss128k -
XX:+UseConcMarkSweepGC
-XX:+UseConcMarkSweepGC：設(shè)置年老代為并發(fā)收集。測(cè)試中配置這個(gè)以后，-XX:NewRatio=4 的配置失效了，原因不明。所以，此時(shí)年輕代大小最好用-Xmn 設(shè)置。
-XX:+UseParNewGC: 設(shè)置年輕代為并行收集?？膳c CMS 收集同時(shí)使用。
JDK5.0 以上，JVM 會(huì)根據(jù)系統(tǒng)配置自行設(shè)置，所以無需再設(shè)置此值。
-XX:CMSFullGCsBeforeCompaction：由于并發(fā)收集器不對(duì)內(nèi)存空間進(jìn)行壓縮、整理，所以運(yùn)行一段時(shí)間以后會(huì)產(chǎn)生“碎片”，使得運(yùn)行效率降低。此值設(shè)置運(yùn)行多少次 GC 以后對(duì)內(nèi)存空間進(jìn)行壓縮、整理。
-XX:+UseCMSCompactAtFullCollection：打開對(duì)年老代的壓縮?？赡軙?huì)影響性能，但是可以消除碎片
8.共享 session 處理
目前的處理方式有如下幾種：
1).使用 Tomcat 本身的 Session 復(fù)制功能
參考 http://ajita.iteye.com/blog/1715312（Session 復(fù)制的配置）
方案的有點(diǎn)是配置簡(jiǎn)單，缺點(diǎn)是當(dāng)集群數(shù)量較多時(shí)，Session 復(fù)制的時(shí)間會(huì)比較長(zhǎng)，影響響應(yīng)的效率
2).使用第三方來存放共享 Session
目前用的較多的是使用 memcached 來管理共享 Session，借助于memcached-sesson-manager 來進(jìn)行 Tomcat 的 Session 管理
參考 http://ajita.iteye.com/blog/1716320（使用 MSM 管理 Tomcat 集群session）
3).使用黏性 session 的策略
對(duì)于會(huì)話要求不太強(qiáng)（不涉及到計(jì)費(fèi)，失敗了允許重新請(qǐng)求下等）的場(chǎng)合，同一個(gè)用戶的 session 可以由 nginx 或者 apache 交給同一個(gè) Tomcat 來處理，這就是所謂的 session sticky 策略，目前應(yīng)用也比較多
參考：http://ajita.iteye.com/blog/1848665（tomcat session sticky）
nginx 默認(rèn)不包含 session sticky 模塊，需要重新編譯才行（windows 下我也不知道怎么重新編譯）
優(yōu)點(diǎn)是處理效率高多了，缺點(diǎn)是強(qiáng)會(huì)話要求的場(chǎng)合不合適
8.添加 JMS 遠(yuǎn)程監(jiān)控
對(duì)于部署在局域網(wǎng)內(nèi)其它機(jī)器上的 Tomcat，可以打開 JMX 監(jiān)控端口，局域網(wǎng)其它機(jī)器就可以通過這個(gè)端口查看一些常用的參數(shù)（但一些比較復(fù)雜的功能不支持），同樣是在 JVM 啟動(dòng)參數(shù)中配置即可，配置如下：
-Dcom.sun.management.jmxremote.ssl=false -
Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=192.168.71.38 設(shè)置 JVM 的 JMS 監(jiān)控監(jiān)聽的 IP地址，主要是為了防止錯(cuò)誤的監(jiān)聽成 127.0.0.1 這個(gè)內(nèi)網(wǎng)地址
-Dcom.sun.management.jmxremote.port=1090 設(shè)置 JVM 的 JMS 監(jiān)控的端口
-Dcom.sun.management.jmxremote.ssl=false 設(shè)置 JVM 的 JMS 監(jiān)控不實(shí)用SSL
-Dcom.sun.management.jmxremote.authenticate=false 設(shè)置 JVM 的 JMS 監(jiān)控不需要認(rèn)證
9.專業(yè)點(diǎn)的分析工具有
IBM ISA，JProfiler、probe 等，具體監(jiān)控及分析方式去網(wǎng)上搜索即可
10.關(guān)于 Tomcat 的 session 數(shù)目
這個(gè)可以直接從 Tomcat 的 web 管理界面去查看即可 ；
或者借助于第三方工具 Lambda Probe 來查看，它相對(duì)于 Tomcat 自帶的管理稍微多了點(diǎn)功能，但也不多 ；
11.監(jiān)視 Tomcat 的內(nèi)存使用情況
使用 JDK 自帶的 jconsole 可以比較明了的看到內(nèi)存的使用情況，線程的狀態(tài)，當(dāng)前加載的類的總量等；
JDK 自帶的 jvisualvm 可以下載插件（如 GC 等），可以查看更豐富的信息。如果是分析本地的 Tomcat 的話，還可以進(jìn)行內(nèi)存抽樣等，檢查每個(gè)類的使用情況
12.打印類的加載情況及對(duì)象的回收情況
這個(gè)可以通過配置 JVM 的啟動(dòng)參數(shù)，打印這些信息（到屏幕（默認(rèn)也會(huì)到catalina.log 中）或者文件），具體參數(shù)如下：
-XX:+PrintGC：輸出形式：[GC 118250K->113543K(130112K), 0.0094143
secs] [Full GC 121376K->10414K(130112K), 0.0650971 secs]
-XX:+PrintGCDetails：輸出形式：[GC [DefNew: 8614K->781K(9088K),
0.0123035 secs] 118250K->113543K(130112K), 0.0124633 secs] [GC
[DefNew: 8614K->8614K(9088K), 0.0000665 secs][Tenured:
112761K->10414K(121024K), 0.0433488 secs] 121376K->10414K(130112K),
0.0436268 secs]
-XX:+PrintGCTimeStamps -XX:+PrintGC：PrintGCTimeStamps 可與上面兩個(gè)
混合使用，輸出形式：11.851: [GC 98328K->93620K(130112K), 0.0082960
secs]
-XX:+PrintGCApplicationConcurrentTime：打印每次垃圾回收前，程序未中斷
的執(zhí)行時(shí)間?？膳c上面混合使用。輸出形式：Application time: 0.5291524
seconds
-XX:+PrintGCApplicationStoppedTime：打印垃圾回收期間程序暫停的時(shí)間。
可與上面混合使用。輸出形式：Total time for which application threads were
stopped: 0.0468229 seconds
-XX:PrintHeapAtGC: 打印 GC 前后的詳細(xì)堆棧信息
-Xloggc:filename:與上面幾個(gè)配合使用，把相關(guān)日志信息記錄到文件以便分析
-verbose:class 監(jiān)視加載的類的情況
-verbose:gc 在虛擬機(jī)發(fā)生內(nèi)存回收時(shí)在輸出設(shè)備顯示信息
-verbose:jni 輸出 native 方法調(diào)用的相關(guān)情況，一般用于診斷 jni 調(diào)用錯(cuò)誤信息
13.Tomcat 一個(gè)請(qǐng)求的完整過程
Ng:(nginx)
upstream yy_001{
server 10.99.99.99:8080;
server 10.99.99.100:8080;
hash $**;
healthcheck_enabled;
healthcheck_delay 3000;
healthcheck_timeout 1000;
healthcheck_failcount 2;
healthcheck_send 'GET /healthcheck.html HTTP/1.0' 'Host: wo.com'
'Connection: close';
}
server {
include base.conf;
server_name wo.de.tian;
...
location /yy/ {
proxy_pass http://yy_001;
}
首先 dns 解析 wo.de.tian 機(jī)器，一般是 ng 服務(wù)器 ip 地址然后 ng 根據(jù) server 的配置，尋找路徑為 yy/的機(jī)器列表，ip 和端口最后 選擇其中一臺(tái)機(jī)器進(jìn)行訪問—->下面為詳細(xì)過程
- 請(qǐng)求被發(fā)送到本機(jī)端口 8080，被在那里偵聽的Coyote HTTP/1.1 Connector 獲得
- Connector 把該請(qǐng)求交給它所在的 Service 的 Engine 來處理，并等待來自Engine 的回應(yīng)
- Engine 獲得請(qǐng)求 localhost/yy/index.jsp，匹配它所擁有的所有虛擬主機(jī) Host
- Engine 匹配到名為 localhost 的 Host（即使匹配不到也把請(qǐng)求交給該 Host
處理，因?yàn)樵?Host 被定義為該 Engine 的默認(rèn)主機(jī)） - localhost Host 獲得請(qǐng)求/yy/index.jsp，匹配它所擁有的所有 Context
- Host 匹配到路徑為/yy 的 Context（如果匹配不到就把該請(qǐng)求交給路徑名為”“的 Context 去處理）
- path=”/yy”的 Context 獲得請(qǐng)求/index.jsp，在它的mapping table 中尋找對(duì)應(yīng)的 servlet
- Context 匹配到 URL PATTERN 為*.jsp 的 servlet，對(duì)應(yīng)于 JspServlet 類
- 構(gòu)造 HttpServletRequest 對(duì)象和HttpServletResponse 對(duì)象，作為參數(shù)調(diào)用JspServlet 的 doGet 或 doPost 方法
10)Context 把執(zhí)行完了之后的 HttpServletResponse 對(duì)象返回給 Host
11)Host 把 HttpServletResponse 對(duì)象返回給 Engine
12)Engine 把 HttpServletResponse 對(duì)象返回給Connector
13)Connector 把 HttpServletResponse 對(duì)象返回給客戶browser
14.Tomcat 工作模式？
Tomcat 是一個(gè) JSP/Servlet 容器。其作為 Servlet 容器，有三種工作模式：獨(dú)立的 Servlet 容器、進(jìn)程內(nèi)的 Servlet 容器和進(jìn)程外的 Servlet 容器。
進(jìn)入 Tomcat 的請(qǐng)求可以根據(jù) Tomcat 的工作模式分為如下兩類：
Tomcat 作為應(yīng)用程序服務(wù)器：請(qǐng)求來自于前端的 web 服務(wù)器，這可能是Apache, IIS, Nginx 等；
Tomcat 作為獨(dú)立服務(wù)器：請(qǐng)求來自于 web 瀏覽器；
