4.2.1.2 基於註解控制器流程的實現

上一節，我們詳細的分析了基於簡單控制器流程的實現，事實上，許多的簡單控制器的實現已經不被推薦使用。自從 2.5釋出以後， Spring開始鼓勵使用基於註解控制器的流程。基於註解的控制器流程具有實現方法簡單，程式程式碼清晰易讀等特點。

基於註解控制器的流程和基於簡單控制器的流程的實現非常相似，派遣器 Servlet在處理一個 HTTP請求的時候，它通過預設註解處理器對映 (DefaultAnnotationHandlerMapping)把 HTTP請求對映到響應的註解控制器 (@Contoller)，然後，把控制流傳給註解方法處理器介面卡 (AnnotationMethodHandlerAdapter)

。註解方法處理器介面卡並不是簡單的傳遞控制流給註解控制器，而是以一定規則查詢註解控制器裡面的處理器方法，並且通過反射的方式對映 HTTP 請求資訊到方法引數，然後使用反射呼叫方法，得到方法的返回結果後，再根據一定的規則把返回結果對映到模型和檢視物件，進而返回給作為總控制器的派遣器 Servlet。

事實上，預設註解處理器對映的實現重用了簡單控制器流程的處理器對映的實現體系結構。回顧上一小結中分析的 Bean名 URL處理器對映繼承自抽象探測 URL處理器對映，實現了其抽象方法 determineUrlsForHandler(),在這個方法實現中，把所有以左劃線 (/)開頭的 Bean名字註冊作為一個簡單的控制器。預設註解處理器對映的實現同樣也實現了抽象方法 determineUrlsForHandler()

，如果某個 Bean中使用了請求對映 (@RequestMappings)註解，則註冊這個 Bean作為一個註解控制器。如下類圖所示，

 

圖表 4 ‑20

如上圖所示，預設註解處理器對映實現了方法 determineUrlsForHandler(),查詢 Bean型別級別的請求對映註解和方法級別的請求對映註解，如果兩個級別的請求對映註解都存在，結合兩個級別的請求對映註解，否則使用方法級別的請求對映註解，構造出一個 URL Pattern集合，並且返回這個 URL Pattern集合，抽象探測 URL處理器對映就會使用這個集合的每一個元素作為關鍵字註冊當前的 Bean作為一個註解控制器。如下程式註釋，

