[SpringMVC] HTTP 请求与响应过程底层源码解析

落日映苍穹つ 2022-06-03 05:43 329阅读 0赞

本篇文章主要根据两种常见的错误场景，深入 SpringMVC HTTP 请求与响应过程流程。而整个 SpringMVC HTTP 请求与响应过程涉及的内容远不止于此，如果读者对本文未涉及的内容有兴趣，欢迎与我交流。

提取主要内容如下：

1.  常见的两种错误场景介绍；
2.  HTTP 请求与处理源码解析；
3.  两种错误场景解决方案；
4.  涉及的设计模式介绍。

相关版本:

*  Maven : apache-maven-3.3.9
 *  SpringMVC :4.1.1.RELEASE
 *  Tomcat-Maven-Plugin: 2.2

介绍方式: 代码 + 文字说明 + 源码截图(为减小篇幅，因此源码部分采用截图的方式)。读者阅读时，结合前面列出的流程图/主要操作步骤，再浏览。

> 本文中涉及的代码[下载][Link 1]

## 一、常见的两种错误场景 ##

### 1.场景1 ###

jQuery 以 ajax 方式访问 SpringMVC 接口时，如未显示指定 Content-Type，则会显示 ‘415 (Unsupported Media Type)’ 错误。如:

![415 错误][415]

前端代码片段:

后端接口代码片段为：

@RequestMapping(value = "/save-by-model-2", method = RequestMethod.POST)
    @ResponseBody
    public Category saveByModel2(@RequestBody Category category){ 
        categoryService.save(category);
        return category;
    }

### 2.场景2 ###

SpringMVC 接口定义返回 Json 格式数据时，一般有 **字符串和对象** 两种方式。而相同条件下，返回 Json 格式字符串时，中文会出现乱码。如:

![中文乱码][55bdb610-f047-11e7-bc73-87cf5851ce7a]

前端代码片段:

后端接口片段：

@RequestMapping(value = "/save-by-map", method = RequestMethod.POST)
    @ResponseBody
    public String saveByMap(@RequestBody Map<String, Object> valMap) { 
        categoryService.save(valMap);
        return valMap.toString();
    }
    
    @RequestMapping(value = "/save-by-map-2", method = RequestMethod.POST)
    @ResponseBody
    public Map<String, Object> saveByMap2(@RequestBody Map<String, Object> valMap) { 
        categoryService.save(valMap);
        return valMap;
    }

## 二、HTTP 请求与响应处理源码解析 ##

SpringMVC 中 HTTP 请求处理流程时序图如下:  
![HTTP 请求处理时序图][HTTP]  
从上图可以看出，所有的 HTTP 请求都会进入到 `DispatcherServlet`类的 `doDispatch()` 方法。该方法中的主要工作为:

1.  获取处理执行链对象: `HandlerExecutionChain mappedHandler = getHandler(processedRequest);`
2.  获取处理适配器: `HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());`
3.  调用拦截器的 `preHandle` 方法；
4.  调用具体的接口方法，并返回模型视图对象: `mv = ha.handle(processedRequest, response,mappedHandler.getHandler());`
5.  调用拦截器的 `postHandle` 方法；
6.  处理结果: `processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);` 。

**注：本次源码解析为通过 `@EnableWebMvc` 方式启动，与配置文件方式启动时的源码略有不同(该方式在 Spring 3.2 以后已被弃用)，如 `HandlerMapping, HandlerAdapter` 的实现 。**

接下来深入 SpringMVC 处理 HTTP 请求的过程:

### 1.获取处理执行链对象 ###

**处理执行链类 `HandlerExecutionChain` : 由处理对象 `handler` 和 拦截器列表 `interceptorList` 组成，通过 `HandlerMapping.getHandler()` 方法返回。**

`DispatcherServlet` 类中获取处理链对象的 `getHandler(HttpServletRequest request)` 方法实现为:

![getHandler()][getHandler]

