文章已託管到GitHub，大家可以去GitHub檢視閱讀，歡迎老闆們前來Star！
搜尋關注微信公眾號 碼出Offer 領取各種學習資料！
SpringMVC執行流程
SpringMVC概述
Spring MVC屬於SpringFrameWork的後續產品，已經融合在Spring Web Flow裡面。Spring 框架提供了構建 Web 應用程式的全功能 MVC 模組。使用 Spring 可插入的 MVC 架構，從而在使用Spring進行WEB開發時，可以選擇使用Spring的Spring MVC框架或整合其他MVC開發框架。
SpringMVC執行流程概括
SpringMVC框架固然強大，但是其執行流程更是妙不可言。所以我們這次要用一個簡單的例子去深究一下SpringMVC的底層執行流程！
如下是SpringMVC的執行流程梗概圖，我會在後面的底層流程剖析中重點提到梗概圖中的這幾個零件，以及它們的作用！
| SpringMVC執行流程梗概圖（切記：該圖只是梳理思路，並不特別嚴謹，請諒解） |
|---|
 |
SpringMVC的重要元件（視覺化元件）
既然，我們要選擇剖析SpringMVC底層執行流程，那肯定是要先分析我們能所看到表面的MVC重要元件。這樣我們分析完可視元件後，就能找到分析SpringMVC底層執行流程的入口，所以分析它的重要元件顯得更是重要！
SpringMVC的重要元件是由核心的前端控制器（web.xml）、後端控制器（Controller）和spring-mvc.xml配置檔案組成。
- 核心的前端控制器： 作為MVC框架，首先要解決的就是如何能收到請求。所以MVC框架大都會設計一款前端控制器（入口或者說起點），選型在Servlet或Filter兩者之一，由前端控制器來最率先的工作，接收請求。在SpringMVC中，也不例外，前端控制器的選型確定為Servlet（DispatcherServlet），此前端控制器在接收請求後，還會負責SpringMVC的核心排程管理，所以既是前端又是核心。
- 後端控制器： 後端控制器為Controller，等價於之前定義的Servlet。MVC框架中，後端控制器也是必不可少的重要元件之一。因為它接收了使用者請求的大量資料引數物件（或Json）儲存在域中方便頁面（JSP）取值，或是攜帶著這些資料返回所需要跳轉（重定向或請求轉發）的頁面。這裡值得注意的是，後端控制器本質並不是一個普通的Servlet，也不是BaseServlet，它只是一個普通的類，裡面卻像曾經的BaseServlet一樣可以擁有很多個方法，這些方法在SpringMVC中成為一個個Handler（換湯不換藥，本質仍然）。所以在MVC模式的執行流程環節中，後端控制器控制著頁面的跳轉和資料的傳遞，在這裡也有著很高的地位。
- spring-mvc.xml配置檔案： 該配置檔案配置著許多在執行過程中需要載入的元件，比如：註解掃描器、註解掃描驅動、試圖解析器、靜態資源處理器、異常解析器、攔截器、上傳解析器等等，如果我們要使用這些元件，就需要在該配置檔案中注入這些元件的相關配置，注入配置後由SpringMVC工廠在執行過程中載入這些元件，以達成我們使用這些元件的目的。所以這也是它受人青睞的原因。
SpringMVC執行流程剖析
上述得知，我們執行流程剖析的入口既是核心的前端控制器，即web.xml，那我們有資格瞭解該前端控制器中配置了什麼！如下：
| 前端控制器 |
|---|
 |
由上圖所知，前端控制器中所包含的即是同時啟動SpringMVC工廠和Spring工廠，讓兩個工廠同時運作處理請求，並作出響應。既然要剖析SpringMVC的底層執行流程，那我們要從載入SpringMVC工廠的DispatcherServlet說起。首先進入到DispatcherServlet中，檢視原始碼所有方法，如下圖所示：
| DispatcherServlet原始碼所有方法 |
|---|
 |
| DispatcherServlet繼承FrameworkServlet |
 |
上圖所示，我進入到了DispatcherServlet中。既然說它是一個Servlet，那肯定是需要尋找它的service方法，因為Service方法是Servlet的核心所在。於是我開啟了IDEA的方法列表搜尋service方法，未果。雖然未果，但是我發現兩個重要的線索，一是該Servlet中有一個doSerivce方法，二是DispatcherServlet繼承了FrameworkServlet，我想既然子類沒有service方法，父類肯定有，於是我進入到了FrameworkServlet檢視原始碼，如下圖所示：
| FrameworkServlet原始碼 |
|---|
 |
我興沖沖在父類（FrameworkServlet）中找到了service方法，但是還是感覺高興的太早了，該service方法中除了resolve方法獲取請求方式和processRequest方法外，我一無所知。隨後竟然發現了紅色箭頭所指向的東西super.service(request, response);，這意味著什麼呢？這意味著它繼承了父類擁有的service方法，於是我點選super句點後面的service方法檢視原始碼驚人的發現這個類竟然是HttpServlet，顯然我們找service方法的這條路走到盡頭了。在裡面有兩個方法存在一個是resolve方法，它是獲取請求方式的。還有一個方法不知道是做什麼的，於是我點選了進去檢視原始碼，如下圖所示：
| processRequest方法原始碼 |
|---|
 |
