处理大致流程图
AbstractHandlerMethodMapping的lookupHandlerMethod
继续上次的getMappingsByUrl，我故意弄了个一对多的看看情况。
他会都加到matches中。
因为有两个所以这里需要排序，排序会根据注解RequestMapping中的属性来进行排序，比如参数个数，请求头个数等等，具体可以自己看下：
比如我这里比较方法个数：
排序后就这样：
所以又会bestMatch = matches.get(0);获取最好的方法：
如果排序完，发现第二个和第一个比较是相同的，那就不知道要选哪个，所以会报异常。
HandlerMethod的createWithResolvedBean
方法获取后，还要进行bean的创建，因为你此时获取的可能只是bean名字，因为前面创建HandlerMethod的时候只是放了beanName，没有进行实例化。
获取到实例后，重新创建一个HandlerMethod：
基本只是把属性重新赋值了下。
AbstractHandlerMapping的getHandlerExecutionChain获取执行链
其实这里就是要放入拦截器了，先创建一个执行链，然后遍历所有拦截器，如果匹配的话就加入其中。
protected HandlerExecutionChain getHandlerExecutionChain(Object handler, HttpServletRequest request) {
HandlerExecutionChain chain = (handler instanceof HandlerExecutionChain ?
(HandlerExecutionChain) handler : new HandlerExecutionChain(handler));//创建执行链
String lookupPath = this.urlPathHelper.getLookupPathForRequest(request, LOOKUP_PATH);
for (HandlerInterceptor interceptor : this.adaptedInterceptors) {
if (interceptor instanceof MappedInterceptor) {
MappedInterceptor mappedInterceptor = (MappedInterceptor) interceptor;
if (mappedInterceptor.matches(lookupPath, this.pathMatcher)) {
//进行uri匹配
chain.addInterceptor(mappedInterceptor.getInterceptor());
}
}
else {
chain.addInterceptor(interceptor);
}
}
return chain;
}
HandlerExecutionChain执行链
可以看到他定义了一个拦截器数组和列表，好像有点重复了。
或许是为了兼容构造方法吧：
拦截器为什么是MappedInterceptor类型的
我们要看拦截器怎么生成的，其实是在RequestMappingHandlerMapping实例化的方法里。
addInterceptors就是添加自定义的，里面还有好几层，是用一个代理WebMvcConfigurer的集合，里面就是我们自己配置类，要实现WebMvcConfigurer接口，实现添加拦截器方法addInterceptors即可。然后再加上下面两个。
关键在this.interceptors = registry.getInterceptors();，进行了处理：
因为拦截器只是一个接口，还需要有包含和排除等路径信息，所以将他们封装成了MappedInterceptor。
最后适配一下放入adaptedInterceptors中：
其他的一些逻辑就不讲了，执行链获取后直接就返回，表示找到了处理器了，至于说其他的处理器映射器后面会讲，先把大致的流程讲完，所以下一篇继续将后面的getHandlerAdapter获取处理器适配器。
好了，今天就到这里了，希望对学习理解有帮助，大神看见勿喷，仅为自己的学习理解，能力有限，请多包涵。