Spring源码之请求路径匹配路由方式

Spring源码之请求路径匹配路由方式

目录请求路径匹配路由入口进入上面方法SpringMVC 将请求找到匹配的处理初始化映射关系从映射关系中寻找匹配方法

请求路径匹配路由

在spring中，当一个请求过来的时候会做路径匹配，下面我们就从源码层面分析一下路径匹配。

示例：

@RequestMapping(value = "/user/{aid}/online/**", method = RequestMethod.GET)

我们一起看看这个方法是如何寻找的，和一些相应的工具类

入口

我的项目使用的是自动配置的RequestMappingHandlerMapping类，在getHandlerInternal()方法中：

HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);

上面这行是根据你的请求path和request去查找合适的method了。在项目启动的时候，Spring就把路径和对应的方法加载到了内存中。

进入上面方法

List directPathMatches = this.mappingRegistry.getMappingsByUrl(lookupPath);

if (directPathMatches != null) {

addMatchingMappings(directPathMatches, matches, request);

}

if (matches.isEmpty()) {

// No choice but to go through all mappings...

addMatchingMappings(this.mappingRegistry.getMappings().keySet(), matches, request);

}

可以看到如果根据lookupPath直接匹配上了，走第一个方法，如果没有，则需要根据规则匹配，走第二个方法。

mappingRegistry.getMappings().keySer()这个方法获取的类型为RequestMappingInfo类型，后面进入了RequestMappingInfo的getMatchingCondition()方法：

