DispatcherServlet的核心工作原理

最后更新于2年前

这有帮助吗？

1. DispatcherServlet#service

既然 SpringWebMvc 的核心是 DispatcherServlet ，而作为 Servlet ，核心处理请求的方法是 service ，所以我们先来到 DispatcherServlet 的父类 FrameworkServlet 重写的 service 方法：

可见，它在调用父类 HttpServlet 之前先拦了一道，它想提前处理 PATCH 类型的请求，而我们刚才发的请求很明显是 GET ，所以这个分支不会走，进入父类 HttpServlet 的 service 方法。

那 HttpServlet 的 service 方法，会根据请求的类型，决定走 doGet 、doPost 等方法，而这些方法才是子类要重写的核心方法。那既然刚才发的是 GET 请求，那就又回到 FrameworkServlet 的 doGet 方法了：（捎带着把 doPost 也带进来了）

WTF ? 合着无论是 doGet 还是 doPost ，到了你 DispatcherServlet 中，又给合起来了呗？那好吧，咱继续往里走。。。

2. processRequest → doService

接下来的这个方法可谓第一个重要的方法，篇幅比较长细节比较多，我们要关注的核心方法，是最中间的 try-catch 块：

可以发现，它真正处理请求的核心方法，是这个 doService 的模板方法。而这个模板方法，就是在 DispatcherServlet 中重写的。

好，咱们继续往下走。进入到 DispatcherServlet 中，发现这个 doService 方法还不是真正干活的，它里面又调用了一个 doDispatch 方法：

诶！看到这里，有 do 作为方法开头，又有 dispatch 与类名一致，那是不是这个方法就是最最核心的方法了呢？（狂喜）

是的，我们终于找到了 DispatcherServlet 的核心方法，就是这个 doDispatch 方法，这里面就会涉及到之前我们讲 DispatcherServlet 工作流程中说到的整个执行过程。

3. DispatcherServlet#doDispatch

在阅读这个方法的源码之前，我们先来看看 SpringFramework 自己对于这个如此重要的方法，是如何诠释的：

Process the actual dispatching to the handler. The handler will be obtained by applying the servlet's HandlerMappings in order. The HandlerAdapter will be obtained by querying the servlet's installed HandlerAdapters to find the first that supports the handler class. All HTTP methods are handled by this method. It's up to HandlerAdapters or handlers themselves to decide which methods are acceptable.

该方法是调度实际请求到具体 Handler 的处理器。

该方法会按顺序检索 DispatcherServlet 中所有的 HandlerMapping ，并找到可以处理该请求的 Handler ，并通过查询 DispatcherServlet 中已装配的所有 HandlerAdapter ，来查找支持 Handler 的第一个 HandlerAdapter 并获取。所有 HTTP 方法都由该方法处理，而最终都是由 HandlerAdapter 或 Handler 本身决定可以处理的请求。

吐槽一下，，，文档注释想翻译好还是挺考验人的，机翻的效果太差了，作者在这里斟酌了好久才整理好这段注释的翻译。

体会一下官方给的解释，其实这跟我们之前分析 DispatcherServlet 的流程时，说法是一样的，只不过在文档注释中并没有解释的那么详尽罢了，我们要抓住的还是整体的脉络。

下面咱来进入方法的实现，这个方法篇幅有点长，按照惯例，咱还是拆解开来看。

3.1 文件上传解析

方法一上来定义好多局部变量，这个我们不关心，下面第一步实际的动作，是对请求中可能存在的文件上传进行解析。

仔细看一下这里面的处理，它想借助一个 multipartResolver ，去检查当前请求是不是一个 multipart 请求。那很明显 GET 请求并不会出现 multipart 类型的请求，所以这部分并不会进入，感兴趣的小伙伴可以用之前 xml 工程中的文件上传例子来测试一下效果。

3.2 【1】获取第一个可用的Handler

接下来到了整个 DispatcherServlet 处理请求的核心第一步：搜索 Handler 。进入到 getHandler 方法中，可以发现它是在现有的所有 HandlerMapping 中，寻找可以返回 HandlerExecutionChain 的 HandlerMapping ，逻辑与前面讲的完全对的上！

这里 Debug 可以发现，DispatcherServlet 中有 3 个 HandlerMapping ，而且都是上一章中我们看到的，DispatcherServlet.properties 中默认加载的那 3 个：

