Web 技術(shù)成為當(dāng)今主流的互聯(lián)網(wǎng) Web 應(yīng)用技術(shù)之一，而 Servlet 是 Java Web 技術(shù)的核心基礎(chǔ)。因而掌握 Servlet 的工作原理是成為一名合格的 Java Web 技術(shù)開發(fā)人員的基本要求。本文將帶你認(rèn)識(shí) Java Web 技術(shù)是如何基于 Servlet 工作，你將知道：以 Tomcat 為例了解 Servlet 容器是如何工作的？一個(gè) Web 工程在 Servlet 容器中是如何啟動(dòng)的？ Servlet 容器如何解析你在 web.xml 中定義的 Servlet ？用戶的請(qǐng)求是如何被分配給指定的 Servlet 的？ Servlet 容器如何管理 Servlet 生命周期？你還將了解到最新的 Servlet 的 API 的類層次結(jié)構(gòu)，以及 Servlet 中一些難點(diǎn)問題的分析。

48?評(píng)論：

許 令波, Java 工程師, 淘寶網(wǎng)

2011 年 2 月 24 日

• 內(nèi)容

從 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)品，目前它的種類很多，但是它們都有自己的市場(chǎng)定位，很難說誰優(yōu)誰劣，各有特點(diǎn)。例如現(xiàn)在比較流行的 Jetty，在定制化和移動(dòng)領(lǐng)域有不錯(cuò)的發(fā)展，我們這里還是以大家最為熟悉 Tomcat 為例來介紹 Servlet 容器如何管理 Servlet。Tomcat 本身也很復(fù)雜，我們只從 Servlet 與 Servlet 容器的接口部分開始介紹，關(guān)于 Tomcat 的詳細(xì)介紹可以參考我的另外一篇文章《 Tomcat 系統(tǒng)架構(gòu)與模式設(shè)計(jì)分析》。

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

圖 1 . Tomcat 容器模型

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

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

<Context path="/projectOne " docBase="D:\projects\projectOne" reloadable="true" />

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

Servlet 容器的啟動(dòng)過程

Tomcat7 也開始支持嵌入式功能，增加了一個(gè)啟動(dòng)類 org.apache.catalina.startup.Tomcat。創(chuàng)建一個(gè)實(shí)例對(duì)象并調(diào)用 start 方法就可以很容易啟動(dòng) Tomcat，我們還可以通過這個(gè)對(duì)象來增加和修改 Tomcat 的配置參數(shù)，如可以動(dòng)態(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("<h1>Hello World!</h1>") > 0);

清單 1 的代碼是創(chuàng)建一個(gè) Tomcat 實(shí)例并新增一個(gè) Web 應(yīng)用，然后啟動(dò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)用對(duì)應(yīng)一個(gè) Context 容器，也就是 Servlet 運(yùn)行時(shí)的 Servlet 容器，添加一個(gè) Web 應(yīng)用時(shí)將會(huì)創(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è)類將會(huì)負(fù)責(zé)整個(gè) Web 應(yīng)用配置的解析工作，后面將會(huì)詳細(xì)介紹。最后將這個(gè) Context 容器加到父容器 Host 中。

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

圖 2. Tomcat 主要類的啟動(dòng)時(shí)序圖（查看大圖）

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

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

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

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

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

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

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

設(shè)置 Context 的 DocBase

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

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

創(chuàng)建 ClassLoader 對(duì)象

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

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

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

接下去將會(huì)將 WebXml 對(duì)象中的屬性設(shè)置到 Context 容器中，這里包括創(chuàng)建 Servlet 對(duì)象、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()); Map<String,String> params = servlet.getParameterMap(); for (Entry<String, String> entry : params.entrySet()) { wrapper.addInitParameter(entry.getKey(), entry.getValue()); } wrapper.setRunAs(servlet.getRunAs()); Set<SecurityRoleRef> 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 對(duì)象。這里 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)用對(duì)應(yīng)一個(gè) Context 容器，容器的配置屬性由應(yīng)用的 web.xml 指定，這樣我們就能理解 web.xml 到底起到什么作用了。

