HandlerMapping之RequestMappingHandlerMapping作用详解

• 前言
• RequestMappingHandlerMapping
  • @RequestMapping
  • @RequestMapping的注册
• 总结

前言

上回我们知道HandlerMapping是用来寻找Handler的，并不与Handler的类型或者实现绑定，而是根据需要定义的。

那么为什么要单独给@RequestMapping实现一个HandlerMapping？这次咱们就来专门看看这个RequestMappingHandlerMapping。

RequestMappingHandlerMapping

名字来源

因为RequestMappingHandlerMapping是专门为@RequestMapping而生的，因此他的名字是这样来的：@RequestMapping的HandlerMapping了。

为什么不叫MethodHandlerMapping呢？

主要还是Handler是一个逻辑概念，MethodHandler了只是对目标方法进行了封装，并不是真正处理请求的。

真正处理请求的是我们@RequestMapping的方法。取个名字都给你讲道理。

@RequestMapping

在解答文章开头的问题前，我们先看看@RequestMapping

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Mapping
public @interface RequestMapping {
	/**
	 * 处理器的名字，支持类级别和方法级别，多个路径用#分割
	 */
	String name() default "";
	/**
	 * 匹配请求路径
	 */
	@AliasFor("path")
	String[] value() default {};
	/**
	 * 匹配请求路径
	 */
	@AliasFor("value")
	String[] path() default {};
	/**
	 * Http请求方法：可选GET, POST, HEAD, OPTIONS, PUT, PATCH, DELETE, TRACE
	 */
	RequestMethod[] method() default {};
	/**
	 * 匹配指定的地址栏参数
	 */
	String[] params() default {};
	/**
	 * 匹配特定的header
	 */
	String[] headers() default {};
	/**
	 * 匹配特定的Content-Type
	 */
	String[] consumes() default {};
	/**
	 * 匹配特定的Accept
	 */
	String[] produces() default {};
}

发现了吗，各位？他除了能根据URI匹配，还能根据请求头、请求方法、甚至是请求参数来匹配！

上回说的基于URL的两种HandlerMapping都不能满足他，因此必须推出一个更加强大、可扩展性更强的HandlerMapping——RequestMappingHandlerMapping

那么问题来了：

• @RequestMapping是在什么如何被解析的呢？
  • 我们很容易想到的就是，遍历容器中所有的对象，检查是否存在@Controller注解。存在，那就是控制器。然后接着遍历所有声明的public方法，检查是否存在@RequestMapping方法。这样，我们就找到了处理器方法。
• @RequestMapping是在什么时候被解析的呢？
  • 本着“谁使用，谁解析”的原则，他自然是被RequestMappingHandlerMapping解析的。而又因为@RequestMapping的寻找可太费功夫，不可能在提供映射服务时再来解析，只能是初始化时进行解析。因此实现InitializingBean进行初始化，是个选择。

没错，实际上，SpringMVC跟你想的一样。在InitializingBean的afterPropertiesSet方法中，完成了以3下件事：

1. 寻找@Controller的bean，并找到所有的@RequestMapping方法
2. 解析@RequestMapping封装成RequestMappingInfo
3. 将以上解析到的信息进行注册。

信息包括：

@RequestMapping的注册

前面的解析@RequestMapping到RequestMappingInfo，可以省略，比较简单。但是@RequestMapping的注册没办法省略。因为如果搞不清楚他是怎么注册的，也就没办法理解他是怎么寻找目标处理器的。

为了支撑@RequestMapping多样化的匹配条件，不能再像前面两款HanderMapping一样，简单粗暴的使用Map了。在 org.springframework.web.servlet.handler.AbstractHandlerMethodMapping 的内部定义了内部类，专门用来做注册中心，管理映射关系。

/**
	 * Mapping注册中心，可以理解为办事处
	 */
	class MappingRegistry {
		/**
		 * T是匹配条件的对象。MappingRegistration是注册的信息，可以理解为你要做事情。
		 * 对于RequestMappingHandlerMapping，T就是RequestMappingInfo
		 * MappingRegistration包括信息：RequestMappingInfo、HandlerMethod、directPaths、mappingName、corsConfig
		 */
		private final Map<T, MappingRegistration<T>> registry = new HashMap<>();
		/**
		 * Map<path, RequestMappingInfo>
		 */
		private final MultiValueMap<String, T> pathLookup = new LinkedMultiValueMap<>();
		/**
		 * Map<mappingName, List<HandlerMethod>>
		 */
		private final Map<String, List<HandlerMethod>> nameLookup = new ConcurrentHashMap<>();
	}

从他的属性，我们可以分析得到如下信息：

1. 直接通过请求路径来查找处理器时，需要经过pathLookup中转registry，最后拿到MappingRegistration才到达HandlerMethod.
2. 直接通过mappingName则可以直接找到HandlerMethod. 不过这个是Spring为了支持 <%@ taglib uri="//www.springframework.org/tags" prefix="s" %> 而提供的。跟我们平时使用没多大关系。

但是各位观众老爷，pathLookup找到的是一个，而mappingName能找到多个，这是咋回事？误会啊，pathLookup的value可不是简单的一个元素，而是多个！他是MultiValueMap，不是我们经常看到的地摊货HashMap。他可以一个key对应多个value。

但是为什么会有多个呢？或者说为什么需要保存多个呢？ 因为一个Handler可以处理多个请求，如果由多个Handler都能处理某一个请求的时候怎么办呢？况且SpringMVC还支持通配符匹配。umm…这一幕有点似曾相识，我们的nginx做路由转发的时候，不是也有类似的问题吗？这意味着在查找Handler的时候，我们还需要找到最佳的匹配。例如，/*相较于/hello，那肯定是/hello更精确，更合适啦。你看，多严谨！

总结

由于@RequestMapping支持灵活的请求匹配条件，而不只是简单的路径，只能开发出RequestMappingHandlerMapping进行支持。

RequestMappingHandlerMapping是通过InitializingBean进行初始化的，在这里完成@RequestMappingHandlerMapping的扫描和解析，以及注册。

HandlerMethod是在注册时进行封装的。获取Handler时，拿到的Handler就是HandlerMethod。

后面的适配器适配的，也是他。

RequestMappingHandlerMapping使用了InitializingBean做初始化，但是当我们自己在做初始化的时候，尤其是使用多种初始化方式的时候，应当要注意Spring的调用顺序，否则有可能发生NPE，或者获取不到目标属性的情况。

例如：同时在ApplicationContextAware、InitializingBean、@PostConstruct进行初始化。 为此，给大家找了官方的bean的生命周期