在學(xué)習(xí)Servlet是找到一篇不錯(cuò)的文章,轉(zhuǎn)載一下。學(xué)習(xí)心得,Servlet其實(shí)只是個(gè)接口,相當(dāng)于是定義了一個(gè)標(biāo)準(zhǔn),Servlet程序運(yùn)行依賴于容器,使用Servlet的目的是讓容器幫你去干一些底層的事情,比如監(jiān)聽請求,讀取數(shù)據(jù),甚至關(guān)閉連接等等,這也是使用中間件的原因分蓖。下面為原文,作者為許令波昔穴。

從 Servlet 容器說起

要介紹 Servlet 必須要先把 Servlet 容器說清楚脯爪，Servlet 與 Servlet 容器的關(guān)系有點(diǎn)像槍和子彈的關(guān)系蓄诽，槍是為子彈而生，而子彈又讓槍有了殺傷力盆佣。雖然它們是彼此依存的往堡，但是又相互獨(dú)立發(fā)展，這一切都是為了適應(yīng)工業(yè)化生產(chǎn)的結(jié)果共耍。從技術(shù)角度來說是為了解耦虑灰，通過標(biāo)準(zhǔn)化接口來相互協(xié)作。既然接口是連接 Servlet 與 Servlet 容器的關(guān)鍵痹兜，那我們就從它們的接口說起穆咐。

前面說了 Servlet 容器作為一個(gè)獨(dú)立發(fā)展的標(biāo)準(zhǔn)化產(chǎn)品，目前它的種類很多字旭，但是它們都有自己的市場定位对湃，很難說誰優(yōu)誰劣，各有特點(diǎn)遗淳。例如現(xiàn)在比較流行的 Jetty拍柒，在定制化和移動領(lǐng)域有不錯(cuò)的發(fā)展，我們這里還是以大家最為熟悉 Tomcat 為例來介紹 Servlet 容器如何管理 Servlet屈暗。Tomcat 本身也很復(fù)雜拆讯，我們只從 Servlet 與 Servlet 容器的接口部分開始介紹，關(guān)于 Tomcat 的詳細(xì)介紹可以參考我的另外一篇文章《 Tomcat 系統(tǒng)架構(gòu)與模式設(shè)計(jì)分析》养叛。

Tomcat 的容器等級中种呐，Context 容器是直接管理 Servlet 在容器中的包裝類 Wrapper，所以 Context 容器如何運(yùn)行將直接影響 Servlet 的工作方式弃甥。

從上圖可以看出 Tomcat 的容器分為四個(gè)等級爽室，真正管理 Servlet 的容器是 Context 容器，一個(gè) Context 對應(yīng)一個(gè) Web 工程潘飘，在 Tomcat 的配置文件中可以很容易發(fā)現(xiàn)這一點(diǎn)肮之，如下：

清單 1 Context 配置參數(shù)

下面詳細(xì)介紹一下 Tomcat 解析 Context 容器的過程，包括如何構(gòu)建 Servlet 的過程卜录。

Servlet 容器的啟動過程

Tomcat7 也開始支持嵌入式功能戈擒，增加了一個(gè)啟動類 org.apache.catalina.startup.Tomcat。創(chuàng)建一個(gè)實(shí)例對象并調(diào)用 start 方法就可以很容易啟動 Tomcat艰毒，我們還可以通過這個(gè)對象來增加和修改 Tomcat 的配置參數(shù)筐高，如可以動態(tài)增加 Context、Servlet 等丑瞧。下面我們就利用這個(gè) Tomcat 類來管理新增的一個(gè) Context 容器柑土，我們就選擇 Tomcat7 自帶的 examples Web 工程，并看看它是如何加到這個(gè) Context 容器中的绊汹。

清單 2 . 給 Tomcat 增加一個(gè) Web 工程

Tomcat tomcat = getTomcatInstance();

File appDir = new File(getBuildDirectory(), "webapps/examples");

tomcat.addWebapp(null, "/examples", appDir.getAbsolutePath());

tomcat.start();

ByteChunk res = getUrl("http://localhost:" + getPort() +

? ? ? ? ? ? ? "/examples/servlets/servlet/HelloWorldExample");

