前言

提到框架,就不得不提一下看源碼,我們平時(shí)總是想求大神帶我們飛,然而看源碼就是一個(gè)向大神學(xué)習(xí)的最直接的一種方式,然而我們每次鼓起勇氣看源碼前是這樣的

但是一點(diǎn)開(kāi)源碼,頓時(shí)代碼如洪流涌入,你的內(nèi)心可能是這樣的

所以我在之前別怕看源碼,一張圖搞定Mybatis的Mapper原理的時(shí)候也提到過(guò),Mybatis的源碼相對(duì)其他框架而言比較簡(jiǎn)單,比較適合剛開(kāi)始克服恐懼心理看源碼實(shí)戰(zhàn),由于Struts2前不久又傳出安全性問(wèn)題,所以Java開(kāi)發(fā)中,表現(xiàn)層框架基本都是SpringMVC,那么我們就來(lái)撕、拉、扯下SpringMVC的神秘外衣,可以對(duì)比之前別怕装哆，Struts2執(zhí)行流程沒(méi)那么難,本篇中會(huì)涉及到一些的Struts2、JavaWeb以及SpringMVC使用上你一些細(xì)節(jié).

SpringMVC執(zhí)行流程圖.png

這是一個(gè)最經(jīng)典的SpringMVC執(zhí)行流程圖,相信做Java開(kāi)發(fā)的都看過(guò),其中有三個(gè)核心的地方,分別是HandlerMapping、HandlerAdapter蜕琴、HttpMessageConveter.看完這個(gè)圖有了大局觀之后,就要開(kāi)車了,前方高能,請(qǐng)扶穩(wěn)坐好.

看源碼,首先要找到入口,那么入口在哪?從流程圖我們就可以看出,DispatcherServlet就是入口核心類(其實(shí)從SpringMVC的配置文件也可以得知),但是這里面有這么多方法,我們又知道哪個(gè)方法才是入口?我們先來(lái)看一下DispatcherServlet的繼承圖

繼承圖.png

從這里就可以看出,DispatcherServlet的本質(zhì)就是Servlet,那么我們回憶一下Servlet的生命周期,生命周期中主要的三個(gè)方法是void init(ServletConfig config)萍桌、void service(ServletRequest req, ServletResponse res)、void destroy(),但是我們又發(fā)現(xiàn)DispatcherServlet里面根本就沒(méi)有service這個(gè)方法,那么這個(gè)時(shí)候就要找它的父類FrameworkServlet.于是我們?cè)趕ervice方法中打上斷點(diǎn),開(kāi)始發(fā)起請(qǐng)求,如圖.super.service(request, response);這里會(huì)根據(jù)得到的請(qǐng)求類型,調(diào)用對(duì)應(yīng)的方法(doGet或者doPost),比如我們這次測(cè)試是get請(qǐng)求,所以調(diào)用的是doGet.

doGet.png

processRequest.png

doService.png

doDispatch,從字面理解就知道,這個(gè)方法是分發(fā)請(qǐng)求的,核心的邏輯都在這里

doDispatch.png

checkMultipart這個(gè)方法是檢查是否是二進(jìn)制的請(qǐng)求(文件上傳的請(qǐng)求)

protectedHttpServletRequestcheckMultipart(HttpServletRequest request)throwsMultipartException{//multipartResolver這是個(gè)視圖解析器,所以這里是判斷一下有沒(méi)有視圖解析器,以及request是不是一個(gè)二進(jìn)制請(qǐng)求if(this.multipartResolver !=null&&this.multipartResolver.isMultipart(request)) {if(WebUtils.getNativeRequest(request, MultipartHttpServletRequest.class) !=null) {? ? ? ? ? ? ? ? logger.debug("Request is already a MultipartHttpServletRequest - if not in a forward, "+"this typically results from an additional MultipartFilter in web.xml");? ? ? ? ? ? }elseif(request.getAttribute(WebUtils.ERROR_EXCEPTION_ATTRIBUTE)instanceofMultipartException) {? ? ? ? ? ? ? ? logger.debug("Multipart resolution failed for current request before - "+"skipping re-resolution for undisturbed error rendering");? ? ? ? ? ? }else{// 如果是二進(jìn)制的話,把request包裝一層,返回MultipartHttpServletRequestreturnthis.multipartResolver.resolveMultipart(request);? ? ? ? ? ? }? ? ? ? }// If not returned before: return original request.returnrequest;? ? }

因?yàn)椴皇嵌M(jìn)制請(qǐng)求,返回的還是原來(lái)的對(duì)象,所以multipartRequestParsed = (processedRequest != request);的結(jié)果是false

