再进去getHandler里边看看呗，里边又有几层，我们最后可以看到它根据路径去匹配，走到了lookupHandlerMethod这么一个方法
protected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception { List<Match> matches = new ArrayList<Match>(); // 获取路径 List<T> directPathMatches = this.mappingRegistry.getMappingsByUrl(lookupPath); // 对匹配的排序，找到最佳匹配的 if (!matches.isEmpty()) { Comparator<Match> comparator = new MatchComparator(getMappingComparator(request)); Collections.sort(matches, comparator); if (logger.isTraceEnabled()) { logger.trace("Found " + matches.size() + " matching mapping(s) for [" + lookupPath + "] : " + matches); } Match bestMatch = matches.get(0); if (matches.size() > 1) { if (CorsUtils.isPreFlightRequest(request)) { return PREFLIGHT_AMBIGUOUS_MATCH; } Match secondBestMatch = matches.get(1); if (comparator.compare(bestMatch, secondBestMatch) == 0) { Method m1 = bestMatch.handlerMethod.getMethod(); Method m2 = secondBestMatch.handlerMethod.getMethod(); throw new IllegalStateException("Ambiguous handler methods mapped for HTTP path '" + request.getRequestURL() + "': {" + m1 + ", " + m2 + "}"); } } handleMatch(bestMatch.mapping, lookupPath, request); return bestMatch.handlerMethod; } else { return handleNoMatch(this.mappingRegistry.getMappings().keySet(), lookupPath, request); } }
找拦截器大概也是上面的一个过程，于是我们就可以顺利拿到HandlerExecutionChain了，找到HandlerExecutionChain后，我们是先去拿对应的HandlerAdaptor。我们也去看看里边做了什么：
// 遍历HandlerAdapter实例，找到个合适的返回 protected HandlerAdapter getHandlerAdapter(Object handler) throws ServletException { for (HandlerAdapter ha : this.handlerAdapters) { if (ha.supports(handler)) { return ha; } } }
我们看一个常用HandlerAdapter实例RequestMappingHandlerAdapter，会发现他会初始化很多的参数解析器，其实我们经常用的@ResponseBody解析器就被内置在里边：
private List<HandlerMethodArgumentResolver> getDefaultArgumentResolvers() { List<HandlerMethodArgumentResolver> resolvers = new ArrayList<HandlerMethodArgumentResolver>(); resolvers.add(new MatrixVariableMethodArgumentResolver()); resolvers.add(new MatrixVariableMapMethodArgumentResolver()); resolvers.add(new ServletModelAttributeMethodProcessor(false)); // ResponseBody Requestbody解析器 resolvers.add(new RequestResponseBodyMethodProcessor(getMessageConverters(), this.requestResponseBodyAdvice)); resolvers.add(new RequestPartMethodArgumentResolver(getMessageConverters(), t // 等等 return resolvers; }
得到HandlerAdaptor后，随之而行的就是拦截器的前置处理，然后就是真实的mv = ha.handle(processedRequest, response, mappedHandler.getHandler())。
这里边嵌套了好几层，我就不一一贴代码了，我们会进入ServletInvocableHandlerMethod#invokeAndHandle方法，我们看一下这里边做了什么：
public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer, Object... providedArgs) throws Exception { // 处理请求 Object returnValue = invokeForRequest(webRequest, mavContainer, providedArgs); setResponseStatus(webRequest); if (returnValue == null) { if (isRequestNotModified(webRequest) || hasResponseStatus() || mavContainer.isRequestHandled()) { mavContainer.setRequestHandled(true); return; } } //.. mavContainer.setRequestHandled(false); try { // 处理返回值 this.returnValueHandlers.handleReturnValue( returnValue, getReturnValueType(returnValue), mavContainer, webRequest); } }
处理请求的方法我们进去看看invokeForRequest
public Object invokeForRequest(NativeWebRequest request, ModelAndViewContainer mavContainer, Object... providedArgs) throws Exception { // 得到参数 Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs); // 调用方法 Object returnValue = doInvoke(args); if (logger.isTraceEnabled()) { logger.trace("Method [" + getMethod().getName() + "] returned [" + returnValue + "]"); } return returnValue; }
我们看看它是怎么处理参数的，getMethodArgumentValues方法进去看看：
private Object[] getMethodArgumentValues(NativeWebRequest request, ModelAndViewContainer mavContainer, Object... providedArgs) throws Exception { // 得到参数 MethodParameter[] parameters = getMethodParameters(); Object[] args = new Object[parameters.length]; for (int i = 0; i < parameters.length; i++) { MethodParameter parameter = parameters[i]; parameter.initParameterNameDiscovery(this.parameterNameDiscoverer); GenericTypeResolver.resolveParameterType(parameter, getBean().getClass()); args[i] = resolveProvidedArgument(parameter, providedArgs); if (args[i] != null) { continue; } // 找到适配的参数解析器 if (this.argumentResolvers.supportsParameter(parameter)) { try { args[i] = this.argumentResolvers.resolveArgument( parameter, mavContainer, request, this.dataBinderFactory); continue; } //..... } return args; }
这些参数解析器实际上在HandlerAdaptor内置的那些，这里不好放代码，所以我截个图吧：
针对于RequestResponseBodyMethodProcessor解析器我们看看里边做了什么：
public Object resolveArgument(MethodParameter parameter, ModelAndViewContainer mavContainer, NativeWebRequest webRequest, WebDataBinderFactory binderFactory) throws Exception { // 通过Converters对参数转换 Object arg = readWithMessageConverters(webRequest, parameter, parameter.getGenericParameterType()); String name = Conventions.getVariableNameForParameter(parameter); WebDataBinder binder = binderFactory.createBinder(webRequest, arg, name); // ... mavContainer.addAttribute(BindingResult.MODEL_KEY_PREFIX + name, binder.getBindingResult()); return arg; }
再进去readWithMessageConverters里边看看：
protected <T> Object readWithMessageConverters(HttpInputMessage inputMessage, MethodParameter param, Type targetType) throws IOException, HttpMediaTypeNotSupportedException, HttpMessageNotReadableException { // ...处理请求头 try { inputMessage = new EmptyBodyCheckingHttpInputMessage(inputMessage); // HttpMessageConverter实例去对参数转换 for (HttpMessageConverter<?> converter : this.messageConverters) { Class<HttpMessageConverter<?>> converterType = (Class<HttpMessageConverter<?>>) converter.getClass(); if (converter instanceof GenericHttpMessageConverter) { GenericHttpMessageConverter<?> genericConverter = (GenericHttpMessageConverter<?>) converter; if (genericConverter.canRead(targetType, contextClass, contentType)) { if (logger.isDebugEnabled()) { logger.debug("Read [" + targetType + "] as \"" + contentType + "\" with [" + converter + "]"); } if (inputMessage.getBody() != null) { inputMessage = getAdvice().beforeBodyRead(inputMessage, param, targetType, converterType); body = genericConverter.read(targetType, contextClass, inputMessage); body = getAdvice().afterBodyRead(body, inputMessage, param, targetType, converterType); } else { body = null; body = getAdvice().handleEmptyBody(body, inputMessage, param, targetType, converterType); } break; } } //...各种判断 return body; }
看到这里，有没有看不懂，想要退出的感觉了？？别慌，三歪带你们看看这份熟悉的配置：
<!-- 启动JSON返回格式 --> <bean class="org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter"> <property name="messageConverters"> <list> <ref bean="jacksonMessageConverter" /> </list> </property> </bean> <bean id="jacksonMessageConverter" class="org.springframework.http.converter.json.MappingJackson2HttpMessageConverter"> <property name="supportedMediaTypes"> <list> <value>text/html;charset=UTF-8</value> <value>application/json;charset=UTF-8</value> <value>application/x-www-form-urlencoded;charset=UTF-8</value> </list> </property> <property name="objectMapper" ref="jacksonObjectMapper" /> </bean> <bean id="jacksonObjectMapper" class="com.fasterxml.jackson.databind.ObjectMapper" />
我们在SpringMVC想要使用@ResponseBody返回JSON格式都会在配置文件上配置上面的配置，RequestMappingHandlerAdapter这个适配器就是上面所说的那个，内置了RequestResponseBodyMethodProcessor解析器，然后MappingJackson2HttpMessageConverter实际上就是HttpMessageConverter接口的实例
然后在返回的时候也经过HttpMessageConverter去将参数转换后，写给HTTP响应报文。转换的流程大致如图所示：
视图解析器后面就不贴了，大概的流程就如上面的源码，我再画个图来加深一下理解吧：
最后
SpringMVC我们使用的时候非常简便，在内部实际上帮我们做了很多(有各种的HandlerAdaptor)，SpringMVC的请求流程面试的时候还是面得很多的，还是可以看看源码它帮我们做了什么，过一遍可能会发现自己能看懂以前的配置了。
现在已经工作有一段时间了，为什么还来写SpringMVC呢，原因有以下几个：
- 我是一个对排版有追求的人，如果早期关注我的同学可能会发现，我的GitHub、文章导航的
read.me会经常更换。现在的GitHub导航也不合我心意了（太长了），并且早期的文章，说实话排版也不太行，我决定重新搞一波。 - 我的文章会分发好几个平台，但文章发完了可能就没人看了，并且图床很可能因为平台的防盗链就挂掉了。又因为有很多的读者问我：”你能不能把你的文章转成PDF啊？“
- 我写过很多系列级的文章，这些文章就几乎不会有太大的改动了，就非常适合把它们给”持久化“。
基于上面的原因，我决定把我的系列文章汇总成一个PDF/HTML/WORD/epub文档。