回頁(yè)首

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

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

創(chuàng)建 Servlet 對(duì)象

如果 Servlet 的 load-on-startup 配置項(xiàng)大于 0，那么在 Context 容器啟動(dòng)的時(shí)候就會(huì)被實(shí)例化，前面提到在解析配置文件時(shí)會(huì)讀取默認(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 啟動(dòng)時(shí)這兩個(gè) Servlet 就會(huì)被啟動(dòng)。

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

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

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

初始化 Servlet

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

如果該 Servlet 關(guān)聯(lián)的是一個(gè) jsp 文件，那么前面初始化的就是 JspServlet，接下去會(huì)模擬一次簡(jiǎn)單請(qǐng)求，請(qǐng)求調(diào)用這個(gè) jsp 文件，以便編譯這個(gè) jsp 文件為 class，并初始化這個(gè) class。

這樣 Servlet 對(duì)象就初始化完成了，事實(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é)。

圖 4. 初始化 Servlet 的時(shí)序圖（查看大圖）

回頁(yè)首

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 主動(dòng)關(guān)聯(lián)的是三個(gè)類，分別是 ServletConfig、ServletRequest 和 ServletResponse。這三個(gè)類都是通過容器傳遞給 Servlet 的，其中 ServletConfig 是在 Servlet 初始化時(shí)就傳給 Servlet 了，而后兩個(gè)是在請(qǐng)求達(dá)到時(shí)調(diào)用 Servlet 時(shí)傳遞過來的。我們很清楚 ServletRequest 和 ServletResponse 在 Servlet 運(yùn)行的意義，但是 ServletConfig 和 ServletContext 對(duì) Servlet 有何價(jià)值？仔細(xì)查看 ServletConfig 接口中聲明的方法發(fā)現(xiàn)，這些方法都是為了獲取這個(gè) Servlet 的一些配置屬性，而這些配置屬性可能在 Servlet 運(yùn)行時(shí)被用到。而 ServletContext 又是干什么的呢？ Servlet 的運(yùn)行模式是一個(gè)典型的“握手型的交互式”運(yùn)行模式。所謂“握手型的交互式”就是兩個(gè)模塊為了交換數(shù)據(jù)通常都會(huì)準(zhǔn)備一個(gè)交易場(chǎng)景，這個(gè)場(chǎng)景一直跟隨個(gè)這個(gè)交易過程直到這個(gè)交易完成為止。這個(gè)交易場(chǎng)景的初始化是根據(jù)這次交易對(duì)象指定的參數(shù)來定制的，這些指定參數(shù)通常就會(huì)是一個(gè)配置類。所以對(duì)號(hào)入座，交易場(chǎng)景就由 ServletContext 來描述，而定制的參數(shù)集合就由 ServletConfig 來描述。而 ServletRequest 和 ServletResponse 就是要交互的具體對(duì)象了，它們通常都是作為運(yùn)輸工具來傳遞交互結(jié)果。

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

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

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

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

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

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

Servlet 中定義的兩個(gè) ServletRequest 和 ServletResponse 它們實(shí)際的對(duì)象又是什么呢？，我們?cè)趧?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 一接受到請(qǐng)求首先將會(huì)創(chuàng)建 org.apache.coyote.Request 和 org.apache.coyote.Response，這兩個(gè)類是 Tomcat 內(nèi)部使用的描述一次請(qǐng)求和相應(yīng)的信息類它們是一個(gè)輕量級(jí)的類，它們作用就是在服務(wù)器接收到請(qǐng)求后，經(jīng)過簡(jiǎn)單解析將這個(gè)請(qǐng)求快速的分配給后續(xù)線程去處理，所以它們的對(duì)象很小，很容易被 JVM 回收。接下去當(dāng)交給一個(gè)用戶線程去處理這個(gè)請(qǐng)求時(shí)又創(chuàng)建 org.apache.catalina.connector. Request 和 org.apache.catalina.connector. Response 對(duì)象。這兩個(gè)對(duì)象一直穿越整個(gè) Servlet 容器直到要傳給 Servlet，傳給 Servlet 的是 Request 和 Response 的門面類 RequestFacade 和 RequestFacade，這里使用門面模式與前面一樣都是基于同樣的目的——封裝容器中的數(shù)據(jù)。一次請(qǐng)求對(duì)應(yīng)的 Request 和 Response 的類轉(zhuǎn)化如下圖所示：

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