从上图可以看到，框架遍历所有的 `HandlerMapping` 对象，调用对应的 `hm.getHandler(request)` 方法，如果获取的处理执行链对象不为 `null` 则返回该处理执行链对象。

**`HandlerMapping`: 定义请求和处理对象之间的映射关系接口。`HandlerMapping` 列表由 SpringMVC 初始化时寻找所有的 `HandlerMapping` 类组成。**

SpringMVC 中，默认的 `HandlerMapping` 实现有:  
![HandlerMapping][]  
上图 `HandlerMapping` 列表中，`RequestMappingHandlerMapping` 类为 `@Controller` 注解的类中的 **`@RequestMapping` 注解方法**创建 `RequestMappingInfo` 对象。而前面示例中定义的接口方法为 `@RequestMapping` 类型，因此此处取得的 `HandlerMapping` 类为该类。简化的类图如下：

![RequestMappingHandlerMapping][]

`RequestMappingInfo` 封装了 `@RequestMapping` 注解方法相关的状态如下:

![RequestMappingInfo][]

而在`RequestMappingHandlerMapping` 类中获取处理链对象则由父类 `AbstractHandlerMapping` 实现:

![getHandler()][getHandler 1]

**在 `AbstractHandlerMapping` 中，主要操作为2步:**

1.  获取处理器对象；
2.  获取处理执行链。

#### 1.1 获取处理器对象\#\#\#\#\#\# ####

由子类 `AbstractHandlerMethodMapping` 实现:

![getHandlerInternal][]

上图实现中返回的处理器对象类型为处理方法 (`HandlerMethod`)。主要操作为:

1.  调用 `UrlPathHelper` 类从 `request` 中获取请求路径 `lookupPath`；
2.  根据请求路径获取处理方法。

在第2步中，**SpringMVC 会根据 `lookupPath` 作为 key 值从缓存的 `urlMap` 对象中获取 `HandlerMethod` ，如果根据 key 值未获取到对应的数据，则会遍历所有的 `urlMap` 数据列表。**

![lookupHandlerMethod()][lookupHandlerMethod]

**注: `urlMap` 中的数据在 SpringMVC 初始化时填入。**

`addMatchingMappings()` 方法中的实现为:

![addMatchingMappings()][addMatchingMappings]

\*\*由于该机制的存在，如果定义的 `@RequestMapping` 与访问的路径不相等，则框架会遍历所有的 `@RequestMapping` 方法。如果数量很多时，则该部分会消耗较多时间。因此如该部分有性能问题，应尽量使 `@RequestMapping` 路径与访问路径匹配以减少遍历开销。 \*\*

\*\*优化建议:  \*\*

1.  SpringMVC-4.0.3 以后的版本可通过`WebMvcConfigurerAdapter.configurePathMatch(PathMatchConfigurer configurer)` 方法自定义实现 `UrlPathHelper, AntPathMatcher` 优化该问题；
2.  修改 `RequestMappingHandlerMapping` 类中 `UrlPathHelper, AntPathMatcher` 的实现 ([代码参考][Link 1])；
3.  定义 `@RequestMapping` 路径与访问路径一致，如访问路径为 ‘[index.do][]’，则相应的 `@RequestMapping(value = "/index.do")`；
4.  减少单个项目中的 `@RequestMapping` 的数量。

#### 1.2 获取处理执行链 ####