既然我們進去看到了processRequest方法的原始碼，就要找重要的方法。何為重要的方法呢，一般被try塊包裹的方法必然是重要方法，於是我找到了doService(request, response);方法，並繼續點選去看該doService方法的原始碼，如下圖所示：
| doService(request, response);方法原始碼 |
|---|
 |
逐漸失去耐心的我真的被驚訝到了，進入到doService方法後，也沒有跳到其他的類中，而卻還是在該類中跳到了一個空的doService();方法中。唉，探究究竟真的是件不容易的事情呀~我嘆了一口氣。冷靜下來一想，父類是空方法沒有實現，那核心邏輯程式碼必定是在子類中了呀。這不是多型嘛！於是，我得出了結論，費勁吧難，找入口的邏輯程式碼回過頭來還是得看DispatcherServlet中的那個doService方法。此時我知道，這必將是一個漫長的探索之路。於是，我秉著探究原理的心態，再一次點進了被我錯過的那個DispatcherServlet中的doSerivce方法，如下圖：
| DispatcherServlet中的doService()方法 |
|---|
 |
既然確定了這是探究底層原理的開始，那我們就在doServie()方法中尋找重要的邏輯，於是我再一次的在try塊中找到了一個名為doDispatch(request, response);的方法（省略了前面的各種初始化和儲存域資料）。在探究底層原理的道路上，你會發現越來越接近真理，雖然這注定是一個漫長的探索過程，我也情願。於是，點選進入到了doDispatch()方法中的原始碼，如下圖所示：
| doDispatch()方法原始碼 |
|---|
 |
走進了doDispatch()方法的原始碼，才知道我沒有看錯你。裡面標有註釋的都是一些重要的執行邏輯方法。接下來我們會一個個的分析，逐步深入理解SpringMVC的執行流程。既然探索執行流程那就少不了Debug（Debug除錯功能，Debug能很清晰的看到執行流程），於是我在getHandler()方法的那一行打了一個斷點。下一步跟進執行流程進入到了getHandler()方法，如下圖所示：
| getHandler方法原始碼（註釋解釋：為當前請求尋找並返回一個handler物件） |
|---|
 |
斷點停留到了這一行，因為getHandler()的名字，顧名思義就是獲取Controller層中的Handler。它是怎麼獲取到的呢？我們在斷點的變數顯示框中，看到handlerMappings是一個陣列，其中有三個物件。他們可以分別以不同的方式處理不同的Handler，其中我們可以點選這個三個物件，一一把其物件展開檢視重要屬性，如下圖所示：
| 0 = {RequestMappingHandlerMapping} |
|---|
 |
| 2 = {SimpleUrlHandlerMapping} |
 |
