前言

提到框架,就不得不提一下看源碼,我們平時(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é).

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

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

從這里就可以看出,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í)候就要找它的父類(lèi)FrameworkServlet.于是我們?cè)趕ervice方法中打上斷點(diǎn),開(kāi)始發(fā)起請(qǐng)求,如圖.super.service(request, response);這里會(huì)根據(jù)得到的請(qǐng)求類(lèi)型,調(diào)用對(duì)應(yīng)的方法(doGet或者doPost),比如我們這次測(cè)試是get請(qǐng)求,所以調(diào)用的是doGet.

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

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

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

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

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

HandlerMapping

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

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

其實(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è)東西被稱(chēng)為處理執(zhí)行鏈

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

HandlerAdapter

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

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

if (ha.supports(handler)) {

return ha;

}

接著往下走

String method = request.getMethod();

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

接著往下走

if (!mappedHandler.applyPreHandle(processedRequest, response)) {

return;

}

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

public class MyInterceptor implements HandlerInterceptor {

}

這里主要是遍歷攔截器,如果返回的是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”)

public String test(Model model) {

model.addAttribute(“msg”, “Hello Toby”);

return “hello”;

}

再繼續(xù)往下走

//默認(rèn)視圖名稱(chēng)

applyDefaultViewName(request, mv);

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

@RequestMapping(“/value2”)

public User value2() {

//報(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)求/value2

return new User(“toby”,”24”);

}

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

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

繼續(xù)往下走

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

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

view.render(mv.getModelInternal(), request, response);

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

protected RequestDispatcher getRequestDispatcher(HttpServletRequest request, String path) {

return request.getRequestDispatcher(path);

}

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

rd.forward(request, response);

繼續(xù)往下走

mappedHandler.triggerAfterCompletion(request, response, null);

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

寫(xiě)在末尾

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,我們又是怎么做的?這些都是非常值得思考.大家可以點(diǎn)擊加入群：478052716【JAVA高級(jí)程序員】里面有Java高級(jí)大牛直播講解知識(shí)點(diǎn) 走的就是高端路線 （如果你想跳槽換工作 但是技術(shù)又不夠 或者工作上遇到了瓶頸 我這里有一個(gè)JAVA的免費(fèi)直播課程 講的是高端的知識(shí)點(diǎn)基礎(chǔ)不好的誤入喲 只要你有1-5年的開(kāi)發(fā)經(jīng)驗(yàn)可以加群找我要課堂鏈接 注意：是免費(fèi)的 沒(méi)有開(kāi)發(fā)經(jīng)驗(yàn)誤入哦）