该方法根据传入的处理器对象建立处理执行链，将传入的处理对象和匹配的拦截器添加到处理执行链对象中，并返回：  
!\[获取处理执行链\]\]([http://images.gitbook.cn/c6ed9660-f480-11e7-9976-43dd6592a81a][http_images.gitbook.cn_c6ed9660-f480-11e7-9976-43dd6592a81a])

### 2.获取处理适配器 ###

\*\*`HandlerAdapter`: \*\* MVC 框架的 SPI 接口，允许核心MVC工作流的参数化(这句话不是很懂…有会的读者欢迎指教)。每一种处理请求的处理器类型必须实现该接口，`DispatcherServlet` 类可根据该接口无限扩展，且 `DispatcherServlet` **根据该接口访问所有已安装的处理器对象**。而处理器类型设置为 `Object`，其他的框架不用修改源码就能和 SpringMVC 整合。完整的接口介绍如下：

![HandlerAdapter][]

传入处理器对象，SpringMVC 遍历所有的 `HandlerAdapter` 类，如果某个处理适配器支持该处理器类型，则返回该处理器:

![handlerAdapters][]

`supports(handler)` 接口判断某个具体的处理适配器是否支持传入的处理器对象，定义如下:

![supports()][supports]

在 `RequestMappingHandlerAdapter` 类中，支持的处理器类型为 `HandlerMethod` ：

![supports()][supports 1]

因此此处返回的 `HandlerAdapter` 实现类为：`RequestMappingHandlerAdapter` 。

### 3.调用拦截器的 `preHandle` 方法 ###

调用处理执行链对象的 `applyPreHandle()` 方法，代码如下:

![applyPreHandle()][applyPreHandle]

可以看出框架会遍历在 **第1步：获取处理链对象** 中获取的拦截器对象，依次调用`preHandle()` 方法，如果某次调用返回 `false`，则会调用 `triggerAfterCompletion()` 方法，并返回 `false`。`triggerAfterCompletion()` 实现如下:

![triggerAfterCompletion()][triggerAfterCompletion]

即依次调用拦截器对象的 `afterCompletion()` 方法。

### 4.调用具体的接口方法 ###

调用 **第2步：获取的处理适配器** 对象的 `handle()` 方法处理请求。而 `RequestMappingHandlerAdapter` 类中处理请求的是 `handleInternal()` 方法。方法执行时序图如下：  
![handlerInternal()][handlerInternal]  
从上图中可以看出，框架先创建 `ServletInvocableHandlerMethod` 对象，然后调用该对象的 `invokeAndHandle(webRequest, mavContainer)` 方法，最后获取 `ModelAndView` 对象。具体实现如下：

![invokeHandleMethod()][invokeHandleMethod]

而 `invokeAndHandle()` 方法中，主要操作为:

1.  根据 `request` 解析参数，并调用具体的方法，获取返回值(即调用 `invokeForRequest()` 方法)；
2.  调用返回值处理器处理返回值。

#### 4.1 调用具体的方法 ####

该部分操作步骤为:

1.  解析参数；
2.  根据参数调用具体的方法，并获取返回值；
3.  返回返回值。

解析参数时，会先获取方法定义的所有参数列表，然后根据每个具体的 `MethodParameter` 类型，调用具体的参数解析器类 `HandlerMethodArgumentResolver` 的解析参数方法 `resolveArgument()` 。源码如下：

![getMethodArgumentValues()][getMethodArgumentValues]

此处的 `argumentResolvers` 对象为 `HandlerMethodArgumentResolverComposite` 类，该类封装了一系列的参数解析器，属性如下：

![HandlerMethodArgumentResolverComposite][]

解析时，根据 `HandlerMethodArgumentResolver.supportsParameter(MethodParameter methodParameter)` 判断该参数解析器是否支持该参数。前面参数由于使用的是 `@RequestBody` 注解，因此调用 `RequestResponseBodyMethodProcessor` 类，典型的还有 `@RequestParam, @PathVariable, @RequestHeader` 等：

![HandlerMethodArgumentResolver][]

而 `RequestResponseBodyMethodProcessor` 类处理参数时，使用了 `HttpMessageConverter` 消息转换机制。

##### 4.1.1 `HttpMessageConverter` 消息转换机制 #####

该机制的流程为:

![HttpMessageConverter][]

由于请求的 `content-type` 为 `application/json` 类型，所以此处调用的消息转换类为 `MappingJackson2HttpMessageConverter` ，默认的字符集为 `UTF-8`:

![default-charset][]

而 `read()` 的实现为调用 `Jackson` 的类 `ObjectMapper.readValue()` 方法:

![read()][read]

**注:** 在调用 `read()` 方法之前，如果无匹配的 `HttpMessageConverter` 类，则会抛出 `HttpMediaTypeNotSupportedException` 异常；

在调用 `write()` 方法之前，如果无匹配的 `HttpMessageConverter` 类，则会抛出 `HttpMediaTypeNotAcceptableException` 异常。

**解析完参数后**，则通过反射机制调用具体的方法并获取返回值:

![invoke()][invoke]

#### 4.2 处理返回值 ####

该部分的逻辑和前面解析参数逻辑类似。主要为调用具体的 `HandlerMethodReturnValueHandler` (返回值处理器) 处理返回值。框架中默认的返回值处理器有:

![HandlerMethodReturnValueHandler][]

此处由于使用 `@ResponseBody` 注解，因此调用 `RequestResponseBodyMethodProcessor` 处理器。该处理器中，使用 `HttpMessageConverter` 消息转换机制(见 4.1.1) ，调用 `write()` 方法处理返回值：

![write()][write]

而在调用 `write()` 方法之前，会调用 `getProducibleMediaTypes()` 方法获取可生产的媒体类型，如果用户自定义 `RequestMapping 的 produces` 属性, 则此处会返回该值；如果用户未定义，则根据返回值 `Class` 类型，遍历系统中的消息转换器列表，获取支持的媒体类型列表：

![getProducibleMediaTypes()][getProducibleMediaTypes]

### 5.调用拦截器的 `postHandle` 方法 ###

调用拦截器对象的 `applyPostHandle()` 方法，代码如下：

![applyPostHandle()][applyPostHandle]

从上图可以看出框架会遍历拦截器对象列表，以处理链对象中拦截器对象列表**相反的顺序**调用拦截器对象的 `postHandle()` 方法。

### 6.处理结果 ###

调用 `processDispatchResult()` 方法，实现代码如下:

![processDispatchResult()][processDispatchResult]

这部分处理主要分为如下几部分:

1.  处理异常；
2.  渲染 `ModelAndView` 对象；
3.  调用处理执行链的 `triggerAfterCompletion()` 方法。

#### 6.1 处理异常 ####

如果在前面的处理中抛出了异常，则会获取相应的模型视图对象。有两种处理方式：如果异常对象为 `ModelAndViewDefiningException` 类型，则直接获取模型视图对象；否则的话调用当前系统内的处理异常解析器 ( `HandlerExceptionResolver` ) 处理:

![handlerExceptionResolvers][]

如果某个异常解析器返回了有效的模型视图对象，则跳出循环。

此处的 `ExceptionHandlerExceptionResolver` 类通过用户自定义的 `@ExceptionHandler` 方法解析异常，如果用户未定义，则跳出该解析器。此处示例代码为:

@ExceptionHandler(Exception.class)
    public String handlerException(HttpServletRequest request, HttpServletResponse response, Exception ex) { 
    	System.out.println("handlerException...");
        return "redirect:/error.do";
    }

在该类的 `doResolveHandlerMethodException()` 方法中，会创建一个 `ServletInvocableHandlerMethod` 对象，然后调用该对象的 `invokeAndHandle()` 方法:

![doResolveHandlerMethodException()][doResolveHandlerMethodException]

与前面处理正常 `HandlerMethod` 流程类似，就不深入探讨了。

#### 6.2 渲染 `ModelAndView` 对象 ####

在渲染方法 `render()` 中，如果传入的 mv 对象是 `View` 引用类型，即为 `String` 字符串时，则调用当前的视图解析器 `ViewResolver` 解析该字符串，如当前配置了视图解析器为:

<bean id="viewResolver" class="org.springframework.web.servlet.view.InternalResourceViewResolver">
        <property name="prefix" value="/"/>
        <property name="suffix" value=".html"/>
    </bean>

则该实现会在视图解析器列表 `viewResolvers` 中：  
![viewResolvers][]  
在解析时，将会添加上对应的 `prefix, suffix`, 处理后的 `View` 对象为:  
![View][]  
接下来则调用 `View` 对象的 `render()` 方法，根据提供的 `Model` 对象渲染该视图对象。

#### 6.3 调用处理执行链的 `triggerAfterCompletion()` 方法 ####

该方法只调用在 `preHandle()` 方法中成功调用且返回为 `true` 的拦截器，且从列表后往前调用：

![triggerAfterCompletion()][triggerAfterCompletion 1]

## 三、解决方案 ##

根据前面的原理介绍可知，文章开头的两种场景错误都是由于在 第4步：调用具体的接口方法 出错：场景1为解析参数时出错，场景2为返回值处理时出错。

### 1. 场景1出错原因 ###

见 4.1.1 消息转换机制。场景1中，ajax 请求如果未设置 `Content-Type` 则会使用默认的类型: `application/x-www-form-urlencoded; charset=UTF-8`，而由于接收参数定义为 `@RequestBody`，对应的参数解析器为 `RequestResponseBodyMethodProcessor` 类，调用 `HttpMessagConverter` 消息转换机制。而 SpringMVC 中并无支持该类型的 `HttpMessageConverter` 类，因此抛出异常。

### 2. 场景1解决方案 ###

指定具体的 Content-Type, 如:

$.ajax({ 
        url: url,
        method: 'post',
        contentType: 'application/json', // 解决 415 错误
        data: JSON.stringify(obj), 
        success: function(data) { 
            console.log(data);
        },
        error: function(data) { 
            console.log("error...");
            console.log(data);
        }
    });

### 3. 场景2出错原因 ###

见 4.2 处理返回值。场景2中，定义了 `@ResponseBody` 注解，调用的返回值处理器为 `RequestResponseBodyMethodProcessor`，调用 `HttpMessagConverter` 消息转换机制。返回的 `Class` 类型是 `String`，而在 SpringMVC 的消息转换器列表中支持该返回值类型的消息转换器有 `StringHttpMessageConverter, MappingJackson2HttpMessageConverter` 支持的媒体列表有：

![MediaTypes][]

取得媒体列表后，会选取其中的一个：

![selectMediaType][]

从图中可以看出 String 返回值类型取得的媒体类型为 `text/plain;charset=ISO-8859-1`，且使用 `StringHttpMessageConverter` 消息转换类。将该媒体类型设置为 `response` 的 `contentType`, 因此返回中文乱码：

![Content-Type][]

而 `Category` 类支持的媒体类型只有两种，因此返回值正常：

![MediaTypes][MediaTypes 1]

### 4. 场景2解决方案 ###

在接口上方定义 `produces` ，如:

@RequestMapping(value = "/save-by-map", method = RequestMethod.POST, java produces = "text/plain;charset=utf-8")
    @ResponseBody
    public String saveByMap(@RequestBody Map<String, Object> valMap) { 
        categoryService.save(valMap);
        return valMap.toString();
    }

或者在 springmvc 的配置文件中配置消息转换器的媒体类型，如:

<mvc:annotation-driven >
    	
    	<mvc:message-converters register-defaults="true">
    		<bean class="org.springframework.http.converter.StringHttpMessageConverter">
    			<property name="supportedMediaTypes" value="text/plain;charset=UTF-8"/>
    	   </bean>
    	</mvc:message-converters>
    </mvc:annotation-driven>

## 四、设计模式 ##

本章内容不包括对具体的设计模式原理介绍，只介绍前面框架源码中出现的设计模式的应用场景，如读者对相关的设计模式原理有兴趣，可查看每小节的链接或者自行学习。

前面研究的原理中，涉及的设计模式如下：

### 1.模板方法模式 ###

> [模板方法模式原理][Link 2]

该模式在框架中使用的地方很多，主要作用为: 定义算法的骨架。

如获取处理执行链方法中，`getHandler()` 方法定义了算法的骨架如下：

![getHandler 方法][getHandler 2]

而 `getHandlerInternal()` 则由具体的子类来实现:

![getHandlerInternal 方法][getHandlerInternal 1]

### 2.适配器模式 ###

该模式本质为: (接口不兼容时，通过)转换匹配，(从而)复用功能。

如 `HandlerAdapter` 的实现，可适配所有的处理器类型。是常见的适配器模式实现方式：

![HandlerAdapter][HandlerAdapter 1]

可以看出 `handle()` 方法传入 `handler` 对象，在实现类中操作传入的 `handler` 对象。有新的处理器类型时，实现该接口即可。如 `@EnableMvc` 方式使用的 `RequestMappingHandlerAdapter`，以及已经弃用的 `AnnotationMethodHandlerAdapter`。

还有种缺省适配方式，由子类选择覆盖需要的方法。如 `WebMvcConfigurerAdapter` 类：  
![WebMvcConfigurerAdapter][]

### 3.责任链模式 ###

该模式本质为：分离对象的职责，动态的组合在一起。

常见的有两种实现方式:

1.  责任链：请求在链上传递，有一个对象处理过则跳出；
2.  功能链：请求在链上传递，链上的每个责任对象负责处理某一方面的功能，处理过不跳出，向下传递。

如 `HandlerExecutionChain` 的实现，为功能链的实现：  
![HandlerExecutionChain][]  
定义的拦截器列表 `interceptorList`，循环调用 `preHandle()` 方法 ，处理用户请求之前，均会经过该拦截器列表中所有的对象处理。

### 4.策略模式 ###

该模式本质为：分离算法，选择实现。即对应同一操作，提供不同的策略实现。

如参数解析器 `HandlerMethodArgumentResolver`:  
![HandlerMethodArgumentResolver][HandlerMethodArgumentResolver 1]

返回值处理器 `HandlerMethodReturnValueHandler`:  
![HandlerMethodReturnValueHandler][HandlerMethodReturnValueHandler 1]

### 5.工厂方法模式 ###

该模式形式为：提供一个创建对象实例的接口，让子类决定实例化哪一个类。

如在 `RequestMappingHandlerAdapter.invokeHandleMethod()` 方法中，创建 `ServletInvocableHandlerMethod` 时，会传入 `WebDataBinderFactory` 对象。而该类即为典型的工厂方法模式的实现:  
![WebDataBinderFactory][]  
在其默认的实现里，通过 `createBinderInstance()` 方法创建 `WebDataBinder` 对象，该实现可由子类自行扩展:  
![createBinderInstance][]

### 6.组合模式 ###

该模式定义为：将对象组合成树型结构，以统一叶子对象和组合对象。

一般有以下两种场景：

1.  统一整体和部分的操作；
2.  统一地使用组合结构中的所有对象。

SpringMVC 中参数解析时调用的 `HandlerMethodArgumentResolverComposite` 类, 组合一系列的参数解析器，即为第2种用法:  
![HandlerMethodArgumentResolverComposite][HandlerMethodArgumentResolverComposite 1]

还有 `HandlerMethodReturnValueHandlerComposite, WebMvcConfigurerComposite` 等。

### 7.单例模式 ###

模式定义为：保证一个类仅有一个实例，并提供一个全局访问点。该模式在日常的开发中应用也非常广泛。

两种典型的实现方式：

1.  懒汉式：一般为延迟加载方式，在使用的对象实例不存在时，再创建对象实例；
2.  饿汉式：一般在初始化时，创建对象实例。

SpringMVC 中，获取 `WebAsyncManager` 类时，即通过缓存的方式实现的懒汉式单例模式。将创建的 `WebAsyncManager` 对象缓存在 `ServletRequest` 中：  
![WebAsyncManager][]  
注：`WebAsyncManager` 类为管理异步请求处理的主要类。

--------------------

SpringMVC 框架中还有很多使用的设计模式未被列出，以上列举的只是前面深入源码过程中比较典型的几个。

## 五、写在最后 ##

知道了 SpringMVC 处理 HTTP 请求的过程之后，通过查看源码可以通过最优的方式使用平时用的一些特性。比如 `@RequestParam` 属性，常见的有如下两种用法：

@RequestParam(value = "name") String name
    @RequestParam String name

通过查看处理该注解的解析参数部分 `AbstractNamedValueMethodArgumentResolver.resolveArgument()` 源码：  
![resolveArgument()][resolveArgument]  
在获取 `NamedValueInfo` 的过程中，会调用 `updateNamedValueInfo()` 方法：  
![updateNamedValueInfo()][updateNamedValueInfo]  
注意上图中圈出的部分，`@RequestParam String name` 方式取得的 `length()` 为0，而 `@RequestParam(value = "name") String name` 方式去除的 `length()` 为4， `@RequestParam String name` 方式会多执行一部分程序。

**因此 `@RequestParam(value = "name") String name` 方式比 `@RequestParam String name` 方式更优。** 需要注意的是，`NameValueInfo` 在第一次访问接口之后会被缓存在本地，key 为对应的 `MethodParameter`。

以上就是我所理解的 SpringMVC 处理 HTTP 请求的过程。而前面所列出的也只是整个 SpringMVC 框架的冰山一角，篇幅较长，文中涉及的流程图画法也比较粗糙，希望没有造成误解。如果读者有不同的意见或者疑问，欢迎与我交流。

[Link 1]: https://github.com/wlmshuaia/JsonDemo
[415]: /images/20220603/07544eee3b114692978a25decdb0b56e.png
[55bdb610-f047-11e7-bc73-87cf5851ce7a]: /images/20220603/4789ac22e1cd4044988d983feb083157.png
[HTTP]: /images/20220603/b8727e881aa04a179730ea3fc81581db.png
[getHandler]: /images/20220603/da4549fbc76f444094e1fb02da1e69e6.png
[HandlerMapping]: /images/20220603/b72ec504f3f947e6936e30f7054fce2c.png
[RequestMappingHandlerMapping]: /images/20220603/105ad69fbb314f8096a52b5d3318acde.png
[RequestMappingInfo]: /images/20220603/148953070f1447819f45679a00a5d7c8.png
[getHandler 1]: /images/20220603/1a9ce4320c0149108fdc219ee0a56afc.png
[getHandlerInternal]: /images/20220603/68ec75cc8f444b7da1fced7aa4a3073a.png
[lookupHandlerMethod]: /images/20220603/16388cb351fe4432be3b70416cb31738.png
[addMatchingMappings]: /images/20220603/5bb7e774696742948810f5e86ffdecad.png
[index.do]: http://index.do
[http_images.gitbook.cn_c6ed9660-f480-11e7-9976-43dd6592a81a]: http://images.gitbook.cn/c6ed9660-f480-11e7-9976-43dd6592a81a
[HandlerAdapter]: /images/20220603/ecd53c427ab946e2957ba106759b0c77.png
[handlerAdapters]: /images/20220603/e1ced7184b524561b1fc330079bb4034.png
[supports]: /images/20220603/9a5f0330cb104326be8bf96d00a14858.png
[supports 1]: /images/20220603/f032dacb0f3941ae9119077de31a9d7c.png
[applyPreHandle]: /images/20220603/7a6178a2e702413283fad76c74597d43.png
[triggerAfterCompletion]: /images/20220603/99167f7908cb4a819b7647370fc7a646.png
[handlerInternal]: /images/20220603/c8336c9551974aa8a64db4d519972632.png
[invokeHandleMethod]: /images/20220603/e4d3cea020b94a259706cd6c8fb6dd37.png
[getMethodArgumentValues]: /images/20220603/839a6c5cc4024893840f70c271f5b0c9.png
[HandlerMethodArgumentResolverComposite]: /images/20220603/89b6c2a3468f4f7e877ce6e6c7a16ed5.png
[HandlerMethodArgumentResolver]: /images/20220603/38be3ae505a240b089fa005916302748.png
[HttpMessageConverter]: /images/20220603/59c6d56559464ad78d18108e2a553bc8.png
[default-charset]: /images/20220603/4259171bc8224323acd7dbcd40006a5c.png
[read]: /images/20220603/ec702d22bf7944cf9f7bc6f6189f506d.png
[invoke]: /images/20220603/5b5cfb551dc146cd90542e6ed9b11536.png
[HandlerMethodReturnValueHandler]: /images/20220603/75236d4f2cfd41e8b3f7545f7bf99e1d.png
[write]: /images/20220603/4b25d03270644daa86b3a32f8a7fc47a.png
[getProducibleMediaTypes]: /images/20220603/69ecd94f958f40aa8f694fad97e33ad0.png
[applyPostHandle]: /images/20220603/fa2757d53b3d477192317a3399623d02.png
[processDispatchResult]: /images/20220603/14315e157eb64b00ac2f303e6ebec967.png
[handlerExceptionResolvers]: /images/20220603/d173e8ce38b84577b8b4b0a1a57184eb.png
[doResolveHandlerMethodException]: /images/20220603/e321d0560e2e49e4ac6f58672a865410.png
[viewResolvers]: /images/20220603/e6efc3b163614daebcbf399502e7b1d8.png
[View]: /images/20220603/67f497f6057c49429baba5491c4e45a9.png
[triggerAfterCompletion 1]: /images/20220603/081851d6b7b046939fd4a325c119f996.png
[MediaTypes]: /images/20220603/4784120eef664d10aa938fc33c53d3f8.png
[selectMediaType]: /images/20220603/089481bbe07e44ae8207a5ee8ab21dd5.png
[Content-Type]: /images/20220603/f62aff2dd41f4943911d2484b27838d5.png
[MediaTypes 1]: /images/20220603/9ed10aa3c92345d3970d25075d0bda82.png
[Link 2]: http://blog.csdn.net/u012099869/article/details/78689257
[getHandler 2]: /images/20220603/eb2cca49941840d083cee7a3f17c0edc.png
[getHandlerInternal 1]: /images/20220603/f2a64a5627574cc19ee4776783e9e82b.png
[HandlerAdapter 1]: /images/20220603/efc1e1bd153d44dba11ca3b7accd760a.png
[WebMvcConfigurerAdapter]: /images/20220603/a879691fddf24c1fa956c1eaeb5e6969.png
[HandlerExecutionChain]: /images/20220603/0ce66ae7ab114642bc9971adcc8b080f.png
[HandlerMethodArgumentResolver 1]: /images/20220603/b2937b1afb9d40c4bb4f97ba0dbf314f.png
[HandlerMethodReturnValueHandler 1]: /images/20220603/c8292e4f94eb47a0a248f7519721facc.png
[WebDataBinderFactory]: /images/20220603/2e606aced2a04cd48e28fa208fd9a77e.png
[createBinderInstance]: /images/20220603/8617f37544114598b8a63c8e08cd3244.png
[HandlerMethodArgumentResolverComposite 1]: /images/20220603/bd0ac86ff7ba4ec0ac063f7d3b0a87c2.png
[WebAsyncManager]: /images/20220603/6b00803f669c4709aec42bd3331f1740.png
[resolveArgument]: /images/20220603/6ccd55b573dd48cc8c416ef2574ebbab.png
[updateNamedValueInfo]: /images/20220603/fc30d14147914db586881966f31d6ac7.png