如上圖得知，RequestMappingHandlerMapping物件識別了我們Controller中的@RequestMapping註解和各個Handler上方的註解路徑。SimpleUrlHandlerMapping物件識別了處理靜態資源驅動所建立的那個預設Servlet，而處理靜態資源的預設Servlet路徑給了/**，它識別了這個路徑。HanderMapping對映器中的物件，通過註解識別獲取到了Controller層的各個Handler請求路徑註解後，就執行到了下一行，如下圖：
| getHandler方法原始碼 |
|---|
 |
通過註解可以找到所有的Handler，其中所有的Handler就儲存在handlerMappings中，於是它就遍歷了此物件。隨後根據各自的請求物件獲取對應的Handler並判空返回獲取到的對應Handler物件。繼續向下執行，你還會發現這麼一個東西，如下圖：
| getHandler方法 |
|---|
 |
對，你會發現即將返回的Handler是一個名為HandlerExecutionChain的執行鏈。其中執行鏈內包含了即將返回的handler物件和一個interceptorList集合，其中集合內有兩個物件，這兩個物件就是攔截器。所以，不管是你自己使用了攔截器還是沒有使用攔截器（內部底層有攔截器），這些攔截器和handler物件會以一個鏈條的形式執行（攔截器在前，handler物件在後）。則執行過程是遵循著先執行攔截器，後返回並執行handler物件的順序。返回了HandlerExecutionChain執行鏈，那麼就要開始執行執行鏈了！問題來了，究竟是誰依次執行攔截器和handler物件呢？如下圖：
| doDispatch()方法原始碼 |
|---|
 |
返回執行鏈後，繼續執行就執行到了這一行程式碼，其註釋解釋為為當前請求物件尋找一個handler介面卡。如果你學過介面卡設計模式也許你會更容易理解，沒有學過也沒有關係，隨後的解釋你也可以理解的。知道了它要為請求物件尋找介面卡，那麼我們繼續執行，就得到了如下啊資訊：
| getHandlerAdapter方法原始碼 |
|---|
 |
執行流程進入到了getHandlerAdapter方法，遠遠看到這個方法有一種似曾相識的感覺，對，它和HandlerMapping對映器很像，簡直就是孿生兄弟。該方法要根據當前返回的handler物件，為其handler物件尋找一個介面卡，而handlerAdapters集合物件中就儲存著三個介面卡，想想我們在對映器中獲取執行鏈的時候是不是也三個呢？對的，他們是成對出現的，handler的物件找其對應的介面卡才可以繼續執行下去。找到與當前handler物件成對的介面卡之後，就返回了該介面卡。介面卡返回後中間經過了如下方法：
| doDispatch()方法原始碼 |
|---|
 |
中間經過了這一段程式碼，獲取了請求物件的請求方式並對此進行了一系列的判斷操作。繼續執行到了下面，下面有一個if判斷，判斷執行了applyPreHandler方法，此方法就是攔截器的前置方法。執行完攔截器的前置方法後，繼續向下執行，這時候就該執行如下程式碼：
| doDispatch()方法原始碼 |
|---|
 |
從此方法可見ha物件是此時的handler物件，說明在執行handler物件之前執行了攔截器，這也是遵循了執行鏈的順序。繼續執行下去，將完成了請求引數物件的封裝和響應中Json字串與物件的轉換後，返回了一個mv物件。那麼mv物件是什麼呢？其實是在上面定義的ModelAndView物件。返回mv物件後，繼續執行便執行到了如下重要的執行邏輯：
| doDispatch()方法原始碼 |
|---|
 |
其中在執行過程中，判斷並執行了攔截器的後置方法。執行完後置方法後，進行了一系列的判斷，就開始執行了processDispatchResult(processdRequest, response, mappdeHandler, mv, dispatchException)方法，該方法中攜帶了請求物件、響應物件、handler物件、ModelAndView物件等，進入到此方法原始碼中，你會發現他進行了一系列的判斷，通過如下方法對ModelAndView物件進行了渲染：
| render方法原始碼 |
|---|
 |
對ModelAndView物件進行渲染和檢視解析後，繼續跟進方法，因為勝利馬上就要來臨了。如下圖：
| render方法原始碼 |
|---|
 |
繼續執行，就會發現它開始通過resolveViewName方法來解析檢視了。於是，就進入到了該方法，如下圖：
| resolveViewName方法原始碼 |
|---|
 |
首先，看到此方法的原始碼，你可以發現，viewResolvers檢視解析器會解析ModelAndView物件，並返回了一個View物件。後來View物件也會被一個名叫render的方法渲染，如下：
| view.render() |
|---|
 |
可見，此View物件並不簡單，它執行了一番過後，由於我的網頁跳轉時使用的請求轉發，於是就到了如下頁面原始碼：
| InternalResourceView原始碼 |
|---|
 |
點選此方法就會發現我們熟悉的請求轉發了，此時它在這裡讀取解析了spring-mvc.xml配置檔案，為內部預設的請求轉發拼接好了路徑forward:/XXX/XXX（此時也解析了spring-mvc.xml配置檔案內的其他元件），如下圖：
| 請求轉發（InternalResourceView.java） |
|---|
 |
如果是重定向呢，那麼就是如下類中的重定向方法，如下圖所示：
| 重定向（RedirectView.java） |
|---|
 |
隨後，轉發或重定向跳轉至JSP頁面（檢視層）後，渲染資料到HTML中，並渲染完HTML內容後，輸出給瀏覽器並作出響應，在瀏覽器中顯示！
此SpringMVC我以打斷點除錯的方式走了一遍底層的執行流程。我相信你自己打斷點除錯也會有一個不錯的收穫！
SpringMVC的內部元件
- HandlerMapping（處理器對映器）
- HandlerAdapter（處理器介面卡）
- ViewResolver（檢視解析器）
SpringMVC預設元件初始化載入
上面我們通過Debug簡單的走了一遍SpringMVC的執行流程，但是前面所說的那麼多內部元件是怎麼來的呢？於是，我從DispatherServlet找到了一個方法initStrategies，如下：
| initStrategies方法原始碼 |
|---|
 |
在執行流程開始之前，做了內部元件的一系列初始化操作，這裡我們以initHandlerMappings方法進行追溯，找到 SpringMVC 的預設配置檔案。進入 initHandlerMappings 方法，因為我們並沒有進行配置（註解或者 Bean 標籤），所以該方法中的前兩種情況都會跳過，會來到最下面的預設情況處，呼叫了 getDefaultStrategies 方法，讀取預設的配置檔案。
| initHandlerMappings方法原始碼 |
|---|
 |
| getDefaultStrategies方法原始碼 |
 |
在 getDefaultStrategies 方法中，有一個 defaultStrategies，我們當該類上面看一下，如下圖：
| defaultStrategies原始碼 |
|---|
 |
這裡就是進行載入預設配置檔案的地方，點選 DEFAULT_STRATEGIES_PATH 常量，找到了預設的配置配置檔案。
| DEFAULT_STRATEGIES_PATH常量 |
|---|
 |
於是我想辦法翻到了這個配置檔案，裡面就初始化了各種元件，大家可以查閱：
| DispatcherServlet.properties配置檔案 |
|---|
 |