强大的DispatcherServlet
还记得在web.xml中配置的DispatcherServlet吗?其实那个就是SpringMVC框架的入口，这也是struts2和springmvc不同点之一，struts2是通过filter的，而springmvc是通过servlet的。看下servlet的结构图
从上面这张图很明显可以看出DispatcherServlet和Servlet以及Spring的关系。而我们今天的重点就从DispatchServlet说起。
在分析之前我用SpringBoot搭建了一个很简单的后台项目，用于分析。代码如下
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.Data;
@Data
@Builder
@AllArgsConstructor
public class User {
private Integer id;
private String name;
private Integer age;
private String address;
public User() {
}
}
/**
* @author generalthink
*/
@RestController
@RequestMapping("/user")
public class UserController {
@RequestMapping(value = "/{id}",method = RequestMethod.GET)
public User getUser(HttpServletRequest request,@PathVariable Integer id) {
//创建一个user,不走数据库只是为了分析springmvc源码
User user = User.builder()
.id(id)
.age(ThreadLocalRandom.current().nextInt(30))
.name("zzz" + id)
.address("成都市").build();
return user;
}
@RequestMapping(value = "/condition",method = RequestMethod.GET)
public User getByNameOrAge(@RequestParam String name,@RequestParam Integer age) {
User user = User.builder().name(name).age(age).address("成都市").id(2).build();
return user;
}
@PostMapping
public Integer saveUser(@RequestBody User user) {
Integer id = user.getName().hashCode() - user.getAge().hashCode();
return id > 0 ? id : -id;
}
}
这里为了方便调试把关注点更多集中在SpringMVC源码中,所以这里的数据都是伪造的。而且这里的关注点也集中到使用注解的Controller(org.springframework.stereotype.Controller)，而不是Controller接口(org.springframework.web.servlet.mvc.Controller),这两者的区别主要在意一个只用标注注解，一个需要实现接口，但是它们都能完成处理请求的基本功能。我们都知道访问servlet的时候默认是访问service方法的，所以我们将断点打在HttpServlet的service方法中，此时查看整个调用栈如下
从这里我们也知道了请求时如何从servlet到了DispatcherServlet的，我们先来看一下DispatcherServlet的doDiapatch的方法逻辑，这里把核心逻辑列出来了，把其他的一些非核心逻辑移除了
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
HttpServletRequest processedRequest = request;
//注意这里放回的是HandlerExecutionChain对象
HandlerExecutionChain mappedHandler = null;
boolean multipartRequestParsed = false;
ModelAndView mv = null;
Exception dispatchException = null;
//检查是否存在文件上传
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
// 根据当前request获取handler,handler中包含了请求url,以及最终定位到的controller以及controller中的方法
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {
noHandlerFound(processedRequest, response);
return;
}
// 通过handler获取对应的适配器,主要完成参数解析
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}
// 调用Controller中的方法
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
applyDefaultViewName(processedRequest, mv);
mappedHandler.applyPostHandle(processedRequest, response, mv);
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}可以看到核心逻辑其实非常简单，首先检查是不是multipart request，如果是则对当前的request进行一定的封装(提取文件等），然后获取对应的handler(保存了请求url对应的controller以及method以及一系列的Interceptor),然后在通过handler获取到对应的handlerAdapter(参数组装)，通过它来进行最终方法的调用
解析multipart
那么是如何解析当前请求是文件上传请求呢？这里直接进入到checkMultipart方法看看是如何解析的：
//我精简了下代码，只提取了核心逻辑
protected HttpServletRequest checkMultipart(HttpServletRequest request) throws MultipartException {
if (this.multipartResolver != null && this.multipartResolver.isMultipart(request)) {
return this.multipartResolver.resolveMultipart(request);
}
return request;
}从这里可以看出通过multipartResolver判断当前请求是否是文件上传请求,如果是则返回MultipartHttpServletRequest(继承自HttpServletRequest).不是则返回原本request对象。
那么问题来了multipartResolver是什么时候初始化的呢？
我们在idea中可以直接将断点定位到multipartResolver属性上，进行请求访问这个时候会发现断点直接进入到了initMultipartResolver方法中，接着跟踪整个调用栈，可以发现调用关系如下：
图上表明了是在初始化servlet的时候对multipartResolver进行了初始化的。
private void initMultipartResolver(ApplicationContext context) {
//从Spring中获取id为multipartResolver的类
this.multipartResolver = context.getBean("multipartResolver", MultipartResolver.class);
}
MultipartResolver接口有CommonsMultipartResolve以及StandardServletMultipartResolver2种实现，CommonsMultipartResolver接口是依赖于commons-upload组件实现的，而 StandardServletMultipartResolver是依赖于Servlet的part(servlet3才存在)实现的.两者判断是否是文件上传请求的方法isMultipart均是通过判定请求方法是否为post以及content-type头是否包含multipart/来进行判定的。
DispatchServlet初始化了哪些内容
protected void initStrategies(ApplicationContext context) {
initMultipartResolver(context); //初始化multipartResolver
initLocaleResolver(context);//初始化localeResolver
initThemeResolver(context);//初始化themResolver
initHandlerMappings(context);//初始化handerMappings
initHandlerAdapters(context);//初始化handlerAdapters
initHandlerExceptionResolvers(context);
initRequestToViewNameTranslator(context);
initViewResolvers(context);//初始化试图解析器
initFlashMapManager(context);
}这些初始化的内容都会在后面被逐一使用，这里先有一个印象。
根据请求获取mapperHandler
还是进入到getHander方法中看看到底做了什么？
@Nullable
protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
if (this.handlerMappings != null) {
for (HandlerMapping hm : this.handlerMappings) {
HandlerExecutionChain handler = hm.getHandler(request);
if (handler != null) {
return handler;
}
}
}
return null;
}
根据HandlerMapping来查看对应的handler,那么进入到initHandlerMappings方法中查看如何初始化handlerMappings
其中获取默认的handlerMappings是去spring-webmvc的org.springframework.web.servlet中的DispatcherServlet.properties中查找，文件内容是这样的
这几个HandlerMapping的作用如下：
SimpleUrlHandlerMapping : 允许明确指定URL模式和Handler的映射关系，内部维护了一个urlMap来确定url和handler的关系
BeanNameUrlHandlerMapping: 指定URL和bean名称的映射关系，不常用，我们的关注点也主要集中在RequestMappingHandlerMapping中
这里也基本明确了HandlerMapping的作用:帮助DispatcherServlet进行Web请求的URL到具体类的匹配,之所以称为HandlerMapping是因为在SpringMVC中并不局限于
必须使用注解的Controller我们也可以继承Controller接口，也同样可以使用第三方接口，比如Struts2中的Action
接着看下getHandler的实现：
@Nullable
protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
if (this.handlerMappings != null) {
for (HandlerMapping hm : this.handlerMappings) {
HandlerExecutionChain handler = hm.getHandler(request);
if (handler != null) {
return handler;
}
}
}
return null;
}
返回的handler是HandlerExecutionChain,这其中包含了真实的handler以及拦击器，可以在执行前,执行后，执行完成这三个阶段处理业务逻辑。RequestMappingHandlerMapping的getHandler的调用逻辑如下：
会遍历所有Controller的url查看是否有符合条件的match(head,url,produce,consume，method都要满足要求),采用antMatcher的方式来进行url匹配，如果匹配上了则返回对应的handler，否则返回null,如果映射发现有重复的映射（url映射相同，请求方法相同，参数相同，请求头相同，consume相同，produce相同，自定义参数相同），则会抛出异常。
而SimpleUrlHandlerMapping的调用逻辑如下：
其中维护了url到handler的映射，先通过url到urlMap中找对应的handler，如果没有找到则尝试pattenMatch，成功则返回对应的handler,未匹配则返回null。
会发现处理HandlerMapping这里运用了模板方法，在抽象类中定义好了业务逻辑，具体实现只需要实现自己的业务逻辑即可。同时也符合开闭原则，完全是面向接口编程，不得不让人叹服这里的涉及逻辑。
分析到这里的时候我们会发现我们之前定义的Controller明显是符合RequestMappingHandlerMapping的策略的，所以返回的HandlerExecutionChain已经包含了需要访问的方法的全路径了。
关于HandlerAdapter
HandlerMapping会通过HandlerExecutionChain返回一个Object类型的Handler对象，用于Web请求处理，这里的Handler并没有限制具体是什么类型，一般来说任何类型的Handler都可以在
SpringMVC中使用，只要它是用于处理Web请求的处理对象就行。
不过对于DispatcherServlet来说就存在问题了，它无法判断到底使用的是什么类型的Handler，也无法知道是调用Handler的哪个方法来处理请求，为了以同意的方式来调用各种类型的Handler,
DispatcherServlet将不同Handler的调用职责转交给了一个成为HandlerAdapter的角色。
先看一下HandlerAdpter接口的定义
public interface HandlerAdapter {
boolean supports(Object handler);
@Nullable
ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception;
long getLastModified(HttpServletRequest request, Object handler);
}
主要关注supports和handle方法。先看下DispatcherServlet中handlerAdapters的初始化过程，和handlerMappings的初始化过程是类似的
上面关于handler的说明中说了其实Object handler实际上是HandlerMethod，所以这里对应的HandlerAdapter就是RequestMappingHandlerAdapter。
找到对应的适配器之后，这个时候就可以调用真正的逻辑了。在这之前使用者可以通过拦截器做一些事儿，比如记录日志，打印执行时间等，所以如果想要在执行的方法之前添加一条语句，我们只需要配置自己的拦击器即可。
发现这个方法的调用逻辑实际上很简单，就是解析参数，然后调用方法。我们来看一下如何进行参数解析的呢？
可以看到几乎所有的核心逻辑都集中到了argumentResovlers中去，那么支持的arguementResolver有哪些？又是在哪里初始化的呢？
首先需要定位到这个属性是从哪里过来的，RequestMappingHandlerAdapter实现了InitializingBean，所以在初始化的时候会执行afterPropertiesSet方法，在这其中对arguementResolvers以及returnValueHandlers进行了初始化。
不同的resovler支持的参数解析不一样，比如说有支持HttpServletRequest注入的，有支持HttpServletREsponse注入的还有支持body体注入的等等。
至此，springmvc的整个调用流程基本就清晰了。
但是到了这里问题仍然没有结束，因为我们还不知道参数具体是如何解析的。比如get方式提交的数据？post方式提交的数据？如何转换成对象的？这写问题都还存在，那我们继续研究。
这里我使用postman工具来发起请求，首先访问 Get http://localhost:8080/user/condition?name=zhangsan&age=25,定位到resolveArgument方法
接着又执行revolver.resolveArgument方法，同样的这里还是使用的模板方法，在抽象类AbstractNamedValueMethodArgumentResolver中定义流程，各个子类只需要实现自己的逻辑即可。RequestParamMethodArgumentResolver的参数就是通过request.getParameter来获取到的。获取到了参数之后就执行反射调用，这个时候就执行了我们写的UserController的对应方法，获取到了User对象，接下来就是处理返回值了，通过returnValueHandlers进行处理
handler会根据返回的类型对数据进行处理，比如说这里就通过response向请求方输出数据，输出数据也是通过messageConverter来实现的
么对于这样的请求又时如何解析的呢？
@PostMapping
public Integer saveUser(@RequestBody User user) {
Integer id = user.getName().hashCode() - user.getAge().hashCode();
return id > 0 ? id : -id;
}
同样我们聚焦在解析参数的时候，在上一个get请求的示例中我说了会先访问AbstractNamedValueMethodArgumentResolver，但是在处理@RequestBody的参数中它使用的是RequestResponseBodyMethodProcessor,它复写了resolveArgument方法。所以不会去执行父类的逻辑。
这里最后会定位到jakson的objectMapper中， 在spring boot中，默认使用Jackson来实现java对象到json格式的序列化与反序列化。当然是可以配置messageConvert的，只需要实现Spring的HttpMessageConverter即可。
源码分析到这里就结束了，当然其中还存在一些没有讲的地方，比如View的渲染呀，一般视图是多种多样的，又html,xml,jsp等等，所以springmvc也提供了接口供用户选择自己需要的模板，只需要实现ViewResolver接口即可。还有关于Theme,MessageResource，Exception的处理等等，如果铺开来讲篇幅实在是太长了，我更相信掌握了核心流程看其他的处理就会很简单了，所以这里也就不对其他枝节内容做分析了。
一图胜千言
