面試高頻SpringMVC執行流程最優解(源碼分析)


文章已托管到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執行流程
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,那我們有資格了解該前端控制器中配置了什么!如下:

前端控制器
image-20200719185840281
image-20200719185840281

由上圖所知,前端控制器中所包含的即是同時啟動SpringMVC工廠和Spring工廠,讓兩個工廠同時運作處理請求,並作出響應。既然要剖析SpringMVC的底層執行流程,那我們要從加載SpringMVC工廠的DispatcherServlet說起。首先進入到DispatcherServlet中,查看源代碼所有方法,如下圖所示:

DispatcherServlet源碼所有方法
image-20200719190557728
image-20200719190557728
DispatcherServlet繼承FrameworkServlet
image-20200719190959184
image-20200719190959184

上圖所示,我進入到了DispatcherServlet中。既然說它是一個Servlet,那肯定是需要尋找它的service方法,因為Service方法是Servlet的核心所在。於是我打開了IDEA的方法列表搜索service方法,未果。雖然未果,但是我發現兩個重要的線索,一是該Servlet中有一個doSerivce方法,二是DispatcherServlet繼承了FrameworkServlet,我想既然子類沒有service方法,父類肯定有,於是我進入到了FrameworkServlet查看源代碼,如下圖所示:

FrameworkServlet源碼
image-20200719193120903
image-20200719193120903

我興沖沖在父類(FrameworkServlet)中找到了service方法,但是還是感覺高興的太早了,該service方法中除了resolve方法獲取請求方式和processRequest方法外,我一無所知。隨后竟然發現了紅色箭頭所指向的東西super.service(request, response);,這意味着什么呢?這意味着它繼承了父類擁有的service方法,於是我點擊super句點后面的service方法查看源碼驚人的發現這個類竟然是HttpServlet,顯然我們找service方法的這條路走到盡頭了。在里面有兩個方法存在一個是resolve方法,它是獲取請求方式的。還有一個方法不知道是做什么的,於是我點擊了進去查看源碼,如下圖所示:

processRequest方法源碼
image-20200719193708541
image-20200719193708541

既然我們進去看到了processRequest方法的源碼,就要找重要的方法。何為重要的方法呢,一般被try塊包裹的方法必然是重要方法,於是我找到了doService(request, response);方法,並繼續點擊去看該doService方法的源碼,如下圖所示:

doService(request, response);方法源碼
image-20200719194003105
image-20200719194003105

逐漸失去耐心的我真的被驚訝到了,進入到doService方法后,也沒有跳到其他的類中,而卻還是在該類中跳到了一個空的doService();方法中。唉,探究究竟真的是件不容易的事情呀~我嘆了一口氣。冷靜下來一想,父類是空方法沒有實現,那核心邏輯代碼必定是在子類中了呀。這不是多態嘛!於是,我得出了結論,費勁吧難,找入口的邏輯代碼回過頭來還是得看DispatcherServlet中的那個doService方法。此時我知道,這必將是一個漫長的探索之路。於是,我秉着探究原理的心態,再一次點進了被我錯過的那個DispatcherServlet中的doSerivce方法,如下圖:

DispatcherServlet中的doService()方法
image-20200719195305154
image-20200719195305154

既然確定了這是探究底層原理的開始,那我們就在doServie()方法中尋找重要的邏輯,於是我再一次的在try塊中找到了一個名為doDispatch(request, response);的方法(省略了前面的各種初始化和存儲域數據)。在探究底層原理的道路上,你會發現越來越接近真理,雖然這注定是一個漫長的探索過程,我也情願。於是,點擊進入到了doDispatch()方法中的源碼,如下圖所示:

doDispatch()方法源碼
image-20200719200052667
image-20200719200052667

走進了doDispatch()方法的源碼,才知道我沒有看錯你。里面標有注釋的都是一些重要的執行邏輯方法。接下來我們會一個個的分析,逐步深入理解SpringMVC的執行流程。既然探索執行流程那就少不了Debug(Debug調試功能,Debug能很清晰的看到執行流程),於是我在getHandler()方法的那一行打了一個斷點。下一步跟進執行流程進入到了getHandler()方法,如下圖所示:

getHandler方法源碼(注釋解釋:為當前請求尋找並返回一個handler對象)
image-20200719201557155
image-20200719201557155

斷點停留到了這一行,因為getHandler()的名字,顧名思義就是獲取Controller層中的Handler。它是怎么獲取到的呢?我們在斷點的變量顯示框中,看到handlerMappings是一個數組,其中有三個對象。他們可以分別以不同的方式處理不同的Handler,其中我們可以點擊這個三個對象,一一把其對象展開查看重要屬性,如下圖所示:

0 = {RequestMappingHandlerMapping}
image-20200719202203776
image-20200719202203776
2 = {SimpleUrlHandlerMapping}
image-20200719202458924
image-20200719202458924

如上圖得知,RequestMappingHandlerMapping對象識別了我們Controller中的@RequestMapping注解和各個Handler上方的注解路徑。SimpleUrlHandlerMapping對象識別了處理靜態資源驅動所創建的那個默認Servlet,而處理靜態資源的默認Servlet路徑給了/**,它識別了這個路徑。HanderMapping映射器中的對象,通過注解識別獲取到了Controller層的各個Handler請求路徑注解后,就執行到了下一行,如下圖:

getHandler方法源碼
image-20200719203457220
image-20200719203457220

通過注解可以找到所有的Handler,其中所有的Handler就存儲在handlerMappings中,於是它就遍歷了此對象。隨后根據各自的請求對象獲取對應的Handler並判空返回獲取到的對應Handler對象。繼續向下執行,你還會發現這么一個東西,如下圖:

getHandler方法
image-20200719204645324
image-20200719204645324

對,你會發現即將返回的Handler是一個名為HandlerExecutionChain的執行鏈。其中執行鏈內包含了即將返回的handler對象和一個interceptorList集合,其中集合內有兩個對象,這兩個對象就是攔截器。所以,不管是你自己使用了攔截器還是沒有使用攔截器(內部底層有攔截器),這些攔截器和handler對象會以一個鏈條的形式執行(攔截器在前,handler對象在后)。則執行過程是遵循着先執行攔截器,后返回並執行handler對象的順序。返回了HandlerExecutionChain執行鏈,那么就要開始執行執行鏈了!問題來了,究竟是誰依次執行攔截器和handler對象呢?如下圖:

doDispatch()方法源碼
image-20200719210132545
image-20200719210132545

返回執行鏈后,繼續執行就執行到了這一行代碼,其注釋解釋為為當前請求對象尋找一個handler適配器。如果你學過適配器設計模式也許你會更容易理解,沒有學過也沒有關系,隨后的解釋你也可以理解的。知道了它要為請求對象尋找適配器,那么我們繼續執行,就得到了如下啊信息:

getHandlerAdapter方法源碼
image-20200719210604037
image-20200719210604037

執行流程進入到了getHandlerAdapter方法,遠遠看到這個方法有一種似曾相識的感覺,對,它和HandlerMapping映射器很像,簡直就是孿生兄弟。該方法要根據當前返回的handler對象,為其handler對象尋找一個適配器,而handlerAdapters集合對象中就存儲着三個適配器,想想我們在映射器中獲取執行鏈的時候是不是也三個呢?對的,他們是成對出現的,handler的對象找其對應的適配器才可以繼續執行下去。找到與當前handler對象成對的適配器之后,就返回了該適配器。適配器返回后中間經過了如下方法:

doDispatch()方法源碼
image-20200719211355102
image-20200719211355102

中間經過了這一段代碼,獲取了請求對象的請求方式並對此進行了一系列的判斷操作。繼續執行到了下面,下面有一個if判斷,判斷執行了applyPreHandler方法,此方法就是攔截器的前置方法。執行完攔截器的前置方法后,繼續向下執行,這時候就該執行如下代碼:

doDispatch()方法源碼
image-20200719211927390
image-20200719211927390

從此方法可見ha對象是此時的handler對象,說明在執行handler對象之前執行了攔截器,這也是遵循了執行鏈的順序。繼續執行下去,將完成了請求參數對象的封裝和響應中Json字符串與對象的轉換后,返回了一個mv對象。那么mv對象是什么呢?其實是在上面定義的ModelAndView對象。返回mv對象后,繼續執行便執行到了如下重要的執行邏輯:

doDispatch()方法源碼
image-20200719213149039
image-20200719213149039

其中在執行過程中,判斷並執行了攔截器的后置方法。執行完后置方法后,進行了一系列的判斷,就開始執行了processDispatchResult(processdRequest, response, mappdeHandler, mv, dispatchException)方法,該方法中攜帶了請求對象、響應對象、handler對象、ModelAndView對象等,進入到此方法源碼中,你會發現他進行了一系列的判斷,通過如下方法對ModelAndView對象進行了渲染:

render方法源碼
image-20200719213629854
image-20200719213629854

對ModelAndView對象進行渲染和視圖解析后,繼續跟進方法,因為勝利馬上就要來臨了。如下圖:

render方法源碼
image-20200719213959635
image-20200719213959635

繼續執行,就會發現它開始通過resolveViewName方法來解析視圖了。於是,就進入到了該方法,如下圖:

resolveViewName方法源碼
image-20200719214336328
image-20200719214336328

首先,看到此方法的源碼,你可以發現,viewResolvers視圖解析器會解析ModelAndView對象,並返回了一個View對象。后來View對象也會被一個名叫render的方法渲染,如下:

view.render()

可見,此View對象並不簡單,它執行了一番過后,由於我的網頁跳轉時使用的請求轉發,於是就到了如下頁面源碼:

InternalResourceView源碼

點擊此方法就會發現我們熟悉的請求轉發了,此時它在這里讀取解析了spring-mvc.xml配置文件,為內部默認的請求轉發拼接好了路徑forward:/XXX/XXX(此時也解析了spring-mvc.xml配置文件內的其他組件),如下圖:

請求轉發(InternalResourceView.java)
image-20200719215453276
image-20200719215453276

如果是重定向呢,那么就是如下類中的重定向方法,如下圖所示:

重定向(RedirectView.java)
image-20200719215921537
image-20200719215921537

隨后,轉發或重定向跳轉至JSP頁面(視圖層)后,渲染數據到HTML中,並渲染完HTML內容后,輸出給瀏覽器並作出響應,在瀏覽器中顯示!

此SpringMVC我以打斷點調試的方式走了一遍底層的執行流程。我相信你自己打斷點調試也會有一個不錯的收獲!

SpringMVC的內部組件
  • HandlerMapping(處理器映射器)
  • HandlerAdapter(處理器適配器)
  • ViewResolver(視圖解析器)
SpringMVC默認組件初始化加載

上面我們通過Debug簡單的走了一遍SpringMVC的執行流程,但是前面所說的那么多內部組件是怎么來的呢?於是,我從DispatherServlet找到了一個方法initStrategies,如下:

initStrategies方法源碼
image-20200720214203411
image-20200720214203411

在執行流程開始之前,做了內部組件的一系列初始化操作,這里我們以initHandlerMappings方法進行追溯,找到 SpringMVC 的默認配置文件。進入 initHandlerMappings 方法,因為我們並沒有進行配置(注解或者 Bean 標簽),所以該方法中的前兩種情況都會跳過,會來到最下面的默認情況處,調用了 getDefaultStrategies 方法,讀取默認的配置文件。

initHandlerMappings方法源碼
image-20200720214539186
image-20200720214539186
getDefaultStrategies方法源碼
image-20200720214701181
image-20200720214701181

在 getDefaultStrategies 方法中,有一個 defaultStrategies,我們當該類上面看一下,如下圖:

defaultStrategies源碼
image-20200720214907843
image-20200720214907843

這里就是進行加載默認配置文件的地方,點擊 DEFAULT_STRATEGIES_PATH 常量,找到了默認的配置配置文件。

DEFAULT_STRATEGIES_PATH常量
image-20200720215021940
image-20200720215021940

於是我想辦法翻到了這個配置文件,里面就初始化了各種組件,大家可以查閱:

DispatcherServlet.properties配置文件
image-20200720215320968
image-20200720215320968


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM