序：先贴一张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的类图：
————————————————————–
好了，上述都是文字型的东西，下面匹配运行时数据强化记忆吧。
1，spring工程初始化时候，AbstractHandlerMethodMapping初始化后的mappingRegistry
它的urlLookup记录了每个URL后缀所对应的[映射信息]，这个映射信息是个数组。
为什么是个数组？因为可能有多个HandlerMethod对应同一个资源URL，只是比如method不同。
registry则记录一个[映射信息]对应应该由哪个Handler的哪个方法(handlerMethod)来执行
mappingLookup和registry类似，只是存的东西更多了一些。
2，解析request请求过程。
当处理url对应的处理匹配信息在urlLookup中不存在时，则循环上述mappingLookup中的所有[映射信息]，然后每个映射信息会判断其自己是否和request相符。
相符则加入到匹配列表中。
上述图中，由于请求是GET类型，而映射信息需要的是POST，两者不匹配,于是methods返回null，该映射信息匹配失败。
总结：
SpringMvc在工程启动时，会循环我们所有的存在@Controller的组件，并将带有RequestMapping注解方法的信息抽取成一个映射信息并持久化在内存(mappingRegistry)中。
例如这样：
而在根据request获取执行HandlerMethod的时候，假如请求为 http://domain:port/schma/test/test1
第一步获取根据request获取对应的url 为： test/test1,根据该值到上述的mappingRegistry中找到它对应的RequstMappingInfo（可能多个）。
(如果处理器中存在通配符的情况，比如 /test/test*,那么urlLookup中则无法匹配到，这时候会循环所有的RequstMappingInfo)
第二步，将第一步中的RequstMappingInfo分别去和当前url对匹配，比对项包括6要素+1自定义条件。全部匹配通过后则会认为该RequstMappingInfo可以处理该request
第三步，如果第二步中 没有匹配到RequstMappingInfo，则返回错误(404),如果有多个，则将其排序，若排序后前两者优先级一致，则返回错误（多个匹配），其他情况，则使用优先级最高的RequstMappingInfo到 mappingRegistry中的mappingLookup中获取对应的HandlerMethod。
至此一个request寻找处理器的流程结束。
