Spring是如何找到URL请求对应的Controller的

本文主要是介绍Spring是如何找到URL请求对应的Controller的，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

文章来源

原文作者：Spring MVC 原文地址:
https://blog.csdn.net/hl233211/article/details/77450697
http://ddrv.cn/a/58528
本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。

序：先贴一张SpringMVC整体的框架原理图

此文主要描述Spring在响应请求的时候是如何根据URL找到对应的处理方法(Handler Method)的。即上图中的第二步（版本号:4.3.4.RELEASE）。

读源码最好的方法是一边调试一边理解，直接靠读很可能最后的结果就是能看懂每行甚至每个方法的意思，但是一串联起来就完全懵圈了，至少我是这个样子的。

1，那么既然要调试，很明显就需要找调试的入口，阅读的起点就在请求分发的地方：DispatcherServlet.doDispatch

此处先大概过一下这个方法，立马我们可以理解根据请求获取对应的处理器主要就在这个方法：getHandler(processedRequest)

对应的方法详细实现：

这里可以发现，它的逻辑很简单，就是循环内存中的handlerMappings，请求每个handleMapping返回一个HandlerExecutionChain。这个HandlerExecutionChain主要是包括了一个handler（处理对象，Object类型），以及一个拦截器列表（拦截器非本次研究对象，先无视）。

OK，那代码阅读至此，我们第一个疑问是:

Q1:DispatcherServlet中的handlerMappings是什么，它是哪里来的？

2，然后我们继续看，下面的核心代码是hm.getHandler(request)方法，它被AbstractHandlerMapping这个抽象类实现。

它直接调用了自身定一个的一个抽象方法：getHandlerInternal,将返回的结果组装成HandlerExecutionChain类型。

AbstractHandlerMethodMapping这个class实现了这个抽象方法

该方法先根据request获取到请求的资源路劲(lookupPath)，然后调用lookupHandlerMethod方法。

这边代码稍微有点多，但是还是可以理解。它定义了一个matchs的列表，然后内存变量mappingRegistry根据lookupPath获取所有的匹配对象。

如果存在这个匹配对象，那么回调用addMatchingMappings方法将匹配的对象映射到matches上。

如果未匹配到这个lookupPath，那么则会循环mappingRegistry中每个Mapping来匹配该路劲（因为RequestMapping中定义的路劲可以有通配符）。

getMappingsByUrl方法：

此处又增加一个疑问：

Q2：这个mappingRegistry变量是何物，什么时候将Mapping结果保存的？

那么现在带着Q1和Q2，我们只需要再了解这个方法了：addMatchingMappings，至于后面的代码，只是看看有没有一个请求映射到多个处理方法，如果存在并且优先级还一样，那么就会报错：Ambiguous handler methods mapped for HTTP path。

3，继续往下，以下为addMatchingMappings方法的逻辑：

注意到AbstractHandlerMethodMapping这个class是个泛型抽象类 getMatchingMapping是个抽象方法，返回值为定义的泛型(T)，我们暂且把这个泛型成为[映射信息]。

根据方法名称，T getMatchingMapping(T,reqeust) ，根据映射信息和请求获取是否匹配，如果匹配则返回映射信息。

RequestMappingInfoHandlerMapping这个class继承了这个抽象类,泛型类型为：RequestMappingInfo。看看它的方法实现：

前五行根据字面意思是分别根据请求判断各要素是否匹配。后两者其实也是，逻辑大部分都一样。

至于为什么源码立马会拆开写，可能是后两者的match方法更加稍微耗时一点吧。

这里7个要素如果都匹配了的话，那么可以说这个[映射信息]就匹配成功了。(其中前六个为自带属性，最后一个为自定义属性）
7要素分别为：

1. methods : 请求方法匹配（POST/GET/DELETE/PUT等等)，对应RequestMapping注解的method
2. params : 请求参数匹配 例如myParam=myValue, 对应RequestMapping注解的params
3. headers:请求头信息(例如：My-Header!=myValue），对应RequestMapping的headers
4. consumes:提交内容类型(例如:application/json,text/html;),对应RequestMapping的consumes
5. produces:返回的内容类型(例如:application/json),对应RequestMapping的consumes
6. patterns:URL格式(例如:test/testDo),对应RequestMapping的value
7. 自定义条件，后续会针对它再写一篇博文。

这些要素的匹配逻辑比较简单，无非就是把请求中的属性和处理方法ReqeustMapping中的属性值比对是否匹配，此处不再做深入。

Q1:DispatcherServlet中的handlerMappings是什么，它是哪里来的？

DispatcherService的initHandlerMappings中初始化了这个成员变量。

逻辑无非就是从spring仓库中获取实现了HandleMapping接口的组件。

以我们常用的配置：annotation-driven为例，其对应的处理解析类为AnnotationDrivenBeanDefinitionParser，它的parse方法：

可以看到，它注册了RequestMappingHandlerMapping这个实现类，而RequestMappingHandlerMapping继承了RequestMappingInfoHandlerMapping

再如通过配置注解的WebMvcConfigurationSupport中，也将RequestMappingHandlerMapping注册在仓库中。

Q2：AbstractHandlerMethodMapping中的mappingRegistry变量是何物，什么时候将Mapping结果保存的？

主要的成员变量：

在AbstractHandlerMethodMapping中有个registerHandlerMethod方法，在初始化之后（afterPropertiesSet）对调用该方法

afterPropertiesSet -> initHandlerMethods ->detectHandlerMethods-> registerHandlerMethod

该方法的逻辑比较好理解，循环一个handler的所有内部方法，获取它的所有方法对应的匹配信息，并且将匹配信息保存在mappingRegistry中。

这里有个需要注意的是 getMappingForMethod 这个抽象方法就是抽取一个Handler里面Method对应的映射信息。

RequestMappingHandlerMapping的实现为：

先获取method对应的RequestMappingInfo，然后获取类对应的RequestMappingInfo（应为@RequestMapping也可以作为类的注解）最后两者进行combine。

combine逻辑即合并两个RequestMapping，比如类对应的path为 test,Method对应的path为 test1,那么最后合并的path即为 test/test1。

以下为Spring默认HandleMapping的类图：

好了，上述都是文字型的东西，下面匹配运行时数据强化记忆吧。

这篇关于Spring是如何找到URL请求对应的Controller的的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---