Spring MVC学习详解

介绍一下Spring MVC的内容。

Spring提供了构建Web应用程序的全功能MVC模块。通过策略接口，Spring高度配置，且支持多种视图技术。例如JSP，Velocity，Tiles，iText和POI等。

Spring MVC功能的实现是基于Servlet功能实现的。也就是通过实现Servlet接口的DispatcherServlet来封装核心功能的实现。如果应用程序需要处理用户输入表单，可以继承AbstractFormController，如果需要把多页输入处理到同一个表单，可以继承

AbstractWizardFormController类。

下面就来简单介绍一些Spring MVC的使用方式。

1.配置web.xml。

Default WebApplicationContext implementation class for ContextLoader.

Used as fallback when no explicit context implementation has been specified as context-param.

Not meant to be customized by application developers.

org.springframework.web.context.WebApplicationContext=org.springframework.web.context.support.XmlWebApplicationContext

3.将实例记录在servletContext中。

4.映射当前的类加载器和创建的实例到全局变量currentContextPerThread中。

在Spring MVC中，ContextLoaderListener只是辅助功能，用于创建WebApplicationContext类型的实例，真正MVC的逻辑是实现在DispatcherServlet里面的。查看该类的继承结构发现，该类实现了Servlet接口，如下所示：

这里先来回顾一下servlet的生命周期：

1.初始化阶段。

servlet容器加载servlet类，把servlet类的class文件中的数据读到内存中。容器创建一个ServletConfig对象。容器创建一个servlet对象，调用servlet的方法进行初始化。

2.运行阶段。

当servlet容器接收到一个请求时，会针对这个请求创建servletRequest和servletResponse对象，然后调用service对象。生成完相应结果之后，然后销毁servletRequest和servletResponse对象。

3.销毁阶段。

Web容器被终止时，容器会先调用servlet的destroy方法，然后再销毁servlet对象，同事也会销毁改servlet对应的ServletConfig对象。

servlet框架是由javax.servlet和javax.servlet.http两个包构成的。

Servlet框架被设计成请求驱动，HTTP包含的方法为delete，get，options，put，post，和trace。分别提供了对应的服务方法。

由上面的介绍可以知道，service初始化阶段会调用其init方法，首先找到该方法的实现。该方法在HttpServletBean中实现，代码如下：

主要过程就是将当前的Servlet实例转化为BeanWrapper，然后就可以使用Spring提供的方式进行对属性的注入。

这些属性包含在FrameworkServlet类中。属性注入主要包含以下几个方面。

1.封装以及验证初始化参数。

ServletConfigPropertyValues除了封装属性之外还有对属性验证的功能。

2.将当前servlet实例转化为BeanWrapper实例。

通过调用PropertyAccessorFactory.forBeanPropertyAccess方法将当前实例转化为BeanWrapper，具体的BeanWrapper实现类为BeanWrapperImpl类。

3.注册相对于Resource的属性编辑器。

也就是用ResourceEditor去解析Resource类型的属性。

4.属性注入。

5.servletBean的初始化。

在ContextLoaderListener中已经创建了WebApplicationContext实例，并且在initServletBean方法中重要的就是对这个实例进行进一步的补充初始化。该方法写在FrameworkServlet类中。

初始化的逻辑委托给了initWebApplicationContext方法。代码如下：

上面函数中实现的主要功能有

5.1.寻找或创建对应的WebApplicationContext实例。主要包括以下几个步骤。

（1）.通过构造函数的注入进行初始化。

（2）.通过contextAttribute进行初始化。

（3）.重新创建WebApplicationContext实例。

如果上面两种方式否没有找到WebApplicationContext实例，此时执行重新创建WebApplicationContext实例的方法：

这里面有一个方法configureAndRefreshWebApplicationContext，代码如下：

该方法的功能是对已经创建的WebApplicationContext实例进行配置以及刷新。最后调用父类的AbstractApplicationContext的refresh进行配置文件加载。

继续回到上面的initWebApplicationContext方法，前面我们把createWebApplicationContext方法分析完了，继续分析后面的代码，能看到调用了onRefresh方法。该方法在DispatcherServlet类中进行了重写。

这里完成的过程主要是：

（1）.初始化MultipartResolver。

（2）.初始化LocaleResolver。

（3）.初始化ThemeResolver。

