通过Debug探索SpringMVC执行过程

对SpringMVC的理解

MVC：MVC是一种设计模式
MVC的原理图：

• M-Model 模型（完成业务逻辑：有javaBean构成，service+dao+entity）
• V-View 视图（做界面的展示 jsp，html……）
• C-Controller 控制器（接收请求—>调用模型—>根据结果派发页面）

SpringMVC工作原理

springMVC是一个MVC的开源框架，springMVC=struts2+spring，springMVC就相当于是Struts2加上sring的整合，但是这里有一个疑惑就是，springMVC和spring是什么样的关系呢？这个在百度百科上有一个很好的解释：意思是说，springMVC是spring的一个后续产品，其实就是spring在原
有基础上，又提供了web应用的MVC模块，可以简单的把springMVC理解为是spring的一个模块（类似AOP，IOC这样的模块），网络上经常会说springMVC和spring无缝集成，其实springMVC就是spring的一个子模块，所以根本不需要同spring进行整合。

• 用户发送请求至前端控制器DispatcherServlet。
• DispatcherServlet收到请求调用HandlerMapping处理器映射器。
• 处理器映射器找到具体的处理器(可以根据xml配置、注解进行查找)，生成处理器对象及处理器拦截器(如果有则生成)一并返回给DispatcherServlet。
• DispatcherServlet调用HandlerAdapter处理器适配器。
• HandlerAdapter经过适配调用具体的处理器(Controller，也叫后端控制器)。
• Controller执行完成返回ModelAndView。
• HandlerAdapter将controller执行结果ModelAndView返回给DispatcherServlet。
• DispatcherServlet将ModelAndView传给ViewReslover视图解析器。
• ViewReslover解析后返回具体View。
• DispatcherServlet根据View进行渲染视图（即将模型数据填充至视图中）。
• DispatcherServlet响应用户。

相关组件介绍：

• 前端控制器DispatcherServlet：其作用就是接收请求，响应结果，相当于转发器，中央处理器。有了dispatcherServlet减少了其它组件之间的耦合度。 用户请求到达前端控制器，它就相当于mvc模式中的c，dispatcherServlet是整个流程控制的中心，由它调用其它组件处理用户的请求，dispatcherServlet的存在降低了组件之间的耦合性。
• 处理器映射器HandlerMapping：根据请求的url查找Handler HandlerMapping负责根据用户请求找到Handler即处理器，springmvc提供了不同的映射器实现不同的映射方式，例如：配置文件方式，实现接口方式，注解方式等。
• 处理器适配器HandlerAdapter：按照特定规则（HandlerAdapter要求的规则）去执行Handler 通过HandlerAdapter对处理器进行执行，这是适配器模式的应用，通过扩展适配器可以对更多类型的处理器进行执行。
• 处理器Handler：Handler 是继DispatcherServlet前端控制器的后端控制器，在DispatcherServlet的控制下Handler对具体的用户请求进行处理。 由于Handler涉及到具体的用户业务请求，所以一般情况需要工程师根据业务需求开发Handler。
• 视图解析器View resolver：进行视图解析，根据逻辑视图名解析成真正的视图（view） View Resolver负责将处理结果生成View视图，View Resolver首先根据逻辑视图名解析成物理视图名即具体的页面地址，再生成View视图对象，最后对View进行渲染将处理结果通过页面展示给用户。 springmvc框架提供了很多的View视图类型，包括：jstlView、freemarkerView、pdfView等。 一般情况下需要通过页面标签或页面模版技术将模型数据通过页面展示给用户，需要由工程师根据业务需求开发具体的页面。
• 视图View： View是一个接口，实现类支持不同的View类型（jsp、
  freemarker、pdf…），需要工程师开发

SpringMVC工作流程

接下来我们借助IDEA的Debug功能探索SpringMVC工作流程。首先我们要确认我们的断点打在哪里。

如果是打在这里的话，那么相当于直接到了处理器那一步，前面的步骤我们都看不到了。根据上面的原理图我们可以知道第一步肯定与DispatcherServlet有关，根据后缀然后再查看它的结构我们可以知道：DispatcherServlet继承自HttpServlet，其本质就是一个Servlet。

根据Servlet的生命周期我们可以知道：每次请求Servlet时，Servlet容器都会调用Servlet的service()方法对请求进行处理。

如果还不是很了解Servlet的生命周期，可以看看我的另一篇文章：
Servlet初识(执行流程、生命周期)

