SpringMVC已经是广大Java程序员很熟悉的东西了,虽然现在已经大量使用SpringBoot和SpringCloud,但是其底层都是对SpringMVC的封装。
相信大家都用过SpringMVC的路径变量吧,代码示例如下:
@RequestMapping("/test/{id}")
public String test(@PathVariable("id") String id) {
return "id=" + id;
}
如上所示,id参数就是路径变量,{id}起到一个占位符的作用,在执行具体请求方法test()的时候,SpringMVC通过@PathVariable注解取到{id}对应的参数值,再通过反射赋值给String id这个参数。
但是一个项目中如果使用了大量的这种带有路径变量的@RequestMapping,会带来一定的性能问题。具体原因下面会详细说明,在此之前,先来梳理一下SpringMVC的请求执行流程。
SpringMVC的请求执行流程回顾
- 用户发起请求,请求由中央调度器DispatcherServlet接收,执行doDispatch方法;
- 中央调度器根据请求信息从处理器映射器中找到请求执行链(拦截器+自定义的处理器Controller);
- 中央调度器根据处理器类型获取到处理器适配器,通过处理器适配器先执行拦截器中的preHandler()方法,再执行自定义处理器中的方法;
- 适配器执行完自定义处理器方法后得到一个ModelAndView,然后再执行拦截器的PostHandle()方法;
- 中央调度器把ModelAndView交给视图解析器处理,得到一个视图(view)对象,然后将模型数据填充到视图(view);
- 把模型数据和View合并输出到Response(应答对象),即渲染视图,用户能看到的处理结果页面。
- 最后执行拦截器的afterCompletion()方法,执行流程结束。
SpringMVC根据请求Url找到对应处理器方法的过程
- 首先,SpringMVC容器在加载的时候,会扫描所有的@Controller或者@RestController修饰的类,将这些类中的@RequestMapping修饰的方法存放到处理器映射器(底层就是ConcurrentHashMap)中,存放的时候以@RequestMapping中声明的url作为key,对应方法的反射信息作为value;
- 用户请求到达中央调度器之后,会根据用户请求的url去处理器映射器中找到对应的处理器方法,然后交给处理器适配器,完成方法的执行,最后经过一系列梳理将数据返回给前端。
带有Url路径变量的请求问题
我们知道,如果是一个不带路径变量的请求url,则直接可以从处理器映射器的Map集合中精确匹配到对应的处理器方法。那带有路径参数的url呢,Map集合的key比如是 /test/{id},而浏览器请求的url是**/test/1**,浏览器的请求url这个时候相当于是动态的,显然无法直接匹配到对应的处理器方法。
那么SpringMVC是如何匹配url请求变量的呢?
我个人刚开始以为SpringMVC采用了什么高深的技术,于是就找时间看了下源码,核心代码在SpringMVC的这个方法:
org.springframework.web.servlet.handler.AbstractHandlerMethodMapping#lookupHandlerMethod
/**
* Look up the best-matching handler method for the current request.
* If multiple matches are found, the best match is selected.
* @param lookupPath mapping lookup path within the current servlet mapping
* @param request the current request
* @return the best-matching handler method, or {@code null} if no match
* @see #handleMatch(Object, String, HttpServletRequest)
* @see #handleNoMatch(Set, String, HttpServletRequest)
*/
@Nullable
protected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception {
//声明了一个集合保存已经匹配好的url路径映射关系
List<Match> matches = new ArrayList<>();
//根据用户的url信息先从处理器映射器的Map集合中查找映射关系
List<T> directPathMatches = this.mappingRegistry.getMappingsByUrl(lookupPath);
if (directPathMatches != null) {
/*
如果在处理器映射器中找到了,则添加到matches这个集合中,因为是从Map集合查找,
从时间复杂度考虑,是一个O(1)的过程
因为@RequestMapping的value属性是一个数组,即一个方法可以声明多个url,所以这里返回一个List
*/
addMatchingMappings(directPathMatches, matches, request);
}
if (matches.isEmpty()) {
// No choice but to go through all mappings...
//首先,这段英文注释是SpringMVC源码里的,意思就是没有办法,只能遍历所有的处理器映射关系
/*
能来到这一行,就说明上面在处理器映射器Map集合中没有精确匹配到对应的映射关系,
在这里就只能遍历整个处理器映射器,然后一个一个去匹配Url对应的映射关系。
具体匹配方式是采用了UrlMatch的一种占位符匹配机制,和正则表达式差不多,这里就不再展开了
*/
addMatchingMappings(this.mappingRegistry.getMappings().keySet(), matches, request);
}
if (!matches.isEmpty()) {
Comparator<Match> comparator = new MatchComparator(getMappingComparator(request));
matches.sort(comparator);
Match bestMatch = matches.get(0);
if (matches.size() > 1) {
if (logger.isTraceEnabled()) {
logger.trace(matches.size() + " matching mappings: " + matches);
}
if (CorsUtils.isPreFlightRequest(request)) {
return PREFLIGHT_AMBIGUOUS_MATCH;
}
Match secondBestMatch = matches.get(1);
if (comparator.compare(bestMatch, secondBestMatch) == 0) {
Method m1 = bestMatch.handlerMethod.getMethod();
Method m2 = secondBestMatch.handlerMethod.getMethod();
String uri = request.getRequestURI();
throw new IllegalStateException(
"Ambiguous handler methods mapped for '" + uri + "': {" + m1 + ", " + m2 + "}");
}
}
handleMatch(bestMatch.mapping, lookupPath, request);
return bestMatch.handlerMethod;
}
else {
return handleNoMatch(this.mappingRegistry.getMappings().keySet(), lookupPath, request);
}
}
从时间复杂度考虑,带有路径变量的url匹配是一个O(n)的复杂度,如下图所示:
如上图Debug所示,SpringMVC要从这一大堆的映射关系中通过for循环遍历去一个一个匹配判断,然后找到带有路径变量的url对应的处理器映射关系,如果项目中 @RequestMapping声明非常多的话,这将是一个非常耗时的过程。
总结
本人刚开始以为SpringMVC肯定会采用很高深高效的方式去解决带有路径变量Url的匹配问题,但是通过对源码的分析,其实并没有,依然采用了我们最能想到的循环遍历方式,这样一个O(n)复杂度的匹配过程。
以上纯属我个人分析,目前从源码表面上看,确实是一个循环遍历,然后逐个匹配判断的过程。如果是我个人对于SpringMVC的这种匹配机制理解不够,欢迎各位网友及时指出上文中分析不合理的地方,谢谢哈!