（4）.初始化HandlerMappings。

（5）.初始化HandlerAdapters。

（6）.初始化HandlerExceptionResolvers。

（7）.初始化RequestToViewNameTranslator。

（8）.初始化ViewResolvers。

（9）.初始化FlashMapManager。

下面就来详细介绍一下这里面的9个初始化操作。

（1）.初始化MultipartResolver。

在Spring中，MultipartResolver主要用来处理文件上传，默认情况下，Spring是没有Multipart的处理的，如果要使用Spring的Multipart，就需要在Web的上下文中添加Multipart解析器。比如常见的配置如下：

1000000

initMultipartResolver方法的代码如下：

按照刚才的说明，之前已经存在了Spring中配置文件的解析，这里只需要使用ApplicationContext的getBean就可以获取对应的bean。进而初始化MultipartResolver中的变量。

（2）.初始化LocaleResolver。

在Spring中的国际化配置一般有三种使用方式。

基于URL参数的配置。通过URL参数来控制国际化。比如在页面上加一句

简体中文

来控制项目中使用的国际化参数。而提供这个功能的就是AcceptHeaderLocaleResolver累，默认的参数名为locale。

第二种就是基于session的配置。具体的类为SessionLocaleResolver。

第三种就是基于Cookie的配置。具体的类为CookieLocaleResolver。

initLocaleResolver具体的代码为

和上面的initMultipartResolver方法类似。

（3）.初始化ThemeResolver。

在Web开发中经常会遇到主题Theme来控制网页风格，这将进一步改善用户体验，简单说就是一个主题就是一组静态资源，可以影响应用程序的视觉效果。Spring中的主题功能和国际化功能非常相似，构成Spring主题功能主要包括如下内容。

（3.1）.主题资源。

Spring中的ThemeSource是Spring中主题资源的接口，Spring的主题需要通过ThemeSource接口来实现存放主题信息的资源。

ResourceBundleThemeSource是ThemeSource接口默认实现类，在Spring中的配置如下：

默认状态下是在类路径根目录下查找相应的资源文件，也可以通过beasenamePrefix指定查找资源文件的包路径。

（3.2）.主题解析器。

ThemeSource定义了一些主题资源，ThemeResolver是主题解析器的接口，主题解析的工作则是其子类完成的。

对于主题解析器，主要有三个比较常见的实现，以主题summer.properties为例。

FixedThemeResolver：用于选择一个固定的主题。

CookieThemeResolver：用于实现用户所选的主题，以Cookie的方式存放在客户端的机器上。

SessionThemeResolver：用户主题保存在用户的HTTP Session中。

以上配置用于设置主题名称，并将该名称保存在用户的HttpSession中。

另外，对于FixedThemeResolver和SessionThemeResolver，共同继承了AbstractThemeResolver类。用户也可以自己实现自己的解析器继承AbstractThemeResolver类。

（3.3）.拦截器。

如果需要根据用户请求来噶变主题，那么Spring提供了一个已经实现的拦截器ThemeChangeInterceptor拦截器，具体的配置如下：

其中设置用户请求参数名为themeName，即URL为?themeName=具体的主题名称。此外还需要在handlerMapping中配置拦截器。

下面来看一下initThemeResolver的方法具体内容：

（4）.初始化HandlerMappings。

当客户端发出的Request时，DispatcherServlet会将Request提交给HandlerMappings，然后HandlerMappings根据WeApplicationContext的配置回传给DispatcherServlet相应的Controller。

在基于Spring MVC的Web应用程序中，我们可以为DispatcherServlet提供多个HandlerMapping工供其使用，DispatcherServlet在选用HandlerMappings的过程中，将根据我们所指定的一系列HandlerMapping的优先级进行排序，然后优先使用在前面的HandlerMapping。如果当前的HandlerMapping能够返回可用的Handler，DispatcherServlet则使用当前返回的Handler进行Web请求的处理，而不再继续询问其他的HandlerMapping。

initHandlerMappings方法的代码如下：

默认情况下，Spring MVC将加载当前系统中所有实现了HandlerMapping接口的bean。如果只期望Spring MVC加载指定的HandlerMapping，可以修改web.xml中的DispatcherServlet的初始化参数，将detectAllHandlerMappings设置为false：

此时，Spring MVC将查找名为handleMapping的bean，并作为当前系统中唯一的HandlerMapping。如果没有定义HandlerMapping的话，则Spring MVC将按照DispatcherServlet所在目录下的DispatcherServlet.properties文件中所定义的HandlerMapping的内容来加载默认的handlerMapping。

（5）.初始化HandlerAdapters。

望文知意，此处是适配器模式的应用。先来看一下initHandlerAdapters方法的代码：

在初始化的过程中使用到了一个变量，detectAllHandlerAdapters，该参数的作用和detectAllHandlerMappings类似，可以在配置文件中指定detectAllHandlerAdapters的值，来强制系统只加载bean name为“handlerAapter”的handlerAdapter。

如果无法找到对应的bean，系统尝试加载默认的适配器。调用的方法为getDefaultStrategies：

在getDefaultStrategies方法中，Spring会尝试从defaultStrategies中加载对应的HandlerAdapter属性，该参数的初始化过程就在DispatcherServlet中的初始化静态块中：

查看DispatcherServlet.properties文件中对应HandlerAdapter的内容：

org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\

org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\

org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter

也就会默认会加载这三个适配器。

下面来介绍一下这三个适配器。

HttpRequestHandlerAdapter：HTTP请求处理器适配器，该适配器仅支持对HTTP请求处理器的适配，简单的将HTTP请求对象和响应对象传递给HTTP请求处理器的实现。并且不需要返回值。主要应用在基于HTTP的远程调用的实现上。

SimpleControllerHandlerAdapter：简单控制器处理器适配器，客户化的业务逻辑通常是在控制器接口中的实现类中实现的。

AnnotationMethodHandlerAdapter：注解方法处理器适配器。这个类的实现是基于注解的实现，需要结合注解方法映射和注解方法处理协同工作。通过反射来发现探测处理器方法的参数，调用处理器方法，并且映射返回值到模型和控制器对象。

（6）.初始化HandlerExceptionResolvers。

基于HandlerExceptionResolvers接口的异常处理，使用这种方式只需要实现HandlerExceptionResolvers方法。该方法返回一个ModelAndView对象，如果返回为null，则Spring会继续寻找其他的实现了HandlerExceptionResolvers接口的bean，换句话说，Spring会搜索所有注册在其环境中的实现了HandlerExceptionResolvers接口的bean，逐个执行，直到返回了一个ModelAndView对象。

初始化的代码如下：

（7）.初始化RequestToViewNameTranslator。

在Controller处理器方法没有返回一个View对象或者逻辑视图名称，Spring就会采用约定好的方式提供一个逻辑视图名称。这个逻辑视图名称是通过Spring定义的RequestToViewNameTranslator接口的getViewName方法来实现的。我们也可以实现自己的RequestToViewNameTranslator接口的getViewName方法来约定没有返回视图名称的时候如何确定视图名称。Spring中的默认实现是DefaultRequestToViewNameTranslator。该类的配置信息主要有：

prefix：前缀，表示约定好的视图名称前加上的前缀，默认是空串。

suffix：后缀，如上的后缀。

separator：分隔符。默认是“/”。

stripLeadingSlash：如果首字母是分隔符，是否要去除，默认是true。

stripTrailingSlash：上面的判断尾字母的选项，默认为true。

stripExtension：如果请求路径包含扩展名，是否要去除，默认为true。

urlDecode：该参数在UrlPathHelper变量中。默认为true。是否需要对URL解码。

接下来看一下DefaultRequestToViewNameTranslator的处理过程。比如请求路径为http://localhost/app/test/index.html，改请求对应的URI为/test/index.html。

如果prefix和suffix都存在，则对应返回的视图名应该是prefix+test/index+suffix。

stripLeadingSlash和stripTrailingSlash都为false，这时候对应的应该是/test/index.html。

如果都采用默认值，返回的是test/index。

这些操作是在initRequestToViewNameTranslator方法中完成的。

（8）.初始化ViewResolvers。

在Spring MVC中，当Controller将请求处理结果放入到ModelAndView中以后，DispatcherServlet会根据合适的ModelAndView选择合适的视图进行渲染。Spring MVC如何选择合适的View，View对象的创建就在ViewResolver中。

该接口定义了一个方法resolveViewName，根据viewName创建合适的View实现。