assertTrue(res.toString().indexOf("

Hello World!

") > 0);

清單 1 的代碼是創(chuàng)建一個(gè) Tomcat 實(shí)例并新增一個(gè) Web 應(yīng)用稽屏，然后啟動 Tomcat 并調(diào)用其中的一個(gè) HelloWorldExample Servlet，看有沒有正確返回預(yù)期的數(shù)據(jù)西乖。

Tomcat 的 addWebapp 方法的代碼如下：

清單 3 .Tomcat.addWebapp

public Context addWebapp(Host host, String url, String path) {

? ? ? silence(url);

? ? ? Context ctx = new StandardContext();

? ? ? ctx.setPath( url );

? ? ? ctx.setDocBase(path);

? ? ? if (defaultRealm == null) {

? ? ? ? ? initSimpleAuth();

? ? ? }

? ? ? ctx.setRealm(defaultRealm);

? ? ? ctx.addLifecycleListener(new DefaultWebXmlListener());

? ? ? ContextConfig ctxCfg = new ContextConfig();

? ? ? ctx.addLifecycleListener(ctxCfg);

? ? ? ctxCfg.setDefaultWebXml("org/apache/catalin/startup/NO_DEFAULT_XML");

? ? ? if (host == null) {

? ? ? ? ? getHost().addChild(ctx);

? ? ? } else {

? ? ? ? ? host.addChild(ctx);

? ? ? }

? ? ? return ctx;

}

前面已經(jīng)介紹了一個(gè) Web 應(yīng)用對應(yīng)一個(gè) Context 容器狐榔，也就是 Servlet 運(yùn)行時(shí)的 Servlet 容器坛增，添加一個(gè) Web 應(yīng)用時(shí)將會創(chuàng)建一個(gè) StandardContext 容器，并且給這個(gè) Context 容器設(shè)置必要的參數(shù)薄腻，url 和 path 分別代表這個(gè)應(yīng)用在 Tomcat 中的訪問路徑和這個(gè)應(yīng)用實(shí)際的物理路徑收捣，這個(gè)兩個(gè)參數(shù)與清單 1 中的兩個(gè)參數(shù)是一致的。其中最重要的一個(gè)配置是 ContextConfig庵楷，這個(gè)類將會負(fù)責(zé)整個(gè) Web 應(yīng)用配置的解析工作罢艾，后面將會詳細(xì)介紹。最后將這個(gè) Context 容器加到父容器 Host 中尽纽。

接下去將會調(diào)用 Tomcat 的 start 方法啟動 Tomcat咐蚯，如果你清楚 Tomcat 的系統(tǒng)架構(gòu)，你會容易理解 Tomcat 的啟動邏輯蜓斧，Tomcat 的啟動邏輯是基于觀察者模式設(shè)計(jì)的仓蛆，所有的容器都會繼承 Lifecycle 接口，它管理者容器的整個(gè)生命周期挎春，所有容器的的修改和狀態(tài)的改變都會由它去通知已經(jīng)注冊的觀察者（Listener）看疙，關(guān)于這個(gè)設(shè)計(jì)模式可以參考《 Tomcat 的系統(tǒng)架構(gòu)與設(shè)計(jì)模式，第二部分：設(shè)計(jì)模式》直奋。Tomcat 啟動的時(shí)序圖可以用圖 2 表示能庆。

圖 2. Tomcat 主要類的啟動時(shí)序圖

上圖描述了 Tomcat 啟動過程中，主要類之間的時(shí)序關(guān)系脚线，下面我們將會重點(diǎn)關(guān)注添加 examples 應(yīng)用所對應(yīng)的 StandardContext 容器的啟動過程搁胆。

當(dāng) Context 容器初始化狀態(tài)設(shè)為 init 時(shí)，添加在 Contex 容器的 Listener 將會被調(diào)用邮绿。ContextConfig 繼承了 LifecycleListener 接口渠旁，它是在調(diào)用清單 3 時(shí)被加入到 StandardContext 容器中。ContextConfig 類會負(fù)責(zé)整個(gè) Web 應(yīng)用的配置文件的解析工作船逮。

ContextConfig 的 init 方法將會主要完成以下工作：

創(chuàng)建用于解析 xml 配置文件的 contextDigester 對象

讀取默認(rèn) context.xml 配置文件顾腊，如果存在解析它

讀取默認(rèn) Host 配置文件，如果存在解析它

讀取默認(rèn) Context 自身的配置文件挖胃，如果存在解析它

設(shè)置 Context 的 DocBase

ContextConfig 的 init 方法完成后杂靶，Context 容器的會執(zhí)行 startInternal 方法，這個(gè)方法啟動邏輯比較復(fù)雜酱鸭，主要包括如下幾個(gè)部分：

創(chuàng)建讀取資源文件的對象

創(chuàng)建 ClassLoader 對象

設(shè)置應(yīng)用的工作目錄

啟動相關(guān)的輔助類如：logger吗垮、realm、resources 等

修改啟動狀態(tài)凹髓，通知感興趣的觀察者（Web 應(yīng)用的配置）

子容器的初始化

獲取 ServletContext 并設(shè)置必要的參數(shù)

初始化“l(fā)oad on startup”的 Servlet

Web 應(yīng)用的初始化工作

Web 應(yīng)用的初始化工作是在 ContextConfig 的 configureStart 方法中實(shí)現(xiàn)的烁登，應(yīng)用的初始化主要是要解析 web.xml 文件，這個(gè)文件描述了一個(gè) Web 應(yīng)用的關(guān)鍵信息蔚舀，也是一個(gè) Web 應(yīng)用的入口饵沧。

Tomcat 首先會找 globalWebXml 這個(gè)文件的搜索路徑是在 engine 的工作目錄下尋找以下兩個(gè)文件中的任一個(gè) org/apache/catalin/startup/NO_DEFAULT_XML 或 conf/web.xml蚀之。接著會找 hostWebXml 這個(gè)文件可能會在 System.getProperty("catalina.base")/conf/${EngineName}/${HostName}/web.xml.default，接著尋找應(yīng)用的配置文件 examples/WEB-INF/web.xml捷泞。web.xml 文件中的各個(gè)配置項(xiàng)將會被解析成相應(yīng)的屬性保存在 WebXml 對象中。如果當(dāng)前應(yīng)用支持 Servlet3.0寿谴，解析還將完成額外 9 項(xiàng)工作锁右，這個(gè)額外的 9 項(xiàng)工作主要是為 Servlet3.0 新增的特性，包括 jar 包中的 META-INF/web-fragment.xml 的解析以及對 annotations 的支持讶泰。

接下去將會將 WebXml 對象中的屬性設(shè)置到 Context 容器中咏瑟，這里包括創(chuàng)建 Servlet 對象、filter痪署、listener 等等码泞。這段代碼在 WebXml 的 configureContext 方法中。下面是解析 Servlet 的代碼片段：

清單 4. 創(chuàng)建 Wrapper 實(shí)例

for (ServletDef servlet : servlets.values()) { Wrapper wrapper = context.createWrapper(); String jspFile = servlet.getJspFile(); if (jspFile != null) { wrapper.setJspFile(jspFile); } if (servlet.getLoadOnStartup() != null) { wrapper.setLoadOnStartup(servlet.getLoadOnStartup().intValue()); } if (servlet.getEnabled() != null) { wrapper.setEnabled(servlet.getEnabled().booleanValue()); } wrapper.setName(servlet.getServletName()); Mapparams = servlet.getParameterMap(); for (Entryentry : params.entrySet()) { wrapper.addInitParameter(entry.getKey(), entry.getValue()); } wrapper.setRunAs(servlet.getRunAs()); Set roleRefs = servlet.getSecurityRoleRefs();

? ? ? ? ? for (SecurityRoleRef roleRef : roleRefs) {

? ? ? ? ? ? ? wrapper.addSecurityReference(

? ? ? ? ? ? ? ? ? ? ? roleRef.getName(), roleRef.getLink());

? ? ? ? ? }

? ? ? ? ? wrapper.setServletClass(servlet.getServletClass());

? ? ? ? ? MultipartDef multipartdef = servlet.getMultipartDef();

? ? ? ? ? if (multipartdef != null) {

? ? ? ? ? ? ? if (multipartdef.getMaxFileSize() != null &&

? ? ? ? ? ? ? ? ? ? ? multipartdef.getMaxRequestSize()!= null &&

? ? ? ? ? ? ? ? ? ? ? multipartdef.getFileSizeThreshold() != null) {

? ? ? ? ? ? ? ? ? wrapper.setMultipartConfigElement(new

MultipartConfigElement(

? ? ? ? ? ? ? ? ? ? ? ? ? multipartdef.getLocation(),

? ? ? ? ? ? ? ? ? ? ? ? ? Long.parseLong(multipartdef.getMaxFileSize()),

? ? ? ? ? ? ? ? ? ? ? ? ? Long.parseLong(multipartdef.getMaxRequestSize()),

? ? ? ? ? ? ? ? ? ? ? ? ? Integer.parseInt(

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? multipartdef.getFileSizeThreshold())));

? ? ? ? ? ? ? } else {

? ? ? ? ? ? ? ? ? wrapper.setMultipartConfigElement(new

MultipartConfigElement(

? ? ? ? ? ? ? ? ? ? ? ? ? multipartdef.getLocation()));

? ? ? ? ? ? ? }

? ? ? ? ? }

? ? ? ? ? if (servlet.getAsyncSupported() != null) {

? ? ? ? ? ? ? wrapper.setAsyncSupported(

? ? ? ? ? ? ? ? ? ? ? servlet.getAsyncSupported().booleanValue());

? ? ? ? ? }

? ? ? ? ? context.addChild(wrapper);

}

這段代碼清楚的描述了如何將 Servlet 包裝成 Context 容器中的 StandardWrapper狼犯，這里有個(gè)疑問余寥，為什么要將 Servlet 包裝成 StandardWrapper 而不直接是 Servlet 對象。這里 StandardWrapper 是 Tomcat 容器中的一部分悯森，它具有容器的特征宋舷，而 Servlet 為了一個(gè)獨(dú)立的 web 開發(fā)標(biāo)準(zhǔn)，不應(yīng)該強(qiáng)耦合在 Tomcat 中瓢姻。

除了將 Servlet 包裝成 StandardWrapper 并作為子容器添加到 Context 中祝蝠，其它的所有 web.xml 屬性都被解析到 Context 中，所以說 Context 容器才是真正運(yùn)行 Servlet 的 Servlet 容器幻碱。一個(gè) Web 應(yīng)用對應(yīng)一個(gè) Context 容器绎狭，容器的配置屬性由應(yīng)用的 web.xml 指定，這樣我們就能理解 web.xml 到底起到什么作用了褥傍。

創(chuàng)建 Servlet 實(shí)例

前面已經(jīng)完成了 Servlet 的解析工作儡嘶，并且被包裝成 StandardWrapper 添加在 Context 容器中，但是它仍然不能為我們工作摔桦，它還沒有被實(shí)例化社付。下面我們將介紹 Servlet 對象是如何創(chuàng)建的，以及如何被初始化的邻耕。

創(chuàng)建 Servlet 對象

如果 Servlet 的 load-on-startup 配置項(xiàng)大于 0鸥咖，那么在 Context 容器啟動的時(shí)候就會被實(shí)例化，前面提到在解析配置文件時(shí)會讀取默認(rèn)的 globalWebXml兄世，在 conf 下的 web.xml 文件中定義了一些默認(rèn)的配置項(xiàng)啼辣，其定義了兩個(gè) Servlet，分別是：org.apache.catalina.servlets.DefaultServlet 和 org.apache.jasper.servlet.JspServlet 它們的 load-on-startup 分別是 1 和 3御滩，也就是當(dāng) Tomcat 啟動時(shí)這兩個(gè) Servlet 就會被啟動鸥拧。

創(chuàng)建 Servlet 實(shí)例的方法是從 Wrapper. loadServlet 開始的党远。loadServlet 方法要完成的就是獲取 servletClass 然后把它交給 InstanceManager 去創(chuàng)建一個(gè)基于 servletClass.class 的對象。如果這個(gè) Servlet 配置了 jsp-file富弦，那么這個(gè) servletClass 就是 conf/web.xml 中定義的 org.apache.jasper.servlet.JspServlet 了沟娱。

創(chuàng)建 Servlet 對象的相關(guān)類結(jié)構(gòu)圖如下：

圖 3. 創(chuàng)建 Servlet 對象的相關(guān)類結(jié)構(gòu)

初始化 Servlet

初始化 Servlet 在 StandardWrapper 的 initServlet 方法中，這個(gè)方法很簡單就是調(diào)用 Servlet 的 init 的方法腕柜，同時(shí)把包裝了 StandardWrapper 對象的 StandardWrapperFacade 作為 ServletConfig 傳給 Servlet济似。Tomcat 容器為何要傳 StandardWrapperFacade 給 Servlet 對象將在后面做詳細(xì)解析。

如果該 Servlet 關(guān)聯(lián)的是一個(gè) jsp 文件盏缤，那么前面初始化的就是 JspServlet砰蠢，接下去會模擬一次簡單請求，請求調(diào)用這個(gè) jsp 文件唉铜，以便編譯這個(gè) jsp 文件為 class台舱，并初始化這個(gè) class。

這樣 Servlet 對象就初始化完成了潭流，事實(shí)上 Servlet 從被 web.xml 中解析到完成初始化竞惋，這個(gè)過程非常復(fù)雜，中間有很多過程幻枉，包括各種容器狀態(tài)的轉(zhuǎn)化引起的監(jiān)聽事件的觸發(fā)碰声、各種訪問權(quán)限的控制和一些不可預(yù)料的錯(cuò)誤發(fā)生的判斷行為等等。我們這里只抓了一些關(guān)鍵環(huán)節(jié)進(jìn)行闡述熬甫，試圖讓大家有個(gè)總體脈絡(luò)胰挑。

下面是這個(gè)過程的一個(gè)完整的時(shí)序圖，其中也省略了一些細(xì)節(jié)椿肩。

Servlet 體系結(jié)構(gòu)

我們知道 Java Web 應(yīng)用是基于 Servlet 規(guī)范運(yùn)轉(zhuǎn)的瞻颂，那么 Servlet 本身又是如何運(yùn)轉(zhuǎn)的呢？為何要設(shè)計(jì)這樣的體系結(jié)構(gòu)郑象。

圖 5.Servlet 頂層類關(guān)聯(lián)圖

從上圖可以看出 Servlet 規(guī)范就是基于這幾個(gè)類運(yùn)轉(zhuǎn)的贡这，與 Servlet 主動關(guān)聯(lián)的是三個(gè)類，分別是 ServletConfig厂榛、ServletRequest 和 ServletResponse盖矫。這三個(gè)類都是通過容器傳遞給 Servlet 的，其中 ServletConfig 是在 Servlet 初始化時(shí)就傳給 Servlet 了击奶，而后兩個(gè)是在請求達(dá)到時(shí)調(diào)用 Servlet 時(shí)傳遞過來的辈双。我們很清楚 ServletRequest 和 ServletResponse 在 Servlet 運(yùn)行的意義，但是 ServletConfig 和 ServletContext 對 Servlet 有何價(jià)值柜砾？仔細(xì)查看 ServletConfig 接口中聲明的方法發(fā)現(xiàn)湃望，這些方法都是為了獲取這個(gè) Servlet 的一些配置屬性，而這些配置屬性可能在 Servlet 運(yùn)行時(shí)被用到。而 ServletContext 又是干什么的呢证芭？ Servlet 的運(yùn)行模式是一個(gè)典型的“握手型的交互式”運(yùn)行模式瞳浦。所謂“握手型的交互式”就是兩個(gè)模塊為了交換數(shù)據(jù)通常都會準(zhǔn)備一個(gè)交易場景，這個(gè)場景一直跟隨個(gè)這個(gè)交易過程直到這個(gè)交易完成為止废士。這個(gè)交易場景的初始化是根據(jù)這次交易對象指定的參數(shù)來定制的叫潦，這些指定參數(shù)通常就會是一個(gè)配置類。所以對號入座官硝，交易場景就由 ServletContext 來描述诅挑，而定制的參數(shù)集合就由 ServletConfig 來描述。而 ServletRequest 和 ServletResponse 就是要交互的具體對象了泛源，它們通常都是作為運(yùn)輸工具來傳遞交互結(jié)果。

ServletConfig 是在 Servlet init 時(shí)由容器傳過來的忿危，那么 ServletConfig 到底是個(gè)什么對象呢达箍？

下圖是 ServletConfig 和 ServletContext 在 Tomcat 容器中的類關(guān)系圖。

圖 6. ServletConfig 在容器中的類關(guān)聯(lián)圖

上圖可以看出 StandardWrapper 和 StandardWrapperFacade 都實(shí)現(xiàn)了 ServletConfig 接口铺厨，而 StandardWrapperFacade 是 StandardWrapper 門面類缎玫。所以傳給 Servlet 的是 StandardWrapperFacade 對象，這個(gè)類能夠保證從 StandardWrapper 中拿到 ServletConfig 所規(guī)定的數(shù)據(jù)解滓，而又不把 ServletConfig 不關(guān)心的數(shù)據(jù)暴露給 Servlet赃磨。

同樣 ServletContext 也與 ServletConfig 有類似的結(jié)構(gòu)，Servlet 中能拿到的 ServletContext 的實(shí)際對象也是 ApplicationContextFacade 對象洼裤。ApplicationContextFacade 同樣保證 ServletContex 只能從容器中拿到它該拿的數(shù)據(jù)邻辉，它們都起到對數(shù)據(jù)的封裝作用，它們使用的都是門面設(shè)計(jì)模式腮鞍。

通過 ServletContext 可以拿到 Context 容器中一些必要信息值骇，比如應(yīng)用的工作路徑，容器支持的 Servlet 最小版本等移国。

Servlet 中定義的兩個(gè) ServletRequest 和 ServletResponse 它們實(shí)際的對象又是什么呢吱瘩？，我們在創(chuàng)建自己的 Servlet 類時(shí)通常使用的都是 HttpServletRequest 和 HttpServletResponse迹缀，它們繼承了 ServletRequest 和 ServletResponse使碾。為何 Context 容器傳過來的 ServletRequest票摇、ServletResponse 可以被轉(zhuǎn)化為 HttpServletRequest 和 HttpServletResponse 呢颅和？

圖 7.Request 相關(guān)類結(jié)構(gòu)圖

上圖是 Tomcat 創(chuàng)建的 Request 和 Response 的類結(jié)構(gòu)圖教届。Tomcat 一接受到請求首先將會創(chuàng)建 org.apache.coyote.Request 和 org.apache.coyote.Response买置，這兩個(gè)類是 Tomcat 內(nèi)部使用的描述一次請求和相應(yīng)的信息類它們是一個(gè)輕量級的類轩触，它們作用就是在服務(wù)器接收到請求后拉馋，經(jīng)過簡單解析將這個(gè)請求快速的分配給后續(xù)線程去處理景馁，所以它們的對象很小，很容易被 JVM 回收僚害。接下去當(dāng)交給一個(gè)用戶線程去處理這個(gè)請求時(shí)又創(chuàng)建 org.apache.catalina.connector. Request 和 org.apache.catalina.connector. Response 對象。這兩個(gè)對象一直穿越整個(gè) Servlet 容器直到要傳給 Servlet，傳給 Servlet 的是 Request 和 Response 的門面類 RequestFacade 和 RequestFacade宾濒，這里使用門面模式與前面一樣都是基于同樣的目的——封裝容器中的數(shù)據(jù)。一次請求對應(yīng)的 Request 和 Response 的類轉(zhuǎn)化如下圖所示：

圖 8.Request 和 Response 的轉(zhuǎn)變過程

Servlet 如何工作

我們已經(jīng)清楚了 Servlet 是如何被加載的、Servlet 是如何被初始化的，以及 Servlet 的體系結(jié)構(gòu)，現(xiàn)在的問題就是它是如何被調(diào)用的析校。

當(dāng)用戶從瀏覽器向服務(wù)器發(fā)起一個(gè)請求吊奢，通常會包含如下信息：http://hostname: port /contextpath/servletpath陪蜻，hostname 和 port 是用來與服務(wù)器建立 TCP 連接，而后面的 URL 才是用來選擇服務(wù)器中那個(gè)子容器服務(wù)用戶的請求贱鼻。那服務(wù)器是如何根據(jù)這個(gè) URL 來達(dá)到正確的 Servlet 容器中的呢宴卖？

Tomcat7.0 中這件事很容易解決，因?yàn)檫@種映射工作有專門一個(gè)類來完成的邻悬，這個(gè)就是 org.apache.tomcat.util.http.mapper症昏，這個(gè)類保存了 Tomcat 的 Container 容器中的所有子容器的信息，當(dāng) org.apache.catalina.connector. Request 類在進(jìn)入 Container 容器之前父丰，mapper 將會根據(jù)這次請求的 hostnane 和 contextpath 將 host 和 context 容器設(shè)置到 Request 的 mappingData 屬性中肝谭。所以當(dāng) Request 進(jìn)入 Container 容器之前，它要訪問那個(gè)子容器這時(shí)就已經(jīng)確定了蛾扇。

圖 9.Request 的 Mapper 類關(guān)系圖

可能你有疑問攘烛，mapper 中怎么會有容器的完整關(guān)系，這要回到圖 2 中 19 步 MapperListener 類的初始化過程镀首，下面是 MapperListener 的 init 方法代碼 :

清單 5. MapperListener.init

public void init() {

???????findDefaultHost();

???????Engine engine = (Engine) connector.getService().getContainer();

???????engine.addContainerListener(this);

???????Container[] conHosts = engine.findChildren();

???????for (Container conHost : conHosts) {

???????????Host host = (Host) conHost;

???????????if (!LifecycleState.NEW.equals(host.getState())) {

???????????????host.addLifecycleListener(this);

???????????????registerHost(host);

???????????}

???????}

}

這段代碼的作用就是將 MapperListener 類作為一個(gè)監(jiān)聽者加到整個(gè) Container 容器中的每個(gè)子容器中坟漱，這樣只要任何一個(gè)容器發(fā)生變化，MapperListener 都將會被通知更哄，相應(yīng)的保存容器關(guān)系的 MapperListener 的 mapper 屬性也會修改芋齿。for 循環(huán)中就是將 host 及下面的子容器注冊到 mapper 中。

圖 10.Request 在容器中的路由圖

上圖描述了一次 Request 請求是如何達(dá)到最終的 Wrapper 容器的成翩，我們現(xiàn)正知道了請求是如何達(dá)到正確的 Wrapper 容器觅捆，但是請求到達(dá)最終的 Servlet 還要完成一些步驟，必須要執(zhí)行 Filter 鏈麻敌，以及要通知你在 web.xml 中定義的 listener栅炒。

接下去就要執(zhí)行 Servlet 的 service 方法了，通常情況下术羔，我們自己定義的 servlet 并不是直接去實(shí)現(xiàn) javax.servlet.servlet 接口职辅，而是去繼承更簡單的 HttpServlet 類或者 GenericServlet 類，我們可以有選擇的覆蓋相應(yīng)方法去實(shí)現(xiàn)我們要完成的工作聂示。

Servlet 的確已經(jīng)能夠幫我們完成所有的工作了域携，但是現(xiàn)在的 web 應(yīng)用很少有直接將交互全部頁面都用 servlet 來實(shí)現(xiàn)，而是采用更加高效的 MVC 框架來實(shí)現(xiàn)鱼喉。這些 MVC 框架基本的原理都是將所有的請求都映射到一個(gè) Servlet秀鞭，然后去實(shí)現(xiàn) service 方法趋观，這個(gè)方法也就是 MVC 框架的入口。

當(dāng) Servlet 從 Servlet 容器中移除時(shí)锋边，也就表明該 Servlet 的生命周期結(jié)束了皱坛，這時(shí) Servlet 的 destroy 方法將被調(diào)用，做一些掃尾工作豆巨。

Session 與 Cookie

前面我們已經(jīng)說明了 Servlet 如何被調(diào)用剩辟，我們基于 Servlet 來構(gòu)建應(yīng)用程序，那么我們能從 Servlet 獲得哪些數(shù)據(jù)信息呢往扔？

Servlet 能夠給我們提供兩部分?jǐn)?shù)據(jù)贩猎，一個(gè)是在 Servlet 初始化時(shí)調(diào)用 init 方法時(shí)設(shè)置的 ServletConfig，這個(gè)類基本上含有了 Servlet 本身和 Servlet 所運(yùn)行的 Servlet 容器中的基本信息萍膛。根據(jù)前面的介紹 ServletConfig 的實(shí)際對象是 StandardWrapperFacade吭服，到底能獲得哪些容器信息可以看看這類提供了哪些接口。還有一部分?jǐn)?shù)據(jù)是由 ServletRequest 類提供蝗罗，它的實(shí)際對象是 RequestFacade艇棕，從提供的方法中發(fā)現(xiàn)主要是描述這次請求的 HTTP 協(xié)議的信息。所以要掌握 Servlet 的工作方式必須要很清楚 HTTP 協(xié)議串塑，如果你還不清楚趕緊去找一些參考資料沼琉。關(guān)于這一塊還有一個(gè)讓很多人迷惑的 Session 與 Cookie。

Session 與 Cookie 不管是對 Java Web 的熟練使用者還是初學(xué)者來說都是一個(gè)令人頭疼的東西桩匪。Session 與 Cookie 的作用都是為了保持訪問用戶與后端服務(wù)器的交互狀態(tài)打瘪。它們有各自的優(yōu)點(diǎn)也有各自的缺陷。然而具有諷刺意味的是它們優(yōu)點(diǎn)和它們的使用場景又是矛盾的吸祟，例如使用 Cookie 來傳遞信息時(shí)，隨著 Cookie 個(gè)數(shù)的增多和訪問量的增加桃移，它占用的網(wǎng)絡(luò)帶寬也很大屋匕，試想假如 Cookie 占用 200 個(gè)字節(jié)，如果一天的 PV 有幾億的時(shí)候借杰，它要占用多少帶寬过吻。所以大訪問量的時(shí)候希望用 Session，但是 Session 的致命弱點(diǎn)是不容易在多臺服務(wù)器之間共享蔗衡，所以這也限制了 Session 的使用纤虽。

不管 Session 和 Cookie 有什么不足，我們還是要用它們绞惦。下面詳細(xì)講一下逼纸，Session 如何基于 Cookie 來工作。實(shí)際上有三種方式能可以讓 Session 正常工作：

基于 URL Path Parameter济蝉，默認(rèn)就支持

基于 Cookie杰刽，如果你沒有修改 Context 容器個(gè) cookies 標(biāo)識的話菠发，默認(rèn)也是支持的

基于 SSL，默認(rèn)不支持贺嫂，只有 connector.getAttribute("SSLEnabled") 為 TRUE 時(shí)才支持

第一種情況下滓鸠，當(dāng)瀏覽器不支持 Cookie 功能時(shí)，瀏覽器會將用戶的 SessionCookieName 重寫到用戶請求的 URL 參數(shù)中第喳，它的傳遞格式如 /path/Servlet;name=value;name2=value2? Name3=value3糜俗，其中“Servlet；”后面的 K-V 對就是要傳遞的 Path Parameters曲饱，服務(wù)器會從這個(gè) Path Parameters 中拿到用戶配置的 SessionCookieName悠抹。關(guān)于這個(gè) SessionCookieName，如果你在 web.xml 中配置 session-config 配置項(xiàng)的話渔工，其 cookie-config 下的 name 屬性就是這個(gè) SessionCookieName 值锌钮，如果你沒有配置 session-config 配置項(xiàng)，默認(rèn)的 SessionCookieName 就是大家熟悉的“JSESSIONID”引矩。接著 Request 根據(jù)這個(gè) SessionCookieName 到 Parameters 拿到 Session ID 并設(shè)置到 request.setRequestedSessionId 中梁丘。