所以我们找到service方法然后打上断点，发现卡上了，说明入口是对的：

接下来我们看重点：

我们从字面意思可以知道这里是对请求进行一个分发，我们步入这个方法，这时候我们可以看到一个HandlerExecutionChain，这就与前面的原理图完全吻合。

此时我们只需要寻找后面是谁给这个mappedHandler赋值的：

我们可以发现通过传入一个被包装过的request请求就得到了我们的HandlerExecutionChain处理器执行链。我们计算这个表达式看一下他的执行结果：

我们可以看到要执行的过滤器以及处理器handler。其中他还拿到了我们的method，也就是说底层是使用方法反射然后使用invoke执行。

注：在IDEA中右键语句，点击计算表达式；

注意：只有断点运行到了这里才能计算

综上所属HandlerExecutionChain处理器执行链就是一个类的实例，其中装着处理器以及拦截器，其中处理器(handler)就是你写的Controller，拦截器有默认的和你自己定义的。

然后我们步入这个getHandler方法看看，根据原理图这个方法肯定和HandlerMapping处理器映射器有关：

我们看到这个handlerMappings有三个处理器映射器：

也就是是说这里遍历依次使用每个处理器映射器，看哪个能拿到处理器链，然后对这个处理器链进行返回。

这里我们依次步过，发现RequestMappingHandlerMapping可以拿到处理器链。这里我们继续进入mapping.getHandler(request)方法中查看：

我们发现getHandlerInternal方法就可以拿到我们的处理器，那么我们就再进入getHandlerInternal方法：

注意这里进入的是AbstractUrlHandlerMapping中的getHandlerInternal方法

发现从lookupHandler方法拿到处理器，我们继续进入：

这里我们就可以看到：通过urlPath(也就是我们设置的路径)在map中去拿到处理器handler

至此，验证了SpringMVC的执行流程：前端控制器接收到客户端的请求后，通过处理器映射器handlerMappings，根据路径urlPath去匹配选择处理器handler，最终返回一个处理器执行链对象HandlerExcutionChain。

---

接下来我们继续查看doDispatch方法，在得到了mappedHandler这个处理器链之后，它再通过getHandlerAdapter方法拿到HandlerAdapter处理器适配器。

然后后面调用了这个HandlerAdapter，得到了mv，这个mv就是ModelAndView

我们看到这里有一个mappedHandler.getHandler()，也就是通过处理器链得到处理器。我们进入getHandler方法看看：

我们发现就是把处理器链的处理器给拿出来，这个处理器与我们前面的Controller也吻合：

那么接下来我们就看看ha.handle方法，我们进入这个方法；

继续进入，来到了RequestMappingHandlerAdapter(也就是我们当前获得的处理器适配器)中的handleInternal方法。

一眼就可以看到invokeHandlerMethod方法，也就是说这个方法用来执行处理器中对应的方法。我们进入这个方法：

这都不重要我们继续往下看，可以看到这个核心方法；

这个地方才真正的开始调用并执行处理器的方法。我们可以初步判断就是这个方法内部拿到我们的请求，然后解析我们的请求参数，再然后传入我们的处理器方法，最后去执行。

我们继续进入这个方法：

还没有看到解析请求参数的步骤继续步入invokeForRequest方法：

也就是说getMethodArgumentValues方法中应该就是参数的解析过程，我们继续进入：

我们可以看看这里的resolvers参数解析器：

我们可以看到几种常用的参数解析器：

就这样循环解析每一个参数，得到参数值列表args：


最后传入doInvoke方法

拓：
考虑到可能有频繁多次的访问，为了避免重复的调用同一个解析器影响效率，在resolveArgument方法的内部对解析器建立了缓存：


也就是说第一次会遍历解析器看哪个适配，如果有适配的就会根据参数把他存入缓存之中再去解析参数。第二次就会根据参数在缓存中找到解析器，直接拿来解析使用，不需要再去遍历看是否适配，如此更加高效。

我们可以继续看看resolver.supportsParameter(parameter)方法，它是用来确认是否适配解析器的：

大致就是通过注解判断使用什么解析器。

至此，验证了SpringMVC的执行流程：前端控制器通过处理器适配器HandlerAdapter，调用处理器的方法(也就是Controller中的方法)，然后处理器执行后返回模型视图对象ModelAndView给处理器适配器，适配器再将模型视图对象返回给前端控制器.