ViewResolver的配置如下，即作为Spring中的Bean存在：

ViewResolvers的初始化工作在initViewResolvers方法中完成：

（9）.初始化FlashMapManager。

Spring MVC Flash attributes提供了一个请求存储属性，可供其他请求使用，在使用重定向的时候非常必要，例如Post/Get/Rediret模式，Flash attributes在重定向之前暂存以便重定向之后还能使用，并立即删除。

初始化的方法initFlashMapManager代码如下：

下面就重点来介绍一下DispatcherServlet的逻辑处理。

根据Servlet的规范，我们知道，Servlet处理Servlet请求最关键的方法就是service方法。DispatcherServlet的父类FrameworkServlet中有对service方法的实现：

由此可见，service方法将处理逻辑委托给了processRequest方法，该方法在FrameworkServlet类中：

主要过程如下：

（1）.为了保证当前线程的LocaleContext以及RequestAttributes可以砸当前请求后还能恢复，提取当前线程的两个属性。

（2）.根据当前request创建对应的LocaleContext和RequestAttributes，并绑定到当前线程。

（3）.委托给doService方法进一步处理。

（4）.请求处理结束后恢复线程到原始状态。

（5）.请求处理结束后无论成功与否发布事件通知。

首先来看一下最重要的doService方法中的逻辑，doService方法在DispatcherServlet类中实现：

但是在doService方法中依然是一些准备工作，这里会把已经初始化好的辅助工具变量比如localeResolver，themeResolver等设置在request中。

最后来到了doDispatch方法中：

下面就来梳理一下这个方法的处理逻辑：

1.MultipartContent类型的request处理。

对于请求的处理，Spring首先考虑的是Multipart的处理，如果是MultipartContent类型的request，就转换为MultipartHttpServletRequest类型的request，具体代码为checkMultipart方法：

2.根据request信息寻找对应的Handler。

在Spring中最简单的映射处理器配置如下：

Spring加载的过程中，会将类型为SimpleUrlHandlerMapping的实例加载到this.handlerMappings变量中。

先来看一下getHandler的处理逻辑：

继续来到AbstractHandlerMapping类中的getHandler方法：

上面的逻辑主要是，首先会使用getHandlerInternal方法根据request信息获取对应的Handler，如果没有对应的handler则使用默认的handler。

2.1.先来看一下getHandlerInternal方法的实现逻辑，如果以SimpleUrlHandlerMapping为例的话，该类的继承结构图如下：

getHandlerInternal方法实现在AbstractUrlHandlerMapping类中：

首先根据request查找对应的Handler开始分析，先截取用于匹配的url有效路径，然后根据路径寻找Handler，如果请求路径仅仅是“/”，则使用RootHandler进行处理，无法找到就使用默认的handler，然后根据beanName获取对应的bean，接下来就是模板方法。

先来看一下截取有效路径的方法：

截取到需要的url之后，就去寻找相应的Handler。来看一下lookupHandler方法的实现。

需要处理的情况有，直接匹配的情况，通配符匹配的情况，找到之后就是调用buildPathExposingHandler方法，

该方法将Handler封装成HandlerExecutionChain对象，并且在这里加入了两个拦截器。也就是链处理机制，是Spring中非常常用的处理方式，也是AOP的重要组成部分，可以方便的对目标对象进行扩展。

接下来回到getHandler方法中，根据request信息获取到handler对象之后，就调用getHandlerExecutionChain方法，将配置中的对应拦截器加入到执行链中，以保证这些拦截器可以有效的作用于目标对象。

至此，我们把doDispatch中的

mappedHandler = getHandler(processedRequest, false);

代码分析完了。

3.如果上面的过程依然没有找到对应的handler，处理过程为：

就是直接通过response向用户返回错误信息。

4.根据当前handler寻找对应的HandlerAdapter。

调用代码为：

HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());

getHandlerAdapter方法的实现如下所示：

主要就是通过遍历所有的适配器来选择合适的适配器返回。判断依据就是supports方法：

查看SimpleControllerHandlerAdapter类里面的supports方法实现：

也就是说对于Spring MVC来说，会把逻辑封装至Controller中。

5.缓存处理。

在介绍缓存处理的支持之前，先来了解一个概念，Last-Modified缓存机制。