下面高潮來(lái)了mappedHandler = getHandler(processedRequest);

getHandler.png

從單詞HandlerExecutionChain就知道,這個(gè)是處理執(zhí)行鏈

HandlerMapping

HandlerMapping就是請(qǐng)求處理映射器,它能根據(jù)不同的請(qǐng)求,選擇最合適的handle(自己編寫的控制器),請(qǐng)求處理映射器可以配置多個(gè),誰(shuí)最先匹配執(zhí)行誰(shuí),

那么這個(gè)for...in它在遍歷些什么東西呢?其實(shí)這個(gè)在DispatcherServlet文件中已經(jīng)有配置了

handlerMapping.png

其實(shí)這個(gè)就是包裝了不同的Mapping來(lái)判斷是通過(guò)BeanNameUrl的方式還是Annotation的方式來(lái)配置,那什么是BeanNameUrl的方式呢?就是我們平時(shí)在xml文件中配置的

通過(guò)這個(gè),把request傳進(jìn)入得到HandlerExecutionChain

HandlerExecutionChain handler = hm.getHandler(request);

HandlerExecutionChain

HandlerExecutionChain(處理執(zhí)行鏈)包含兩部分內(nèi)容,一部分是請(qǐng)求對(duì)應(yīng)的控制器,一部分是攔截器,真正執(zhí)行handle之前,有一系列操作,例如數(shù)據(jù)轉(zhuǎn)換,格式化,數(shù)據(jù)驗(yàn)證這些,都是由攔截器來(lái)做的

另外需要注意的是,假如你自定義了n個(gè)攔截器,會(huì)發(fā)現(xiàn)HandlerExecutionChain會(huì)有n+1個(gè)攔截器,說(shuō)明有一個(gè)是他內(nèi)部有的,從這里我們可以知道它的執(zhí)行順序,比如這里要先執(zhí)行攔截器,再執(zhí)行我們控制器,所以這個(gè)東西被稱為處理執(zhí)行鏈

下面又來(lái)到了第二波高潮(這個(gè)時(shí)候那些嘴上說(shuō)不要的同學(xué),身體還是要很誠(chéng)實(shí)的繼續(xù)往下看),HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

getHandlerAdapter.png

HandlerAdapter

HandlerAdapter(處理適配器)這個(gè)翻譯成中文可能比較low,但是從名稱我們就可以得知,這個(gè)是用來(lái)執(zhí)行handler(控制器),那這個(gè)for...in究竟在遍歷些什么呢?其實(shí)這個(gè)在配置文件中也是有配置好的了

HandlerAdapter.png

這里是判斷handle適不適合這個(gè)RequestMappingHandleAdapter,適合就返回

if(ha.supports(handler)) {returnha;}

接著往下走

String method = request.getMethod();

這個(gè)方法是獲取方法類型的,那么這個(gè)get和post請(qǐng)求有什么區(qū)別呢?get請(qǐng)求是有一個(gè)緩存的,但是post請(qǐng)求是不會(huì)有的

接著往下走

if(!mappedHandler.applyPreHandle(processedRequest, response)) {return;}

applyPreHandle.png

在這里我們可以回憶一下HandlerInterceptor的三個(gè)方法