好，那我们直接调整到断点停在 RequestMappingHandlerMapping 的循环中，断点进入。

3.2.1 AbstractHandlerMapping#getHandler

Debug 首先进入到的是父类 AbstractHandlerMapping ，这有点出乎意料，但又在情理之中，因为 SpringWebMvc 的类结构设计都是父类提供流程的抽象定义，子类负责具体的功能实现。

我们先看一眼这里面的流程定义：

总结下来，就两步：搜索 Handler 、构造 **HandlerExecutionChain** 对象。咱分解来看哈，先看如何搜索 Handler 的。

3.2.1.1 RequestMappingHandlerMapping搜索Handler

Debug 进入 getHandlerInternal 方法，发现它先是到了一个叫 RequestMappingInfoHandlerMapping 的，不过那里面直接调用的 super ，而继续往上走 super ，就到 RequestMappingHandlerMapping 的父类 AbstractHandlerMethodMapping 了。

这个源码的流程就有必要看看了，首先它会解析出本次请求的 uri ，Debug 至此会发现能解析出 /demo 来：

接下来，它要执行 lookupHandlerMethod 方法，从本身的 HandlerMethod 中看看有没有能匹配上的。不过这个源码实在是有点长，咱就不在这里贴出来了，小伙伴可以借助着 IDE 来看。

这里我们 Debug 会发现，HandlerMapping 中的确有 3 个解析好的 Handler ，有前面入门的时候写的，也有后面我们讲解异步请求时写的：

可见 /demo 也在其中，于是就可以成功的返回 HandlerMethod 了。

3.2.1.2 包装HandlerMethod

本来上面就已经返回 HandlerMethod 了，为啥在这里还要再创建一下子呢？我们可以先仔细观察一下源码：

诶？bean 还有可能是字符串呢？如果是的话，还会从 BeanFactory 中取？这什么操作？莫慌，我们先看看这个方法的文档注释：

If the provided instance contains a bean name rather than an object instance, the bean name is resolved before a HandlerMethod is created and returned.

如果提供的 HandlerMethod 实例包含 bean 的名称而不是对象实例，则在创建并返回 HandlerMethod 之前先解析该 bean 的名称。

果然，这个 HandlerMethod 是有可能先存一个 bean 的名称的，而 Debug 到这里，发现确实存了 bean 的 name （注意是个字符串）：

好吧，那一切都讲得通了，这样执行完成后，也就彻底找到了可以处理请求的 Handler 。

3.2.2 构造HandlerExecutionChain

HandlerMethod 拿到之后，接下来它并不会立即返回，而是会组合 WebMvc 中注册的拦截器：

这个应该不难理解吧，毕竟具体要执行哪些拦截器，这里是需要实际匹配才能筛选出来的。

注意一点，我们之前在 spring-mvc.xml 中配置的也好，WebMvcConfigurer 中配置的也好，最终构造的拦截器，类型都是 MappedInterceptor ，毕竟咱当时配置的标签就叫 mapping ：

好，这一步执行完之后，HandlerMapping 的工作就全部完成，接下来可以回到 DispatcherServlet 了。

3.3 【2】获取HandlerAdapter

接下来就到了 DispatcherServlet 核心处理流程的第二步了，它要根据 HandlerMapping 找到的 Handler ，寻找一个可以执行这个 Handler 的 HandlerAdapter 。

而这个 getHandlerAdapter 方法的逻辑，跟寻找 HandlerMapping 时如出一辙：

Debug 至此处，可以发现有 4 个 HandlerAdapter ：

不用想，最后能返回的一定是 RequestMappingHandlerAdapter ，进到他的 supports 方法，可以发现它其实只需要判断 Handler 的类型是不是 HandlerMethod ：

很明显，上面 RequestMappingHandlerMapping 本来就封装的 HandlerMethod ，所以这里理所当然的返回 true 。

3.4 回调拦截器

经历了上面的过程后，下面就可以进行真正的逻辑触发了。在执行 Handler 之前，先要执行我们编写的那些拦截器，首先是 preHandle 方法的拦截回调，在源码中也是简单的循环依次调用：

在这里我们也发现了，如果 preHandle 方法返回了 false ，则内部的 if 结构会触发，返回 false 。而上面我们也看到了，如果 mappedHandler.applyPreHandle 方法返回 false ，则会直接 return 掉，不会继续执行 Handler 的逻辑了。

