[springframework]-spring-mvc

一、简介

Spring MVC 是 Spring 全家桶中一个重要的组成部分。
Spring MVC 通过策略接口 使得 Spring MVC 框架高度可配置。 Spring MVC 包含多种视图技术，例如 JavaServer Pages（JSP）技术、Velocity、Tiles、iText和POI。Spring MVC 框架并不关心用户使用的是什么视图技术，它只提供相关接口规范。这也使得 Spring MVC 更灵活，定制化开发更简便。

二、项目中的简单使用

直接使用的 spring boot 中 web 模块演示demo

简单的使用代码，如下：

@RequestMapping("/demo")
@RestController  //@Controller
public class DemoController {
    @Autowired
    private JwtTokenUtils jwtTokenUtils;
    @RequestMapping("/create-token")
    public String generateToken(){
        return jwtTokenUtils.createToken(1L);
    }
}

Spring MVC 底层依赖的是 spring context 也就是 IOC 容器。通过特定的注解 @Controller(@RestController) ) ，使得被标注的类能够被加载如 IOC 容器中，同时能够被 Spring MVC 识别。然后通过 @RequestMapping(“${url}”) 将方法暴露同时指定资源访问路径 url。

详细的操作可以参考 Spring MVC 官方文档

二、原理 / 流程

先来看看图中各个组件：

• DispatcherServlet

  DispatcherServlet 是 Spring MVC 的请求入口，被称为 Front Controller 。 接收 request 请求，然后转发各个组件进行处理。

• HandlerMapping

  DispatcherServlet 第一个转发的组件，根据请求中的请求路径 url，获取对应的 Controller 信息。

• HandlerAdapter

  根据 HandlerMapping 中返回的 url -> Controller 映射关系，返回 ModelAndView 给 DispatcherServlet。

• ViewResolver

  ViewResolver 是一个视图解析器，根据 前面得到的 ModelAndView 进行解析。

• View

  ViewResolver 解析 ModelAndView 之后得到的展示数据。该数据可以是 json ，xml，jsp页面等数据。

我们再来总结一下 Spring MVC 的具体工作流程：

第一步：request 请求被 DispatcherServlet 接收 统一处理

第二步：DispatcherServlet 根据请求从 HandlerMapping 中获取 请求url 对应的映射的 controller，然后将结果返回给 DispatcherServlet

第三步：DispatcherServlet 根据 RequestMapping 返回的 Handler 去 HandlerAdapter 中去获取对应适配的 ModelAndView 返回给 DispatcherServlet

第四步：DispatcherServlet 根据返回的 ModelAndView 去 ViewResolver 中进行解析。最后得到 View

三、源码解析

DispatcherServlet 作为 Spring MVC 的入口，我们就先来看看 DispatcherServlet。如下图，DispatcherServlet 类继承结构：

首先 DispatcherServlet 实现了 ApplicationContextAware，所以DispatcherServlet 能够直接获取 spring 的上下文，也就是 能够直接操作 IOC 容器。

看图我们可以知道 DispatcherServlet 其实就是一个 Servlet 。而说到 Servlet 我们比较关注的就是 doGet() 、doPost() 、doService()方法，还有就是 Servlet 生命周期 init()、destroy()方法。

首先我们来看看 init() 方法的实现

init() 方法没有直接在 DispatcherServlet 中实现，而是由其父类 HttpServletBean 实现，我们简单来看看其中代码：

public abstract class HttpServletBean extends HttpServlet implements EnvironmentCapable, EnvironmentAware {
    ..........
    // Let subclasses do whatever initialization they like.
    initServletBean();
    ..........
}

其中比较重要的一个方法就是 initServletBean() ，且这个方法还是其子类 FrameworkServlet 实现。下面我们来看看 FrameworkServlet 部分代码：

public abstract class FrameworkServlet extends HttpServletBean implements ApplicationContextAware {
    ..........
    @Override
    protected final void initServletBean() throws ServletException {
        ..........
        this.webApplicationContext = initWebApplicationContext();
        ..........
    }
   protected WebApplicationContext initWebApplicationContext() {
       ..........
       onRefresh(wac);
       ..........
   }
   protected void onRefresh(ApplicationContext context) {
        // For subclasses: do nothing by default.
    }
}

看上面可以知道 initServletBean() 中调用的 initWebApplicationContext() ，initWebApplicationContext() 调用的 onRefresh()；结果 onRefresh() 由 FrameworkServlet 子类 DispatcherServlet 实现。

从上面我们就可以捋清楚，Servlet 中的 init() 方法，绕了一圈，最后被换了个名字叫做 onRefresh() 在 DispatcherServlet 中被实现了。

有了源头之后，我们再来看看 DispatcherServlet 在初始化 init() 方法所执行的 onRefresh() 究竟做了些什么事

public class DispatcherServlet extends FrameworkServlet {
    ..........
     @Override
    protected void onRefresh(ApplicationContext context) {
        initStrategies(context);
    }
    protected void initStrategies(ApplicationContext context) {
             // 初始化 多媒体解析器  
            initMultipartResolver(context);  
            // 初始化 位置解析器  
            initLocaleResolver(context);  
            // 初始化 主题解析器  
            initThemeResolver(context);  
            // 初始化 HandlerMappings  
            initHandlerMappings(context);  
            // 初始化 HandlerAdapters  
            initHandlerAdapters(context);  
            // 初始化 异常解析器  
            initHandlerExceptionResolvers(context);  
            // 初始化 请求到视图名转换器  
            initRequestToViewNameTranslator(context);  
            // 初始化 视图解析器  
            initViewResolvers(context);  
            // 初始化 FlashMapManager  
            initFlashMapManager(context);  
    }
    ..........
}

从上面我们可以看到，DispatcherServlet 在初始化的时候，针对 Spring MVC 的工作做了很多的准备工作。

这几个初始化的方法大同小异，我们看看其中的 initHandlerMappings() 初始化 HandlerMapping，

public class DispatcherServlet extends FrameworkServlet {
    ..........
    HandlerMapping hm = context.getBean(HANDLER_MAPPING_BEAN_NAME, HandlerMapping.class);
    ..........
}

可以发现所有的初始化方法，都是直接从IOC 容器中获取。

到这里就完成了 DispatcherServlet 中 init() 的所有初始化方法。

不过为了加深理解 Spring MVC 工作机制，我们再来解析一下 HandlerMapping 究竟是如何被加载进入 IOC 容器中的，并且 HandlerMapping 中都放了些啥。

我们先来看看 HandlerMapping 中类继承结构

在上图的继承结构中，我们又看到了 ApplicationContextAware ，实现了 ApplicationContextAware 就能够持有 Spring 上下文，针对 IOC 容器的操作就变得轻而易举了。
除了 ApplicationContextAware 之外，我们还可以看到 InitializingBean 。InitializingBean接口为实现该接口的 Bean 提供了初始化方法的方式，它只有 afterPropertiesSet() 方法，凡是继承该接口的类，在初始化 Bean 的时候都会执行该方法。

我们以 AbstractHandlerMethodMapping 获取方法url 链接的 HandlerMapping 为例进行源码跟踪。以 afterPropertiesSet() 为入口查看：

public abstract class AbstractHandlerMethodMapping<T> extends AbstractHandlerMapping implements InitializingBean {
    ..........
    @Override
    public void afterPropertiesSet() {
        initHandlerMethods();
    }
    protected void initHandlerMethods() {
        // getCandidateBeanNames() 获取 IOC 容器中所有的 beanName
        for (String beanName : getCandidateBeanNames()) {
            if (!beanName.startsWith(SCOPED_TARGET_NAME_PREFIX)) {
                 // 遍历并进行处理
                processCandidateBean(beanName);
            }
        }
        handlerMethodsInitialized(getHandlerMethods());
    }
    // 处理方法
    protected void processCandidateBean(String beanName) {
        Class<?> beanType = null;
        try {
             // 根据 beanName 从 IOC 容器中获取类
            beanType = obtainApplicationContext().getType(beanName);
        }
        catch (Throwable ex) {
            // An unresolvable bean type, probably from a lazy bean - let's ignore it.
            if (logger.isTraceEnabled()) {
                logger.trace("Could not resolve type for bean '" + beanName + "'", ex);
            }
        }
         // 判定类是否为 handler (判定条件：类拥有 Controller 注解或者 RequestMapping注解)
        // 可以跟踪 isHandler() 方法查看
        if (beanType != null && isHandler(beanType)) {
            // 获取拼接符合要求的 Bean中的 method 的 url 
            detectHandlerMethods(beanName);
        }
    }
    ..........
}

根据上面的代码 AbstractHandlerMethodMapping 类初始化时，先获取所有容器中 beanName，
然后遍历 beanName，并获取对应实例。判断实例是否有 @Controller 和 @RequestMapping 注解。满足条件的 实例对象进入 detectHandlerMethods() 方法，进行相关方法 url 的拼接。有兴趣的小伙伴可以通过 debug 查看 detectHandlerMethods() 中的操作，能够看到这里面的处理就是将 url 对应的method 以及类之间的关系分别进行存储。

再来看看 doPost、doGet、doService()

这里我们将三个方法一起讲解，因为 doPost() doGet() 最后都调用了 doService() 方法。我们下面来验证一下，
DispatcherServlet 中 doGet() 和 doPost() 在 FrameworkServlet 中实现，下面我们来看看代码:

public abstract class FrameworkServlet extends HttpServletBean implements ApplicationContextAware {
    ..........
    @Override
    protected final void doGet(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }
    @Override
    protected final void doPost(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        processRequest(request, response);
    }
    rotected final void processRequest(HttpServletRequest request, HttpServletResponse response)
            throws ServletException, IOException {
        ..........
        doService(request, response);
        ..........
    }
    ..........
}

从上面的代码我们可以验证我们的结论，doGet() 、doPost() 最后都是调用的 doService() 方法。

通过查看代码，我们可以知道 doService() 在 FrameworkServlet 中没有实现而是在 DispatcherServlet 中被重写，下面我们来看看 DispatcherServlet 中 doService() 都做了些什么。代码如下：

public class DispatcherServlet extends FrameworkServlet {
    ..........
    @Override
    protected void doService(HttpServletRequest request, HttpServletResponse response) 
        throws Exception {
        ..........
        doDispatch(request, response);
        ..........
    }
    ..........
}

在 doService() 中，最主要的调用的就是 doDispatch() 方法。
下面我们来看看 doDispatch() 方法，代码如下：

public class DispatcherServlet extends FrameworkServlet {
    ..........
     protected void doDispatch(HttpServletRequest request, HttpServletResponse response) 
        throws Exception {
        HttpServletRequest processedRequest = request;
        HandlerExecutionChain mappedHandler = null;
        boolean multipartRequestParsed = false;
        WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request);
        try {
            ModelAndView mv = null;
            Exception dispatchException = null;
            try {
                // 检查本次请求是否是图片上传请求
                processedRequest = checkMultipart(request);
                multipartRequestParsed = (processedRequest != request);
                // Determine handler for the current request.
                // 主线第一步、确定当前请求的 handler(也就是 Controller)
                // -- 该操作返回 HandlerExecutionChain 
                // -- HandlerExecutionChain 中存放的是 handler 和 HandlerInterceptor
                mappedHandler = getHandler(processedRequest);
                if (mappedHandler == null) {
                    // 如果 handler 不能存在返回 404 
                    noHandlerFound(processedRequest, response);
                    return;
                }
                // Determine handler adapter for the current request.
                // 主线第二步、确定当前请求对应的handler 的 适配器 handlerAdapter 
                HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
                // Process last-modified header, if supported by the handler.
                // 如果该 handler 支持 ,处理 last-modified 请求头
                String method = request.getMethod();
                boolean isGet = "GET".equals(method);
                if (isGet || "HEAD".equals(method)) {
                    long lastModified = ha.getLastModified(request, mappedHandler.getHandler());
                    if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) {
                        return;
                    }
                }
                if (!mappedHandler.applyPreHandle(processedRequest, response)) {
                    return;
                }
                // Actually invoke the handler.
                // 主线第三步、真实调用 handler 中的方法，然后返回对应的视图
                mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
                if (asyncManager.isConcurrentHandlingStarted()) {
                    return;
                }
                // 主线第四步、根据响应的视图进行视图解析
                applyDefaultViewName(processedRequest, mv);
                mappedHandler.applyPostHandle(processedRequest, response, mv);
            }
            catch (Exception ex) {
                dispatchException = ex;
            }
            catch (Throwable err) {
                // As of 4.3, we're processing Errors thrown from handler methods as well,
                // making them available for @ExceptionHandler methods and other scenarios.
                dispatchException = new NestedServletException("Handler dispatch failed", err);
            }
            processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);
        }
        catch (Exception ex) {
            triggerAfterCompletion(processedRequest, response, mappedHandler, ex);
        }
        catch (Throwable err) {
            triggerAfterCompletion(processedRequest, response, mappedHandler,
                    new NestedServletException("Handler processing failed", err));
        }
        finally {
            if (asyncManager.isConcurrentHandlingStarted()) {
                // Instead of postHandle and afterCompletion
                if (mappedHandler != null) {
                    mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);
                }
            }
            else {
                // Clean up any resources used by a multipart request.
                if (multipartRequestParsed) {
                    cleanupMultipart(processedRequest);
                }
            }
        }
    }
    ..........
}

