封面：舊日?qǐng)D片，有些懷念已經(jīng)逝去的夏天啊。

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

注意: 本文 SpringBoot 版本為 2.5.2; JDK 版本 為 jdk 11.

前言：

前文：你了解SpringBoot啟動(dòng)時(shí)API相關(guān)信息是用什么數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)的嗎？（上篇）

寫文的原因，我前文說過就不再復(fù)述了。

問題大致如下：

為什么瀏覽器向后端發(fā)起請(qǐng)求時(shí)，就知道要找的是哪一個(gè)接口？采用了什么樣的匹配規(guī)則呢？

SpringBoot 后端是如何存儲(chǔ) API 接口信息的？又是拿什么數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)的呢？

@ResponseBody @GetMapping("/test") public String test(){return "test"; }

說實(shí)話，聽他問完，我感覺我又不夠卷了，簡直靈魂拷問，我一個(gè)答不出來。我們一起去了解了解吧！

如果文章中有不足之處，請(qǐng)你一定要及時(shí)批正！在此鄭重感謝。

👉啟動(dòng)流程

一、請(qǐng)求流程

其他的不看了,我們就直接從 DispatcherServlet 處入手了.

我們只看我們關(guān)注的,不是我們關(guān)注的,我們就不做多討論了.

這邊同樣也畫了一個(gè)流程圖給大家參考：

1.1、DispatcherServlet

我們都熟悉SpringMVC 處理請(qǐng)求的模式,就不多討論了.直接肝了.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));}}}// 使框架對(duì)象可用于處理程序和視圖對(duì)象。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.// 獲取匹配的執(zhí)行鏈 這里就是我們下一處入口了mappedHandler = getHandler(processedRequest);if (mappedHandler == null) {noHandlerFound(processedRequest, response);return;}//返回此處理程序?qū)ο蟮?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.//使用給定的處理程序來處理此請(qǐng)求。 在這里面反射執(zhí)行業(yè)務(wù)方法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

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

@Nullable protected HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {if (this.handlerMappings != null) {for (HandlerMapping mapping : this.handlerMappings) {//返回 HandlerExecutionChain 我們從這里繼續(xù)往下HandlerExecutionChain handler = mapping.getHandler(request);if (handler != null) {return handler;}}}return null; }

1.2、HandlerMapping

public interface HandlerMapping {//... 剩余了其他的代碼/**返回此請(qǐng)求的處理程序和任何攔截器。 可以根據(jù)請(qǐng)求 URL、會(huì)話狀態(tài)或?qū)崿F(xiàn)類選擇的任何因素進(jìn)行選擇。返回的 HandlerExecutionChain 包含一個(gè)處理程序?qū)ο?#xff0c;而不是標(biāo)簽接口，因此處理程序不受任何方式的約束。 例如，可以編寫 HandlerAdapter 以允許使用另一個(gè)框架的處理程序?qū)ο蟆Ｈ绻凑业狡ヅ漤?xiàng)，則返回null 。這不是錯(cuò)誤。DispatcherServlet 將查詢所有已注冊(cè)的 HandlerMapping beans 以找到匹配項(xiàng)，只有在沒有找到處理程序時(shí)才確定有錯(cuò)誤*/@NullableHandlerExecutionChain getHandler(HttpServletRequest request) throws Exception; }

1.3、AbstractHandlerMapping

AbstractHandlerMapping：HandlerMapping 實(shí)現(xiàn)的抽象基類。 支持排序、默認(rèn)處理程序、處理程序攔截器，包括由路徑模式映射的處理程序攔截器。

public abstract class AbstractHandlerMapping extends WebApplicationObjectSupportimplements HandlerMapping, Ordered, BeanNameAware {//..../**查找給定請(qǐng)求的處理程序，如果沒有找到特定的處理程序，則回退到默認(rèn)處理程序。*/@Override@Nullablepublic final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception {// 查找給定請(qǐng)求的處理程序，如果未找到特定請(qǐng)求，則返回null 。 // 我們主要看這個(gè)方法，接著跟進(jìn)去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():為給定的處理程序構(gòu)建一個(gè)HandlerExecutionChain ，包括適用的攔截器。HandlerExecutionChain executionChain = getHandlerExecutionChain(handler, request);// 跨域相關(guān) 沒有去細(xì)看了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，但它是個(gè)抽象方法，我們往下看它實(shí)現(xiàn)，才知曉它做了什么。

/** 查找給定請(qǐng)求的處理程序，如果未找到特定請(qǐng)求，則返回null 。 如果設(shè)置了一個(gè)null返回值將導(dǎo)致默認(rèn)處理程序。 */ @Nullable protected abstract Object getHandlerInternal(HttpServletRequest request) throws Exception;

我們往下看他的實(shí)現(xiàn)：

1.4、AbstractHandlerMethodMapping< T >

1.4.1、getHandlerInternal

/** * 查找給定請(qǐng)求的處理程序方法。 */ @Override @Nullable protected HandlerMethod getHandlerInternal(HttpServletRequest request) throws Exception {//initLookupPath方法的實(shí)現(xiàn)在上層類中 AbstractHandlerMapping 中// 方法解釋為：初始化用于請(qǐng)求映射的路徑。// lookupPath 變量見名思義，我們可以知道，其實(shí)它就是 查找路徑String lookupPath = initLookupPath(request);this.mappingRegistry.acquireReadLock();try {//查找當(dāng)前請(qǐng)求的最佳匹配處理程序方法。 如果找到多個(gè)匹配項(xiàng)，則選擇最佳匹配項(xiàng)// 這里就關(guān)系到了我們是如何進(jìn)行匹配的啦。HandlerMethod handlerMethod = lookupHandlerMethod(lookupPath, request);return (handlerMethod != null ? handlerMethod.createWithResolvedBean() : null);}finally {this.mappingRegistry.releaseReadLock();} }

1.4.2、lookupHandlerMethod （匹配接口代碼）

需要注意的是匹配方法時(shí)，是根據(jù) @RequestMapping 里面的value路徑來匹配的，如果匹配到的有多個(gè)，如你配置了通配符，也配置了精確配置，他都會(huì)匹配到放在一個(gè)集合中，根據(jù)規(guī)則排序，然后取集合的第一個(gè)元素。有興趣的可以看看這個(gè)排序的規(guī)則，理論上肯定是路徑越精確的會(huì)優(yōu)先，具體代碼實(shí)現(xiàn)如下：

/** 查找當(dāng)前請(qǐng)求的最佳匹配處理程序方法。 如果找到多個(gè)匹配項(xiàng)，則選擇最佳匹配項(xiàng)。 我們看這個(gè)doc 注釋，就知道這是個(gè)重點(diǎn)啦 */ @Nullable protected HandlerMethod lookupHandlerMethod(String lookupPath, HttpServletRequest request) throws Exception {List<Match> matches = new ArrayList<>();//返回給定 URL 路徑的匹配項(xiàng)。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()) {// 這里也取出第一個(gè)，當(dāng)沒有多個(gè)匹配時(shí)，直接使用這個(gè)Match bestMatch = matches.get(0);if (matches.size() > 1) {//排序規(guī)則Comparator<Match> comparator = new MatchComparator(getMappingComparator(request));//進(jìn)行排序matches.sort(comparator);// 取出第一個(gè)bestMatch = matches.get(0);if (logger.isTraceEnabled()) {logger.trace(matches.size() + " matching mappings: " + matches);}// 跨域相關(guān)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());// 這句方法注釋上就一句 在找到匹配的映射時(shí)調(diào)用。具體作用沒有搞懂handleMatch(bestMatch.mapping, lookupPath, request);return bestMatch.getHandlerMethod();}else {return handleNoMatch(this.mappingRegistry.getRegistrations().keySet(), lookupPath, request);} }

第二句中的this.mappingRegistry，它就是一個(gè)private final MappingRegistry mappingRegistry = new MappingRegistry();

它的方法getMappingsByDirectPath(lookupPath) 方法，真實(shí)調(diào)用如下：

/**返回給定 URL 路徑的匹配項(xiàng)。 */ @Nullable public List<T> getMappingsByDirectPath(String urlPath) {return this.pathLookup.get(urlPath); }

hxdm，看到這個(gè) this.mappingRegistry 和 this.pathLookup 有沒有一股子熟悉感啊，它就是我們啟動(dòng)時(shí)存儲(chǔ)信息的類和數(shù)據(jù)結(jié)構(gòu)啊，xd。

那這結(jié)果就非常明了了啊。

我們獲取到的List<T> directPathMatches的這個(gè) list 就是我們啟動(dòng)時(shí)掃描到的所有接口，之后再經(jīng)過排序，取第一個(gè)，找到最匹配的。

xdm，我們完事了啊。

1.4.3、addMatchingMappings

private void addMatchingMappings(Collection<T> mappings, List<Match> matches, HttpServletRequest request) {for (T mapping : mappings) {//檢查映射是否與當(dāng)前請(qǐng)求匹配，并返回一個(gè)（可能是新的）映射與當(dāng)前請(qǐng)求相關(guān)的條件。T match = getMatchingMapping(mapping, request);if (match != null) {// 我看注釋 Match 就是 已經(jīng)匹配的HandlerMethod 及其映射的包裝器，用于在當(dāng)前請(qǐng)求的上下文中將最佳匹配與比較器進(jìn)行比較。//這里的 this.mappingRegistry.getRegistrations() 返回的就是項(xiàng)目啟動(dòng)時(shí)注冊(cè)的 被 RequestMapping 注解修飾的方法相關(guān)信息//private final Map<T, MappingRegistration<T>> registry = new HashMap<>();// 后面跟的 .get(mapping) 就是獲取到我們向后端請(qǐng)求的方法// 這里的mapping 就是我們請(qǐng)求的 url、方式 等。matches.add(new Match(match, this.mappingRegistry.getRegistrations().get(mapping)));}} }

這么說還是不太好說清楚，我們直接去方法調(diào)用處，看它改變了什么了吧。

簡單說就是將信息存儲(chǔ)到 matches 變量中了。還有就是將匹配HandlerMethod的實(shí)例取出來了。

二、小結(jié)

掃描所有注冊(cè)的Bean

遍歷這些Bean，依次判斷是否是處理器，并檢測(cè)其HandlerMethod

遍歷Handler中的所有方法，找出其中被@RequestMapping注解標(biāo)記的方法。

獲取方法method上的@RequestMapping實(shí)例。

檢查方法所屬的類有沒有@RequestMapping注解

將類層次的RequestMapping和方法級(jí)別的RequestMapping結(jié)合 (createRequestMappingInfo)

當(dāng)請(qǐng)求到達(dá)時(shí)，去urlMap中需找匹配的url，以及獲取對(duì)應(yīng)mapping實(shí)例，然后去handlerMethods中獲取匹配HandlerMethod實(shí)例。

后續(xù)就是SpringMVC 執(zhí)行流程了。

將RequestMappingInfo實(shí)例以及處理器方法注冊(cè)到緩存中。

寫到這里基本可以回答完文前所說的三個(gè)問題了。

他問的是為什么瀏覽器在向后端發(fā)起請(qǐng)求的時(shí)候，就知道要找的是哪一個(gè)API 接口，你們 SpringBoot 后端框架是如何存儲(chǔ)API接口的信息的？是拿什么數(shù)據(jù)結(jié)構(gòu)存儲(chǔ)的呢？

第一個(gè)答案：將所有接口信息存進(jìn)一個(gè)HashMap,請(qǐng)求時(shí)，取出相關(guān)聯(lián)的接口，排序之后，匹配出最佳的 接口。

第二個(gè)答案:大致就是和MappingRegistry 這個(gè)注冊(cè)表類相關(guān)了。

第三個(gè)答案:我們之前看到存儲(chǔ)信息時(shí),都是 HashMap 相關(guān)的類來存儲(chǔ)的,那么我們可以知道它底層的數(shù)據(jù)結(jié)構(gòu)就是 數(shù)組+鏈表+紅黑樹

三、后語

若不是小伙伴提起那三問，我想我也不會(huì)有如此興致，去一步一步Debug閱讀相關(guān)源碼，此文多半可能會(huì)胎死腹中了。

在此非常感謝 @小宇。不瞞大家，他又邀請(qǐng)我一起去讀 ORM 框架源碼了。不過得好好等上一段時(shí)間了。

個(gè)人所談：

閱讀源碼的過程中，其實(shí)真的是充滿有趣和枯燥的。

讀懂了一些關(guān)鍵東西，就開心的不得了；而像“又忘記debug到哪了，思路又涼了"，就會(huì)開始滿心抱怨（我常常罵完一兩句），然后就繼續(xù)的去看。

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

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

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

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

如果覺得本文讓你有所收獲，希望能夠點(diǎn)個(gè)贊，給予一份鼓勵(lì)。

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

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。