（5.1）.在客户端第一次输入URL之后，服务端会返回内容和状态码200，表示请求成功，同时会添加一个Last-Modified的响应头，表示i文件在服务器上的最后更新时间。比如说在浏览器中输入https://www.baidu.com/img/bdlogo.png获取百度首页的log页面。

网络的响应情况为：

服务器的返回“Last-Modified: Fri, 01 Aug 2014 11:57:57 GMT”就是表示最后的变更时间。

（5.2）.客户端第二次请求次URL的时候，客户端会向服务端发送请求头“If-Modified-Since: Fri, 01 Aug 2014 11:57:57 GMT ”，如果服务端的内容没有变化，则自动返回304响应头，只有响应头，内容为空，就节省了网络带宽。

同样，Spring提供的对LastModified机制的支持，只需要实现LastModified接口，如下所示：

public class DemoLastModifiedController extends AbstractController implements LastModified {

private long lastModified;

@Override

public long getLastModified(HttpServletRequest request) {

if (lastModified == 0L) {

lastModified = System.currentTimeMillis();

}

return lastModified;

}

@Override

protected ModelAndView handleRequestInternal(HttpServletRequest request, HttpServletResponse response) throws Exception {

response.getWriter().write(“aa”);

return null;

}

}

Spring判断过期，通过判断请求的“If-Modified-Since”是否大于等于当前的getLastModified方法中时间戳，主要的实现代码为：

6.HandlerInterceptor的处理。

Servlet API定义的Servlet过滤器可以在servlet处理每个web请求的前后分别进行前置处理和后置处理。Spring中的拦截器需要实现HandlerInterceptor接口，实现三个方法：preHandle，postHandle和afterCompletion。preHandle和postHandle分别是在处理程序处理请求之前和之后被调用的。第二个方法还可以访问返回的ModelAndView对象。最后一个是在所有请求处理完成之后呗调用的。

下面是一个HandlerInterceptor的简单实现：

7.逻辑处理。

真正的逻辑处理其实是通过适配器中转调用Handler并返回视图的，对应的代码如下：

mv = ha.handle(processedRequest, response, mappedHandler.getHandler());

同样，这里来分析一下SimpleControllerHandlerAdapter中的实现：

进入到handleRequest方法：

真正的执行逻辑是在handleRequestInternal方法中的。

8.异常处理。

如果下面判断到出现了异常，会在调用processDispatchResult方法的时候进行识别，

processHandlerException中的代码为：

也就是把异常交给HandlerExceptionResolver的resolveException方法进行处理。

9.根据视图跳转页面。

在上面processDispatchResult的方法中，render方法就是处理页面跳转的逻辑。

上面的主要逻辑梳理如下：

9.1.解析视图名称。上面提到了DispatcherServlet会根据ModelAndView选择合适的视图来进行渲染，这一功能就是在resolveViewName中完成的。

来看一下AbstractCachingViewResolver类中的resolveViewName的处理逻辑：

如果不存在缓存的情况下就直接创建视图，如果存在就直接从缓存中提取。

createView的代码为，代码在UrlBasedViewResolver类中：

如果当前解析器不支持当前解析器如viewName为空等情况。

分别处理前缀为redirect:和forward:的情况。

最后调用父类的createView方法：

主要是考虑了几个方面的处理：

基于效率的考虑，提供了缓存的支持。

提供了redirect:和forward:前缀的支持。

添加了前缀以及后缀，并向View中加入了必须的属性设置。

9.2.页面跳转。

继续分析上面的render方法，通过viewName解析到对应的View之后，就可以进一步处理跳转逻辑了。

此处调用的代码为：

view.render(mv.getModelInternal(), request, response);

具体的实现代码为：

createMergedOutputModel方法：

renderMergedOutputModel方法：

上面的exposeModelAsRequestAttributes方法就是把model中的属性设置到request中。

至此，我们把Spring MVC的逻辑都分析完了。简单总结一下就是：

Spring MVC在容器启动的时候就把所有的请求和映射关系存放到内存中，客户端请求的时候根据request中的内容寻找对应的Handler处理请求。所以说如果存在相同的URL注解的话，Spring MVC启动的时候会报错，内容为

Ambiguous mapping found. Cannot map ‘userController’ bean method

也就是发现了模糊映射的错误。

介绍完了Spring MVC，接下来介绍Spring的远程服务。