文章内容输出来源： 拉勾教育java高薪训练营
一 简介
Spring Mvc是什么，mvc 是一种设计模型，Spring Mvc 就是spring 对这一套模型的具体实现。
或者说Spring MVC 是⼀种基于 Java 的实现 MVC 设计模型的请求驱动类型的轻量级 Web 框架
说到web框架，肯定绕不开servlet，Spring MVC 本质可以认为是对servlet的封装
1 spring 怎么实现 mvc
一个常见的mvc模式如下（M:model, V:View, C:Controller）
一个标准的请求如下：
- 前端发起请求
- 控制器处理分发这些请求给某些业务
- 业务生成数据模型
- 这些模型传回给视图模板渲染
- 渲染结果返回给前端
我的个人理解就是，数据，展示，逻辑，这三个部分分层来实现，使得整个流程更加清晰，后面阅读源码的时候我也发现spring自己很重视这种分层思想。
那么，spring中具体实现又是怎样呢？其实和这个图大同小异， 也有一个前端控制器(DispatcherServlet) 用来分发请求。
这个控制器根据请求找到一个处理器适配器处理请求返回ModelAndView，又把ModelAndView交给 视图控制器 解析成View对象，然后渲染视图返回。如下图：
区别确实不大，就增加了几个小步骤。
在这里，前端发起请求过来后，一共有11个具体步骤
- 第⼀步：⽤户发送请求⾄前端控制器DispatcherServlet
- 第⼆步：DispatcherServlet收到请求调⽤HandlerMapping处理器映射器
- 第三步：处理器映射器根据请求Url找到具体的Handler（后端控制器），⽣成处理器对象及处理器拦截 器(如果 有则⽣成)⼀并返回DispatcherServlet
- 第四步：DispatcherServlet调⽤HandlerAdapter处理器适配器去调⽤Handler
- 第五步：处理器适配器执⾏Handler
- 第六步：Handler执⾏完成给处理器适配器返回ModelAndView
- 第七步：处理器适配器向前端控制器返回 ModelAndView，ModelAndView 是SpringMVC 框架的⼀个 底层对 象，包括 Model 和 View
- 第⼋步：前端控制器请求视图解析器去进⾏视图解析，根据逻辑视图名来解析真正的视图。
- 第九步：视图解析器向前端控制器返回View
- 第⼗步：前端控制器进⾏视图渲染，就是将模型数据（在 ModelAndView 对象中）填充到 request 域
- 第⼗⼀步：前端控制器向⽤户响应结果
很容易看出整个核心就是前端控制器，DispatcherServlet。
那么他具体又是个什么东西呢？
其实就是一个继承了Servlet的类，负责传统的doGet, doPost等功能，只不过还曾加了一堆其他功能。
他的实现也体现了spring的分层思想，并没有简单的直接继承 Servlet。
为了实现增加的功能，它的内部还定义了九大组件来处理不同的逻辑。说是九大组件，其实就是类里面的九个属性值。
2 Spring MVC 九⼤组件
2.1 HandlerMapping（处理器映射器）
HandlerMapping 是⽤来查找 Handler 的，也就是处理器，具体的表现形式可以是类，也可以是 ⽅法。⽐如，标注了@RequestMapping的每个⽅法都可以看成是⼀个Handler。Handler负责具 体实际的请求处理，在请求到达后，HandlerMapping 的作⽤便是找到请求相应的处理器 Handler 和 Interceptor.
2.2 HandlerAdapter（处理器适配器）
HandlerAdapter 是⼀个适配器。因为 Spring MVC 中 Handler 可以是任意形式的，只要能处理请 求即可。但是把请求交给 Servlet 的时候，由于 Servlet 的⽅法结构都是 doService(HttpServletRequest req,HttpServletResponse resp)形式的，要让固定的 Servlet 处理 ⽅法调⽤ Handler 来进⾏处理，便是 HandlerAdapter 的职责。
2.3 HandlerExceptionResolver 异常处理器
HandlerExceptionResolver ⽤于处理 Handler 产⽣的异常情况。它的作⽤是根据异常设置 ModelAndView，之后交给渲染⽅法进⾏渲染，渲染⽅法会将 ModelAndView 渲染成⻚⾯。
2.4 ViewResolver 视图解析器
⽤于将String类型的视图名和Locale解析为View类型的视图，只有⼀ 个resolveViewName()⽅法。从⽅法的定义可以看出，Controller层返回的String类型视图名 viewName 最终会在这⾥被解析成为View。View是⽤来渲染⻚⾯的，也就是说，它会将程序返回 的参数和数据填⼊模板中，⽣成html⽂件。ViewResolver 在这个过程主要完成两件事情： ViewResolver 找到渲染所⽤的模板（第⼀件⼤事）和所⽤的技术（第⼆件⼤事，其实也就是找到 视图的类型，如JSP）并填⼊参数。默认情况下，Spring MVC会⾃动为我们配置⼀个 InternalResourceViewResolver,是针对 JSP 类型视图的。
2.5 RequestToViewNameTranslator 请求视图转换器
RequestToViewNameTranslator 组件的作⽤是从请求中获取 ViewName.因为 ViewResolver 根据 ViewName 查找 View，但有的 Handler 处理完成之后,没有设置 View，也没有设置 ViewName， 便要通过这个组件从请求中查找 ViewName。
2.6 LocaleResolver
ViewResolver 组件的 resolveViewName ⽅法需要两个参数，⼀个是视图名，⼀个是 Locale。 LocaleResolver ⽤于从请求中解析出 Locale，⽐如中国 Locale 是 zh-CN，⽤来表示⼀个区域。这 个组件也是 i18n 的基础。
2.7 ThemeResolver 主题处理器
ThemeResolver 组件是⽤来解析主题的。主题是样式、图⽚及它们所形成的显示效果的集合。 Spring MVC 中⼀套主题对应⼀个 properties⽂件，⾥⾯存放着与当前主题相关的所有资源，如图 ⽚、CSS样式等。创建主题⾮常简单，只需准备好资源，然后新建⼀个“主题名.properties”并将资 源设置进去，放在classpath下，之后便可以在⻚⾯中使⽤了。SpringMVC中与主题相关的类有 ThemeResolver、ThemeSource和Theme。ThemeResolver负责从请求中解析出主题名， ThemeSource根据主题名找到具体的主题，其抽象也就是Theme，可以通过Theme来获取主题和 具体的资源。
2.8 MultipartResolver 文件处理器
MultipartResolver ⽤于上传请求，通过将普通的请求包装成 MultipartHttpServletRequest 来实 现。MultipartHttpServletRequest 可以通过 getFile() ⽅法 直接获得⽂件。如果上传多个⽂件，还 可以调⽤ getFileMap()⽅法得到Map<FileName，File>这样的结构，MultipartResolver 的作⽤就 是封装普通的请求，使其拥有⽂件上传的功能。
2.9 FlashMapManager
FlashMap ⽤于重定向时的参数传递，⽐如在处理⽤户订单时候，为了避免重复提交，可以处理完 post请求之后重定向到⼀个get请求，这个get请求可以⽤来显示订单详情之类的信息。这样做虽然 可以规避⽤户重新提交订单的问题，但是在这个⻚⾯上要显示订单的信息，这些数据从哪⾥来获得 呢？因为重定向时么有传递参数这⼀功能的，如果不想把参数写进URL（不推荐），那么就可以通 过FlashMap来传递。只需要在重定向之前将要传递的数据写⼊请求（可以通过ServletRequestAttributes.getRequest()⽅法获得）的属性OUTPUT_FLASH_MAP_ATTRIBUTE 中，这样在重定向之后的Handler中Spring就会⾃动将其设置到Model中，在显示订单信息的⻚⾯ 上就可以直接从Model中获取数据。FlashMapManager 就是⽤来管理 FalshMap 的
二 重点是什么
很明显，九大组件有一些不常用，有一些也不是那么重要。
所以整个组件和请求过程中，哪些是比较重要的呢？
我认为是找到处理器适配器并执行和视图生成渲染这两个部分。
由于现在基本上后端分离，试图渲染一般交给前端去做，所以重点就只剩如何找到处理器适配器并执行。
那么如何找到这些适配器，都有哪些适配器，他们在哪儿呢？
显然需要深入阅读 DispatcherServlet
三 DispatcherServlet 源码分析
首先借用视频中的一张图
可以看到，DispatcherServlet 上面还有两个继承类帮助他完成请求分发的工作。
这里就是spring的分层实现了。我在原有的讲解下，查看源码经过分析，扩展总结了下面的分层设计。
1 DispatcherServlet 继承关系
1.1 HttpServlet
这个我们知道是javax里面的实现，已经不属于spring的范畴，继承这个类就可以处理get和post等请求，所以在这个情景下就是最底层的父类
1.2 HttpServletBean
这是spring的第一个简单继承类，在这层次负责处理spring基础信息，就是配置和环境神马的，还用于处理web.xml里面的配置，就是咱们在web.xml里面配置的 init-param 这些。给后续子类提供配置处理功能，方便他们使用。
<servlet>
<servlet-name>springmvc</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<init-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath*:springmvc.xml</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
1.3 FramewordServlet
他被定义为Spring中最基本的Servlet，在这个层次负责利用上一层的配置把 Servlet 和 spring中的apllicationContext 整合到一起，相当于为子类提供了spring全家桶，而且负责为每一个Servlet 都维护一个WebApplicationContext。
从上面的图中可以看到，Servlet 调用doGet, doPost 就是在这里完成的。不仅如此, 他还把常用的 get,post,delete,put 封装为都统一调用的 processReqeust 方法。就是上面图片右边那个小方框。
这个processReqeust方法实际上只做了一些和统计，配置，钩子函数处理等边边角角的事，把要处理的任务抽出来变成了 doService 方法给子类实现。
总的来说，这个类通过父类对配置文件的处理，完成了和spring的对接，使得子类可以专注于自己的业务逻辑，是一个很清晰的层次结构。
1.4 DispacherServlet
说是SpringMvc 的核心应该没什么问题， 他在这一层次负责具体请求处理。
父类为他完成了对接工作，他就负责实现我们上面提到的MVC设计， 九大组件也定义在这里，利用这九大组件的帮助下，完成 doService 的实现， 实现MVC。
2 具体分析
九大组件定义如下，前面已经介绍过了，就不多说了。
/** MultipartResolver used by this servlet. */
@Nullable
private MultipartResolver multipartResolver;
/** LocaleResolver used by this servlet. */
@Nullable
private LocaleResolver localeResolver;
/** ThemeResolver used by this servlet. */
@Nullable
private ThemeResolver themeResolver;
/** List of HandlerMappings used by this servlet. */
@Nullable
private List<HandlerMapping> handlerMappings;
/** List of HandlerAdapters used by this servlet. */
@Nullable
private List<HandlerAdapter> handlerAdapters;
/** List of HandlerExceptionResolvers used by this servlet. */
@Nullable
private List<HandlerExceptionResolver> handlerExceptionResolvers;
/** RequestToViewNameTranslator used by this servlet. */
@Nullable
private RequestToViewNameTranslator viewNameTranslator;
/** FlashMapManager used by this servlet. */
@Nullable
private FlashMapManager flashMapManager;
/** List of ViewResolvers used by this servlet. */
@Nullable
private List<ViewResolver> viewResolvers;
来到doService 方法， 整个方法并不是很长，流程很清晰，总结如下
实现代码
@Override
protected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception {
logRequest(request);
// Keep a snapshot of the request attributes in case of an include,
// to be able to restore the original attributes after the include.
Map<String, Object> attributesSnapshot = null;
if (WebUtils.isIncludeRequest(request)) {
attributesSnapshot = new HashMap<>();
Enumeration<?> attrNames = request.getAttributeNames();
while (attrNames.hasMoreElements()) {
String attrName = (String) attrNames.nextElement();
if (this.cleanupAfterInclude || attrName.startsWith(DEFAULT_STRATEGIES_PREFIX)) {
attributesSnapshot.put(attrName, request.getAttribute(attrName));
}
}
}
// Make framework objects available to handlers and view objects.
request.setAttribute(WEB_APPLICATION_CONTEXT_ATTRIBUTE, getWebApplicationContext());
request.setAttribute(LOCALE_RESOLVER_ATTRIBUTE, this.localeResolver);
request.setAttribute(THEME_RESOLVER_ATTRIBUTE, this.themeResolver);
request.setAttribute(THEME_SOURCE_ATTRIBUTE, getThemeSource());
if (this.flashMapManager != null) {
FlashMap inputFlashMap = this.flashMapManager.retrieveAndUpdate(request, response);
if (inputFlashMap != null) {
request.setAttribute(INPUT_FLASH_MAP_ATTRIBUTE, Collections.unmodifiableMap(inputFlashMap));
}
request.setAttribute(OUTPUT_FLASH_MAP_ATTRIBUTE, new FlashMap());
request.setAttribute(FLASH_MAP_MANAGER_ATTRIBUTE, this.flashMapManager);
}
try {
doDispatch(request, response);
}
finally {
if (!WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) {
// Restore the original attribute snapshot, in case of an include.
if (attributesSnapshot != null) {
restoreAttributesAfterInclude(request, attributesSnapshot);
}
}
}
}
总的来说，就是处理请求属性的注入。
重点在doDispatch 这里, 进去继续看代码会发现实现过程和我们最开始的图一样了。
流程：
简略代码如下
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception {
//omit..
try {
ModelAndView mv = null;
Exception dispatchException = null;
try {
// 1 检查是否是⽂件上传的请求
processedRequest = checkMultipart(request);
multipartRequestParsed = (processedRequest != request);
// Determine handler for the current request.
/*
2 取得处理当前请求的Controller，这⾥也称为Handler，即处理器 这⾥并不是直接返回
Controller，⽽是返回 HandlerExecutionChain 请求处
理链对象 该对象封装了Handler和Inteceptor */
mappedHandler = getHandler(processedRequest);
if (mappedHandler == null) {
// 如果 handler 为空，则返回404
noHandlerFound(processedRequest, response);
return;
}
// Determine handler adapter for the current request.
// 3 获取处理请求的处理器适配器 HandlerAdapter
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
// Process last-modified header, if supported by the handler.
// 处理 last-modified 请求头
//omit..
if (!mappedHandler.applyPreHandle(processedRequest, response)) {
return;
}
// Actually invoke the handler.
// 4 实际处理器处理请求，返回结果视图对象
mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
if (asyncManager.isConcurrentHandlingStarted()) {
return;
}
// 结果视图对象的处理
applyDefaultViewName(processedRequest, mv);
mappedHandler.applyPostHandle(processedRequest, response, mv);
}
//omit catch...
// 5 跳转⻚⾯，渲染视图
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
}
//omit catch finaly
}
看来前面分析的没啥毛病，接下来具体看看几个关键的步骤。
2.1 核⼼步骤 1 getHandler 获得处理器链
追踪请求过程发现，他是通过遍历两个HandlerMapping，来试图获取能够处理当前请求的执⾏链，而且简单的情况下，只有两种处理器链。
看得出只要有一个处理器链能够处理请求就可以直接返回了，这里最终返回的是RequestMapperHandlerMapping
通过分析，可以看出处理器链代表的是某一类的handler，比如这里就是两类：根据bean的名字来处理，或者根据request路径来处理
2.2 核⼼步骤 2 getHandlerAdapter 获取处理器适配器
拿到了处理器链，还得从链获取一个具体的处理器，这就是 getHandlerAdapter，获取方法也很简单粗暴，遍历处理器链中的各个HandlerAdapter，看哪个Adapter⽀持处理当前Handler，就直接返回,最终返回的是RequestMappingHandlerAdapter
2.3 核⼼步骤 3 handler.handle 适配器处理
这个handler要做的就是特定的工作了，比如这一次拿到的RequestMappingHandlerAdapter要做的就是处理对含有 @RequestMapping 注解的类和方法通过request请求实现调用。
说白了，就是通过请求地址，根据controller头上的 @RequestMapping和方法上面的 @RequestMapping 找到方法，从请求中解析参数，然后传入到具体方法里面去，和自定义mvc干的事情一样。
执行过程截图入如下：
401
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