3.5 【3】执行Handler的逻辑

接下来，是 DispatcherServlet 核心工作流程的第三步，它要委托 HandlerAdapter 去执行 Handler 方法了。

进入到 RequestMappingHandlerAdapter 的父类 AbstractHandlerMethodAdapter 中，可以发现它直接调用了另一个模板方法 handleInternal ：

诶？是不是这种方法调用出现好多次了？在 SpringWebMvc 中，对于父类调用子类的方法，貌似出现 xxx → doXxx 方法不是很多，而是 **xxx → xxxInternal** 比较多！所以各位，在这里也要多留心注意一下哈。

3.5.1 handleInternal

来到 RequestMappingHandlerAdapter 重写的 handleInternal 方法：

刨去那些分支代码不看，核心的方法操作就相当于将方法的执行，转发到了 invokeHandlerMethod 方法中而已，那么我们继续往下跳转。

3.5.2 invokeHandlerMethod

好家伙，这个 invokeHandlerMethod 方法又是好长啊，我们继续分段来看。

3.5.2.1 参数绑定器初始化

这个步骤的方法，从方法名也能知道，它要初始化一个 WebDataBinder ，而这个家伙在我们之前学习 @ControllerAdvice 注解中有提到，它跟 @InitBinder 注解有配合使用。而点开这个源码，我们就可以发现 @InitBinder 注解的踪迹了：

看上面的 lambda 表达式，它过滤的就是那些 @InitBinder 注解的方法，所以我们在编写 @InitBinder 注解标注的方法时，会传入一个 WebDataBinder ，也就有原理可循了。

3.5.2.2 参数预绑定

接下来是参数预绑定，这个概念似乎不是很能理解，但小册只要提到另一个注解，估计各位立马就能反应过来了：@ModelAttribute 。这个方法的处理逻辑，跟上面的 getDataBinderFactory 方法又是如出一辙：

一样的套路，一样的 lambda ，这里要过滤出来的方法，就是那些被 @ModelAttribute 注解标注，同时还没有被 @RequestMapping 标注的方法，这样后面就可以完成 @ModelAttribute 注解的底层处理了。

3.5.2.3 创建方法执行对象

接下来，它创建了一个 ServletInvocableHandlerMethod 对象，而创建的逻辑也是相当 “敷衍” 了：

哦好吧，只是一个二度封装而已啊，那没事了。。。哎，怎么能没事呢，下面马上就要用到了，快继续往下看。

3.5.2.4 执行Controller的方法

接下里中间的一大段源码小册都省略掉了，不是主干逻辑处理小伙伴可以自行深入研究，咱下面要看的是刚刚在上面创建完 ServletInvocableHandlerMethod 后的调用：

原来如此，这个 ServletInvocableHandlerMethod 创建出来，还是有用的啊，这个家伙才是能真正执行我们编写的那些 Controller 方法的。

3.5.3 【反射】invocableMethod.invokeAndHandle

来，进入到它的 invokeAndHandle 方法：

好家伙第一句代码就是核心了。。。啊？你问我为啥这就是核心？这都有返回值了你说是不是 Controller 方法都执行完了呢？

什么？你还是好奇？那我们就进去看一下：

3.5.3.1 反射执行Controller方法

好家伙，这直接解析完方法参数后，反射执行 **method.invoke** 了啊，实锤执行 Controller 方法咯。

OK ，到这里，Controller 方法就执行完毕了，接下来就应该处理返回值了吧，根据返回值的类型，要有具体的处理方式。

3.5.3.2 处理方法返回值

这个 invokeAndHandle 方法的最后 try-catch 块部分，就是解析返回值并处理的逻辑。由于这个 HandlerMethodReturnValueHandlerComposite 是一个复合对象，它里面组合了一堆 HandlerMethodReturnValueHandler ，所以这里面的逻辑可想而知，又是跟前面的 HandlerMapping 、HandlerAdapter 差不多，使用 for 循环去匹配可以处理这个 Controller 返回值的 HandlerMethodReturnValueHandler ，并返回：

这个地方，对于返回视图，和返回 json 数据，其实际处理的 HandlerMethodReturnValueHandler 是不一样的。

3.5.3.3 处理视图返回

视图的返回是 String 类型，其底层的处理实现是 ViewNameMethodReturnValueHandler ：

