紙上得來終覺淺，絕知此事要躬行
注意: 本文 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 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。
按順序嘗試所有處理程序映射。
@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 以找到匹配項，只有在沒有找到處理程序時才確定有錯誤
*/
@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返回值將導致默認處理程序。
*/
@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到哪了，思路又涼了"，就會開始滿心抱怨（我常常罵完一兩句），然后就繼續的去看。
大家好，我是博主
寧在春：主頁一名喜歡文藝卻踏上編程這條道路的小青年。
希望：
我們，待別日相見時，都已有所成。
另外就只能說是在此提供一份個人見解。因文字功底不足、知識缺乏，寫不出十分術語化的文章，望見諒。
如果覺得本文讓你有所收獲，希望能夠點個贊，給予一份鼓勵。
也希望大家能夠積極交流。如有不足之處，請大家及時批正，在此鄭重感謝大家。