回頁(yè)首

Servlet 如何工作

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

當(dāng)用戶從瀏覽器向服務(wù)器發(fā)起一個(gè)請(qǐng)求，通常會(huì)包含如下信息：http://hostname: port /contextpath/servletpath，hostname 和 port 是用來與服務(wù)器建立 TCP 連接，而后面的 URL 才是用來選擇服務(wù)器中那個(gè)子容器服務(wù)用戶的請(qǐng)求。那服務(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 將會(huì)根據(jù)這次請(qǐng)求的 hostnane 和 contextpath 將 host 和 context 容器設(shè)置到 Request 的 mappingData 屬性中。所以當(dāng) Request 進(jìn)入 Container 容器之前，它要訪問那個(gè)子容器這時(shí)就已經(jīng)確定了。

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

可能你有疑問，mapper 中怎么會(huì)有容器的完整關(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 都將會(huì)被通知，相應(yīng)的保存容器關(guān)系的 MapperListener 的 mapper 屬性也會(huì)修改。for 循環(huán)中就是將 host 及下面的子容器注冊(cè)到 mapper 中。

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

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

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

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

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

回頁(yè)首

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í)際對(duì)象是 StandardWrapperFacade，到底能獲得哪些容器信息可以看看這類提供了哪些接口。還有一部分?jǐn)?shù)據(jù)是由 ServletRequest 類提供，它的實(shí)際對(duì)象是 RequestFacade，從提供的方法中發(fā)現(xiàn)主要是描述這次請(qǐng)求的 HTTP 協(xié)議的信息。所以要掌握 Servlet 的工作方式必須要很清楚 HTTP 協(xié)議，如果你還不清楚趕緊去找一些參考資料。關(guān)于這一塊還有一個(gè)讓很多人迷惑的 Session 與 Cookie。

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

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

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

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

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

第一種情況下，當(dāng)瀏覽器不支持 Cookie 功能時(shí)，瀏覽器會(huì)將用戶的 SessionCookieName 重寫到用戶請(qǐng)求的 URL 參數(shù)中，它的傳遞格式如 /path/Servlet;name=value;name2=value2? Name3=value3，其中“Servlet；”后面的 K-V 對(duì)就是要傳遞的 Path Parameters，服務(wù)器會(huì)從這個(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 中。

請(qǐng)注意如果客戶端也支持 Cookie 的話，Tomcat 仍然會(huì)解析 Cookie 中的 Session ID，并會(huì)覆蓋 URL 中的 Session ID。

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

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

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

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

圖 12.Session 工作的時(shí)序圖（查看大圖）

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

回頁(yè)首

Servlet 中的 Listener

整個(gè) Tomcat 服務(wù)器中 Listener 使用的非常廣泛，它是基于觀察者模式設(shè)計(jì)的，Listener 的設(shè)計(jì)對(duì)開發(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 中的 <listener> 標(biāo)簽中。當(dāng)然也可以在應(yīng)用程序中動(dòng)態(tài)添加 Listener，需要注意的是 ServletContextListener 在容器啟動(dòng)之后就不能再添加新的，因?yàn)樗O(jiān)聽的事件已經(jīng)不會(huì)再出現(xiàn)。掌握這些 Listener 的使用，能夠讓我們的程序設(shè)計(jì)的更加靈活。

回頁(yè)首

總結(jié)

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

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

轉(zhuǎn)載于:https://www.cnblogs.com/daishuguang/p/3916560.html

總結(jié)

以上是生活随笔為你收集整理的【Java】Servlet 工作原理解析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。