而它对于返回的视图名称的处理，是把它放入 ModelAndViewContainer 中，执行 setViewName 方法：

哎？我们之前在操作 ModelAndView 的时候，设置返回跳转的视图，不也是这么干的嘛！只是在这里我们返回视图名称，底层让 WebMvc 帮我们干了 setViewName 方法而已。

3.5.3.4 处理json数据响应

想要响应 json 数据，则需要在方法 / 所在类上标注 @ResponseBody 注解，而处理它的底层实现是 RequestResponseBodyMethodProcessor ：

它会判断方法上有没有标注 @RequestBody 或者 @ResponseBody 注解，刚好跟编码要求对应起来。

而 RequestResponseBodyMethodProcessor 对于 json 数据的响应，也就是把要响应的数据，序列化成 json ，写入 HttpServletResponse 中：

这个 writeWithMessageConverters 方法复杂得很，感兴趣的小伙伴可以进去挑战一下，它的底层逻辑无非还是把 json 数据写进 HttpServletResponse 的 OutputStream 中罢了，小册就不展开了。

3.5.4 getModelAndView

回到刚才的 invokeHandlerMethod 方法吧，可能有的小伙伴已经忘了走到哪里了，咱刚才走到的是这里：

Controller 方法执行完毕后，如果是返回跳转视图，则此时 mavContainer 中是已经设置过视图名称的。

接下来就可以进入到 getModelAndView 方法中了：

可以发现，在这里面的核心，就是把 ModelAndViewContainer 转换为实际的 ModelAndView ，返回，完事。

到此为止，HandlerAdapter 的工作也全部做完了。

3.6 回调拦截器

接下来，它要继续调用拦截器的 postHandle 方法了，调用逻辑与前面一样，不再深入啦。

3.7 【4】处理视图、解析异常

上面的 try-catch 块执行完毕后，最后一步，到了 DispatcherServlet 核心工作流程的最后一步了，它要处理视图，以及解析其中的异常了。

进入 processDispatchResult 方法中，这里面的核心是三大步骤：

分开来看哈。

3.7.1 处理异常

对于一般在 Controller 方法，或者其中调用的 Service 中出现的异常，都不会是 ModelAndViewDefiningException （源码也没有任何构造 ModelAndViewDefiningException 的部分），所以我们只需要看下面的 else 块即可。

而在 else 块中，它调用了一个 processHandlerException 方法，将原有的 ModelAndView 替换掉了，那自然这个 processHandlerException 方法就是处理异常的核心逻辑咯，咱进去看一看：

哇，又是循环找可以处理当前异常的 HandlerExceptionResolver ，这套路已经快看烦了是吧，所以小册也就不再啰嗦了。

如果小伙伴想测试一下这个部分的逻辑，可以在 Controller 的方法中自己构造一个异常（除零异常、空指针等），再编写一个 @ExceptionHandler 去处理一下，把断点打在这里，会发现有一个 ExceptionHandlerExceptionResolver 可以处理异常，这家伙就是编写的 @ExceptionHandler 注解的方法，包装出来的，具体的内部执行各位可以自行深入，或者参照 SpringBoot 小册第 26 章，里面有细节的描述。

3.7.2 渲染视图

接下来，无论异常处理怎样，最后都是要渲染视图的，而渲染视图的核心方法，是在这个 if 块中的 render 。这个方法的源码不是很多，咱看一下主线流程就可以了：

可以发现，它拿着上面处理好的 ModelAndView ，到方法里面来处理。首先它会从 ModelAndView 中取逻辑视图的名称，如果有，那就借助 ViewResolver 去找视图（也就是我们之前注册的那个 InternalResourceViewResolver ），解析到了，就返回；解析不到，就抛异常。

找到视图之后，在最低下，它会调用 View 的 render 方法去渲染视图，那里面的逻辑就超级复杂了，咱就不看了，涉及到具体的 jsp 、FreeMarker 、Thymeleaf 等模板引擎的处理咱也没必要深究。

3.7.3 回调拦截器

渲染视图完成后，最后再调用拦截器的 afterCompletion 方法，完事。此时异常处理和视图渲染都完成了，如果是响应 json 数据的话也写入 OutputStream 了，所以我们之前在学拦截器的时候，说这个时机叫完全执行，因为这一步走完之后就没有后续的核心逻辑了，DispatcherServlet 的处理也全部结束了。

最后更新于2年前

这有帮助吗？