本篇我們將來分析一下Tomcat中所涉及到設計模式，本文我們將主要來分析 外觀模式 ， 觀察者模式 ， 責任鏈模式 ， 模板方法模式 , 命令模式 。?

在開始本文之前，筆者先說明一下對于設計模式的一點看法。筆者曾經經常看到網上有人討論設計模式，也偶爾會遇到有人非要嚴格按照GOF設計模式的類圖以及其中的角色去套用別人的設計，只要類圖不一樣，或者角色多了或者少了就會覺得怎么和官方定義的模式不一樣，其實這都是對設計模式的誤解。設計模式其實不僅僅存在軟件行業，各行各業其實都有模式，它是所在行業對一些通用問題解決方案的總結和抽象，是一種對常見問題的抽象的解決方案，不是一種具體的實現，所以我們在討論設計模式的時候，千萬別一個勁的套用GOF設計模式中的類圖以及其中所涉及到的角色，而是要理解設計模式的思維，理解設計模式的使用場景，只有理解了設計模式中所蘊含的思維以及具體的使用場景以后，你才算是真正的掌握了它。ok,小扯了一下淡，接下來我們進入主題吧。

?

外觀模式

定義

外觀模式封裝了子系統的具體實現，提供統一的外觀類給外部系統，這樣當子系統內部實現發生變化的時候，不會影響到外部系統。

外觀模式在Tomcat的應用

在Tomcat中對于Request,Response,StandardSession,ApplicationContext,StandardWrapper都采用了外觀模式，它的類圖如下：

通過上圖，我們可以看到RequestFacade包裝了Request，它們都實現了HttpServletRequest，當傳遞Request對象給應用的時候，其實是返回了RequestFacade對象，而RequestFacade內部可以根據是否自定義了安全管理器來進行相應的操作。

對于Response,StandardSession等處理是類似的，這里就不贅述了。

觀察者模式

定義

觀察者模式是一種非常常用的模式，比如大家熟悉的發布-訂閱模式，客戶端應用中的事件監聽器，以及通知等其實都屬于觀察者模式。觀察者模式主要是在當系統中發生某個狀態變更或者事件的時候，有另外一些組件或者對象對此次變化有興趣，這個時候那些對變化感興趣的對象就可以做為觀察者對象來監聽變化，而被觀察對象要負責發生變化的時候觸發通知操作。

觀察者模式在Tomcat的應用

Tomcat中需要對很多組件進行生命周期管理，為此Tomcat抽象了統一的生命周期管理骨架，通過這個骨架將所有需要進行生命周期管理的類都納入進來管理，而這里的骨架的類圖如下：

通過上圖我們可以看出Tomcat抽象了一個LifecycleSupport的類，而所有需要生命周期管理的組件通過LifecycleSupport類通知對某個生命周期事件感興趣的觀察者，而所有的觀察者都需要實現LifecycleListener。
另外我們需要關注一下EventObject對象，它里面定義了一個事件源對象，所謂事件源就是事件發生的地方，而在Tomcat的設計中，事件源就是實現了LifeCycle接口的各個需要管理生命周期的組件，這里LifecycleSupport和LifeCycleBase之間是雙向的關聯，LifeCycleSupport關聯LifeCycle對象就是為了實現事件源的傳遞，這樣在LifeCycleSupport觸發事件的時候，可以通過事件源構建EventObject.這樣以來LifecycleListener就可以通過事件對象獲取到事件源，從而做一些與事件源相關的操作。

責任鏈模式

定義

通過名稱我們應該就能知道責任鏈模式是解決啥問題的？當我們系統在處理某個請求的時候，請求需要經過很多個節點進行處理，每個節點只關注自己的應該做的工作，做完自己的工作以后，將工作轉給下一個節點進行處理，直到所有節點都處理完畢。責任鏈模式在日常生活中例子挺多，比如快遞，當你發一個從深圳到北京的快遞的時候，你的包裹會從一個分撥中心傳遞到下一個分撥中心，直到目的地，這里面每個分撥中心都是鏈路上的一個節點，它做完自己的工作，然后將工作傳遞到下一個節點，還比如路由器中傳遞某個數據包其實也是同樣的思路。

責任鏈模式在Tomcat的應用

Tomcat中請求的處理流程其實就是采用了責任鏈模式，關于Tomcat請求處理，大家可以參考下Tomcat請求處理流程（Tomcat源代碼閱讀系列之五）,Tomcat中責任鏈模式的實現的類圖如下圖所示：

從上圖中，我們可以看到每一個容器都會有一個Pipeline，而一個Pipeline又會具有多個Valve閥門，其中StandardEngine對應的閥門是StandardEngineValve，StandardHost對應的閥門是StandardHostValve，StandardContext對應的閥門是StandardContextValve，StandardWrapper對應的閥門是StandardWrapperValve。這里每一Pipeline就好比一個管道，而每一Valve就相當于一個閥門，一個管道可以有多個閥門，而對于閥門來說有兩種，一種閥門在處理完自己的事情以后，只需要將工作委托給下一個和自己在同一管道的閥門即可，第二種閥門是負責銜接各個管道的，它負責將請求傳遞給下個管道的第一個閥門處理，而這種閥門叫Basic閥門，它是每個管道中最后一個閥門，上面的Standard*Valve都屬于第二種閥門。我們可以形象的通過下圖來描述上面的過程:

通過上圖，我們可以很清楚的了解到Tomcat的請求處理流程。當用戶請求服務器的時候，Connector會接受請求，從Socket連接中根據http協議解析出對應的數據，構造Request和Response對象，然后傳遞給后面的容器處理，頂層容器是StandardEngine，StandardEngine處理請求其實是通過容器的Pipeline進行的，而Pipeline其實最終是通過管道上的各個閥門進行的，當請求到達StandardEngineValve的時候，此閥門會將請求轉發給對應StandardHost的Pipeline的第一個閥門處理，然后以此最終到達StandardHostValve閥門，它又會將請求轉發給StandardContext的Pipeline的第一個閥門，這樣以此類推，最后到達StandardWrapperValve，此閥門會根據Request來構建對應的Servelt，并將請求轉發給對應的HttpServlet處理。從這里我們可以看出其實Tomcat核心處理流程就是通過責任鏈一步步的組裝起來的。

模板方法模式

定義

模板方法模式抽象出某個業務操作公共的流程，將流程分為幾個步驟，其中有一些步驟是固定不變的，有一些步驟是變化的，固定不變的步驟通過一個基類來實現，而變化的部分通過鉤子方法讓子類去實現，這樣就實現了對系統中流程的統一化規范化管理。在日常生活中其實也有類似的例子，比如我們知道的連鎖加盟店，他們都是有固定的加盟流程，只不過每一家店開的時候，店的選址，裝修等不同的而已，但是總體的加盟流程已經是確定的。

模板方法模式在Tomcat的應用

Tomcat中關于生命周期管理的地方很好應用了模板方法模式，在一個組件的生命周期中都會涉及到init(初始化)，start（啟動），stop(停止)，destory（銷毀），而對于每一個生命周期階段其實都有固定一些事情要做，比如判斷前置狀態，設置后置狀態，以及通知狀態變更事件的監聽者等，而這些工作其實是可以固化的，所以Tomcat中就將每個生命周期階段公共的部分固化，然后通過initInternal,startInternal,stopInternal,destoryInternal這幾個鉤子方法開放給子類去實現具體的邏輯。Tomcat中關于模板方法模式的實現如下圖所示：

命令模式

定義

命令模式將請求封裝為一個命令，將命令發送者和命令接受者解耦，并且所有命令對客戶端來說都有統一的調用接口，使用命令模式還可以支持命令的撤銷操作，在很多GUI程序中大量使用了此模式。
接下來我們來說一個場景大家感受下，我們有時候可能會遇到接口方法參數過多的問題，這樣的接口不僅看起來丑陋而且不方便閱讀，對客戶端不友好。遇到這種情況我們可能選擇將各種參數打包為一個參數對象，接口只需要一個參數對象即可，但是在具體的接口實現中，我們又要做條件判斷根據參數值的不同做出不同的響應操作，這個時候其實就可以考慮將不同的邏輯實現和各種參數通過命令打包，然后提供一個命令工廠，客戶端通過工廠生產出命令，然后直接調用即可。
其實在日常生活中，命令模式也很常見，比如公司老大給你分配了個任務，讓你去做，他可能不關心你具體怎么做的，你做完了以后告訴他結果即可。

命令模式在Tomcat的應用

命令模式在Tomcat中主要是應用在對請求的處理過程中，Tomcat的實現中，根據它支持兩種協議AJP和Http,而在具體的IO實現中，又分為Java同步阻賽IO,Java同步非祖塞IO，以及采用APRApache Portable Runtime?支持庫,因此Tomcat統一了org.apache.coyote.Processor接口，根據協議和IO實現的不同通過不同的Process子類去實現，Connector作為客戶端每次只需要根據具體的協議和IO實現創建對應的Process執行即可。下面我們來看一下命令模式在Tomcat中實現的相關類圖:

通過上圖我們可以清楚的看到，Tomcat首先根據協議的不同將Processor分為了Ajp和Http兩組，然后又根據具體的IO實現方式的不同，將每一組都會實現同步祖塞IO,同步非祖塞IO，以及APR的Processor。 接下來我們再來看一個類圖，我們就可以更加清楚的看到Tomcat中是如何利用命令模式來根據不同的協議以及IO實現方式來處理請求的。我們來看一下Tomcat中關于ProtocolHandler的類圖。

通過上圖我們可以看到針對每一種協議和IO實現方式的組合，都會有相應的協議處理類，而每個協議處理類都會有一個Handler，而每一個Handler在運行的時候就會創建出對應的Processor，比如AjpProtocol.AjpConnectionHandler創建AjpProcessor處理器，其它的類似。

通過上面的描述，我們可以看出Tomcat接受請求的處理流程如下：
Connector通過對應的Endpint監聽Socket連接，當對應的端口有連接進來的時候，對應的Endpoint就會通過對應的Handler類處理，而Handler處理的時候，又會創建對應的Processor處理,而對應的Processor命令對象會解析Socket流的數據，然后生成Request和Response對象，最終通過上面說的責任鏈模式一步步的通過各個容器。

總結

以上是生活随笔為你收集整理的Tomcat源代码阅读系列之八：Tomcat 设计模式总结的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。