@Override protected String[] determineUrlsForHandler(String beanName) { // 取得Web應用程式環境 ApplicationContext context = getApplicationContext(); // 取得當前Bean的型別 Class<?> handlerType = context.getType(beanName); // 找到型別級別的請求對映註解(@RequestMapping) RequestMapping mapping = context.findAnnotationOnBean(beanName, RequestMapping.class); if (mapping != null) { // 如果型別級別聲明瞭請求對映註解(@RequestMapping) // 快取處理器型別和型別級別請求對映註解(@RequestMapping) this.cachedMappings.put(handlerType, mapping); // 開始查詢所有應用在當前Bean的URL Pattern,這些URL Pattern是根據型別級別和方法級別的請求對映註解(@RequestMapping)計算得到的 Set<String> urls = new LinkedHashSet<String>(); // 取得型別級別的URL Pattern String[] typeLevelPatterns = mapping.value(); if (typeLevelPatterns.length > 0) { // 如果型別級別的請求對映註解(@RequestMapping)指定了URL Pattern，結合型別級別的URL Pattern和方法級別的URL Pattern String[] methodLevelPatterns = determineUrlsForHandlerMethods(handlerType); // 對於每個型別級別的URL Pattern結合每一個方法級別的URL Pattern for (String typeLevelPattern : typeLevelPatterns) { // 如果沒有使用斜線/開頭，則新增一個斜線/開頭，因為匹配時候的URI是以/開頭的 if (!typeLevelPattern.startsWith("/")) { typeLevelPattern = "/" + typeLevelPattern; } for (String methodLevelPattern : methodLevelPatterns) { // 結合任意一個型別級別的URL Pattern和任意一個方法級別的URL Pattern String combinedPattern = getPathMatcher().combine(typeLevelPattern, methodLevelPattern); // 新增結合的URL Pattern到結果集合 addUrlsForPath(urls, combinedPattern); } // 新增型別級別的URL Pattern到結果集合 addUrlsForPath(urls, typeLevelPattern); } // 返回URL Pattern結果集合 return StringUtils.toStringArray(urls); } else { // 如果型別級別的請求對映註解(@RequestMapping)沒有配置URL Pattern，則直接返回所有方法級別的請求對映註解(@RequestMapping)中的URL Pattern return determineUrlsForHandlerMethods(handlerType); } } else if (AnnotationUtils.findAnnotation(handlerType, Controller.class) != null) { // 如果沒有宣告型別級別的請求對映註解(@RequestMapping)，但是聲明瞭型別級別的控制器註解(@Controller)，則直接返回所有方法級別的請求對映註解(@RequestMapping)中的URL Pattern return determineUrlsForHandlerMethods(handlerType); } else { // 如果既沒有方法級別的請求對映註解(@RequestMapping)也沒有型別級別的控制器註解(@Controller)，則這個Bean不是註解控制器，返回null return null; } } protected String[] determineUrlsForHandlerMethods(Class<?> handlerType) { // 宣告成final是為了您名類的訪問 final Set<String> urls = new LinkedHashSet<String>(); // 如果是代理類則使用代理類實現的介面，否則用類本身來探測處理器方法 Class<?>[] handlerTypes = Proxy.isProxyClass(handlerType) ? handlerType.getInterfaces() : new Class<?>[]{handlerType}; // 對於每個型別，遍歷型別中的每個處理器方法 for (Class<?> currentHandlerType : handlerTypes) { ReflectionUtils.doWithMethods(currentHandlerType, new ReflectionUtils.MethodCallback() { public void doWith(Method method) { // 取得當前方法級別宣告的請求對映註解(@RequestMapping) RequestMapping mapping = AnnotationUtils.findAnnotation(method, RequestMapping.class); if (mapping != null) { // 如果方法級別的請求對映註解(@RequestMapping)存在 // 遍歷每一個請求對映註解(@RequestMapping)中註冊的URL Pattern String[] mappedPaths = mapping.value(); for (String mappedPath : mappedPaths) { // 新增到返回URL Pattern集合中 addUrlsForPath(urls, mappedPath); } } } }); } // 返回結果集合 return StringUtils.toStringArray(urls); } protected void addUrlsForPath(Set<String> urls, String path) { // 直接新增到結果集合中 urls.add(path); // 如果使用預設字尾，則新增另外兩個URL到URL Pattern集合中，用於匹配副檔名字尾和斜線/字尾 if (this.useDefaultSuffixPattern && path.indexOf('.') == -1 && !path.endsWith("/")) { urls.add(path + ".*"); urls.add(path + "/"); } }

在預設註解處理器對映中除了實現了提取註解處理器中配置的 URL Pattern 外，還改寫了一個校驗處理器的方法 validateHandler() ，這個方法的實現根據型別級別的請求對映的配置，校驗當前的請求是否能夠應用到這個處理器上。這個校驗方法是在派遣器 Servlet 將一個請求對映到響應的處理器的時候呼叫的。具體邏輯如下，

• 如果處理器型別級別請求對映定義了 HTTP 方法，則當前 HTTP 請求方法必須是請求對映定義的這些 HTTP 方法之一。
• 如果處理器型別級別請求對映定義了 HTTP 引數，則當前 HTTP 請求引數必須包含請求對映定義的所有的 HTTP 引數。
• 如果處理器型別級別請求對映定義了 HTTP 頭，則 HTTP 請求頭必須包含請求對映定義的所有的 HTTP 頭。

否則，這個處理器不能處理當前的 HTTP 請求，丟擲異常，終止處理。可見，型別級別的請求對映是優先校驗的，方法級別的請求對映是後來校驗的，所以，我們得出一下結論。

• 方法級別請求對映定義的 HTTP 方法必須是型別級別請求對映定義的 HTTP 方法的子集，否則沒有意義。
• 方法級別請求對映定義的 HTTP 引數可以多餘型別級別請求對映定義的 HTTP 引數。
• 方法級別請求對映定義的 HTTP 頭可以多餘型別級別請求對映定義的 HTTP 頭。

如下程式註釋，

//這個方法是在派遣器Servlet查詢到一個處理器物件時呼叫的 @Override protected void validateHandler(Object handler, HttpServletRequest request) throws Exception { // 從快取中得到宣告在處理器類級別的請求對映註解(@ReuqestMapping) RequestMapping mapping = this.cachedMappings.get(handler.getClass()); if (mapping == null) { // 如果快取中沒有，則直接取得，通常情況下，初始化的時候加入的 mapping = AnnotationUtils.findAnnotation(handler.getClass(), RequestMapping.class); } if (mapping != null) { // 校驗方法級別的對映資訊 validateMapping(mapping, request); } } protected void validateMapping(RequestMapping mapping, HttpServletRequest request) throws Exception { // 取得型別級別宣告的HTTP方法 RequestMethod[] mappedMethods = mapping.method(); if (!ServletAnnotationMappingUtils.checkRequestMethod(mappedMethods, request)) { // 如果當前請求的HTTP方法不是型別級別宣告的HTTP方法，而且型別級別聲明瞭一個或者一個以上的HTTP方法 String[] supportedMethods = new String[mappedMethods.length]; // 取得型別級別宣告的HTTP方法，這些方法是支援的HTTP方法 for (int i = 0; i < mappedMethods.length; i++) { supportedMethods[i] = mappedMethods[i].name(); } // 丟擲異常，提示哪些HTTP方法是支援的 throw new HttpRequestMethodNotSupportedException(request.getMethod(), supportedMethods); // 取得型別級別宣告的HTTP引數 String[] mappedParams = mapping.params(); if (!ServletAnnotationMappingUtils.checkParameters(mappedParams, request)) { // 如果當前請求的HTTP引數不包含型別級別宣告的HTTP引數，而且型別級別聲明瞭一個或者一個以上的HTTP引數 // 丟擲異常，提示那些引數應該包含在HTTP請求中 throw new UnsatisfiedServletRequestParameterException(mappedParams, request.getParameterMap()); } // 取得型別級別宣告的HTTP頭 String[] mappedHeaders = mapping.headers(); if (!ServletAnnotationMappingUtils.checkHeaders(mappedHeaders, request)) { // 如果當前請求的HTTP頭不包含型別級別宣告的HTTP頭，而且型別級別聲明瞭一個或者一個以上的HTTP頭 // 丟擲異常，提示哪些頭資訊應該包含在在HTTP請求中 throw new ServletRequestBindingException("Header conditions /"" + StringUtils.arrayToDelimitedString(mappedHeaders, ", ") + "/" not met for actual request"); } //可見，如果型別級別聲明瞭支援的HTTP方法，那麼，方法中宣告的方法應該是型別級別宣告HTTP方法的子集，引數和頭資訊的宣告則可以是遞增的 }

通過以上我們的分析，我們理解在基於註解控制器流程的實現中，預設註解處理器對映是通過處理器中宣告的請求對映註解註冊註解控制器以及查詢註解控制器的。作為總控制器的派遣器 Servlet 通過 HTTP 請求得到一個註解控制器，將註解控制器等傳給註解方法處理器介面卡進行處理器方法的呼叫，對處理器方法的呼叫是通過反射實現的，在呼叫之前，需要通過反射從請求引數，請求頭等探測所有需要的引數，再呼叫後返回方法結果後，再通過一定規則對映結果到模型和檢視物件。這個流程是在註解方法處理器介面卡類和相關的支援類實現的，如下類圖所示，

 

圖表 4 ‑21

如上圖所示，註解方法處理器介面卡類實現了處理器介面卡介面。在 handle() 方法的實現中，使用兩個輔助類 Servlet 處理器方法解析器 (ServletHandlerMethodResolver) 和 Servlet 處理器方法呼叫器 (ServletHandlerMethodInvoker) 利用反射的原理呼叫註解處理器中的處理器方法。在處理器方法呼叫之前，通過引數註解從 HTTP 請求中提取引數值，在處理器方法呼叫之後通過註解對映方法的返回值到模型和檢視物件，最後返回給派遣器 Servlet 進行檢視解析和檢視顯示。如下流程圖所示，

 

圖表 4 ‑22

根據上面流程圖顯示的順序，我們將深入的對程式碼進行剖析，派遣器 Servlet 從預設註解處理器對映得到了註解控制器後，將控制器傳遞給註解方法處理器介面卡的 handle() 方法， handle() 方法在進行通用的 HTTP 請求方法檢查和設定 HTTP 響應快取資訊後，根據需要對處理器方法進行同步或者非同步的呼叫，如下程式碼註釋，

public ModelAndView handle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 如果在處理器型別級別聲明瞭Session屬性(@SessionAttributes), 為這個處理器使用特殊的快取時間，這個特殊的快取時間通過屬性cacheSecondsForSessionAttributeHandlers配置 if (AnnotationUtils.findAnnotation(handler.getClass(), SessionAttributes.class) != null) { // 如果使用Session屬性管理，預設情況下，指導使用者不使用快取 checkAndPrepare(request, response, this.cacheSecondsForSessionAttributeHandlers, true); } 如果處理器級別沒有宣告Session屬性(@SessionAttributes)，則使用預設的快取配置 else { // 預設的快取配置是通過屬性cacheSeconds配置的 checkAndPrepare(request, response, true); } // 如果配置了Session內同步 if (this.synchronizeOnSession) { // 取得Session物件，如果沒有並不建立新的Session HttpSession session = request.getSession(false); // 如果Session存在 if (session != null) { // 取得Session互斥鎖物件，預設是Session物件自己 Object mutex = WebUtils.getSessionMutex(session); // 同步呼叫處理器方法 synchronized (mutex) { return invokeHandlerMethod(request, response, handler); } } } // 如果沒有配置Session內同步，或者還沒有建立Session物件，則直接呼叫處理器方法，不需要Session內同步 return invokeHandlerMethod(request, response, handler); } protected ModelAndView invokeHandlerMethod(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception { // 通過傳入的註解控制器構造一個方法解析器，一個型別的處理器對應一個Servlet處理器方法解析器 ServletHandlerMethodResolver methodResolver = getMethodResolver(handler); // 根據URL Pattern匹配，解析得到註解控制器中能夠處理當前請求的處理器方法 Method handlerMethod = methodResolver.resolveHandlerMethod(request); // 構造方法呼叫器，一個型別的處理器對應一個Servlet處理器方法呼叫器，處理器方法的呼叫邏輯就是在這個類中實現的 ServletHandlerMethodInvoker methodInvoker = new ServletHandlerMethodInvoker(methodResolver); // 構造Web請求物件，它是一個代理物件，包含請求和響應引用和資訊 ServletWebRequest webRequest = new ServletWebRequest(request, response); // 構造空的模型物件，用於方法呼叫過程中儲存必要的資料，狀態，結果等等 ExtendedModelMap implicitModel = new BindingAwareModelMap(); // 通過反射呼叫處理器方法，在這個方法實現中，通過反射和宣告在引數上的註解探測得到引數值，通過反射呼叫處理器方法得到返回值，更多的模型資料通過隱式模型返回 Object result = methodInvoker.invokeHandlerMethod(handlerMethod, handler, webRequest, implicitModel); // 通過方法結果的型別和其上宣告的註解，把結果和模型資料對映成為模型和檢視物件 ModelAndView mav = methodInvoker.getModelAndView(handlerMethod, handler.getClass(), result, implicitModel, webRequest); // 匯出Session屬性從模型到Session中，如果是繫結物件，同時匯出繫結結果 methodInvoker.updateModelAttributes(handler, (mav != null ? mav.getModel() : null), implicitModel, webRequest); return mav; }  

如上程式碼註釋，對於如何解析處理器方法，如何解析引數，如何呼叫處理器方法以及如果對映返回值等的實現都是封裝在處理器方法解析器和處理器方法呼叫器的實現中的，我們稍後會深入剖析這些邏輯的實現。

註解方法處理器介面卡也對處理器介面卡介面的另外兩個方法進行實現，如下程式碼註釋，

public boolean supports(Object handler) { // 對於一個Bean物件，只要其中有一個方法聲明瞭請求對映註解(@RequestMapping)，則這個Bean物件是註解控制器 return getMethodResolver(handler).hasHandlerMethods(); } public long getLastModified(HttpServletRequest request, Object handler) { // 註解方法控制器介面卡不支援最後修改操作，這可能是因為註解控制器基本應用到Form的處理過程，不需要支援最後修改操作，最後修改操作更多應用到請求資源上 // 【問題】下面的兩個實現可能會更好， // 1. 可以通過反射判斷註解控制器是不是已經實現了LastModified介面 // 2. 也可以擴充套件一個方法註解，宣告為這個註解的方法則用來返回實現返回最後修改的時間 return -1; }   

如上程式註釋可見， supports() 和 getLastModified() 的實現是非常簡單的，這裡不再詳細分析。通過上面的流程圖和程式碼註釋，我們也已經大體的瞭解了通過反射呼叫處理器方法的總體步驟，現在我們開始深入剖析註解方法處理器介面卡是如何實現方法解析，方法呼叫以及模型結果資料對映的。

如何解析處理器方法呢？

正如註解控制器的名字所示，它是基於註解資訊的控制器，這個控制器是一個普通的 Bean, 不需要實現任何介面或者繼承抽象類。一個註解控制器可能包含一個或者更多的處理器方法，這些處理器方法是用請求對映註解 (@RequestMapping) 標誌的，請求對映註解包含著用於匹配 HTTP 請求的 URI Pattern, 請求方法，請求引數，請求頭的資訊。這些在請求對映中宣告的資訊會用於匹配 HTTP 請求，如果匹配成功，則會使用匹配的處理器方法處理請求。我們首先分析請求對映註解 (@RequestMapping) 都包含哪些屬性資訊。

public @interface RequestMapping { // 用於匹配查詢路徑的URI Pattern，HTTP請求的查詢路徑必須匹配URI Pattern之一 String[] value() default {}; // 處理器方法所支援的HTTP方法，這些方法包括 GET, POST, HEAD, OPTIONS, PUT, DELETE, TRACE，HTTP請求方法必須是其中之一 RequestMethod[] method() default {}; // HTTP請求必須包含所有的這些引數 String[] params() default {}; // HTTP請求必須包含所有的這些頭 String[] headers() default {}; }  

如上程式碼所示，宣告在一個處理器方法或者處理器型別級別的請求對映註解可以包含 URI Pattern, 請求 方法，請求 引數， 請求頭等資訊。在匹配的時候， URI Pattern 是最重要的匹配資訊，如果沒有指定 URI Pattern ，則使用其餘資訊匹配。下面我們分析註解方法處理器介面卡是如何使用這些資訊匹配一個 HTTP 請求到一個處理器方法的。

首先，註解方法處理器介面卡為每一個處理器型別建立一個處理器方法解析器，處理器方法解析器通過反射分析處理器型別，並且取得所有聲明瞭請求對映註解的處理器方法，初始化繫結方法，模型屬性方法。如下程式碼所示，

private ServletHandlerMethodResolver(Class<?> handlerType) { // 使用父類的初始化方法進行初始化，一個處理器型別對應一個Servlet處理器方法解析器 init(handlerType); } public void init(Class<?> handlerType) { // 如果處理器型別是代理類，則獲得建立代理類指定的介面，否則使用處理器型別本身，這樣可以忽略代理類本身的方法invoke() Class<?>[] handlerTypes = Proxy.isProxyClass(handlerType) ? handlerType.getInterfaces() : new Class<?>[] {handlerType}; // 遍歷獲得的每一個型別 for (final Class<?> currentHandlerType : handlerTypes) { // 遍歷每個型別的每個方法 ReflectionUtils.doWithMethods(currentHandlerType, new ReflectionUtils.MethodCallback() { public void doWith(Method method) { // 如果這是介面的方法，取得實現介面的代理類中的物件的方法，這樣主要是忽略代理類本身的方法invoke() Method specificMethod = ClassUtils.getMostSpecificMethod(method, currentHandlerType); // 如果是處理器方法，儲存處理器方法 if (isHandlerMethod(method)) { handlerMethods.add(specificMethod); } // 如果是初始化繫結方法，儲存初始化繫結方法 else if (method.isAnnotationPresent(InitBinder.class)) { initBinderMethods.add(specificMethod); } // 如果是模型屬性方法，儲存模型屬性方法 else if (method.isAnnotationPresent(ModelAttribute.class)) { modelAttributeMethods.add(specificMethod); } } // 跳過橋樑方法，橋樑方法是編譯器產生，用來解決模板的方法的過載問題的 }, ReflectionUtils.NON_BRIDGED_METHODS); } // 取得型別級別的請求對映註解 this.typeLevelMapping = AnnotationUtils.findAnnotation(handlerType, RequestMapping.class); // 取得型別級別的Session屬性註解 SessionAttributes sessionAttributes = handlerType.getAnnotation(SessionAttributes.class); this.sessionAttributesFound = (sessionAttributes != null); // 如果存在型別級別的Session屬性註解 if (this.sessionAttributesFound) { // 儲存型別級別的Session屬性註解宣告的屬性名字或者型別 this.sessionAttributeNames.addAll(Arrays.asList(sessionAttributes.value())); this.sessionAttributeTypes.addAll(Arrays.asList(sessionAttributes.types())); } } protected boolean isHandlerMethod(Method method) { // 如果方法上存在請求對映註解，則這個方法是處理器方法 return AnnotationUtils.findAnnotation(method, RequestMapping.class) != null; }  

我們看到，對於一個處理器型別初始化一個處理器方法解析器，處理器方法解析器在解析處理器方法時使用了一個複雜的邏輯決定這些方法中的哪些方法可以處理當前 HTTP 請求。如果多個處理器方法可以處理當前的請求，那麼選擇最佳匹配的處理器方法。以下詳細分析這個工作流程。

在初始化階段，我們已經儲存了所有聲明瞭請求對映註解的處理器方法。現在我們遍歷所有的處理器方法，判斷是否此方法支援當前的 HTTP 請求。

如果請求對映註解的處理器方法包含 URI Pattern 的資訊，那麼對於每一個 URI Pattern ，則檢視是否存在型別級別的 URI Pattern ，如果存在，則結合型別級別的 URI Pattern 。否則，如果最佳匹配的 URI Pattern 存在，則結合最佳匹配的 URI Pattern 。否則單獨使用處理器方法級別的 URI Pattern 匹配當前的查詢路徑。如果 URI Pattern 匹配成功，檢視是否 HTTP 請求匹配宣告的請求方法，請求引數和請求頭。如果這些資訊都匹配成功，則添加當前 URI Pattern 到匹配路徑集合中，並通過路徑匹配對比器對匹配路徑集合進行排序，同事標識當前處理器方法為匹配。

如果請求對映註解的處理器方法不包含 URI Pattern 的資訊，則只需要檢視是否匹配宣告的請求方法，請求引數和請求頭。如果這些資訊匹配，則認為當前處理器方法為匹配。一種特殊情況是，如果請求對映註解中沒有宣告 HTTP 方法和引數，那麼首先使用處理器方法名解析器解析處理器方法名，如果解析的方法名和當前處理器方法相同，則認為當前處理器方法為匹配。預設的方法名解析器是通過去掉 URI 最後一部分的檔名副檔名得到的。

如果某一個處理器方法匹配，儲存這個處理器方法到匹配的處理器方法集合中。如果處理器集合中已經存在一個處理器方法，而且已存處理器方法和現在處理器方法不是同一個處理器方法，那麼我們需要解析衝突。在這種情況下，如果沒有路徑資訊，我們需要使用方法名解析器解析最佳處理器方法。處理規則如下，

1.        如果已存處理器方法和當前處理器方法名相同，則使用後解析的方法。

2.        否則，如果解析的方法名和已存處理器方法同名，繼續使用已存處理器方法。如果解析的方法名和當前處理器方法同名，則使用當前處理器方法。

3.        如果解析的方法名既不等於當前處理器方法也不等於已存的處理器方法，則丟擲異常，終止處理。

根據上面的邏輯分析，最終如果有一個或者多個處理器方法匹配當前 HTTP 請求，則通過請求對映資訊對比器找到最佳匹配的處理器方法。如下程式碼所示，

public Method resolveHandlerMethod(HttpServletRequest request) throws ServletException { // 取得查詢路徑，查詢路徑是URI去掉應用程式環境部分和Servlet環境部分的剩餘部分 String lookupPath = urlPathHelper.getLookupPathForRequest(request); // 取得URL對比器，如果有多個URI Pattern匹配，用於對比找到最佳匹配 Comparator<String> pathComparator = pathMatcher.getPatternComparator(lookupPath); // 用於儲存請求對映資訊到處理器方法的對映 Map<RequestMappingInfo, Method> targetHandlerMethods = new LinkedHashMap<RequestMappingInfo, Method>(); Set<String> allowedMethods = new LinkedHashSet<String>(7); String resolvedMethodName = null; // 遍歷每一個處理器方法 for (Method handlerMethod : getHandlerMethods()) { RequestMappingInfo mappingInfo = new RequestMappingInfo(); // 取得處理器方法的請求對映註解 RequestMapping mapping = AnnotationUtils.findAnnotation(handlerMethod, RequestMapping.class); // 取得宣告在請求對映註解上的路徑資訊，也就是URI Pattern mappingInfo.paths = mapping.value(); // 如果處理器型別級別沒有宣告處理器對映或者方法級別處理器對映包含的HTTP方法資訊不同於型別級別處理器對映包含的HTTP方法資訊，則使用方法級別的宣告資訊 if (!hasTypeLevelMapping() || !Arrays.equals(mapping.method(), getTypeLevelMapping().method())) { mappingInfo.methods = mapping.method(); } // 如果處理器型別級別沒有宣告處理器對映或者方法級別處理器對映包含的HTTP引數資訊不同於型別級別處理器對映包含的HTTP引數資訊，則使用方法級別的宣告資訊 if (!hasTypeLevelMapping() || !Arrays.equals(mapping.params(), getTypeLevelMapping().params())) { mappingInfo.params = mapping.params(); } // 如果處理器型別級別沒有宣告處理器對映或者方法級別處理器對映包含的HTTP頭資訊不同於型別級別處理器對映包含的HTTP頭資訊，則使用方法級別的宣告資訊 if (!hasTypeLevelMapping() || !Arrays.equals(mapping.headers(), getTypeLevelMapping().headers())) { mappingInfo.headers = mapping.headers(); } boolean match = false; // 如果URI Pattern存在，則先匹配URI if (mappingInfo.paths.length > 0) { List<String> matchedPaths = new ArrayList<String>(mappingInfo.paths.length); for (String methodLevelPattern : mappingInfo.paths) { // 取得匹配的URI Pattern String matchedPattern = getMatchedPattern(methodLevelPattern, lookupPath, request); // 如果取得的URI pattern不為空，則說明這個URI Pattern匹配成功 if (matchedPattern != null) { // 匹配HTTP方法，引數和頭等資訊 if (mappingInfo.matches(request)) { match = true; // 記錄匹配的URI Pattern matchedPaths.add(matchedPattern); } else { // 否則如果匹配失敗，記錄支援的HTTP方法，用來構造提示使用者資訊 for (RequestMethod requestMethod : mappingInfo.methods) { allowedMethods.add(requestMethod.toString()); } break; } } } // 排序匹配的URI Pattern集合 Collections.sort(matchedPaths, pathComparator); // 設定匹配的URI Pattern資訊到請求對映資訊中 mappingInfo.matchedPaths = matchedPaths; } // 如果URI Pattern不存在，則只需要匹配HTTP方法，引數和請求頭 else { // 則只需要匹配HTTP方法，引數和請求頭 match = mappingInfo.matches(request); // 如果沒有宣告請求方法和請求引數（可能僅僅請求頭匹配），則使用方法名解析器解析處理器方法，如果方法名解析器解析的方法和當前方法不同名，則匹配失敗 if (match && mappingInfo.methods.length == 0 && mappingInfo.params.length == 0 && resolvedMethodName != null && !resolvedMethodName.equals(handlerMethod.getName())) { match = false; } else { // 否則如果匹配失敗，否則記錄支援的HTTP方法，用來構造提示使用者資訊 for (RequestMethod requestMethod : mappingInfo.methods) { allowedMethods.add(requestMethod.toString()); } } } // 如果這個處理器方法和當前的HTTP請求匹配成功 if (match) { // 儲存請求對映資訊到當前處理器方法的對映，如果有已存的處理器方法，則取得已存的處理器方法，這意味著對同一個請求對映資訊配置了兩個處理器方法 Method oldMappedMethod = targetHandlerMethods.put(mappingInfo, handlerMethod); // 如果已存的處理器方法不同於當前處理器方法 if (oldMappedMethod != null && oldMappedMethod != handlerMethod) { // 如果請求對映註解中沒有URI Pattern宣告資訊，則使用方法名解析器解析衝突 if (methodNameResolver != null && mappingInfo.paths.length == 0) { // 如果已存處理器方法和當前處理器方法名不同 if (!oldMappedMethod.getName().equals(handlerMethod.getName())) { if (resolvedMethodName == null) { // 使用方法名解析器解析方法名 resolvedMethodName = methodNameResolver.getHandlerMethodName(request); } // 如果解析方法名不等於已存方法名，則拋棄已存方法 if (!resolvedMethodName.equals(oldMappedMethod.getName())) { oldMappedMethod = null; } // 如果解析方法名不等於當前方法名 if (!resolvedMethodName.equals(handlerMethod.getName())) { // 如果已存方法名沒有被拋棄，也就是解析方法名等於已存方法名 if (oldMappedMethod != null) { // 恢復並仍然使用已存方法名 targetHandlerMethods.put(mappingInfo, oldMappedMethod); oldMappedMethod = null; } else { // 解析方法名既不等於已存方法名也不等於當前方法名 targetHandlerMethods.remove(mappingInfo); } } } } // 解析方法名既不等於已存方法名也不等於當前方法名 if (oldMappedMethod != null) { throw new IllegalStateException( "Ambiguous handler methods mapped for HTTP path '" + lookupPath + "': {" + oldMappedMethod + ", " + handlerMethod + "}. If you intend to handle the same path in multiple methods, then factor " + "them out into a dedicated handler class with that path mapped at the type level!"); } } } } // 如果有一個或者多個處理器方法匹配 if (!targetHandlerMethods.isEmpty()) { // 取得所有匹配的請求對映資訊 List<RequestMappingInfo> matches = new ArrayList<RequestMappingInfo>(targetHandlerMethods.keySet()); // 獲得可以對請求對映資訊排列的對比器 RequestMappingInfoComparator requestMappingInfoComparator = new RequestMappingInfoComparator(pathComparator); // 排序 Collections.sort(matches, requestMappingInfoComparator); // 第一個為最佳匹配處理器方法 RequestMappingInfo bestMappingMatch = matches.get(0); // 取得最佳匹配處理器方法的最佳匹配路徑 String bestMatchedPath = bestMappingMatch.bestMatchedPath(); if (bestMatchedPath != null) { // 如果存在最佳匹配路徑，則提取模板變數 extractHandlerMethodUriTemplates(bestMatchedPath, lookupPath, request); } // 返回處理器方法 return targetHandlerMethods.get(bestMappingMatch); } // 如果沒有處理器方法匹配 else { // 當URI Pattern匹配或者沒有宣告URI Pattern的時候，如果HTTP方法，請求引數或者頭資訊不匹配，則提示HTTP方法不支援，並且提示那些HTTP方法支援 if (!allowedMethods.isEmpty()) { throw new HttpRequestMethodNotSupportedException(request.getMethod(), StringUtils.toStringArray(allowedMethods)); } // 否則提示使用者沒有請求處理器方法 else { throw new NoSuchRequestHandlingMethodException(lookupPath, request.getMethod(), request.getParameterMap()); } } } private String getMatchedPattern(String methodLevelPattern, String lookupPath, HttpServletRequest request) { // 如果型別級別聲明瞭請求對映註解的URI Pattern if (hasTypeLevelMapping() && (!ObjectUtils.isEmpty(getTypeLevelMapping().value()))) { // 取得型別級別宣告的請求對映註解的URI Pattern String[] typeLevelPatterns = getTypeLevelMapping().value(); // 遍歷每一個URI Pattern for (String typeLevelPattern : typeLevelPatterns) { // 補充URI字首 if (!typeLevelPattern.startsWith("/")) { typeLevelPattern = "/" + typeLevelPattern; } // 結合方法級別的URL Pattern String combinedPattern = pathMatcher.combine(typeLevelPattern, methodLevelPattern); // 如果查詢路徑匹配結合的URL Pattern if (isPathMatchInternal(combinedPattern, lookupPath)) { // 返回匹配結合的URL Pattern return combinedPattern; } } // 如果無法匹配，則返回空 return null; } // 取得最佳匹配URI Pattern String bestMatchingPattern = (String) request.getAttribute(HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE); // 如果存在最佳匹配URL Pattern if (StringUtils.hasText(bestMatchingPattern)) { // 結合最佳匹配URL Pattern和方法級別的URI Pattern String combinedPattern = pathMatcher.combine(bestMatchingPattern, methodLevelPattern); // 如果結合URI Pattern匹配，則使用這個結合的Pattern if (!combinedPattern.equals(bestMatchingPattern) && (isPathMatchInternal(combinedPattern, lookupPath))) { return combinedPattern; } } // 【問題】問什麼我們需要使用最佳匹配Pattern進行結合 // 如果型別級別沒有宣告請求對映註解的URI Pattern，則使用方法級別的URI Pattern進行匹配 if (isPathMatchInternal(methodLevelPattern, lookupPath)) { return methodLevelPattern; } return null; } private boolean isPathMatchInternal(String pattern, String lookupPath) { // 如果查詢路徑和URI Pattern相等或者匹配 if (pattern.equals(lookupPath) || pathMatcher.match(pattern, lookupPath)) { return true; } // 增加字尾進行匹配 boolean hasSuffix = pattern.indexOf('.') != -1; if (!hasSuffix && pathMatcher.match(pattern + ".*", lookupPath)) { return true; } // 增加字首進行匹配 boolean endsWithSlash = pattern.endsWith("/"); if (!endsWithSlash && pathMatcher.match(pattern + "/", lookupPath)) { return true; } return false; } private void extractHandlerMethodUriTemplates(String mappedPath, String lookupPath, HttpServletRequest request) { Map<String, String> variables = null; boolean hasSuffix = (mappedPath.indexOf('.') != -1); // 如果路徑不存在.字元(例如.do)，則使用模糊字尾匹配，增加.*進行匹配，意味著可以以任何字串結尾 if (!hasSuffix && pathMatcher.match(mappedPath + ".*", lookupPath)) { String realPath = mappedPath + ".*"; if (pathMatcher.match(realPath, lookupPath)) { variables = pathMatcher.extractUriTemplateVariables(realPath, lookupPath); } } // 使用模糊字首進行匹配，如果URI Pattern沒有以/開始，則表示可以以任意路徑開始 if (variables == null && !mappedPath.startsWith("/")) { String realPath = "/**/" + mappedPath; if (pathMatcher.match(realPath, lookupPath)) { variables = pathMatcher.extractUriTemplateVariables(realPath, lookupPath); } else { // 如果路徑沒有匹配成功則增加模糊字尾繼續匹配 realPath = realPath + ".*"; if (pathMatcher.match(realPath, lookupPath)) { variables = pathMatcher.extractUriTemplateVariables(realPath, lookupPath); } } } // 匯出得到的模板變數到請求屬性中 if (!CollectionUtils.isEmpty(variables)) { Map<String, String> typeVariables = (Map<String, String>) request.getAttribute(HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE); if (typeVariables != null) { variables.putAll(typeVariables); } request.setAttribute(HandlerMapping.URI_TEMPLATE_VARIABLES_ATTRIBUTE, variables); } }   

如何解析處理器方法引數呢？

註解方法處理器介面卡是通過請求對映註解解析處理器方法的。解析得到了處理器方法，在呼叫處理器方法之前我們必須首先解析所有的處理器方法引數。處理器方法引數也是通過各種註解標記的，不同的註解包含著資訊指導註解方法處理器介面卡從不同的資料來源取得資料。下面我們詳細分析，處理器方法引數所支援的所有註解。

最常用的應用在處理器方法引數上的註解是請求引數註解 (@RequestParam) 。 請求引數註解指導註解方法處理器介面卡通過引數名字找到請求引數值，並且賦值給當前方法引數。如下程式碼註釋，

@Target(ElementType.PARAMETER) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface RequestParam { // 請求引數名字 String value() default ""; // 請求引數是不是必須的 boolean required() default true; // 如果提供了預設值，則請求引數自動變成非必須的 String defaultValue() default ValueConstants.DEFAULT_NONE; }   

請求頭註解 (@RequestHeader) 指導註解方法處理器介面卡通過頭名字找到請求頭的值，並且賦值給當前方法引數。如下程式碼註釋，

@Target(ElementType.PARAMETER) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface RequestHeader { // 請求頭名字 String value() default ""; // 請求頭是不是必須的 boolean required() default true; // 如果提供了預設值，則請求頭自動變成非必須的 String defaultValue() default ValueConstants.DEFAULT_NONE; }  

請求體註解 (@RequestBody) 指導註解方法處理器介面卡通過訊息轉換器將請求體轉換成 Java 物件作為當前方法引數的值。但是請求註解並沒有宣告任何屬性資訊，它只是個標誌，指導註解方法處理器介面卡為當前引數解析請求體。如下程式碼註釋，

@Target(ElementType.PARAMETER) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface RequestBody { }  

Cookie 值註解 (@CookieValue) 指導註解方法處理器介面卡通過 Cookie 名字找到 Cookie 的值，並且賦值給當前方法引數。如下程式碼註釋，

@Target(ElementType.PARAMETER) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface CookieValue { // Cookie名字 String value() default ""; // Cookie值是不是必須的 boolean required() default true; // 如果提供了預設值，則Cookie值自動變成非必須的 String defaultValue() default ValueConstants.DEFAULT_NONE; }  

路徑變數註解 (@PathVariable) 指導註解方法處理器介面卡通過路徑變數名字找到路徑變數的值 ( 路徑變數通常被稱為模板變數 ) ，並且賦值給當前方法引數。如下程式碼註釋，

@Target(ElementType.PARAMETER) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface PathVariable { // 路徑變數的名字 String value() default ""; }  

模型屬性註解 (@ModelAttribute) 指導註解方法處理器介面卡通過模型屬性名字找到模型屬性的值，並且賦值給當前方法引數。模型屬性註解也可以用於宣告在方法上，這種情況下把方法的返回值作為模型資料值放入隱式模型中。如下程式碼註釋，

// 可以生命在引數上，作為引數的輸入值，也可以生命在方法上，方法的返回值會被加入到隱式模型中 @Target({ElementType.PARAMETER, ElementType.METHOD}) @Retention(RetentionPolicy.RUNTIME) @Documented public @interface ModelAttribute { // 模型屬性的名字 String value() default ""; }  

對於一個處理器方法引數，只能宣告上面的註解中的一個，或者不宣告註解。如果聲明瞭上面註解中的一個，則根據註解解析處理器方法引數的值。如果一個處理器方法引數沒有宣告任何註解，則檢視是否配置有客戶化 Web 引數解析器，如果存在則使用客戶化 Web 引數解析器進行解析。如果沒有配置客戶化 Web 引數解析器或者客戶化 Web 引數解析器不能解析當前引數，則判斷是不是標準的 WebRequest 型別，如果是