戰(zhàn))
1. 為什么值得花時(shí)間啃透HandlerAdapter很多人第一次翻Spring MVC源碼都是從DispatcherServlet的doDispatch方法開始的。那段代碼里有一行特別不起眼但極其關(guān)鍵的調(diào)用mappedHandler getHandler(processedRequest)拿到HandlerExecutionChain之后緊接著就是HandlerAdapter ha getHandlerAdapter(mappedHandler.getHandler())。絕大多數(shù)人掃一眼就過(guò)去了覺得無(wú)非是找個(gè)適配器來(lái)執(zhí)行handler。但真正在項(xiàng)目里踩過(guò)坑的人都清楚Spring MVC最靈活、最容易出問(wèn)題、也最能體現(xiàn)框架設(shè)計(jì)功力的地方恰恰就在這個(gè)接口上。你寫的RequestMapping方法能被執(zhí)行、ResponseBody能自動(dòng)轉(zhuǎn)JSON、HttpEntity參數(shù)能自動(dòng)綁定、ResponseEntity能自動(dòng)處理狀態(tài)碼背后全是HandlerAdapter在干活。這篇文章不打算復(fù)述官方文檔而是從一個(gè)實(shí)際維護(hù)過(guò)多個(gè)Spring MVC定制化項(xiàng)目的開發(fā)者視角把HandlerAdapter這個(gè)接口從設(shè)計(jì)動(dòng)機(jī)、源碼實(shí)現(xiàn)、擴(kuò)展點(diǎn)到實(shí)戰(zhàn)踩坑完整地拆一遍。適合已經(jīng)用過(guò)Spring MVC、能寫Controller、但想搞清楚請(qǐng)求到底是怎么被路由到我的方法上的中高級(jí)開發(fā)者?？赐曛竽銘?yīng)該能自己寫一個(gè)自定義的HandlerAdapter也能在遇到參數(shù)綁定失敗返回值處理異常這類問(wèn)題時(shí)快速定位到是哪一環(huán)出了問(wèn)題。2. HandlerAdapter接口的整體設(shè)計(jì)與思路拆解2.1 從DispatcherServlet的視角看適配器模式要理解HandlerAdapter得先理解DispatcherServlet的困境。作為一個(gè)前端控制器它需要處理各種各樣的處理器有Controller注解的普通Bean、有實(shí)現(xiàn)了Controller接口的老式Bean、有HttpRequestHandler、還有RequestMapping標(biāo)注的方法。這些處理器的調(diào)用方式完全不同——有的需要反射調(diào)用方法有的直接調(diào)handleRequest有的還要處理參數(shù)解析和返回值。如果DispatcherServlet里寫一堆if-else判斷類型再分別調(diào)用代碼會(huì)爛到無(wú)法維護(hù)。所以Spring用了適配器模式DispatcherServlet只認(rèn)HandlerAdapter接口所有具體的調(diào)用邏輯封裝在各自的適配器實(shí)現(xiàn)里。這樣新增一種處理器類型只需要新增一個(gè)適配器DispatcherServlet一行都不用改。這個(gè)設(shè)計(jì)思路在Spring里反復(fù)出現(xiàn)但HandlerAdapter是最典型的一個(gè)。它的接口定義極其簡(jiǎn)潔public interface HandlerAdapter { boolean supports(Object handler); ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception; long getLastModified(HttpServletRequest request, Object handler); }三個(gè)方法各司其職。supports負(fù)責(zé)判斷這個(gè)適配器能不能處理當(dāng)前handlerhandle負(fù)責(zé)真正的執(zhí)行g(shù)etLastModified用于處理HTTP緩存?？雌饋?lái)簡(jiǎn)單但每個(gè)方法背后都有講究。2.2 supports方法的判斷邏輯與性能考量supports方法看似只是類型判斷但它的調(diào)用時(shí)機(jī)很關(guān)鍵。在DispatcherServlet.getHandlerAdapter里是遍歷所有已注冊(cè)的HandlerAdapter逐個(gè)調(diào)用supports第一個(gè)返回true的就用它。這意味著適配器的注冊(cè)順序會(huì)影響匹配結(jié)果如果有多個(gè)適配器都支持同一個(gè)handler先注冊(cè)的勝出supports會(huì)被頻繁調(diào)用實(shí)現(xiàn)必須足夠輕量判斷邏輯要精確不能出現(xiàn)誤判導(dǎo)致用錯(cuò)適配器以RequestMappingHandlerAdapter為例它的supports實(shí)現(xiàn)是Override public boolean supports(Object handler) { return handler instanceof HandlerMethod; }就一行instanceof非常輕。而HttpRequestHandlerAdapter的判斷是handler instanceof HttpRequestHandler。這種設(shè)計(jì)保證了即使注冊(cè)了七八個(gè)適配器每次匹配的開銷也可以忽略不計(jì)。注意如果你自己寫適配器supports里千萬(wàn)不要做數(shù)據(jù)庫(kù)查詢、反射掃描這類重操作否則每個(gè)請(qǐng)求都會(huì)付出代價(jià)。2.3 handle方法的返回值設(shè)計(jì)為什么是ModelAndViewhandle方法返回ModelAndView這個(gè)設(shè)計(jì)經(jīng)常被吐槽過(guò)時(shí)因?yàn)楝F(xiàn)在大部分接口都是返回JSON。但理解這個(gè)設(shè)計(jì)要回到Spring MVC的早期定位它首先是一個(gè)MVC框架視圖渲染是核心職責(zé)。ModelAndView承載了模型數(shù)據(jù)視圖名這兩個(gè)渲染必需的信息。那返回JSON的接口怎么辦答案是返回null。RequestResponseBodyMethodProcessor在處理ResponseBody時(shí)會(huì)直接把數(shù)據(jù)寫進(jìn)response的output stream然后返回null的ModelAndView。DispatcherServlet拿到null之后就知道響應(yīng)已經(jīng)處理完了不需要渲染視圖直接走processDispatchResult的后續(xù)邏輯。這個(gè)設(shè)計(jì)其實(shí)很巧妙用一個(gè)統(tǒng)一的返回值類型同時(shí)支持了視圖渲染和直接寫響應(yīng)兩種模式。代價(jià)是null的語(yǔ)義不夠明確讀源碼時(shí)容易困惑。2.4 getLastModified與HTTP緩存的關(guān)聯(lián)getLastModified是三個(gè)方法里最容易被忽略的。它對(duì)應(yīng)HTTP協(xié)議里的Last-Modified頭用于協(xié)商緩存。如果handler實(shí)現(xiàn)了LastModified接口適配器會(huì)返回其getLastModified值DispatcherServlet會(huì)據(jù)此判斷是否返回304。大部分現(xiàn)代項(xiàng)目用ETag或者干脆不做緩存所以這個(gè)方法經(jīng)常返回-1表示不支持。但如果你做的是內(nèi)容型網(wǎng)站靜態(tài)資源或者變化不頻繁的頁(yè)面用好這個(gè)方法能顯著降低帶寬。HttpRequestHandlerAdapter就完整實(shí)現(xiàn)了這個(gè)邏輯因?yàn)樗幚淼腍ttpRequestHandler本身就繼承了LastModified接口。3. 核心實(shí)現(xiàn)類的源碼細(xì)節(jié)與實(shí)操要點(diǎn)3.1 RequestMappingHandlerAdapter最核心也最復(fù)雜RequestMappingHandlerAdapter是日常開發(fā)中99%的請(qǐng)求最終會(huì)走到的適配器。它的handle方法核心邏輯是Override protected ModelAndView handleInternal(HttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod) throws Exception { ModelAndView mav; checkRequest(request); if (this.synchronizeOnSession) { HttpSession session request.getSession(false); if (session ! null) { Object mutex WebUtils.getSessionMutex(session); synchronized (mutex) { mav invokeHandlerMethod(request, response, handlerMethod); } } else { mav invokeHandlerMethod(request, response, handlerMethod); } } else { mav invokeHandlerMethod(request, response, handlerMethod); } if (!response.containsHeader(HEADER_CACHE_CONTROL)) { if (getSessionAttributesHandler(handlerMethod).hasSessionAttributes()) { applyCacheSeconds(response, this.cacheSecondsForSessionAttributeHandlers); } else { prepareResponse(response); } } return mav; }這段代碼里有幾個(gè)關(guān)鍵點(diǎn)值得展開。第一是checkRequest它會(huì)校驗(yàn)請(qǐng)求方法是否被支持。如果你在RequestMapping里限定了method RequestMethod.POST但用GET請(qǐng)求訪問(wèn)就會(huì)在這里拋出HttpRequestMethodNotSupportedException。這個(gè)異常最終會(huì)被DefaultHandlerExceptionResolver處理成405響應(yīng)。第二是session同步邏輯。synchronizeOnSession默認(rèn)是false如果開啟同一個(gè)session的請(qǐng)求會(huì)串行執(zhí)行。這個(gè)特性在早期處理并發(fā)問(wèn)題時(shí)用過(guò)但現(xiàn)在基本不推薦——它會(huì)嚴(yán)重拖累性能而且用session鎖解決并發(fā)本身就是個(gè)壞味道。第三是緩存頭的處理。prepareResponse會(huì)根據(jù)配置設(shè)置Cache-Control頭。默認(rèn)情況下如果沒(méi)有顯式配置Spring不會(huì)設(shè)置任何緩存頭這也是為什么很多接口在瀏覽器里默認(rèn)不緩存。3.2 invokeHandlerMethod的參數(shù)解析鏈路invokeHandlerMethod是整個(gè)適配器最核心的方法它要完成參數(shù)解析、方法調(diào)用、返回值處理三件事。參數(shù)解析依賴HandlerMethodArgumentResolver鏈返回值處理依賴HandlerMethodReturnValueHandler鏈。ServletInvocableHandlerMethod invocableMethod createInvocableHandlerMethod(handlerMethod); if (this.argumentResolvers ! null) { invocableMethod.setHandlerMethodArgumentResolvers(this.argumentResolvers); } if (this.returnValueHandlers ! null) { invocableMethod.setHandlerMethodReturnValueHandlers(this.returnValueHandlers); } invocableMethod.invokeAndHandle(webRequest, mavContainer);argumentResolvers和returnValueHandlers是在afterPropertiesSet里初始化的默認(rèn)會(huì)加載一長(zhǎng)串解析器。這個(gè)順序非常重要因?yàn)榻馕銎饕彩堑谝粋€(gè)支持的就用。默認(rèn)的參數(shù)解析器順序大致是RequestParamMethodArgumentResolver、RequestParamMapMethodArgumentResolver、PathVariableMethodArgumentResolver、ServletModelAttributeMethodProcessor、RequestResponseBodyMethodProcessor等等。如果你自定義了一個(gè)解析器想讓它優(yōu)先于內(nèi)置的必須通過(guò)setArgumentResolvers或者setCustomArgumentResolvers調(diào)整順序。實(shí)操心得自定義參數(shù)解析器時(shí)最常見的坑是我的解析器沒(méi)生效。90%的情況是因?yàn)閮?nèi)置解析器先匹配上了。比如你想解析一個(gè)自定義注解標(biāo)注的參數(shù)但參數(shù)類型是StringRequestParamMethodArgumentResolver可能會(huì)先把它當(dāng)成普通參數(shù)處理。解決辦法是讓自定義解析器的supportsParameter判斷更精確或者用setCustomArgumentResolvers確保優(yōu)先級(jí)。3.3 SimpleControllerHandlerAdapter與老式ControllerSimpleControllerHandlerAdapter處理的是實(shí)現(xiàn)了Controller接口的Bean。它的handle方法簡(jiǎn)單到極致Override public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { return ((Controller) handler).handleRequest(request, response); }這種老式寫法現(xiàn)在幾乎沒(méi)人用了但在一些遺留系統(tǒng)里還能見到。它的優(yōu)勢(shì)是簡(jiǎn)單直接沒(méi)有反射開銷劣勢(shì)是每個(gè)Controller只能處理一個(gè)URL而且參數(shù)綁定要自己寫。如果你在維護(hù)老項(xiàng)目看到這種寫法不要驚訝它和Controller是可以共存的因?yàn)閮蓚€(gè)適配器都注冊(cè)了各管各的。3.4 HttpRequestHandlerAdapter與靜態(tài)資源處理HttpRequestHandlerAdapter處理HttpRequestHandler最典型的應(yīng)用是ResourceHttpRequestHandler——也就是Spring MVC處理靜態(tài)資源的機(jī)制。當(dāng)你配置了mvc:resources或者addResourceHandlers請(qǐng)求靜態(tài)文件時(shí)走的就是這個(gè)適配器。它的handle方法會(huì)調(diào)用handler.handleRequest而ResourceHttpRequestHandler會(huì)去查找資源文件、設(shè)置Content-Type、處理Last-Modified和ETag、支持Range請(qǐng)求。這也是為什么Spring MVC處理靜態(tài)資源的性能其實(shí)不差——它做了完整的HTTP緩存協(xié)商。3.5 適配器的注冊(cè)與初始化順序在WebMvcConfigurationSupport里默認(rèn)適配器的注冊(cè)順序是Bean public HandlerAdapter requestMappingHandlerAdapter() { ... } Bean public HandlerAdapter httpRequestHandlerAdapter() { ... } Bean public HandlerAdapter simpleControllerHandlerAdapter() { ... }注意requestMappingHandlerAdapter排在最前面。這個(gè)順序決定了當(dāng)handler同時(shí)滿足多個(gè)適配器的supports時(shí)優(yōu)先用哪個(gè)。實(shí)際上HandlerMethod只被RequestMappingHandlerAdapter支持所以順序影響不大但理解這個(gè)機(jī)制對(duì)自定義適配器很重要。4. 自定義HandlerAdapter的完整實(shí)操過(guò)程4.1 什么場(chǎng)景下需要自定義適配器大部分項(xiàng)目一輩子都不需要自定義HandlerAdapter。但以下幾種場(chǎng)景自定義是合理的你有一套自己的處理器抽象比如基于注解的RPC方法想復(fù)用Spring MVC的請(qǐng)求分發(fā)機(jī)制你想對(duì)特定類型的handler做統(tǒng)一的預(yù)處理比如統(tǒng)一的日志、鑒權(quán)、限流你在做框架層面的擴(kuò)展比如實(shí)現(xiàn)一個(gè)輕量級(jí)的API網(wǎng)關(guān)需要強(qiáng)調(diào)的是如果你的需求只是在Controller執(zhí)行前后做點(diǎn)事用HandlerInterceptor就夠了不要上適配器。適配器的粒度更粗它是如何調(diào)用handler層面的擴(kuò)展不是調(diào)用前后層面的。4.2 定義自定義handler與適配器假設(shè)我們要實(shí)現(xiàn)一個(gè)簡(jiǎn)單的場(chǎng)景某些類實(shí)現(xiàn)了ApiHandler接口它們的handle方法接收一個(gè)MapString, Object參數(shù)返回一個(gè)Map結(jié)果框架自動(dòng)把結(jié)果序列化成JSON。先定義handler接口public interface ApiHandler { MapString, Object handle(MapString, Object params); }然后寫適配器public class ApiHandlerAdapter implements HandlerAdapter { private final ObjectMapper objectMapper new ObjectMapper(); Override public boolean supports(Object handler) { return handler instanceof ApiHandler; } Override public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { ApiHandler apiHandler (ApiHandler) handler; MapString, Object params extractParams(request); MapString, Object result apiHandler.handle(params); response.setContentType(application/json;charsetUTF-8); response.setStatus(HttpServletResponse.SC_OK); objectMapper.writeValue(response.getWriter(), result); return null; } Override public long getLastModified(HttpServletRequest request, Object handler) { return -1; } private MapString, Object extractParams(HttpServletRequest request) { MapString, Object params new HashMap(); EnumerationString names request.getParameterNames(); while (names.hasMoreElements()) { String name names.nextElement(); params.put(name, request.getParameter(name)); } return params; } }這個(gè)適配器做了三件事從請(qǐng)求里提取參數(shù)、調(diào)用handler、把結(jié)果寫成JSON。返回null的ModelAndView告訴DispatcherServlet不需要渲染視圖。4.3 注冊(cè)適配器到Spring MVC注冊(cè)方式取決于你的配置方式。如果是Java ConfigConfiguration EnableWebMvc public class WebConfig implements WebMvcConfigurer { Override public void addArgumentResolvers(ListHandlerMethodArgumentResolver resolvers) { // 參數(shù)解析器擴(kuò)展 } Bean public ApiHandlerAdapter apiHandlerAdapter() { return new ApiHandlerAdapter(); } }但這里有個(gè)坑Bean注冊(cè)的HandlerAdapter會(huì)被加到默認(rèn)適配器列表里但順序不確定。如果你想確保它在特定位置需要更精細(xì)的控制。更可靠的方式是重寫requestMappingHandlerAdapter的配置或者直接操作RequestMappingHandlerMapping。實(shí)際上Spring MVC的適配器列表是在DispatcherServlet.initHandlerAdapters里初始化的它會(huì)從容器里拿所有HandlerAdapter類型的Bean然后按Order排序。所以給自定義適配器加Order注解可以控制順序Bean Order(0) public ApiHandlerAdapter apiHandlerAdapter() { return new ApiHandlerAdapter(); }4.4 讓自定義handler被HandlerMapping發(fā)現(xiàn)光有適配器還不夠DispatcherServlet得先通過(guò)HandlerMapping找到你的handler。默認(rèn)的RequestMappingHandlerMapping只認(rèn)Controller和RequestMapping。要讓ApiHandler被識(shí)別需要自定義HandlerMappingpublic class ApiHandlerMapping extends AbstractHandlerMapping { private final MapString, ApiHandler handlerMap new HashMap(); public void registerHandler(String path, ApiHandler handler) { handlerMap.put(path, handler); } Override protected Object getHandlerInternal(HttpServletRequest request) throws Exception { String path request.getRequestURI(); return handlerMap.get(path); } }然后在配置里注冊(cè)這個(gè)HandlerMapping。注意HandlerMapping和HandlerAdapter是配套的HandlerMapping負(fù)責(zé)找到handlerHandlerAdapter負(fù)責(zé)執(zhí)行handler。兩者通過(guò)handler對(duì)象關(guān)聯(lián)但彼此不知道對(duì)方的存在這是Spring MVC解耦的關(guān)鍵。4.5 參數(shù)提取的健壯性處理上面extractParams的實(shí)現(xiàn)很粗糙只處理了query參數(shù)。實(shí)際項(xiàng)目中要考慮POST請(qǐng)求的body解析JSON、form-data文件上傳字符編碼參數(shù)類型轉(zhuǎn)換如果這些都要自己寫工作量不小。這也是為什么大部分場(chǎng)景下直接用RequestMapping更劃算——Spring已經(jīng)幫你處理好了所有這些細(xì)節(jié)。自定義適配器的價(jià)值在于特殊場(chǎng)景的定制不是重新造輪子。實(shí)操心得寫自定義適配器時(shí)參數(shù)提取和結(jié)果序列化這兩塊最容易出問(wèn)題。建議先用最簡(jiǎn)單的實(shí)現(xiàn)跑通流程再逐步增加復(fù)雜度。不要一上來(lái)就想著支持所有Content-Type先把a(bǔ)pplication/json和application/x-www-form-urlencoded搞定覆蓋80%的場(chǎng)景。5. 常見問(wèn)題與排查技巧實(shí)錄5.1 參數(shù)綁定失敗從異常棧定位到解析器參數(shù)綁定失敗是最高頻的問(wèn)題。典型異常是MissingServletRequestParameterException、MethodArgumentTypeMismatchException、HttpMessageNotReadableException。排查思路是看異常類型確定是哪個(gè)解析器拋的看異常信息里的參數(shù)名確認(rèn)是哪個(gè)參數(shù)檢查請(qǐng)求實(shí)際發(fā)送的內(nèi)容用抓包工具或日志對(duì)照解析器的supportsParameter邏輯判斷為什么匹配到了這個(gè)解析器比如HttpMessageNotReadableException通常是RequestResponseBodyMethodProcessor拋的說(shuō)明RequestBody的JSON解析失敗。原因可能是請(qǐng)求體為空、JSON格式錯(cuò)誤、目標(biāo)類型沒(méi)有默認(rèn)構(gòu)造函數(shù)、字段類型不匹配。這時(shí)候打開DEBUG日志看Jackson的具體報(bào)錯(cuò)信息比看異常棧有用得多。5.2 返回值處理異常ResponseBody的坑ResponseBody返回對(duì)象時(shí)如果序列化失敗會(huì)拋HttpMessageNotWritableException。常見原因?qū)ο罄镉醒h(huán)引用比如雙向關(guān)聯(lián)的實(shí)體對(duì)象里有無(wú)法序列化的類型比如InputStream返回的是null但配置了不允許null循環(huán)引用是最隱蔽的。比如Order里有ListOrderItemOrderItem里又有Order的引用Jackson序列化時(shí)會(huì)無(wú)限遞歸。解決辦法是用JsonIgnore或者JsonManagedReference/JsonBackReference。5.3 適配器不生效supports返回false的排查自定義適配器不生效第一步是確認(rèn)supports有沒(méi)有被調(diào)用。可以在supports里打日志看請(qǐng)求進(jìn)來(lái)時(shí)有沒(méi)有打印。如果沒(méi)有說(shuō)明HandlerMapping沒(méi)找到你的handler或者h(yuǎn)andler類型不對(duì)。如果有打印但返回false檢查instanceof判斷。還有一種情況適配器被調(diào)用了但用的是別的適配器。這時(shí)候看DispatcherServlet的DEBUG日志它會(huì)打印Using handler adapter [xxx]。如果用的是內(nèi)置適配器說(shuō)明你的handler被內(nèi)置適配器先匹配上了。5.4 常見問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方向405 Method Not AllowedcheckRequest校驗(yàn)失敗檢查RequestMapping的method配置415 Unsupported Media TypeContent-Type不匹配檢查consumes配置和請(qǐng)求頭400 Bad Request參數(shù)綁定失敗看異常類型定位解析器500 序列化異常返回值無(wú)法序列化檢查循環(huán)引用、null值自定義適配器不生效supports返回false或順序問(wèn)題打日志確認(rèn)調(diào)用鏈靜態(tài)資源404ResourceHttpRequestHandler未匹配檢查資源路徑配置5.5 獨(dú)家避坑技巧第一個(gè)技巧調(diào)試適配器問(wèn)題時(shí)把org.springframework.web.servlet.DispatcherServlet的日志級(jí)別調(diào)到DEBUG它會(huì)打印handler、adapter、interceptor的完整匹配過(guò)程。這比斷點(diǎn)調(diào)試高效得多。第二個(gè)技巧RequestMappingHandlerAdapter的argumentResolvers和returnValueHandlers是可以通過(guò)Bean覆蓋的。如果你需要全局修改參數(shù)解析行為不要改源碼直接提供一個(gè)自定義的RequestMappingHandlerAdapterBean設(shè)置你自己的解析器列表。第三個(gè)技巧ControllerAdvice配合ExceptionHandler能處理大部分異常但有些異常在適配器層面就拋出了還沒(méi)到Controller。比如HttpRequestMethodNotSupportedException它是在checkRequest里拋的ExceptionHandler能捕獲但如果你自定義了適配器要確保異常能正常傳播出去。第四個(gè)技巧getLastModified返回-1表示不支持緩存返回具體時(shí)間戳表示支持。如果你做的是內(nèi)容型接口實(shí)現(xiàn)這個(gè)方法能顯著降低服務(wù)器壓力。但要注意時(shí)間戳的精度是秒級(jí)如果內(nèi)容變化頻繁緩存反而會(huì)導(dǎo)致數(shù)據(jù)不一致。6. 從適配器看Spring MVC的擴(kuò)展哲學(xué)HandlerAdapter這個(gè)接口只有三個(gè)方法但它體現(xiàn)了Spring框架一以貫之的設(shè)計(jì)哲學(xué)面向接口編程、職責(zé)單一、通過(guò)組合而非繼承實(shí)現(xiàn)擴(kuò)展。DispatcherServlet不關(guān)心handler是什么只關(guān)心有沒(méi)有適配器能處理它適配器不關(guān)心請(qǐng)求怎么來(lái)的只關(guān)心怎么調(diào)用handlerhandler不關(guān)心框架怎么運(yùn)作只關(guān)心我的業(yè)務(wù)邏輯。這種分層讓每一層都可以獨(dú)立演化。你可以換掉HandlerMapping而不影響適配器可以新增適配器而不影響DispatcherServlet可以自定義handler而不影響其他組件。理解了這一點(diǎn)再看Spring MVC的其他組件——ViewResolver、HandlerExceptionResolver、MultipartResolver——會(huì)發(fā)現(xiàn)它們都是同一個(gè)套路的產(chǎn)物。我在實(shí)際項(xiàng)目中做過(guò)一次比較激進(jìn)的改造把RequestMappingHandlerAdapter替換成了一個(gè)自定義實(shí)現(xiàn)在invokeHandlerMethod之前插入了統(tǒng)一的參數(shù)校驗(yàn)和日志記錄。改造過(guò)程比想象中順利因?yàn)檫m配器的邊界非常清晰只要保證handle方法的輸入輸出契約不變內(nèi)部怎么改都不會(huì)影響其他組件。這種可替換性正是良好抽象的價(jià)值所在。如果你正在維護(hù)一個(gè)中大型的Spring MVC項(xiàng)目建議花半天時(shí)間把DispatcherServlet、HandlerMapping、HandlerAdapter這三者的協(xié)作關(guān)系畫一遍。不需要畫得多漂亮關(guān)鍵是理清請(qǐng)求進(jìn)來(lái)之后每一步是誰(shuí)在處理、處理完交給誰(shuí)。理清之后再遇到路由、參數(shù)、返回值相關(guān)的問(wèn)題定位速度會(huì)快一個(gè)數(shù)量級(jí)。 Spring MVC HandlerAdapter 源碼解析與自定義適配器實(shí)戰(zhàn)
1. 為什么值得花時(shí)間啃透HandlerAdapter很多人第一次翻Spring MVC源碼都是從DispatcherServlet的doDispatch方法開始的。那段代碼里有一行特別不起眼但極其關(guān)鍵的調(diào)用mappedHandler getHandler(processedRequest)拿到HandlerExecutionChain之后緊接著就是HandlerAdapter ha getHandlerAdapter(mappedHandler.getHandler())。絕大多數(shù)人掃一眼就過(guò)去了覺得無(wú)非是找個(gè)適配器來(lái)執(zhí)行handler。但真正在項(xiàng)目里踩過(guò)坑的人都清楚Spring MVC最靈活、最容易出問(wèn)題、也最能體現(xiàn)框架設(shè)計(jì)功力的地方恰恰就在這個(gè)接口上。你寫的RequestMapping方法能被執(zhí)行、ResponseBody能自動(dòng)轉(zhuǎn)JSON、HttpEntity參數(shù)能自動(dòng)綁定、ResponseEntity能自動(dòng)處理狀態(tài)碼背后全是HandlerAdapter在干活。這篇文章不打算復(fù)述官方文檔而是從一個(gè)實(shí)際維護(hù)過(guò)多個(gè)Spring MVC定制化項(xiàng)目的開發(fā)者視角把HandlerAdapter這個(gè)接口從設(shè)計(jì)動(dòng)機(jī)、源碼實(shí)現(xiàn)、擴(kuò)展點(diǎn)到實(shí)戰(zhàn)踩坑完整地拆一遍。適合已經(jīng)用過(guò)Spring MVC、能寫Controller、但想搞清楚請(qǐng)求到底是怎么被路由到我的方法上的中高級(jí)開發(fā)者?？赐曛竽銘?yīng)該能自己寫一個(gè)自定義的HandlerAdapter也能在遇到參數(shù)綁定失敗返回值處理異常這類問(wèn)題時(shí)快速定位到是哪一環(huán)出了問(wèn)題。2. HandlerAdapter接口的整體設(shè)計(jì)與思路拆解2.1 從DispatcherServlet的視角看適配器模式要理解HandlerAdapter得先理解DispatcherServlet的困境。作為一個(gè)前端控制器它需要處理各種各樣的處理器有Controller注解的普通Bean、有實(shí)現(xiàn)了Controller接口的老式Bean、有HttpRequestHandler、還有RequestMapping標(biāo)注的方法。這些處理器的調(diào)用方式完全不同——有的需要反射調(diào)用方法有的直接調(diào)handleRequest有的還要處理參數(shù)解析和返回值。如果DispatcherServlet里寫一堆if-else判斷類型再分別調(diào)用代碼會(huì)爛到無(wú)法維護(hù)。所以Spring用了適配器模式DispatcherServlet只認(rèn)HandlerAdapter接口所有具體的調(diào)用邏輯封裝在各自的適配器實(shí)現(xiàn)里。這樣新增一種處理器類型只需要新增一個(gè)適配器DispatcherServlet一行都不用改。這個(gè)設(shè)計(jì)思路在Spring里反復(fù)出現(xiàn)但HandlerAdapter是最典型的一個(gè)。它的接口定義極其簡(jiǎn)潔public interface HandlerAdapter { boolean supports(Object handler); ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception; long getLastModified(HttpServletRequest request, Object handler); }三個(gè)方法各司其職。supports負(fù)責(zé)判斷這個(gè)適配器能不能處理當(dāng)前handlerhandle負(fù)責(zé)真正的執(zhí)行g(shù)etLastModified用于處理HTTP緩存?？雌饋?lái)簡(jiǎn)單但每個(gè)方法背后都有講究。2.2 supports方法的判斷邏輯與性能考量supports方法看似只是類型判斷但它的調(diào)用時(shí)機(jī)很關(guān)鍵。在DispatcherServlet.getHandlerAdapter里是遍歷所有已注冊(cè)的HandlerAdapter逐個(gè)調(diào)用supports第一個(gè)返回true的就用它。這意味著適配器的注冊(cè)順序會(huì)影響匹配結(jié)果如果有多個(gè)適配器都支持同一個(gè)handler先注冊(cè)的勝出supports會(huì)被頻繁調(diào)用實(shí)現(xiàn)必須足夠輕量判斷邏輯要精確不能出現(xiàn)誤判導(dǎo)致用錯(cuò)適配器以RequestMappingHandlerAdapter為例它的supports實(shí)現(xiàn)是Override public boolean supports(Object handler) { return handler instanceof HandlerMethod; }就一行instanceof非常輕。而HttpRequestHandlerAdapter的判斷是handler instanceof HttpRequestHandler。這種設(shè)計(jì)保證了即使注冊(cè)了七八個(gè)適配器每次匹配的開銷也可以忽略不計(jì)。注意如果你自己寫適配器supports里千萬(wàn)不要做數(shù)據(jù)庫(kù)查詢、反射掃描這類重操作否則每個(gè)請(qǐng)求都會(huì)付出代價(jià)。2.3 handle方法的返回值設(shè)計(jì)為什么是ModelAndViewhandle方法返回ModelAndView這個(gè)設(shè)計(jì)經(jīng)常被吐槽過(guò)時(shí)因?yàn)楝F(xiàn)在大部分接口都是返回JSON。但理解這個(gè)設(shè)計(jì)要回到Spring MVC的早期定位它首先是一個(gè)MVC框架視圖渲染是核心職責(zé)。ModelAndView承載了模型數(shù)據(jù)視圖名這兩個(gè)渲染必需的信息。那返回JSON的接口怎么辦答案是返回null。RequestResponseBodyMethodProcessor在處理ResponseBody時(shí)會(huì)直接把數(shù)據(jù)寫進(jìn)response的output stream然后返回null的ModelAndView。DispatcherServlet拿到null之后就知道響應(yīng)已經(jīng)處理完了不需要渲染視圖直接走processDispatchResult的后續(xù)邏輯。這個(gè)設(shè)計(jì)其實(shí)很巧妙用一個(gè)統(tǒng)一的返回值類型同時(shí)支持了視圖渲染和直接寫響應(yīng)兩種模式。代價(jià)是null的語(yǔ)義不夠明確讀源碼時(shí)容易困惑。2.4 getLastModified與HTTP緩存的關(guān)聯(lián)getLastModified是三個(gè)方法里最容易被忽略的。它對(duì)應(yīng)HTTP協(xié)議里的Last-Modified頭用于協(xié)商緩存。如果handler實(shí)現(xiàn)了LastModified接口適配器會(huì)返回其getLastModified值DispatcherServlet會(huì)據(jù)此判斷是否返回304。大部分現(xiàn)代項(xiàng)目用ETag或者干脆不做緩存所以這個(gè)方法經(jīng)常返回-1表示不支持。但如果你做的是內(nèi)容型網(wǎng)站靜態(tài)資源或者變化不頻繁的頁(yè)面用好這個(gè)方法能顯著降低帶寬。HttpRequestHandlerAdapter就完整實(shí)現(xiàn)了這個(gè)邏輯因?yàn)樗幚淼腍ttpRequestHandler本身就繼承了LastModified接口。3. 核心實(shí)現(xiàn)類的源碼細(xì)節(jié)與實(shí)操要點(diǎn)3.1 RequestMappingHandlerAdapter最核心也最復(fù)雜RequestMappingHandlerAdapter是日常開發(fā)中99%的請(qǐng)求最終會(huì)走到的適配器。它的handle方法核心邏輯是Override protected ModelAndView handleInternal(HttpServletRequest request, HttpServletResponse response, HandlerMethod handlerMethod) throws Exception { ModelAndView mav; checkRequest(request); if (this.synchronizeOnSession) { HttpSession session request.getSession(false); if (session ! null) { Object mutex WebUtils.getSessionMutex(session); synchronized (mutex) { mav invokeHandlerMethod(request, response, handlerMethod); } } else { mav invokeHandlerMethod(request, response, handlerMethod); } } else { mav invokeHandlerMethod(request, response, handlerMethod); } if (!response.containsHeader(HEADER_CACHE_CONTROL)) { if (getSessionAttributesHandler(handlerMethod).hasSessionAttributes()) { applyCacheSeconds(response, this.cacheSecondsForSessionAttributeHandlers); } else { prepareResponse(response); } } return mav; }這段代碼里有幾個(gè)關(guān)鍵點(diǎn)值得展開。第一是checkRequest它會(huì)校驗(yàn)請(qǐng)求方法是否被支持。如果你在RequestMapping里限定了method RequestMethod.POST但用GET請(qǐng)求訪問(wèn)就會(huì)在這里拋出HttpRequestMethodNotSupportedException。這個(gè)異常最終會(huì)被DefaultHandlerExceptionResolver處理成405響應(yīng)。第二是session同步邏輯。synchronizeOnSession默認(rèn)是false如果開啟同一個(gè)session的請(qǐng)求會(huì)串行執(zhí)行。這個(gè)特性在早期處理并發(fā)問(wèn)題時(shí)用過(guò)但現(xiàn)在基本不推薦——它會(huì)嚴(yán)重拖累性能而且用session鎖解決并發(fā)本身就是個(gè)壞味道。第三是緩存頭的處理。prepareResponse會(huì)根據(jù)配置設(shè)置Cache-Control頭。默認(rèn)情況下如果沒(méi)有顯式配置Spring不會(huì)設(shè)置任何緩存頭這也是為什么很多接口在瀏覽器里默認(rèn)不緩存。3.2 invokeHandlerMethod的參數(shù)解析鏈路invokeHandlerMethod是整個(gè)適配器最核心的方法它要完成參數(shù)解析、方法調(diào)用、返回值處理三件事。參數(shù)解析依賴HandlerMethodArgumentResolver鏈返回值處理依賴HandlerMethodReturnValueHandler鏈。ServletInvocableHandlerMethod invocableMethod createInvocableHandlerMethod(handlerMethod); if (this.argumentResolvers ! null) { invocableMethod.setHandlerMethodArgumentResolvers(this.argumentResolvers); } if (this.returnValueHandlers ! null) { invocableMethod.setHandlerMethodReturnValueHandlers(this.returnValueHandlers); } invocableMethod.invokeAndHandle(webRequest, mavContainer);argumentResolvers和returnValueHandlers是在afterPropertiesSet里初始化的默認(rèn)會(huì)加載一長(zhǎng)串解析器。這個(gè)順序非常重要因?yàn)榻馕銎饕彩堑谝粋€(gè)支持的就用。默認(rèn)的參數(shù)解析器順序大致是RequestParamMethodArgumentResolver、RequestParamMapMethodArgumentResolver、PathVariableMethodArgumentResolver、ServletModelAttributeMethodProcessor、RequestResponseBodyMethodProcessor等等。如果你自定義了一個(gè)解析器想讓它優(yōu)先于內(nèi)置的必須通過(guò)setArgumentResolvers或者setCustomArgumentResolvers調(diào)整順序。實(shí)操心得自定義參數(shù)解析器時(shí)最常見的坑是我的解析器沒(méi)生效。90%的情況是因?yàn)閮?nèi)置解析器先匹配上了。比如你想解析一個(gè)自定義注解標(biāo)注的參數(shù)但參數(shù)類型是StringRequestParamMethodArgumentResolver可能會(huì)先把它當(dāng)成普通參數(shù)處理。解決辦法是讓自定義解析器的supportsParameter判斷更精確或者用setCustomArgumentResolvers確保優(yōu)先級(jí)。3.3 SimpleControllerHandlerAdapter與老式ControllerSimpleControllerHandlerAdapter處理的是實(shí)現(xiàn)了Controller接口的Bean。它的handle方法簡(jiǎn)單到極致Override public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { return ((Controller) handler).handleRequest(request, response); }這種老式寫法現(xiàn)在幾乎沒(méi)人用了但在一些遺留系統(tǒng)里還能見到。它的優(yōu)勢(shì)是簡(jiǎn)單直接沒(méi)有反射開銷劣勢(shì)是每個(gè)Controller只能處理一個(gè)URL而且參數(shù)綁定要自己寫。如果你在維護(hù)老項(xiàng)目看到這種寫法不要驚訝它和Controller是可以共存的因?yàn)閮蓚€(gè)適配器都注冊(cè)了各管各的。3.4 HttpRequestHandlerAdapter與靜態(tài)資源處理HttpRequestHandlerAdapter處理HttpRequestHandler最典型的應(yīng)用是ResourceHttpRequestHandler——也就是Spring MVC處理靜態(tài)資源的機(jī)制。當(dāng)你配置了mvc:resources或者addResourceHandlers請(qǐng)求靜態(tài)文件時(shí)走的就是這個(gè)適配器。它的handle方法會(huì)調(diào)用handler.handleRequest而ResourceHttpRequestHandler會(huì)去查找資源文件、設(shè)置Content-Type、處理Last-Modified和ETag、支持Range請(qǐng)求。這也是為什么Spring MVC處理靜態(tài)資源的性能其實(shí)不差——它做了完整的HTTP緩存協(xié)商。3.5 適配器的注冊(cè)與初始化順序在WebMvcConfigurationSupport里默認(rèn)適配器的注冊(cè)順序是Bean public HandlerAdapter requestMappingHandlerAdapter() { ... } Bean public HandlerAdapter httpRequestHandlerAdapter() { ... } Bean public HandlerAdapter simpleControllerHandlerAdapter() { ... }注意requestMappingHandlerAdapter排在最前面。這個(gè)順序決定了當(dāng)handler同時(shí)滿足多個(gè)適配器的supports時(shí)優(yōu)先用哪個(gè)。實(shí)際上HandlerMethod只被RequestMappingHandlerAdapter支持所以順序影響不大但理解這個(gè)機(jī)制對(duì)自定義適配器很重要。4. 自定義HandlerAdapter的完整實(shí)操過(guò)程4.1 什么場(chǎng)景下需要自定義適配器大部分項(xiàng)目一輩子都不需要自定義HandlerAdapter。但以下幾種場(chǎng)景自定義是合理的你有一套自己的處理器抽象比如基于注解的RPC方法想復(fù)用Spring MVC的請(qǐng)求分發(fā)機(jī)制你想對(duì)特定類型的handler做統(tǒng)一的預(yù)處理比如統(tǒng)一的日志、鑒權(quán)、限流你在做框架層面的擴(kuò)展比如實(shí)現(xiàn)一個(gè)輕量級(jí)的API網(wǎng)關(guān)需要強(qiáng)調(diào)的是如果你的需求只是在Controller執(zhí)行前后做點(diǎn)事用HandlerInterceptor就夠了不要上適配器。適配器的粒度更粗它是如何調(diào)用handler層面的擴(kuò)展不是調(diào)用前后層面的。4.2 定義自定義handler與適配器假設(shè)我們要實(shí)現(xiàn)一個(gè)簡(jiǎn)單的場(chǎng)景某些類實(shí)現(xiàn)了ApiHandler接口它們的handle方法接收一個(gè)MapString, Object參數(shù)返回一個(gè)Map結(jié)果框架自動(dòng)把結(jié)果序列化成JSON。先定義handler接口public interface ApiHandler { MapString, Object handle(MapString, Object params); }然后寫適配器public class ApiHandlerAdapter implements HandlerAdapter { private final ObjectMapper objectMapper new ObjectMapper(); Override public boolean supports(Object handler) { return handler instanceof ApiHandler; } Override public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { ApiHandler apiHandler (ApiHandler) handler; MapString, Object params extractParams(request); MapString, Object result apiHandler.handle(params); response.setContentType(application/json;charsetUTF-8); response.setStatus(HttpServletResponse.SC_OK); objectMapper.writeValue(response.getWriter(), result); return null; } Override public long getLastModified(HttpServletRequest request, Object handler) { return -1; } private MapString, Object extractParams(HttpServletRequest request) { MapString, Object params new HashMap(); EnumerationString names request.getParameterNames(); while (names.hasMoreElements()) { String name names.nextElement(); params.put(name, request.getParameter(name)); } return params; } }這個(gè)適配器做了三件事從請(qǐng)求里提取參數(shù)、調(diào)用handler、把結(jié)果寫成JSON。返回null的ModelAndView告訴DispatcherServlet不需要渲染視圖。4.3 注冊(cè)適配器到Spring MVC注冊(cè)方式取決于你的配置方式。如果是Java ConfigConfiguration EnableWebMvc public class WebConfig implements WebMvcConfigurer { Override public void addArgumentResolvers(ListHandlerMethodArgumentResolver resolvers) { // 參數(shù)解析器擴(kuò)展 } Bean public ApiHandlerAdapter apiHandlerAdapter() { return new ApiHandlerAdapter(); } }但這里有個(gè)坑Bean注冊(cè)的HandlerAdapter會(huì)被加到默認(rèn)適配器列表里但順序不確定。如果你想確保它在特定位置需要更精細(xì)的控制。更可靠的方式是重寫requestMappingHandlerAdapter的配置或者直接操作RequestMappingHandlerMapping。實(shí)際上Spring MVC的適配器列表是在DispatcherServlet.initHandlerAdapters里初始化的它會(huì)從容器里拿所有HandlerAdapter類型的Bean然后按Order排序。所以給自定義適配器加Order注解可以控制順序Bean Order(0) public ApiHandlerAdapter apiHandlerAdapter() { return new ApiHandlerAdapter(); }4.4 讓自定義handler被HandlerMapping發(fā)現(xiàn)光有適配器還不夠DispatcherServlet得先通過(guò)HandlerMapping找到你的handler。默認(rèn)的RequestMappingHandlerMapping只認(rèn)Controller和RequestMapping。要讓ApiHandler被識(shí)別需要自定義HandlerMappingpublic class ApiHandlerMapping extends AbstractHandlerMapping { private final MapString, ApiHandler handlerMap new HashMap(); public void registerHandler(String path, ApiHandler handler) { handlerMap.put(path, handler); } Override protected Object getHandlerInternal(HttpServletRequest request) throws Exception { String path request.getRequestURI(); return handlerMap.get(path); } }然后在配置里注冊(cè)這個(gè)HandlerMapping。注意HandlerMapping和HandlerAdapter是配套的HandlerMapping負(fù)責(zé)找到handlerHandlerAdapter負(fù)責(zé)執(zhí)行handler。兩者通過(guò)handler對(duì)象關(guān)聯(lián)但彼此不知道對(duì)方的存在這是Spring MVC解耦的關(guān)鍵。4.5 參數(shù)提取的健壯性處理上面extractParams的實(shí)現(xiàn)很粗糙只處理了query參數(shù)。實(shí)際項(xiàng)目中要考慮POST請(qǐng)求的body解析JSON、form-data文件上傳字符編碼參數(shù)類型轉(zhuǎn)換如果這些都要自己寫工作量不小。這也是為什么大部分場(chǎng)景下直接用RequestMapping更劃算——Spring已經(jīng)幫你處理好了所有這些細(xì)節(jié)。自定義適配器的價(jià)值在于特殊場(chǎng)景的定制不是重新造輪子。實(shí)操心得寫自定義適配器時(shí)參數(shù)提取和結(jié)果序列化這兩塊最容易出問(wèn)題。建議先用最簡(jiǎn)單的實(shí)現(xiàn)跑通流程再逐步增加復(fù)雜度。不要一上來(lái)就想著支持所有Content-Type先把a(bǔ)pplication/json和application/x-www-form-urlencoded搞定覆蓋80%的場(chǎng)景。5. 常見問(wèn)題與排查技巧實(shí)錄5.1 參數(shù)綁定失敗從異常棧定位到解析器參數(shù)綁定失敗是最高頻的問(wèn)題。典型異常是MissingServletRequestParameterException、MethodArgumentTypeMismatchException、HttpMessageNotReadableException。排查思路是看異常類型確定是哪個(gè)解析器拋的看異常信息里的參數(shù)名確認(rèn)是哪個(gè)參數(shù)檢查請(qǐng)求實(shí)際發(fā)送的內(nèi)容用抓包工具或日志對(duì)照解析器的supportsParameter邏輯判斷為什么匹配到了這個(gè)解析器比如HttpMessageNotReadableException通常是RequestResponseBodyMethodProcessor拋的說(shuō)明RequestBody的JSON解析失敗。原因可能是請(qǐng)求體為空、JSON格式錯(cuò)誤、目標(biāo)類型沒(méi)有默認(rèn)構(gòu)造函數(shù)、字段類型不匹配。這時(shí)候打開DEBUG日志看Jackson的具體報(bào)錯(cuò)信息比看異常棧有用得多。5.2 返回值處理異常ResponseBody的坑ResponseBody返回對(duì)象時(shí)如果序列化失敗會(huì)拋HttpMessageNotWritableException。常見原因?qū)ο罄镉醒h(huán)引用比如雙向關(guān)聯(lián)的實(shí)體對(duì)象里有無(wú)法序列化的類型比如InputStream返回的是null但配置了不允許null循環(huán)引用是最隱蔽的。比如Order里有ListOrderItemOrderItem里又有Order的引用Jackson序列化時(shí)會(huì)無(wú)限遞歸。解決辦法是用JsonIgnore或者JsonManagedReference/JsonBackReference。5.3 適配器不生效supports返回false的排查自定義適配器不生效第一步是確認(rèn)supports有沒(méi)有被調(diào)用。可以在supports里打日志看請(qǐng)求進(jìn)來(lái)時(shí)有沒(méi)有打印。如果沒(méi)有說(shuō)明HandlerMapping沒(méi)找到你的handler或者h(yuǎn)andler類型不對(duì)。如果有打印但返回false檢查instanceof判斷。還有一種情況適配器被調(diào)用了但用的是別的適配器。這時(shí)候看DispatcherServlet的DEBUG日志它會(huì)打印Using handler adapter [xxx]。如果用的是內(nèi)置適配器說(shuō)明你的handler被內(nèi)置適配器先匹配上了。5.4 常見問(wèn)題速查表問(wèn)題現(xiàn)象可能原因排查方向405 Method Not AllowedcheckRequest校驗(yàn)失敗檢查RequestMapping的method配置415 Unsupported Media TypeContent-Type不匹配檢查consumes配置和請(qǐng)求頭400 Bad Request參數(shù)綁定失敗看異常類型定位解析器500 序列化異常返回值無(wú)法序列化檢查循環(huán)引用、null值自定義適配器不生效supports返回false或順序問(wèn)題打日志確認(rèn)調(diào)用鏈靜態(tài)資源404ResourceHttpRequestHandler未匹配檢查資源路徑配置5.5 獨(dú)家避坑技巧第一個(gè)技巧調(diào)試適配器問(wèn)題時(shí)把org.springframework.web.servlet.DispatcherServlet的日志級(jí)別調(diào)到DEBUG它會(huì)打印handler、adapter、interceptor的完整匹配過(guò)程。這比斷點(diǎn)調(diào)試高效得多。第二個(gè)技巧RequestMappingHandlerAdapter的argumentResolvers和returnValueHandlers是可以通過(guò)Bean覆蓋的。如果你需要全局修改參數(shù)解析行為不要改源碼直接提供一個(gè)自定義的RequestMappingHandlerAdapterBean設(shè)置你自己的解析器列表。第三個(gè)技巧ControllerAdvice配合ExceptionHandler能處理大部分異常但有些異常在適配器層面就拋出了還沒(méi)到Controller。比如HttpRequestMethodNotSupportedException它是在checkRequest里拋的ExceptionHandler能捕獲但如果你自定義了適配器要確保異常能正常傳播出去。第四個(gè)技巧getLastModified返回-1表示不支持緩存返回具體時(shí)間戳表示支持。如果你做的是內(nèi)容型接口實(shí)現(xiàn)這個(gè)方法能顯著降低服務(wù)器壓力。但要注意時(shí)間戳的精度是秒級(jí)如果內(nèi)容變化頻繁緩存反而會(huì)導(dǎo)致數(shù)據(jù)不一致。6. 從適配器看Spring MVC的擴(kuò)展哲學(xué)HandlerAdapter這個(gè)接口只有三個(gè)方法但它體現(xiàn)了Spring框架一以貫之的設(shè)計(jì)哲學(xué)面向接口編程、職責(zé)單一、通過(guò)組合而非繼承實(shí)現(xiàn)擴(kuò)展。DispatcherServlet不關(guān)心handler是什么只關(guān)心有沒(méi)有適配器能處理它適配器不關(guān)心請(qǐng)求怎么來(lái)的只關(guān)心怎么調(diào)用handlerhandler不關(guān)心框架怎么運(yùn)作只關(guān)心我的業(yè)務(wù)邏輯。這種分層讓每一層都可以獨(dú)立演化。你可以換掉HandlerMapping而不影響適配器可以新增適配器而不影響DispatcherServlet可以自定義handler而不影響其他組件。理解了這一點(diǎn)再看Spring MVC的其他組件——ViewResolver、HandlerExceptionResolver、MultipartResolver——會(huì)發(fā)現(xiàn)它們都是同一個(gè)套路的產(chǎn)物。我在實(shí)際項(xiàng)目中做過(guò)一次比較激進(jìn)的改造把RequestMappingHandlerAdapter替換成了一個(gè)自定義實(shí)現(xiàn)在invokeHandlerMethod之前插入了統(tǒng)一的參數(shù)校驗(yàn)和日志記錄。改造過(guò)程比想象中順利因?yàn)檫m配器的邊界非常清晰只要保證handle方法的輸入輸出契約不變內(nèi)部怎么改都不會(huì)影響其他組件。這種可替換性正是良好抽象的價(jià)值所在。如果你正在維護(hù)一個(gè)中大型的Spring MVC項(xiàng)目建議花半天時(shí)間把DispatcherServlet、HandlerMapping、HandlerAdapter這三者的協(xié)作關(guān)系畫一遍。不需要畫得多漂亮關(guān)鍵是理清請(qǐng)求進(jìn)來(lái)之后每一步是誰(shuí)在處理、處理完交給誰(shuí)。理清之后再遇到路由、參數(shù)、返回值相關(guān)的問(wèn)題定位速度會(huì)快一個(gè)數(shù)量級(jí)。