請注意如果客戶端也支持 Cookie 的話，Tomcat 仍然會解析 Cookie 中的 Session ID旺韭，并會覆蓋 URL 中的 Session ID氛谜。

如果是第三種情況的話將會根據(jù) javax.servlet.request.ssl_session 屬性值設(shè)置 Session ID。

有了 Session ID 服務(wù)器端就可以創(chuàng)建 HttpSession 對象了区端，第一次觸發(fā)是通過 request. getSession() 方法值漫，如果當(dāng)前的 Session ID 還沒有對應(yīng)的 HttpSession 對象那么就創(chuàng)建一個(gè)新的，并將這個(gè)對象加到 org.apache.catalina. Manager 的 sessions 容器中保存织盼，Manager 類將管理所有 Session 的生命周期杨何，Session 過期將被回收，服務(wù)器關(guān)閉沥邻，Session 將被序列化到磁盤等危虱。只要這個(gè) HttpSession 對象存在，用戶就可以根據(jù) Session ID 來獲取到這個(gè)對象唐全，也就達(dá)到了狀態(tài)的保持埃跷。

圖 11.Session 相關(guān)類圖

上從圖中可以看出從 request.getSession 中獲取的 HttpSession 對象實(shí)際上是 StandardSession 對象的門面對象，這與前面的 Request 和 Servlet 是一樣的原理邮利。下圖是 Session 工作的時(shí)序圖：

圖 12.Session 工作的時(shí)序圖

還有一點(diǎn)與 Session 關(guān)聯(lián)的 Cookie 與其它 Cookie 沒有什么不同弥雹，這個(gè)配置的配置可以通過 web.xml 中的 session-config 配置項(xiàng)來指定。

Servlet 中的 Listener

整個(gè) Tomcat 服務(wù)器中 Listener 使用的非常廣泛延届，它是基于觀察者模式設(shè)計(jì)的剪勿，Listener 的設(shè)計(jì)對開發(fā) Servlet 應(yīng)用程序提供了一種快捷的手段，能夠方便的從另一個(gè)縱向維度控制程序和數(shù)據(jù)方庭。目前 Servlet 中提供了 5 種兩類事件的觀察者接口窗宦，它們分別是：4 個(gè) EventListeners 類型的赦颇，ServletContextAttributeListener、ServletRequestAttributeListener赴涵、ServletRequestListener媒怯、HttpSessionAttributeListener 和 2 個(gè) LifecycleListeners 類型的，ServletContextListener髓窜、HttpSessionListener扇苞。如下圖所示：

圖 13.Servlet 中的 Listener

它們基本上涵蓋了整個(gè) Servlet 生命周期中，你感興趣的每種事件寄纵。這些 Listener 的實(shí)現(xiàn)類可以配置在 web.xml 中的 標(biāo)簽中鳖敷。當(dāng)然也可以在應(yīng)用程序中動態(tài)添加 Listener，需要注意的是 ServletContextListener 在容器啟動之后就不能再添加新的程拭，因?yàn)樗O(jiān)聽的事件已經(jīng)不會再出現(xiàn)定踱。掌握這些 Listener 的使用，能夠讓我們的程序設(shè)計(jì)的更加靈活恃鞋。

總結(jié)

本文涉及到內(nèi)容有點(diǎn)多崖媚，要把每個(gè)細(xì)節(jié)都說清楚，似乎不可能恤浪，本文試著從 Servlet 容器的啟動到 Servlet 的初始化畅哑，以及 Servlet 的體系結(jié)構(gòu)等這些環(huán)節(jié)中找出一些重點(diǎn)來講述，目的是能讀者有一個(gè)總體的完整的結(jié)構(gòu)圖水由，同時(shí)也詳細(xì)分析了其中的一些難點(diǎn)問題荠呐，希望對大家有所幫助。

原文鏈接

https://www.ibm.com/developerworks/cn/java/j-lo-servlet/index.html