SpringMVC中的handlerMappings对象用法
从springmvc源码解析所用的例子，一个http://localhost:9090/web/hi?name=yang请求调用到下面的地方，发现一个特殊的对象handlermappings，通过请求uri去找handler的时候需要通过这个handlermapping来找，那么handlermappings是怎么样的呢？
从断点调试中，我们可以看到这handlermappings一共有5个，分别是webmvcconfigurationsupportxxx，requestmappinghandlermapping和beannameurlhandlermapping。
首先，我们先了解一下这个handlermappings是什么？从官方描述看，handlermappings是dispatcherservlet内部的一种bean类型，dispatcherservlet内部有很多bean类型，包括handlermapping，handleradapter，handlerexceptionresolver，viewresolver，localeresolver ，themesresolver，multipart resolver和flashmapmanager 。
其中handlermapping是一个将请求与用于预处理和后处理的拦截器列表一起映射起来的处理程序，除了webmvcconfigurationsupportxxx供用户自定义的映射处理器之外，
主要有以下两种内置类型：
（1）requestmappinghandlermapping(它支持@requestmapping修饰的方法)
（2）simpleurlhandlermapping(它为处理程序维护uri路径模式的显式注册)
一.handlermappings集合内部的元素是什么，有什么作用？
通过官方文档描述，handlermappings集合内部最主要有两种映射处理器类型requestmappinghandlermapping和simpleurlhandlermapping，它们分别用于处理不同类型的controller。
我们知道可以通过注解@controller或@restcontroller注解方式来声明一个controller，然后使用@requestmapping来修饰类名或方法名，这种方式其实是由requestmappinghandlermapping映射处理器来对请求地址和方法名进行映射的；那么simpleurlhandlermapping又用于处理哪种方式的controller呢，那就是采用实现controller接口或实现httprequesthandler接口的类，这种声明controller的方式是早期的做法现在在实际开发中用的比较少了但是也是springmvc所支持的。
对于requestmappinghandlermapping
这种类型的handlermapping是我们通过@requestmapping+请求地址来修饰方法时，会由这么一个映射器来对这种配置方式进行解析和映射处理，也就是说requestmappinghandlermapping类型的映射器是为注解声明方式的映射专门设计的，<k,v>映射关系会存储在这个handlermapping的map中。
对于simpleurlhandlermapping
这个映射器则是为继承controller类或实现httprequesthandler接口的类进行解析和映射处理的。
用代码举例子来验证，我们分别新建两个类分别实现controller接口和实现httprequesthandler接口，在类中写请求接收方法，那么通过这两种声明的controller通过请求地址在查询请求方法时就会由simpleurlhandlermapping进行存储和映射，<k,v>映射关系会存储在这个simpleurlhandlermapping的map中。
（1）实现controller接口的方式：
（2）实现httprequesthandler接口的方式：
然后重新进行debug，使用http://localhost:9090/beanweb或http://localhost:9090/beanweb2请求，就会看到在handlermapping中查找handler时会跳过第一种注解类型的requestmappinghandlermapping，而真正进行解析处理的就是第二种非注解方式simpleurlhandlermapping：
因此我们现在就明白了这个handlermappings映射处理器集合的数据是怎么样的，集合内存储的映射处理器分别处理怎么样的请求。那么这个集合数据是怎么初始化的呢？
二.handlermappings集合是怎么初始化的？
通过ideaj的find usages工具，在本文图一的this.handlermappings进行调用搜索，可以一层层找到如下调用链：
httpservletbean.init-->initservletbean()-->frameworkservlet.initservletbean-->
frameworkservlet.initwebapplicationcontext-->frameworkservlet.onrefresh
-->dispatcherservlet.onrefresh-->dispatcherservlet.initstrategies-->dispatcherservlet.inithandlermappings
-->dispatcherservlet.getdefaultstrategies-->strategies.add((t) strategy)
通过前面springmvc前两个流程的学习可知，dispatcherservlet继承了frameworkservlet，同时就集成了httpservlet，也就是说dispatcherservlet本质上就是一个servlet，那么在容器加载这个servlet的时候如果设置了<load-on-startup>加载时马上进行初始化，则在加载时会自动执行其init方法，于是就有了上面调用链的第一个httpservletbean.init入口。
我们的目的是找到哪里进行了handlermappings的核心操作，通过调用关系我们找到核心代码在dispatcherservlet.inithandlermappings：
通过上面代码返回的对象我们可以大胆推测matchingbeans就是我们要了解的handlermappings集合，这个方法内部完成了对多种类型handlermapping的初始化。通过查看我们重点关注的两种映射器对象值，可以分别看到<k,v>关系：
上面就可以看到前面我们提到的urllookup的map集合以及handlermap集合。为了了解这些不同的请求地址是怎么分配给不同类型的映射器来处理的，我们继续点开这个核心方法：
实际由下面这行代码完成了：
lbf.getbeansoftype(type, includenonsingletons, alloweagerinit)
而真正值得思考的逻辑在于
string[] beannames = getbeannamesfortype(type, includenonsingletons, alloweagerinit);
上面方法的逻辑就会自动生成一个有5种类型handlermapping的handlermappings，那么这5种映射器是怎么产生的呢？
通过核心代码我们可以知道，这里通过传入一个type="handlermapping"的类型，在beandefinitionnames的集合中匹配所有属于handlermapping类型的beanname，然后放入到result数组返回，然后在单例池中根据beanname获取对应的handlermapping类型的bean。
也就是说这些handlermapping映射处理器的生成是通过在beandefinition中匹配，如果匹配上了从单例池中获取对应类型的bean，因此最后的handlermappings中就有这5种类型了，至于请求路径和方法名怎么作为k,v绑定到对应映射器上的，由于个人阅读源码的能力有限这部分代码小编还尚未理解，作为小编的一个未解之谜吧。
当然，既然5种类型的映射器是通过bd来生成的，那这些beandefinition又是什么时候被加到spring容器中的呢？
这就不得不提一下关于handlermapping映射处理器的配置文件:dispatchservlet.properties文件，这个文件就定义了哪些内置使用的组件声明。
实际上，通过上面源码的调试，对于handleradaper的流程和handlermapping其实是很类似的。
总结
（1）handlermappings映射器集合内部一共有5个不同类型的映射器
分别是webmvcconfigurationsupportxxx，requestmappinghandlermapping和beannameurlhandlermapping，requestmappinghandlermapping映射处理器用于使用注解方式请求地址和方法名进行映射的controller，simpleurlhandlermapping用于实现controller接口或实现httprequesthandler接口的controller；
（2）handlermappings映射器集合初始化会经历一个调用链
在dispatchservlet启动时自动开始初始化，
httpservletbean.init-->initservletbean()-->frameworkservlet.initservletbean--> frameworkservlet.initwebapplicationcontext-->frameworkservlet.onrefresh -->dispatcherservlet.onrefresh-->dispatcherservlet.initstrategies-->dispatcherservlet.inithandlermappings -->dispatcherservlet.getdefaultstrategies-->strategies.add((t) strategy)
初始化的结果是产生一个handlermappings映射器集合，内部包含5种不同类型的映射器，每种映射器内部由map<k,v>来维护一个<请求地址，全限定方法名>的映射关系；
（3）handlermappings映射器集合的每个映射处理器
是在初始化时就生成了beandefinition，通过beandefinitionname和传入的type=handlermapping类型在所有beandefinitionnames集合中匹配所有的映射处理器，再从单例池中获取其对应bean实例放入handlermappings中；
（4）对于handleradaper的初始化和handlermapping流程是类似的
（5）<请求地址全限定方法名>的映射关系
在哪里生成并维护到映射处理器中的，这部分代码小编暂时还没能了解到。
三.handlermappings有什么扩展？
我们知道，springmvc中不能直接通过url来访问web-inf下的静态资源，如我们在工程webapp/jsp/新建一个1.jsp文件，通过
localhost:9090/jsp/1.jsp访问时会报如下404错误
但是springboot却可以通过url直接访问webapp,static,resource等包下面的静态资源，为什么会这样呢？原因就在于springboot对springmvc的handlermappings进行了自己的拓展。
之所以springmvc不能访问静态资源是因为对于这种访问静态资源的请求，在handlermappings内没有任何一个默认的映射器可以进行解析处理，因此自然这种请求就会被忽视。
对于springboot来说，它自己实现了一个针对这种访问静态资源的映射处理器并交由handlermappings来管理，因此就可以做到类似拓展，对于这个知识点在对springboot学习时看能否研究一下这个特殊的映射处理器是怎么样的，这里暂时知道这么一个结论即可。
到此关于handlermappings对象的研究学习暂时到此，回到springmvc的主线流程逻辑中继续学习后续的步骤。
以上为个人经验，希望能给大家一个参考，也希望大家多多支持。