publicclassMyInterceptorimplementsHandlerInterceptor{//表示控制器方法執(zhí)行之前調(diào)用的方法,返回結(jié)果為boolean,如果為true,表示放行,如果為false,表示攔截publicbooleanpreHandle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o)throwsException{? ? ? ? System.out.println("MyInterceptor.preHandle");returntrue;? ? }//控制器執(zhí)行完方法之后,視圖結(jié)合之前publicvoidpostHandle(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o, ModelAndView modelAndView)throwsException{? ? ? ? System.out.println("MyInterceptor.postHandle");? ? }//視圖結(jié)合完成之后調(diào)用的方法publicvoidafterCompletion(HttpServletRequest httpServletRequest, HttpServletResponse httpServletResponse, Object o, Exception e)throwsException{? ? ? ? System.out.println("MyInterceptor.afterCompletion");? ? }}

這里主要是遍歷攔截器,如果返回的是false,從!mappedHandler.applyPreHandle(processedRequest, response這個(gè)判斷可以得知,就不再繼續(xù)往下執(zhí)行了.

繼續(xù)往下走

// Actually invoke the handler.mv = ha.handle(processedRequest, response,mappedHandler.getHandler());

從注釋上看,這里去調(diào)用handle的方法,這個(gè)方法會(huì)做很多事情,比如之前提到的參數(shù)自動(dòng)注入就是在這個(gè)步驟做的,這個(gè)步驟層級(jí)結(jié)構(gòu)太深,篇幅有限,暫時(shí)不探討,這個(gè)時(shí)候把斷點(diǎn)打到控制器的方法上

@RequestMapping("/test")publicStringtest(Model model){? ? model.addAttribute("msg","Hello Toby");return"hello";}

再繼續(xù)往下走

//默認(rèn)視圖名稱applyDefaultViewName(request, mv);

這個(gè)默認(rèn)的視圖名稱又什么用呢?我們?cè)谑褂蒙鲜遣皇怯龅竭^(guò)直接返回Model但是沒(méi)有View的情況,例如

@RequestMapping("/value2")publicUservalue2(){//報(bào)錯(cuò):Circular view path [value2]: would dispatch back to the current handler URL [/value2] again//此時(shí)該方法只有模型,沒(méi)有視圖,SpringMVC會(huì)默認(rèn)給你視圖,默認(rèn)的視圖名為:請(qǐng)求的名字(/value2)//相當(dāng)于又去重新請(qǐng)求/value2returnnewUser("toby","24");}

繼續(xù)往下走mappedHandler.applyPostHandle(processedRequest, response, mv);

applyPostHandle.png

從這里我們就知道的執(zhí)行順序是反過(guò)來(lái)的(這個(gè)結(jié)論先記下,后面我會(huì)畫圖喚醒你的記憶)

繼續(xù)往下走

processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);

processDispatchResult.png

render.png

//這里決定究竟是轉(zhuǎn)發(fā)還是重定向,或者說(shuō)變成其他視圖view.render(mv.getModelInternal(), request, response);

render.png

renderMergedOutputModel.png

通過(guò)這個(gè)方法把請(qǐng)求路徑傳進(jìn)來(lái)

protectedRequestDispatchergetRequestDispatcher(HttpServletRequest request, String path){returnrequest.getRequestDispatcher(path);}

先拿到RequestDispatcher對(duì)象,最終再去調(diào)用forward,其實(shí)底層還是servlet的內(nèi)容

rd.forward(request, response);

繼續(xù)往下走

mappedHandler.triggerAfterCompletion(request, response,null);

triggerAfterCompletion.png

好了,由applyPreHandle凌简、applyPostHandle上炎、triggerAfterCompletion、這三個(gè)方法可以得知攔截器的執(zhí)行順序,下面我用一張圖來(lái)描述

攔截器執(zhí)行流程圖.png

寫在末尾：如果你在學(xué)習(xí)Java的過(guò)程中或者在工作中遇到什么問(wèn)題都可以來(lái)群里提問(wèn)雏搂，阿里Java高級(jí)大牛直播講解知識(shí)點(diǎn)藕施，分享知識(shí)，多年工作經(jīng)驗(yàn)的梳理和總結(jié)凸郑，帶著大家全面裳食、科學(xué)地建立自己的技術(shù)體系和技術(shù)認(rèn)知！可以加群找我要課堂鏈接 注意：是免費(fèi)的 沒(méi)有開(kāi)發(fā)經(jīng)驗(yàn)誤入哦! 非喜勿入芙沥！?學(xué)習(xí)交流QQ群：478052716

SpringMVC的簡(jiǎn)單執(zhí)行流程到這里就基本結(jié)束了,但是SpringMVC的設(shè)計(jì)精髓不僅僅剛才我們所看到的這些,每一個(gè)細(xì)節(jié)上都值得我們思考,然而這個(gè)思考的過(guò)程,才是看源碼的價(jià)值所在.就舉個(gè)簡(jiǎn)單的例子,就拿異步回調(diào)來(lái)說(shuō),iOS是通常是通過(guò)block诲祸、Android是通過(guò)interface、JavaScript是通過(guò)function,然后他們又有什么異同,就拿Node.js來(lái)說(shuō),到處是異步編程,但是異步套異步又很容易出問(wèn)題,我們又是如何解決異步變同步的問(wèn)題?如果換做是iOS,我們又是怎么做的?這些都是非常值得思考.時(shí)間比較倉(cāng)促,如果文中有不對(duì)的地方,還望大家斧正.