public RequestMappingInfo getMatchingCondition(HttpServletRequest request) {

RequestMethodsRequestCondition methods = this.methodsCondition.getMatchingCondition(request);

ParamsRequestCondition params = this.paramsCondition.getMatchingCondition(request);

HeadersRequestCondition headers = this.headersCondition.getMatchingCondition(request);

ConsumesRequestCondition consumes = this.consumesCondition.getMatchingCondition(request);

ProducesRequestCondition produces = this.producesCondition.getMatchingCondition(request);

if (methods == null || params == null || headers == null || consumes == null || produces == null) {

return null;

}

PatternsRequestCondition patterns = this.patternsCondition.getMatchingCondition(request);

if (patterns == null) {

return null;

}

可以看到代码里面会查看各种条件是否匹配，包括，请求方法methods，参数params,请求头headers,还出入参类型等相关的consumers,produces等，最后一行就是我们要找的路径匹配patternsCondition.getMatchingCondition(request)。

这个方法会走到PatternRequestCondition的getMatchingPattern方法，然后调用如下方法，获取pattern：

if (this.pathMatcher.match(pattern, lookupPath)) {

return pattern;

}

上面这个pathMatcher的类型就是AntPathMatcher类，就是通过调用AntPathMatcher类的match方法，查看是否匹配，然后返回pattern。

SpringMVC 将请求找到匹配的处理

在SpringMVC的模式下，浏览器的一个请求是如何映射到指定的controller的呢？

初始化映射关系

在web服务器启动时，Spring容器中会保存一个map的数据结构，里边记录这controller和url请求中的对应关系。那么这个map中的数据是如何来的呢？

首先来看AbstractHandlerMethodMapping的initHandlerMethods方法（至于为什么直接找到这个方法，我也是网上搜索的，之前的调用链没去纠结）

protected void initHandlerMethods() {

if (logger.isDebugEnabled()) {

logger.debug("Looking for request mappings in application context: " + getApplicationContext());

}

//获取Spring容器装配的所有bean的名称

String[] beanNames = (this.detectHandlerMethodsInAncestorContexts ?

BeanFactoryUtils.beanNamesForTypeIncludingAncestors(getApplicationContext(), Object.class) :

getApplicationContext().getBeanNamesForType(Object.class));

//遍历

for (String beanName : beanNames) {

//判断该bean是否有@controller或者@RequestMapping注解

if (!beanName.startsWith(SCOPED_TARGET_NAME_PREFIX) &&

isHandler(getApplicationContext().getType(beanName))){

//如果有上述注解，则需要保存对应关系

detectHandlerMethods(beanName);

}

}

handlerMethodsInitialized(getHandlerMethods());

}

protected void detectHandlerMethods(final Object handler) {

//获取传过来handler的类信息

Class> handlerType =

(handler instanceof String ? getApplicationContext().getType((String) handler) : handler.getClass());

// Avoid repeated calls to getMappingForMethod which would rebuild RequestMappingInfo instances

//初始化一个保存映射信息的map

final Map mappings = new IdentityHashMap();

final Class> userType = ClassUtils.getUserClass(handlerType);

Set methods = HandlerMethodSelector.selectMethods(userType, new MethodFilter() {

@Override

public boolean matches(Method method) {

//获取该类里所有方法的映射信息 T为RequestMappingInfo

//mapping值的形式为{[/test/test1],methods=[],params=[],headers=[],consumes=[],produces=[],custom=[]}

T mapping = getMappingForMethod(method, userType);

if (mapping != null) {

//将信息加入map

mappings.put(method, mapping);

return true;

}

else {

return false;

}

}

});

for (Method method : methods) {

//注册HandlerMethod，在里边进行一些重复验证等

registerHandlerMethod(handler, method, mappings.get(method));

}

}

上述方法中调用了一个比较重要的方法，getMappingForMethod，通过这个方法生成后续我们一直会用到的一个RequestMappingInfo对象。具体方法如下：

@Override

//该方法接收两个参数，一个是具体方法，一个是方法所在的类

protected RequestMappingInfo getMappingForMethod(Method method, Class> handlerType) {

RequestMappingInfo info = null;

//找到方法的@RequestMapping注解

RequestMapping methodAnnotation = AnnotationUtils.findAnnotation(method, RequestMapping.class);

if (methodAnnotation != null) {

//这个方法返回null

RequestCondition> methodCondition = getCustomMethodCondition(method);

//创建RequestMappingInfo对象

info = createRequestMappingInfo(methodAnnotation, methodCondition);

//找到类的@RequestMapping注解

RequestMapping typeAnnotation = AnnotationUtils.findAnnotation(handlerType, RequestMapping.class);

if (typeAnnotation != null) {

//该方法也返回一个null

RequestCondition> typeCondition = getCustomTypeCondition(handlerType);

//如果类和方法都有@RequestMapping注解，则进行combine操作

info = createRehttp://questMappingInfo(typeAnnotation, typeCondition).combine(info);

}

}

return info;

}

那么上述方法中调用的createRequestMappingInfo方法有事如何真正的创建出一个RequestMappingInfo对象的呢？

protected RequestMappingInfo createRequestMappingInfo(RequestMapping annotation, RequestCondition> customCondition) {

//拿到@RequestMapping注解上的value值

String[] patterns = resolveEmbeddedValuesInPatterns(annotation.value());

//创建一个RequestMappingInfo，参数为一堆condition，出了PatternsRequestCondition，其余全部使用@RequestMapping注解上的值

return new RequestMappingInfo(

annotation.name(),

new PatternsRequestCondition(patterns, getUrlPathHelper(), getPathMatcher(),

this.useSuffixPatternMatch, this.useTrailingSlashMatch, this.fileExtensions),

new RequestMethodsRequestCondition(annotation.method()),

new ParamsRequestCondition(annotation.params()),

new HeadersRequestCondition(annotation.headers()),

new ConsumesRequestCondition(annotation.consumes(), annotation.headers()),

new ProducesRequestCondition(annotation.produces(), annotation.headers(), this.contentNegotiationManager),

customCondition);

}

protected void registerHandlerMethod(Object handler, Method method, T mapping) {

//handler此处为带有@controller或者@RequestMapping的类的名称

//初始化一个HandlerMethod，包含一些类的名称和方法等信息

HandlerMethod newHandlerMethod = createHandlerMethod(handler, method);

HandlerMethod oldHandlerMethod = this.handlerMethods.get(mapping);

//判断是否有handlerMethods是否有重复数据，有则抛异常，没有则将其加入handlerMethods map中

if (oldHandlerMethod != null && !oldHandlerMethod.equals(newHandlerMethod)) {

throw new IllegalStateException("Ambiguous mapping found. Cannot map '" + newHandlerMethod.getBean() +

"' bean method \n" + newHandlerMethod + "\nto " + mapping + ": There is already '" +

oldHandlerMethod.getBean() + "' bean method\n" + oldHandlerMethod + " mapped.");

}

this.handlerMethods.put(mapping, newHandlerMethod);

if (logger.isInfoEnabled()) {

logger.info("Mapped \"" + mapping + "\" onto " + newHandlerMethod);

}

//将没有*号和问好的pattern加入到urlMap中

Set patterns = getMappingPathPatterns(mapping);

for (String pattern : patterns) {

if (!getPathMatcher().isPattern(pattern)) {

this.urlMap.add(pattern, mapping);

}

}

//维护一个nameMap，key为名字，格式为congroller类大写字母+#+方法名

//比如TestBank类的getBank方法，可以为TB#getBank

if (this.namingStrategy != null) {

String name = this.namingStrategy.getName(newHandlerMethod, mapping);

updateNameMap(name, newHandlerMethod);

}

}

由上述registerHandlerMethod方法我们可以看出，该方法共维护了三个map分别是：

handlermethods: key为RequestMappingInfo value为HandlerMethod

urlMap: key为没有*和？的pattern（比如/test/test1）value为RequestMappingInfo

nameMap: key为名字，格式为congroller类大写字母+#+方法名,比如TestBank类的getBank方法，key为TB#getBank

上述三个map在后续匹配浏览器请求用哪个方法来处理时会重点用到。

从映射关系中寻找匹配方法

那么DispatcherServlet是如何处理一个请求的呢？

我们从DispatcherServlet的doService方法来看起，该方法中，最终会调用到AbstractHandlerMethodMapping类的lookupHandlerMethod方法来确定这个请求应该由哪个方法处理，代码如下：

protected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception {

List<Match> matches = new ArrayList();

//从urlMap中寻找能匹配的处理方法

List directPathMatches = this.urlMap.get(lookupPath);

//如果从urlMap中找到匹配的处理方法，则调用addMatchingMappings方法，将匹配的方法放入matches集合

if (directPathMatches != null) {

addMatchingMappings(directPathMatches, matches, request);

}

//如果urlMap中没有找到直接匹配的方法

if (matches.isEmpty()) {

// No choice but to go through all mappings...

addMatchingMappings(this.handlerMethods.keySet(), matches, request);

}

if (!matches.isEmpty()) {

//如果找到了匹配的方法，先获取一个比较器

Comparator comparator = new MatchComparator(getMappingComparator(request));

//将匹配到的方法按照比较器排序

Collections.sort(matches, comparator);

if (logger.isTraceEnabled()) {

logger.trace("Found " + matches.size() + " matching mapping(s) for [" + lookupPath + "] : " + matches);

}

//如果成功匹配的方法只有一个，拿这个方法返回。如果匹配到多个方法，取最匹配的前两个进行比较。

//如果比较结果为0，则抛出没有找到唯一合适处理方法的异常

Match bestMatch = matches.get(0);

if (matches.size() > 1) {

Match secondBestMatch = matches.get(1);

if (comparator.compare(bestMatch, secondBestMatch) == 0) {

Method m1 = bestMatch.handlerMethod.getMethod();

Method m2 = secondBestMatch.handlerMethod.getMethod();

throw new IllegalStateException(

"Ambiguous handler methods mapped for HTTP path '" + request.getRequestURL() + "': {" +

m1 + ", " + m2 + "}");

}

}

handleMatch(bestMatch.mapping, lookupPath, request);

return bestMatch.handlerMethod;

}

else {

//没有找到匹配的则返回null

return handleNoMatch(handlerMethods.keySet(), lookupPath, request);

}

}

从上述代码可以看出，程序会先从this.urlMap中寻找是否有匹配的方法,那么这个urlMap中的数据是从什么时候加载的呢？我们网上翻看registerHandlerMethod方法，在web服务器启动时，该方法初始化了urlMap中的数据。

通过上述分析，大致可以了解到Spring容器是如何维护url和方法之间的映射关系，以及当收到请求时又是如何将请求匹配到正确的方法的。

至于没有分析到的当类和方法都有@RequestMapping注解时触发的combine操作究竟做了什么，当找到多个匹配方法是又是如何通过比较器进行排序的，我们下次再分析。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。