在研究源碼的時候，我們應該從最高層來看，所以我們先看這個介面的定義： 通過上面的分析已經大概明白了HandlerMapping的目的，他的目的就是一個請求來了以後，我們需要通過HandlerMapping來構造一個執行後續操作的環境，這裡麵包括我們定義的支持媒體類型，隨請求來的各種參數，系統中設置的 ...
在研究源碼的時候，我們應該從最高層來看，所以我們先看這個介面的定義：
package org.springframework.web.servlet; import javax.servlet.http.HttpServletRequest; /**
1.定義一個將請求和處理器進行映射的介面。
開發人員也可以自己實現這個介面，雖然這是不必須的，因為現在的springmvc中已經提供了大量的實現，最典型的就是
BeanNameUrlHandlerMapping,SimpleUrlHandlerMapping，RequestMappingHandlerMapping等等，以前的版本中，如果我們沒有顯示的設置的話
那麼就是前面的兩個RequestMapping，但是現在的版本是BeanNameUrlHandlerMapping,DefaultAnnotationHandlerMapping這兩個，配置了mvc:annotation-driven註解的話 就是
RequestMappingHandlerMapping
)
2.在映射的結果中可以包括0或多個的攔截器，在執行處理器的前面會先執行preHandle，如果攔截器都返回true的時候，才會執行處理器的邏輯
同時處理參數的能力也是非常的強大的，我們可以定義RequestMapping處理各種參數（但是明顯不用這樣做的，我們可以直接定義參數轉化器）
3.因為系統可以設置多個的HandlerMapping，所以我們應該實現Ordered這個介面，表示個各自的優先順序，越小優先順序越高。預設是Integer.MAX_VALUE.優先順序是最低的
*/
public interface HandlerMapping { //這個屬性表示的是url對應的HandlerMapping String PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE = HandlerMapping.class.getName() + ".pathWithinHandlerMapping"; //這個request匹配度最高的HanlderMapping String BEST_MATCHING_PATTERN_ATTRIBUTE = HandlerMapping.class.getName() + ".bestMatchingPattern"; //是否支持類級別的映射 像我們的DefaultAnnotationHandlerMapping就使用了這個屬性來表示支持類級別的。（如果我們沒有設置的話，預設就是支持的
//@see AnnotationMethodHandlerAdapter$ServletHandlerMethodResolver.useTypeLevelMapping()） String INTROSPECT_TYPE_LEVEL_MAPPING = HandlerMapping.class.getName() + ".introspectTypeLevelMapping"; //也是request中的KEY名稱，值時map，存放在的是鍵值對 String URI_TEMPLATE_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".uriTemplateVariables"; //和上面差不多，但是類別有一些不同 存放的是Matrix Variable（就是值可以用;分割的那個） String MATRIX_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".matrixVariables"; //HandlerMapping支持的媒體類型 String PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE = HandlerMapping.class.getName() + ".producibleMediaTypes"; /**
這個這個類的唯一一個方法，根據職責單一原則，我們就明白了，HandlerMapping的唯一職責就是將一個請求根據不同的策略
最終轉化為HandlerExecutionChain這樣的一個對象，這裡不是一個介面，而是一個類，這個類就是封裝了處理器和一系列的
攔截器，並且代理了這一系列處理的的前置和後置處理
*/ HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception; }
通過上面的分析已經大概明白了HandlerMapping的目的，他的目的就是一個請求來了以後，我們需要通過HandlerMapping來構造一個執行後續操作的環境，這裡麵包括我們定義的支持媒體類型，隨請求來的各種參數，系統中設置的攔截器等等。如果要我說，這一步相當於springmvc的入口吧。
我們再看一個基礎的抽象類，這個類就是就是提供了一些基本的設施，留下一個主要的工作給子類來進行實現，這是個是AbstractHandlerMapping。因為這個很多的方法，我並不會將類貼出來，主要分析一下這個類實現了哪些的功能，以及我們關註點在哪裡，擴展在哪裡。
這個抽象類不僅實現了HandlerMapping，而且實現了Ordered介面，這個介面在HandlerMapping中提示了我們就是定義自己的順序。並且繼承了spring的基礎設置類，來提供一些ServletContext和WebApplicationContext這些的引用。所以，如果我們要實現自己的HandlerMapping的話，還是建議這個抽象類就OK了。
我們看最主要的一個方法:
@Override public final HandlerExecutionChain getHandler(HttpServletRequest request) throws Exception { 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 = getApplicationContext().getBean(handlerName); } return getHandlerExecutionChain(handler, request); }
其實getHandlerInternal(...)是一個模板方法，讓子類來返回處理器，如果是空的話，那麼就返回預設的處理器.但是如果我們想要自己設置預設的處理器的話，我們要自己註入。預設是null。如果我們提供了一個string類型的處理器，他會去當前的容器中查找處理器，很奇怪的是，我發現子類中也做了這樣的一件事==!,而且這代碼還是同一個哥們寫的。看來大神的思想我們還是不太懂呢。還有最後的getHandlerExecutionChai非常的重要，攔截器都是在這個方法裡面獲取到的. 除了這些重要的點，這個抽象類還留了一個子:extendInterceptors(List<Object> interceptors) 留給子類對攔截器做一些操作。
接下來就是對每一種不同類型的HandlerMapping的不同處理了，但是歸根結底還是返回HandlerExecutionChain，裡面包括了處理器，攔截器等