doDispatcher() 主线流程如下：
request 通过 doPost、doGet 然后经由 doService() ，最后进入到 doDispatch() 中。
第一步、通过 request 请求获取 对应的 handler (controller)。如果返回对应的handler 为空，则报404 错误。
第二步、根据获取到的 handler 查找对应的 适配器 handlerAdapter
第三步、通反射调用 handler 中对应的方法，然后将返回结果封装成对应的 ModelAndView
第四步、解析 ModelAndView ，得出对应的响应数据 View （可以是 json、xml、jsp等）

在知道了主线流程之后，基本上就能够知道 SpringMVC 究竟做了什么。

但是我还想知道 上面第三步 handle() 里面做了什么，因为在开发过程中我们用到的如 @ReuqestParam 等究竟是怎么完成的。下面我们来跟踪相关的代码,首先我们再来看看相关类结构，

doDispatcher() 主线流程中第三步，handle() 真实调用的是 RequestMappingHandlerAdapter 中的 handleInternal() 方法，现在我们来看看相关代码：

public class RequestMappingHandlerAdapter extends AbstractHandlerMethodAdapter
        implements BeanFactoryAware, InitializingBean {
    ..........
    @Override
    protected ModelAndView handleInternal(HttpServletRequest request,
            HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {
        ..........
        mav = invokeHandlerMethod(request, response, handlerMethod);
        ..........
    }
    @Nullable
    protected ModelAndView invokeHandlerMethod(HttpServletRequest request,
            HttpServletResponse response, HandlerMethod handlerMethod) throws Exception {
        ..........
        invocableMethod.invokeAndHandle(webRequest, mavContainer);
        ..........
    }
    ..........
}

通过上面的代码，可以得知最终调用的 是 ServletInvocableHandlerMethod 中的 invokeAndHandle() 方法。我们继续追踪代码

public class ServletInvocableHandlerMethod extends InvocableHandlerMethod {
    ..........
    public void invokeAndHandle(ServletWebRequest webRequest, ModelAndViewContainer mavContainer,
            Object... providedArgs) throws Exception {
        ..........
        Object returnValue = invokeForRequest(webRequest, mavContainer, providedArgs);
        ..........
    }
    ..........
}

此时调用的是 ServletInvocableHandlerMethod 父类 InvocableHandlerMethod 中的方法 invokeForRequest()。继续追踪代码

public class InvocableHandlerMethod extends HandlerMethod {
    ..........
    @Nullable
    public Object invokeForRequest(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
            Object... providedArgs) throws Exception {
        Object[] args = getMethodArgumentValues(request, mavContainer, providedArgs);
        if (logger.isTraceEnabled()) {
            logger.trace("Arguments: " + Arrays.toString(args));
        }
        return doInvoke(args);
    }
    protected Object[] getMethodArgumentValues(NativeWebRequest request, @Nullable ModelAndViewContainer mavContainer,
            Object... providedArgs) throws Exception {
        if (ObjectUtils.isEmpty(getMethodParameters())) {
            return EMPTY_ARGS;
        }
        MethodParameter[] parameters = getMethodParameters();
        Object[] args = new Object[parameters.length];
        for (int i = 0; i < parameters.length; i++) {
            MethodParameter parameter = parameters[i];
            parameter.initParameterNameDiscovery(this.parameterNameDiscoverer);
            args[i] = findProvidedArgument(parameter, providedArgs);
            if (args[i] != null) {
                continue;
            }
            if (!this.resolvers.supportsParameter(parameter)) {
                throw new IllegalStateException(formatArgumentError(parameter, "No suitable resolver"));
            }
            try {
                args[i] = this.resolvers.resolveArgument(parameter, mavContainer, request, this.dataBinderFactory);
            }
            catch (Exception ex) {
                // Leave stack trace for later, exception may actually be resolved and handled..
                if (logger.isDebugEnabled()) {
                    String error = ex.getMessage();
                    if (error != null && !error.contains(parameter.getExecutable().toGenericString())) {
                        logger.debug(formatArgumentError(parameter, error));
                    }
                }
                throw ex;
            }
        }
        return args;
    }
    ..........
}

到这里我们就可以看到这里完成了参数与方法中对应参数进行绑定的操作。

以上便是 SpringMVC 整体流程剖析。