封面：舊日圖片，有些懷念已經逝去的夏天啊。

紙上得來終覺淺，絕知此事要躬行

注意: 本文 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

@Override protected 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 afterCompletionif (mappedHandler != null) {mappedHandler.applyAfterConcurrentHandlingStarted(processedRequest, response);}}else {// Clean up any resources used by a multipart request.if (multipartRequestParsed) {cleanupMultipart(processedRequest);}}} }

3）getHandler

返回此請求的 HandlerExecutionChain。
按順序嘗試所有處理程序映射。

@Nullable protected 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 以找到匹配項，只有在沒有找到處理程序時才確定有錯誤*/@NullableHandlerExecutionChain getHandler(HttpServletRequest request) throws Exception; }

1.3、AbstractHandlerMapping

AbstractHandlerMapping：HandlerMapping 實現的抽象基類。 支持排序、默認處理程序、處理程序攔截器，包括由路徑模式映射的處理程序攔截器。

public abstract class AbstractHandlerMapping extends WebApplicationObjectSupportimplements HandlerMapping, Ordered, BeanNameAware {//..../**查找給定請求的處理程序，如果沒有找到特定的處理程序，則回退到默認處理程序。*/@Override@Nullablepublic 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返回值將導致默認處理程序。 */ @Nullable protected abstract Object getHandlerInternal(HttpServletRequest request) throws Exception;

我們往下看他的實現：

1.4、AbstractHandlerMethodMapping< T >

1.4.1、getHandlerInternal

/** * 查找給定請求的處理程序方法。 */ @Override @Nullable protected 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 注釋，就知道這是個重點啦 */ @Nullable protected 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 路徑的匹配項。 */ @Nullable public 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到哪了，思路又涼了"，就會開始滿心抱怨（我常常罵完一兩句），然后就繼續的去看。

大家好，我是博主寧在春：主頁

一名喜歡文藝卻踏上編程這條道路的小青年。

希望：我們，待別日相見時，都已有所成。

另外就只能說是在此提供一份個人見解。因文字功底不足、知識缺乏，寫不出十分術語化的文章，望見諒。

如果覺得本文讓你有所收獲，希望能夠點個贊，給予一份鼓勵。

也希望大家能夠積極交流。如有不足之處，請大家及時批正，在此鄭重感謝大家。

掘友可以看看這👉 寧在春 | 掘金

總結

以上是生活随笔為你收集整理的你知道从浏览器发送请求给SpringBoot后端时，是如何准确找到哪个接口的？（下篇）学废了吗？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。