纸上得来终觉浅，绝知此事要躬行
留神: 本文 SpringBoot 版本为 2.5.2; JDK 版本 为 jdk 11.
前言：
前文：你理解SpringBoot启动时API相干信息是用什么数据结构存储的吗？（上篇）
写文的起因，前文说过就不再复述了。
问题大抵如下：
为什么浏览器向后端发动申请时，就晓得要找的是哪一个接口？采纳了什么样的匹配规定呢？
SpringBoot 后端是如何存储 API 接口信息的？又是拿什么数据结构存储的呢？
@ResponseBody@GetMapping("/test")public String test(){ return "test";}说实话，听他问完，我感觉我又不够卷了，几乎灵魂拷问，我一个答不进去。咱们一起去理解理解吧！
如果文章中有不足之处，请你肯定要及时批正！在此郑重感激。
启动流程
一、申请流程
其余的不看了,咱们就间接从 DispatcherServlet 处动手了.
咱们只看咱们关注的,不是咱们关注的,咱们就不做多探讨了.
这边同样也画了一个流程图给大家参考：
1.1、DispatcherServlet
咱们都相熟SpringMVC 解决申请的模式,就不多探讨了.间接肝了.0
1）doService
@Overrideprotected void doService(HttpServletRequest request, HttpServletResponse response) throws Exception { logRequest(request); // Keep a snapshot of the request attributes in case of an include, // to be able to restore the original attributes after the include. Map<String, Object> attributesSnapshot = null; if (WebUtils.isIncludeRequest(request)) { attributesSnapshot = new HashMap<>(); Enumeration<?> attrNames = request.getAttributeNames(); while (attrNames.hasMoreElements()) { String attrName = (String) attrNames.nextElement(); if (this.cleanupAfterInclude || attrName.startsWith(DEFAULT_STRATEGIES_PREFIX)) { attributesSnapshot.put(attrName, request.getAttribute(attrName)); } } } // 使框架对象可用于处理程序和视图对象。 request.setAttribute(WEB_APPLICATION_CONTEXT_ATTRIBUTE, getWebApplicationContext()); request.setAttribute(LOCALE_RESOLVER_ATTRIBUTE, this.localeResolver); request.setAttribute(THEME_RESOLVER_ATTRIBUTE, this.themeResolver); request.setAttribute(THEME_SOURCE_ATTRIBUTE, getThemeSource()); if (this.flashMapManager != null) { FlashMap inputFlashMap = this.flashMapManager.retrieveAndUpdate(request, response); if (inputFlashMap != null) { request.setAttribute(INPUT_FLASH_MAP_ATTRIBUTE, Collections.unmodifiableMap(inputFlashMap)); } request.setAttribute(OUTPUT_FLASH_MAP_ATTRIBUTE, new FlashMap()); request.setAttribute(FLASH_MAP_MANAGER_ATTRIBUTE, this.flashMapManager); } RequestPath previousRequestPath = null; if (this.parseRequestPath) { previousRequestPath = (RequestPath) request.getAttribute(ServletRequestPathUtils.PATH_ATTRIBUTE); ServletRequestPathUtils.parseAndCache(request); } try { // 从这里去下一步. doDispatch(request, response); } finally { if (!WebAsyncUtils.getAsyncManager(request).isConcurrentHandlingStarted()) { // Restore the original attribute snapshot, in case of an include. if (attributesSnapshot != null) { restoreAttributesAfterInclude(request, attributesSnapshot); } } if (this.parseRequestPath) { ServletRequestPathUtils.setParsedRequestPath(previousRequestPath, request); } }}2）doDispatch
protected void doDispatch(HttpServletRequest request, HttpServletResponse response) throws Exception { HttpServletRequest processedRequest = request; HandlerExecutionChain mappedHandler = null; boolean multipartRequestParsed = false; WebAsyncManager asyncManager = WebAsyncUtils.getAsyncManager(request); try { ModelAndView mv = null; Exception dispatchException = null; try { processedRequest = checkMultipart(request); multipartRequestParsed = (processedRequest != request); // Determine handler for the current request. // 获取匹配的执行链 这里就是咱们下一处入口了 mappedHandler = getHandler(processedRequest); if (mappedHandler == null) { noHandlerFound(processedRequest, response); return; } //返回此处理程序对象的 HandlerAdapter。 HandlerAdapter ha = getHandlerAdapter(mappedHandler.getHandler()); // Process last-modified header, if supported by the handler. String method = request.getMethod(); boolean isGet = HttpMethod.GET.matches(method); if (isGet || HttpMethod.HEAD.matches(method)) { long lastModified = ha.getLastModified(request, mappedHandler.getHandler()); if (new ServletWebRequest(request, response).checkNotModified(lastModified) && isGet) { return; } } if (!mappedHandler.applyPreHandle(processedRequest, response)) { return; } // Actually invoke the handler. //应用给定的处理程序来解决此申请。 在这外面反射执行业务办法 mv = ha.handle(processedRequest, response, mappedHandler.getHandler()); if (asyncManager.isConcurrentHandlingStarted()) { return; } applyDefaultViewName(processedRequest, mv); mappedHandler.applyPostHandle(processedRequest, response, mv); } catch (Exception ex) { dispatchException = ex; } catch (Throwable err) { // As of 4.3, we're processing Errors thrown from handler methods as well, // making them available for @ExceptionHandler methods and other scenarios. dispatchException = new NestedServletException("Handler dispatch failed", err); } processDispatchResult(processedRequest, response, mappedHandler, mv, dispatchException); } catch (Exception ex) { triggerAfterCompletion(processedRequest, response, mappedHandler, ex); } catch (Throwable err) { triggerAfterCompletion(processedRequest, response, mappedHandler, new NestedServletException("Handler processing failed", err)); } finally { if (asyncManager.isConcurrentHandlingStarted()) { // Instead of postHandle and afterCompletion if (mappedHandler != null) { mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response); } } else { // Clean up any resources used by a multipart request. if (multipartRequestParsed) { cleanupMultipart(processedRequest); } } }}3）getHandler
返回此申请的 HandlerExecutionChain。
按程序尝试所有处理程序映射。
@Nullableprotected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception { if (this.handlerMappings != null) { for (HandlerMapping mapping : this.handlerMappings) { //返回 HandlerExecutionChain 咱们从这里持续往下 HandlerExecutionChain handler = mapping.getHandler(request); if (handler != null) { return handler; } } } return null;}1.2、HandlerMapping
public interface HandlerMapping { //... 残余了其余的代码 /** 返回此申请的处理程序和任何拦截器。 能够依据申请 URL、会话状态或实现类抉择的任何因素进行抉择。 返回的 HandlerExecutionChain 蕴含一个处理程序对象，而不是标签接口，因而处理程序不受任何形式的束缚。 例如，能够编写 HandlerAdapter 以容许应用另一个框架的处理程序对象。 如果未找到匹配项，则返回null 。这不是谬误。 DispatcherServlet 将查问所有已注册的 HandlerMapping beans 以找到匹配项，只有在没有找到处理程序时才确定有谬误 */ @Nullable HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception;}1.3、AbstractHandlerMapping
AbstractHandlerMapping：HandlerMapping 实现的形象基类。 反对排序、默认处理程序、处理程序拦截器，包含由门路模式映射的处理程序拦截器。
public abstract class AbstractHandlerMapping extends WebApplicationObjectSupport implements HandlerMapping, Ordered, BeanNameAware { //.... /** 查找给定申请的处理程序，如果没有找到特定的处理程序，则回退到默认处理程序。 */ @Override @Nullable public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception { // 查找给定申请的处理程序，如果未找到特定申请，则返回null 。 // 咱们次要看这个办法，接着跟进去 Object handler = getHandlerInternal(request); if (handler == null) { handler = getDefaultHandler(); } if (handler == null) { return null; } // Bean name or resolved handler? if (handler instanceof String) { String handlerName = (String) handler; handler = obtainApplicationContext().getBean(handlerName); } // 确保存在拦截器和其他人的缓存查找门路 if (!ServletRequestPathUtils.hasCachedPath(request)) { initLookupPath(request); } //getHandlerExecutionChain():为给定的处理程序构建一个HandlerExecutionChain ，包含实用的拦截器。 HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request); // 跨域相干 没有去细看了 if (hasCorsConfigurationSource(handler) || CorsUtils.isPreFlightRequest(request)) { CorsConfiguration config = getCorsConfiguration(handler, request); if (getCorsConfigurationSource() != null) { CorsConfiguration globalConfig = getCorsConfigurationSource().getCorsConfiguration(request); config = (globalConfig != null ? globalConfig.combine(config) : config); } if (config != null) { config.validateAllowCredentials(); } executionChain = getCorsHandlerExecutionChain(request, executionChain, config); } return executionChain; } // ...}getHandlerInternal 办法定义在 AbstractHandlerMapping，但它是个形象办法，咱们往下看它实现，才通晓它做了什么。
/**查找给定申请的处理程序，如果未找到特定申请，则返回null 。 如果设置了一个null返回值将导致默认处理程序。*/@Nullableprotected abstract Object getHandlerInternal(HttpServletRequest request) throws Exception;咱们往下看他的实现：
1.4、AbstractHandlerMethodMapping< T >
1.4.1、getHandlerInternal
/*** 查找给定申请的处理程序办法。*/@Override@Nullableprotected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception { //initLookupPath办法的实现在下层类中 AbstractHandlerMapping 中 // 办法解释为：初始化用于申请映射的门路。 // lookupPath 变量见名思义，咱们能够晓得，其实它就是 查找门路 String lookupPath = initLookupPath(request); this.mappingRegistry.acquireReadLock(); try { //查找以后申请的最佳匹配处理程序办法。 如果找到多个匹配项，则抉择最佳匹配项 // 这里就关系到了咱们是如何进行匹配的啦。 HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request); return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null); } finally { this.mappingRegistry.releaseReadLock(); }}1.4.2、lookupHandlerMethod （匹配接口代码）
须要留神的是匹配办法时，是依据 @RequestMapping 外面的value门路来匹配的，如果匹配到的有多个，如你配置了通配符，也配置了准确配置，他都会匹配到放在一个汇合中，依据规定排序，而后取汇合的第一个元素。有趣味的能够看看这个排序的规定，实践上必定是门路越准确的会优先，具体代码实现如下：
/**查找以后申请的最佳匹配处理程序办法。 如果找到多个匹配项，则抉择最佳匹配项。咱们看这个doc 正文，就晓得这是个重点啦*/@Nullableprotected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception { List<Match> matches = new ArrayList<>(); //返回给定 URL 门路的匹配项。 List<T> directPathMatches = this.mappingRegistry.getMappingsByDirectPath(lookupPath); if (directPathMatches != null) { // 下文 addMatchingMappings(directPathMatches, matches, request); } if (matches.isEmpty()) { addMatchingMappings(this.mappingRegistry.getRegistrations().keySet(), matches, request); } if (!matches.isEmpty()) { // 这里也取出第一个，当没有多个匹配时，间接应用这个 Match bestMatch = matches.get(0); if (matches.size() > 1) { //排序规定 Comparator<Match> comparator = new MatchComparator(getMappingComparator(request)); //进行排序 matches.sort(comparator); // 取出第一个 bestMatch = matches.get(0); if (logger.isTraceEnabled()) { logger.trace(matches.size() + " matching mappings: " + matches); } // 跨域相干 if (CorsUtils.isPreFlightRequest(request)) { for (Match match : matches) { if (match.hasCorsConfig()) { return PREFLIGHT_AMBIGUOUS_MATCH; } } } else { Match secondBestMatch = matches.get(1); if (comparator.compare(bestMatch, secondBestMatch) == 0) { Method m1 = bestMatch.getHandlerMethod().getMethod(); Method m2 = secondBestMatch.getHandlerMethod().getMethod(); String uri = request.getRequestURI(); throw new IllegalStateException( "Ambiguous handler methods mapped for '" + uri + "': {" + m1 + ", " + m2 + "}"); } } } //这句代码剖析图在上面。 request.setAttribute(BEST_MATCHING_HANDLER_ATTRIBUTE, bestMatch.getHandlerMethod()); // 这句办法正文上就一句 在找到匹配的映射时调用。具体作用没有搞懂 handleMatch(bestMatch.mapping, lookupPath, request); return bestMatch.getHandlerMethod(); } else { return handleNoMatch(this.mappingRegistry.getRegistrations().keySet(), lookupPath, request); }}第二句中的 this.mappingRegistry，它就是一个private final MappingRegistry mappingRegistry = new MappingRegistry();
它的办法getMappingsByDirectPath(lookupPath) 办法，实在调用如下：
/**返回给定 URL 门路的匹配项。 */@Nullablepublic List<T> getMappingsByDirectPath(String urlPath) { return this.pathLookup.get(urlPath);}hxdm，看到这个 this.mappingRegistry 和 this.pathLookup 有没有一股子相熟感啊，它就是咱们启动时存储信息的类和数据结构啊，xd。
那这后果就十分明了了啊。
咱们获取到的List<T> directPathMatches 的这个 list 就是咱们启动时扫描到的所有接口，之后再通过排序，取第一个，找到最匹配的。
xdm，咱们完事了啊。
1.4.3、addMatchingMappings
private void addMatchingMappings(Collection<T> mappings, List<Match> matches, HttpServletRequest request) { for (T mapping : mappings) { //查看映射是否与以后申请匹配，并返回一个（可能是新的）映射与以后申请相干的条件。 T match = getMatchingMapping(mapping, request); if (match != null) { // 我看正文 Match 就是 曾经匹配的HandlerMethod 及其映射的包装器，用于在以后申请的上下文中将最佳匹配与比拟器进行比拟。 //这里的 this.mappingRegistry.getRegistrations() 返回的就是我的项目启动时注册的 被 RequestMapping 注解润饰的办法相干信息 //private final Map<T, MappingRegistration<T>> registry = new HashMap<>(); // 前面跟的 .get(mapping) 就是获取到咱们向后端申请的办法 // 这里的mapping 就是咱们申请的 url、形式 等。 matches.add(new Match(match, this.mappingRegistry.getRegistrations().get(mapping))); } }}这么说还是不太好说分明，咱们间接去办法调用处，看它扭转了什么了吧。
简略说就是将信息存储到 matches 变量中了。还有就是将匹配HandlerMethod的实例取出来了。
二、小结
- 扫描所有注册的Bean
- 遍历这些Bean，顺次判断是否是处理器，并检测其HandlerMethod
- 遍历Handler中的所有办法，找出其中被@RequestMapping注解标记的办法。
- 获取办法method上的@RequestMapping实例。
- 查看办法所属的类有没有@RequestMapping注解
- 将类档次的RequestMapping和办法级别的RequestMapping联合 (createRequestMappingInfo)
- 当申请达到时，去urlMap中需找匹配的url，以及获取对应mapping实例，而后去handlerMethods中获取匹配HandlerMethod实例。
- 后续就是SpringMVC 执行流程了。
- 将RequestMappingInfo实例以及处理器办法注册到缓存中。
写到这里根本能够答复完文前所说的三个问题了。
他问的是为什么浏览器在向后端发动申请的时候，就晓得要找的是哪一个API 接口，你们 SpringBoot 后端框架是如何存储API接口的信息的？是拿什么数据结构存储的呢？
第一个答案：将所有接口信息存进一个HashMap,申请时，取出相关联的接口，排序之后，匹配出最佳的 接口。
第二个答案:大抵就是和MappingRegistry 这个注册表类相干了。
第三个答案:咱们之前看到存储信息时,底层是用 HashMap 来存储的,那么咱们能够晓得它底层的数据结构就是 数组+链表+红黑树
三、后语
若不是小伙伴提起那三问，我想我也不会有如此兴致，去一步一步Debug浏览相干源码，此文多半可能会胎死腹中了。
在此非常感谢 @小宇。不瞒大家，他又邀请我一起去读 ORM 框架源码了。不过得好好等上一段时间了。
集体所谈：浏览源码的过程中，其实真的是充斥乏味和干燥的。
读懂了一些要害货色，就开心的不得了；而像“又遗记debug到哪了，思路又凉了"，就会开始满心埋怨（我经常骂完一两句），而后就持续的去看。
大家好，我是博主
宁在春：主页一名喜爱文艺却踏上编程这条路线的小青年。
心愿：
咱们，待别日相见时，都已有所成。
另外就只能说是在此提供一份个人见解。因文字功底有余、常识不足，写不出非常术语化的文章，望见谅。
如果感觉本文让你有所播种，心愿可能点个赞，给予一份激励。
也心愿大家可能踊跃交换。如有不足之处，请大家及时批正，在此郑重感激大家。
知乎 | 宁在春
简书 | 宁在春
CSDN | 宁在春
掘金 | 宁在春
博客园 | 宁在春