SpringMVC 核心源码分析

作者: 丑人林宗己 | 来源:发表于2019-09-30 09:19 被阅读0次

Spring的源码非常复杂，想要一篇概览几乎不可能，所以只能分而治之，本文摘写自近期抽空翻阅SpringMVC框架的部分源码，借此由浅入深地探索SpringMVC的核心体系结构。

在前后端分离大行其道的今日，由后端完成渲染的JSP/Freemarker时代可以说已经逐渐被NodeJS搭建的大前端体系取代，所以本文也不去翻阅SpringMVC视图渲染部分，仅认为后端作为一个数据服务接口来看到，简而言之，仅分析SpringMVC与前端的JSON交互流程。

基于过往的研发经验相信绝大多数都了解到，SpringMVC的核心组件为DispatcherServlet组件，而实现的规约则是J2EE关于Servlet的规范。如果对于Servlet规范不甚清楚，请抽空自行补充。本篇仅讨论HTTP请求的完整调用链路，不涉及其他协议规范说明。

DispatcherServlet

作为一个全局Servlet，欲深究其意，需先了解DispatcherServlet容器初始化时做了什么处理？而DispatcherServlet对象初始化包括如下三部分：

DispatcherServlet对象静态初始化部分？
构造函数？
Servlet规范中容器初始化流程？

在整个容器初始化的过程，只有明白其中会涉及到得我们需要去核心关注的部分，才能很好的把握住SpringMVC的核心流程，从中透析核心体系。

静态初始化部分

static {
        // Load default strategy implementations from properties file.
        // This is currently strictly internal and not meant to be customized
        // by application developers.
        try {
            ClassPathResource resource = new ClassPathResource(DEFAULT_STRATEGIES_PATH, DispatcherServlet.class);
            defaultStrategies = PropertiesLoaderUtils.loadProperties(resource);
        }
        catch (IOException ex) {
            throw new IllegalStateException("Could not load '" + DEFAULT_STRATEGIES_PATH + "': " + ex.getMessage());
        }
    }

静态初始化实际是读取了DispatcherServlet.properties文件的内容，其中都有些什么呢？摘4.3.18.RELESE版本的文件，内容如下：

// 省略...
org.springframework.web.servlet.HandlerMapping=org.springframework.web.servlet.handler.BeanNameUrlHandlerMapping,\
    org.springframework.web.servlet.mvc.annotation.DefaultAnnotationHandlerMapping

org.springframework.web.servlet.HandlerAdapter=org.springframework.web.servlet.mvc.HttpRequestHandlerAdapter,\
    org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter,\
    org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter
// 省略....

找一个类进去翻阅，可以猜测它可能是要初始化这些Bean，再查阅DispatcherServlet#getDefaultStrategies() 即可确认，当然，这部分并非是静态初始化就完成，而是延迟至Serlvet容器初始化时分批进行初始化。

构造函数

翻阅代码可以发现内部有两个构造函数，那么究竟在容器初始化的时候默认调用的是哪个？

easy，打个断点DEBUG一下就可以，基于我的环境上我发现是默认无参构造函数。（基于springboot 1.5.6版本）

那么是谁来调用改无参构造函数的呢？

easy，在springboot环境运行时可以看到有一个显眼的注解SpringBootApplication，而该注解的组成部分还包括EnableAutoConfiguration，这个注解又是要解决什么的呢？

它将默认加载spring-boot-autoconfig下的spring.factories文件内部的类，比如：

org.springframework.boot.autoconfigure.web.DispatcherServletAutoConfiguration,\
org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration,\

///.....

那么查阅这些类，它们做了什么？比如DispatcherServletAutoConfiguration，查阅时发现它加了注解Configuration

查阅该注解你又将发现它会处理声明@Bean的方法，并将该Bean注入到Spring容器中，由容器托管其生命周期。

Servlet容器初始化

查阅javax.servlet.Servlet接口的定义，可以清晰的看到规范中定义四个方法，其中需要重点关注如 init, service

那么DispatcherServlet容器在初始化时做了什么？

HttpServlet#init() -> FrameworkServlet#initServletBean -> DispatchserServlet#initStrategies()

注：如果想要知道Serlevt如何工作，可以翻阅Tomcat源码，以此看到工业级产品如何实现Servlet规范

翻阅DispatchserServlet#initStrategies()可以看到好几个方法，方法名称皆以init打头，那么它们就是在初始化什么？为什么在自己的程序中使用@Controller, @RequestMapping, @ResponseBody就可以跟前端完成常见的JSON交互了呢？

为了完成非常复杂的功能交互，SpringMVC定义了非常多的顶级接口，而我们核心要关注的无非是HandlerMapping, HandlerAdpater

HandlerMapping

查阅DispatcherServlet#initHandlerMappings()方法时发现一个问题，那就是它并非依据前文中提到的DispatcherServlet.properties中加载出来的对象，而是从ApplicationContext中取

Map<String, HandlerMapping> matchingBeans =
                    BeanFactoryUtils.beansOfTypeIncludingAncestors(context, HandlerMapping.class, true, false);

那么取出了什么Bean呢？

image.png

这些Bean从而何来？前文说过，本文基于springboot 1.5.6版本，程序启动加载spring-boot-autoconfig下的spring.factories文件，其中比如org.springframework.boot.autoconfigure.web.WebMvcAutoConfiguration

由于我们实际编码过程经常使用@RequestMapping来完成URL路径标记，那么先从与之有些类似的RequestMappingHandlerMapping中翻阅代码，看看初始化时核心放了什么？

public RequestMappingHandlerMapping requestMappingHandlerMapping() {
        RequestMappingHandlerMapping mapping = createRequestMappingHandlerMapping();
        mapping.setOrder(0);
        mapping.setInterceptors(getInterceptors());
        mapping.setContentNegotiationManager(mvcContentNegotiationManager());
        mapping.setCorsConfigurations(getCorsConfigurations());

        PathMatchConfigurer configurer = getPathMatchConfigurer();
        if (configurer.isUseSuffixPatternMatch() != null) {
      // 比如这个，很多开发者应该都记得以前URL一般都有后缀，比如.action, .do, .ac等等
            mapping.setUseSuffixPatternMatch(configurer.isUseSuffixPatternMatch());
        }
        if (configurer.isUseRegisteredSuffixPatternMatch() != null) {
            mapping.setUseRegisteredSuffixPatternMatch(configurer.isUseRegisteredSuffixPatternMatch());
        }
        if (configurer.isUseTrailingSlashMatch() != null) {
            mapping.setUseTrailingSlashMatch(configurer.isUseTrailingSlashMatch());
        }
        UrlPathHelper pathHelper = configurer.getUrlPathHelper();
        if (pathHelper != null) {
            mapping.setUrlPathHelper(pathHelper);
        }
        PathMatcher pathMatcher = configurer.getPathMatcher();
        if (pathMatcher != null) {
            mapping.setPathMatcher(pathMatcher);
        }

        return mapping;
    }

单单查阅内部方法，类的命名大致可以猜测出一些信息来，不过最终的使用还是要通过其他核心流程来分析。

HandlerAdpater

同理的方式可以看到核心的关注类

image.png

Servlet容器工作流程

DispatcherServlet#doDispatch()，可以认为是Servlet规范中的service()语义。

截取核心代码如下，并且将会按照入口核心源码来分析

HandlerExecutionChain mappedHandler = getHandler(processedRequest);
HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler());
ModelAndView mv = ha.handle(processedRequest, response, mappedHandler.getHandler());
processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException);

getHandler(processedRequest)

/**
     * Return the HandlerExecutionChain for this request.
     * <p>Tries all handler mappings in order.
     * @param request current HTTP request
     * @return the HandlerExecutionChain, or {@code null} if no handler could be found
     */
    protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {
        for (HandlerMapping hm : this.handlerMappings) {
            if (logger.isTraceEnabled()) {
                logger.trace(
                        "Testing handler map [" + hm + "] in DispatcherServlet with name '" + getServletName() + "'");
            }
            HandlerExecutionChain handler = hm.getHandler(request);
            if (handler != null) {
                return handler;
            }
        }
        return null;
    }

方法语义其实很简单，从注入的一堆HandlerMapping中查找合适的一个并返回。那么什么是合适的？查阅HandlerMapping中对于getHandler()方法的注解:

Return a handler and any interceptors for this request. The choice may be made
on request URL, session state, or any factor the implementing class chooses.

HandlerExecutionChain包含着真正的HandlerMapping，以及一系列的拦截器。通过DEBUG可以发现最终找到的对象为RequestMappingHandlerMapping，怎么匹配的呢？通过结果来反向推导原因。Spring框架中大量使用了模板方法，所以看类实现过程要关注子类与父类之间的关系。

RequestMappingHandlerMapping

类体系

先查阅整个类结构体系，相当复杂，不过不要紧，看关键点。

HandlerMapping <-- AbstractHandlerMapping <-- AbstractHandlerMethodMapping <-- RequestMappingInfoHandlerMapping <--RequestMappingHandlerMapping

初始化流程

RequestMappingHandlerMapping作为一个由Spring托管的Bean，在它初始化的生命周期中，有非常关键的一步，即afterPropertiesSet方法，跟踪上去，最终你会看到如下几个核心的方法:

//初始化HandlerMethods
AbstractHandlerMethodMapping#initHandlerMethods
// 判断这个类是否有@Controller 或者@RequestMapping
RequestMappingHandlerMapping#isHandler()
// 查找hanlder内部方法
AbstractHandlerMethodMapping#detectHandlerMethods()
// 找到handler内部带有标记的@RequestMapping的方法，包装成RequestMappingInfo
RequestMappingHandlerMapping#getMappingForMethod()
// 找到一个可以被调用的目标方法Method
AopUtils.selectInvocableMethod(entry.getKey(), userType)
// 将相信的handler，method等信息注册到MappingRegistry中，注册前会将信息包装成HandlerMethod
AbstractHandlerMethodMapping#registerHandlerMethod(handler, method, RequestMappingInfo)
// 注册，MappingRegistry有非常核心的Map，比如urlLookup
MappingRegistry#register(RequestMappingInfo, handler, Method)
最终的HandlerMethod包括了什么信息？

this.bean = bean;
this.beanType = ClassUtils.getUserClass(bean);
this.method = method;
this.bridgedMethod = BridgeMethodResolver.findBridgedMethod(method);
this.parameters = initMethodParameters();

注：这些信息最终可以通过反射来完成方法的调用。

在完成初始化之后，当进来时，如何完成URL与Controller中的Method的对应呢？

映射

AbstractHandlerMethodMapping#getHandlerInternal()
AbstractHandlerMethodMapping#lookupHandlerMethod()
MappingRegistry#getMappingsByUrl()
当完成初始化之后，通过请求的URL找到对应的HandlerMethod其实非常简单.

getHandlerAdapter()

通过RequestMappingHandlerMapping来找Adapter，先来看HandlerAdapter接口的定义：MVC framework SPI, allowing parameterization of the core MVC workflow.

它的核心在于，找到RequestMappingHandlerMapping来完成从请求到执行到响应的完整工作流程。

通过DEBUG可以非常快速定外找，需要关注的核心实现为RequestMappingHandlerAdapter.通过其父类实现的support()其实也可以非常快速确定，因为它支持的Handler类型为HandlerMethod.

handler()

RequestMappingHandlerAdapter

可以非常明显看到这个类内部包含着一系列的HttpMessageConverter，这些对象可以解决什么问题呢？

方法调用

RequestMappingHandlerAdapter#invokeHandlerMethod()
ServletInvocableHandlerMethod#invokeAndHandle()
InvocableHandlerMethod#invokeForRequest()
InvocableHandlerMethod#doInvoke()
// 最终方法执行
Method#invoke()

也就是说，HTTP请求进入SpringMVC应用之后，匹配到HandlerMethod，最终通过HandlerMethod中包含的Method对象，而Method通过Java反射即可完成方法调用。

完成调用的过程分两部分：

从HTTP中解析参数
将返回值进行处理（比如声明@ResponseBody）

参数解析

参数的解析以及映射是一件相当复杂的工作，比如

@ResponseBody
@RequestMapping("data")
fun userData(@RequestParam TransferObject json) : UserData {
    return UserData(...);
}

在一个完整的HTTP请求中，核心参数可能在URL上，也可以在Body上，当要完成参数解析时，需要从中取出参数，并按照方法所需入参进行封装，最后入参完成方法调用，欲深究请关注如下方法

InvocableHandlerMethod#getMethodArgumentValues()

返回值处理

返回值可能会有各式各样的结果，一般情况下可能是一个JSON对象，通过DEBUG可以看到核心类RequestResponseBodyMethodProcessor

public boolean supportsReturnType(MethodParameter returnType) {
        return (AnnotatedElementUtils.hasAnnotation(returnType.getContainingClass(), ResponseBody.class) ||
                returnType.hasMethodAnnotation(ResponseBody.class));
    }

从HTTP协议来看，在入参时就已经明确了响应体的类型，核心参数为：accept，常见比如application/json， text/html，等等。SpringMVC如何处理这个问题呢？请聚焦于MediaType

AbstractMessageConverterMethodProcessor#writeWithMessageConverters()

// 从http请求中取出来后进行解析
List<MediaType> requestedMediaTypes = getAcceptableMediaTypes(request);
// 根据返回值判断何时的MediaType
List<MediaType> producibleMediaTypes = getProducibleMediaTypes(request, valueType, declaredType);

比如上请求，根据返回值判断即为JSON，故而结果如下图：

image.png

MediaType将决定以何中HttpMessageConvert来完成对象的转换处理，以及流输出。

messageConverter.canWrite(declaredType, valueType, selectedMediaType)
messageConverter.write(outputValue, declaredType, selectedMediaType, outputMessage)

而判断的核心在于实现类的supportedMediaTypes参数值，比如：

public MappingJackson2HttpMessageConverter(ObjectMapper objectMapper) {
        super(objectMapper, MediaType.APPLICATION_JSON, new MediaType("application", "*+json"));
}

钩子函数

在将返回值写入到输出流中前，提供了钩子函数RequestResponseBodyAdviceChain

processDispatchResult()

完成请求的后置处理。

比如mappedHandler.triggerAfterCompletion(request, response, null)

其实是将所有的后置拦截器完成调用。

思考

看完了完整的流程后，如果需要对SpringMVC做一些优化，需要如何？

优化的层面往往是往下往上两个层面。

往下从使用层面去考虑，选用更适合SpringMVC框架的用法，比如URL匹配规则简单化
往上从优化层面去考虑，比如减少不必要的Bean创建，简化从HandlerMap, HandlerAdapter等的寻找链路，加快容器初始化，提高调用链路效率，等等

SpringMVC 核心源码分析

DispatcherServlet

静态初始化部分

构造函数

Servlet容器初始化

HandlerMapping

HandlerAdpater

Servlet容器工作流程

getHandler(processedRequest)

RequestMappingHandlerMapping

类体系

初始化流程

映射

getHandlerAdapter()

handler()

RequestMappingHandlerAdapter

方法调用

参数解析

返回值处理

钩子函数

processDispatchResult()

思考

相关文章

网友评论

延伸阅读

深度阅读

栏目导航

热点阅读

SSM