日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

RELATEED CONSULTING
相關(guān)咨詢
選擇下列產(chǎn)品馬上在線溝通
服務(wù)時間：8:30-17:00
你可能遇到了下面的問題
關(guān)閉右側(cè)工具欄

新聞中心

這里有您想知道的互聯(lián)網(wǎng)營銷解決方案
Spring5新寵PathPattern，AntPathMatcher：那我走？

前言

你好，我是YourBatman。

創(chuàng)新互聯(lián)公司是專業(yè)的廣豐網(wǎng)站建設(shè)公司，廣豐接單;提供成都網(wǎng)站建設(shè)、成都網(wǎng)站制作,網(wǎng)頁設(shè)計,網(wǎng)站設(shè)計,建網(wǎng)站,PHP網(wǎng)站建設(shè)等專業(yè)做網(wǎng)站服務(wù);采用PHP框架,可快速的進(jìn)行廣豐網(wǎng)站開發(fā)網(wǎng)頁制作和功能擴(kuò)展;專業(yè)做搜索引擎喜愛的網(wǎng)站,專業(yè)的做網(wǎng)站團(tuán)隊,希望更多企業(yè)前來合作!

依稀記得3年前的在“玩”Spring WebFlux的時候，看到PathPattern在AbstractHandlerMapping中起到了重要作用：用于URL的匹配。當(dāng)時就很好奇：這一直不都是AntPathMatcher的活嗎?

于是乎我就拿出了自己更為熟悉的Spring WebMvc對于類進(jìn)行功能比對，發(fā)現(xiàn)PathPattern扮演的角色和AntPathMatcher一毛一樣，所以當(dāng)時也就沒去深入研究啦。

正所謂念念不忘必有回響。時隔3年最近又回到搞WebFlux了，欠下的債總歸要還呀，有必要把PathPattern深入解讀，畢竟它是Spring5在路徑解析器方面的新寵，貫穿WebFlux上下。重點是號稱比AntPathMatcher擁有更好的使用體驗以及更快的匹配效率，咦，勾起了興趣了解一下~

正值周末，說干就干。

所屬專欄

  • 點撥-Spring技術(shù)棧

本文提綱

版本約定

  • JDK：8
  • Spring Framework：5.3.x

正文

PathPattern是Spring5新增的API，所在包：org.springframework.web.util.pattern.PathPattern，所屬模塊為spring-web?？梢娝鼘閃eb設(shè)計的“工具”。

不同于AntPathMatcher是一個“上帝類”把所有活都干了，新的路徑匹配器圍繞著PathPattern擁有一套體系，在設(shè)計上更具模塊化、更加面向?qū)ο螅瑥亩鴵碛辛烁玫目勺x性和可擴(kuò)展性。

下面深入了解下該技術(shù)體系下的核心元素。主要有：

  • PathElement：路徑元素。一個URL模板根據(jù)/可以拆分成N多個路徑元素對象
  • PathContainer：URL的結(jié)構(gòu)化表示。一個URL對應(yīng)一個PathContainer對象實例
  • PathPattern：路徑解析的模式。路徑模式匹配器的最核心API
  • PathPatternParser：將一個String類型的模式解析為PathPattern實例，這是創(chuàng)建PathPattern實例的唯一方式

PathElement：路徑元素

顧名思義，它表示路徑節(jié)點。一個path會被解析成N多個PathElement節(jié)點。

核心屬性：

 
 
 
 
      
  
  
  
  1. // Since: 5.0 
    2.   
  
  
  
  2. abstract class PathElement { 
    3.   
  
  
  
  3.  
    4.   
  
  
  
  4.  protected final int pos; 
    5.   
  
  
  
  5.  protected final char separator; 
    6.   
  
  
  
  6.  @Nullable 
    7.   
  
  
  
  7.  protected PathElement next; 
    8.   
  
  
  
  8.  @Nullable 
    9.   
  
  
  
  9.  protected PathElement prev; 
    10.   
  
  
  
  10. } 
    11.
  • pos：該節(jié)點在path里的起點位置
  • separator：該path使用的分隔符
  • next：后節(jié)點，可以為null(如最后一個節(jié)點)
  • prev：前節(jié)點，可以為null(如第一個節(jié)點)

所有的PathElement之間形成鏈狀結(jié)構(gòu)，構(gòu)成一個完整的URL模板。

Tips：我個人意見，并不需要太深入去了解PathElement內(nèi)部的具體實現(xiàn)，在宏觀角度了解它的定義，然后認(rèn)識下它的子類實現(xiàn)不同的節(jié)點類型即可

它有如下子類實現(xiàn)：

SeparatorPathElement

分離器元素。代表用于分離的元素(默認(rèn)是/，也可以是.)

 
 
 
 
      
  
  
  
  1. @Test 
    2.   
  
  
  
  2. public void test1() { 
    3.   
  
  
  
  3.     PathPatternParser parser = new PathPatternParser(); 
    4.   
  
  
  
  4.     PathPattern pathPattern = parser.parse("/api/v1"); 
    5.   
  
  
  
  5.     System.out.println(pathPattern); 
    6.   
  
  
  
  6. } 
    7.

斷點調(diào)試查看解析后的pathPattern變量擁有的元素情況：

可以看到這是標(biāo)準(zhǔn)的鏈?zhǔn)浇Y(jié)構(gòu)嘛，這種關(guān)系用圖畫出來就是這樣子：

其中綠色的/都是SeparatorPathElement類型，藍(lán)色都是LiteralPathElement字面量類型。將一個Pattern拆解成為了一個個的Element對象，后面就可以方便的面向?qū)ο缶幊?，大大增加了可讀性、降低出錯的概率。

說明：由于這是第一個元素，所以才舉了個實際的代碼示例輔助理解。下面的就只需描述概念啦，舉一反三即可~

WildcardPathElement

通配符元素。如：/api/*/yourbatman

說明：在路徑中間它至少匹配1個字符(//不行，/ /可行)，但在路徑末尾可以匹配0個字符

SingleCharWildcardedPathElement

單字符通配符元素。如：/api/your??tman

說明：一個?代表一個單字通配符，若需要適配多個用多個?即可

WildcardTheRestPathElement

通配剩余路徑元素。如：/api/yourbatman/**

說明：**只能放在path的末尾，這才是rest剩余的含義嘛

CaptureVariablePathElement

將一段路徑作為變量捕獲的路徑元素。如：/api/yourbatman/{age}

說明：{age}就代表此元素類型被封裝進(jìn)來

CaptureTheRestPathElement

捕獲路徑其余部分的路徑元素。如：/api/yourbatman/{*restPath}

說明：若待匹配的路徑是/api/yourbatman/a/b/c，那么restPath=a/b/c

LiteralPathElement

字面量元素。不解釋~

RegexPathElement

正則表達(dá)式元素。如：api/*_*/*_{age}說明：*_*和*_{age}都會被解析為該元素類型，這種寫法是從AntPathMatcher里派生來過的(但不會依賴于AntPathMatcher)

總之：任何一個字符串的pattern最終都會被解析為若干段的PathElement，這些PathElement以鏈?zhǔn)浇Y(jié)構(gòu)連接起來用以表示該pattern，形成一個對象數(shù)據(jù)。不同于AntPathMatcher的純字符串操作，這里把每一段都使用對象來描述，結(jié)構(gòu)化的表示使得可讀性更強(qiáng)、更具靈活性，甚至可以獲得更好的性能表現(xiàn)。

PathContainer：URL的結(jié)構(gòu)化表示

和PathPattern類似，待匹配的path的每一段都會表示為一個元素并保存其元數(shù)據(jù)信息。也就是說：每一個待匹配的URL路徑都會被解析為一個PathContainer實例。

PathContainer雖然是個接口，但我們無需關(guān)心其實現(xiàn)，類同于Java 8的java.util.stream.Collector接口使用者無需關(guān)心其實現(xiàn)一樣。因為提供了靜態(tài)工具方法用于直接生成對應(yīng)實例。體驗一把：

 
 
 
 
      
  
  
  
  1. @Test 
    2.   
  
  
  
  2. public void test2() { 
    3.   
  
  
  
  3.     PathContainer pathContainer = PathContainer.parsePath("/api/v1/address", PathContainer.Options.HTTP_PATH); 
    4.   
  
  
  
  4.     System.out.println(pathContainer); 
    5.   
  
  
  
  5. } 
    6.

debug模式運(yùn)行，查看pathContainer對象詳情：

這和解析為PathPattern的結(jié)構(gòu)何其相似(不過這里元素們是通過有序的集合組織起來的)。對比看來，拍腦袋應(yīng)該能夠猜到何新版的匹配效率會更高了吧。

補(bǔ)充說明：

  • value和valueToMatch的區(qū)別：value是原值，valueToMatch是(處理過的，比如已解碼的)最終參與匹配的值
  • parameters代表路徑參數(shù)。若希望它有值只需使用;號分隔填值即可。如：/api;abc/v1，此參數(shù)一般都用不著

因為Http中是允許這樣攜帶參數(shù)的，但是目錄(.形式)就不能這么寫啦

PathPattern：路徑解析的模式

表示解析路徑的模式。包括用于快速匹配的路徑元素鏈，并累積用于快速比較模式的計算狀態(tài)。它是直接面向使用者進(jìn)行匹配邏輯的最重要API，完成match操作。

PathPattern所在包是org.springframework.web.util.pattern.PathPattern，位于spring-web模塊，專為web(含webmvc和webflux)設(shè)計的全新一套路徑匹配API，具有更高的匹配效率。

認(rèn)識下它的成員屬性：

 
 
 
 
      
  
  
  
  1. // Since: 5.0 
    2.   
  
  
  
  2. public class PathPattern implements Comparable { 
    3.   
  
  
  
  3.  
    4.   
  
  
  
  4.  // pattern的字符串形式 
    5.   
  
  
  
  5.  private final String patternString; 
    6.   
  
  
  
  6.  // 用于構(gòu)建本實例的解析器 
    7.   
  
  
  
  7.  private final PathPatternParser parser; 
    8.   
  
  
  
  8.  // 分隔符使用/還是.，默認(rèn)是/ 
    9.   
  
  
  
  9.  private final PathContainer.Options pathOptions; 
    10.   
  
  
  
  10.  // 如果pattern里結(jié)尾沒/而待匹配的有，仍然讓其匹配成功（true），默認(rèn)是true 
    11.   
  
  
  
  11.  private final boolean matchOptionalTrailingSeparator; 
    12.   
  
  
  
  12.  // 是否對大小寫敏感，默認(rèn)是true 
    13.   
  
  
  
  13.  private final boolean caseSensitive; 
    14.   
  
  
  
  14.  // 鏈?zhǔn)浇Y(jié)構(gòu)：表示URL的每一部分元素 
    15.   
  
  
  
  15.  @Nullable 
    16.   
  
  
  
  16.  private final PathElement head; 
    17.   
  
  
  
  17.  
    18.   
  
  
  
  18.  private int capturedVariableCount; 
    19.   
  
  
  
  19.  private int normalizedLength; 
    20.   
  
  
  
  20.  private boolean endsWithSeparatorWildcard = false; 
    21.   
  
  
  
  21.  private int score; 
    22.   
  
  
  
  22.  private boolean catchAll = false; 
    23.   
  
  
  
  23.  
    24.   
  
  
  
  24. } 
    25.

以上屬性是直接讀取，下面這些個是計算出來的，比較特殊就特別照顧下：

  • capturedVariableCount：在這個模式中捕獲的變量總數(shù)。也就是{xxx}或者正則捕獲的總數(shù)嘍
  • normalizedLength：通配符批到的變量長度的總和(關(guān)于長度的計算有個約定：如?是1，字面量就是字符串長度)，這個變量對提升匹配速度有幫助
  • endsWithSeparatorWildcard：標(biāo)記該模式是否以隔離符或者通配符*結(jié)尾
  • score：分?jǐn)?shù)用于快速比較該模式。不同的模式組件被賦予不同的權(quán)重。分?jǐn)?shù)越低越具體，如：捕獲到的變量分?jǐn)?shù)值為1，通配符值是100
  • catchAll：該pattern是否以**或者{*xxx}結(jié)尾

score、catchAll等標(biāo)記用于加速匹配的速度，具體體現(xiàn)在PathPattern.SPECIFICITY_COMPARATOR這個比較器上，這是PathPattern速度比AntPathMatcher快的根因之一

值得注意的是：所有屬性均不提供public的set方法，也就是說PathPattern實例一旦創(chuàng)建就是只讀(不可變)實例了。

快速創(chuàng)建缺省的實例

上面了解到，PathPattern的構(gòu)造器不是public的，所以有且僅能通過PathPatternParser創(chuàng)建其實例。然而，為快速滿足絕大多數(shù)場景，Spring還提供了一種快速創(chuàng)建缺省的PathPattern實例的方式：

PathPatternParser提供一個全局共享的、只讀的實例用于快速創(chuàng)建缺省的PathPattern實例，類似于實例工廠的作用。畢竟絕大部分場景下用PathPattern的缺省屬性即可，因此有了它著實方便不少。

注意：雖然該P(yáng)athPatternParser實例是全局共享只有1個，但是，創(chuàng)建出來的PathPattern可是不同實例哦(基本屬性都一樣而已)

代碼示例

PathPattern的匹配方式和AntPathMatcher基本保持一致：使用的基于Ant風(fēng)格模式匹配。

但是發(fā)現(xiàn)沒，這里不再強(qiáng)調(diào)Ant字樣，也許Spring覺得Ant的概念確實已廉頗老矣?不符合它緊跟潮流的身份?

相比于AntPathMatcher，PathPattern主要有兩處地方不一樣：

說明：PathPattern只支持兩種分隔符(/和.)，而AntPathMatcher可以隨意指定。雖然這也是不同點，但這一般無傷大雅所以就不單獨(dú)列出了

1. 新增{*pathVariable}語法支持

這是PathPattern新增的“語法”，表示匹配余下的path路徑部分并將其賦值給pathVariable變量。

 
 
 
 
      
  
  
  
  1. @Test 
    2.   
  
  
  
  2. public void test1() { 
    3.   
  
  
  
  3.     System.out.println("======={*pathVariable}語法======"); 
    4.   
  
  
  
  4.     PathPattern pattern = PathPatternParser.defaultInstance.parse("/api/yourbatman/{*pathVariable}"); 
    5.   
  
  
  
  5.  
    6.   
  
  
  
  6.     // 提取匹配到的的變量值 
    7.   
  
  
  
  7.     System.out.println("是否匹配：" + pattern.matches(PathContainer.parsePath("/api/yourbatman/a/b/c"))); 
    8.   
  
  
  
  8.     PathPattern.PathMatchInfo pathMatchInfo = pattern.matchAndExtract(PathContainer.parsePath("/api/yourbatman/a/b/c")); 
    9.   
  
  
  
  9.     System.out.println("匹配到的值情況：" + pathMatchInfo.getUriVariables()); 
    10.   
  
  
  
  10. } 
    11.   
  
  
  
  11.  
    12.   
  
  
  
  12. ======={*pathVariable}語法====== 
    13.   
  
  
  
  13. 是否匹配：true 
    14.   
  
  
  
  14. 匹配到的值情況：{pathVariable=/a/b/c} 
    15.

在沒有PathPattern之前，雖然也可以通過/**來匹配成功，但卻無法得到匹配到的值，現(xiàn)在可以了!

和**的區(qū)別

我們知道/**和/{*pathVariable}都有匹配剩余所有path的“能力”，那它倆到底有什么區(qū)別呢?

  1. /**能匹配成功，但無法獲取到動態(tài)成功匹配元素的值
  2. /{*pathVariable}可認(rèn)為是/**的加強(qiáng)版：可以獲取到這部分動態(tài)匹配成功的值

正所謂一代更比一代強(qiáng)嘛，如是而已。

和**的優(yōu)先級關(guān)系

既然/**和/{*pathVariable}都有匹配剩余path的能力，那么它倆若放在一起，優(yōu)先級關(guān)系是怎樣的呢?

妄自猜測沒有意義，跑個案例一看便知：由于PathPattern實現(xiàn)了比較器接口，因此本例利用SortedSet自動排序即可，排第一的證明優(yōu)先級越高

 
 
 
 
      
  
  
  
  1. @Test 
    2.   
  
  
  
  2. public void test2() { 
    3.   
  
  
  
  3.     System.out.println("======={*pathVariable}和/**優(yōu)先級======"); 
    4.   
  
  
  
  4.     PathPattern pattern1 = PathPatternParser.defaultInstance.parse("/api/yourbatman/{*pathVariable}"); 
    5.   
  
  
  
  5.     PathPattern pattern2 = PathPatternParser.defaultInstance.parse("/api/yourbatman/**"); 
    6.   
  
  
  
  6.  
    7.   
  
  
  
  7.     SortedSet sortedSet = new TreeSet<>(); 
    8.   
  
  
  
  8.     sortedSet.add(pattern1); 
    9.   
  
  
  
  9.     sortedSet.add(pattern2); 
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11.     System.out.println(sortedSet); 
    12.   
  
  
  
  12. } 
    13.   
  
  
  
  13.  
    14.   
  
  
  
  14. ======={*pathVariable}和/**優(yōu)先級====== 
    15.   
  
  
  
  15. [/api/yourbatman/**, /api/yourbatman/{*pathVariable}] 
    16.

測試代碼的細(xì)節(jié)：故意將/{*pathVariable}先放進(jìn)set里面而后放/**，但最后還是/**在前。

結(jié)論：當(dāng)二者同時出現(xiàn)(出現(xiàn)沖突)時，/**優(yōu)先匹配。

2. 禁用中間**語法支持

在上篇文章對AntPathMatcher的詳細(xì)分析文章中，我們知道是可以把/**放在整個URL中間用來匹配的，如：

 
 
 
 
      
  
  
  
  1. @Test 
    2.   
  
  
  
  2. public void test4() { 
    3.   
  
  
  
  3.     System.out.println("=======**:匹配任意層級的路徑/目錄======="); 
    4.   
  
  
  
  4.     String pattern = "/api/**/yourbatman"; 
    5.   
  
  
  
  5.  
    6.   
  
  
  
  6.     match(1, MATCHER, pattern, "/api/yourbatman"); 
    7.   
  
  
  
  7.     match(2, MATCHER, pattern, "/api//yourbatman"); 
    8.   
  
  
  
  8.     match(3, MATCHER, pattern, "/api/a/b/c/yourbatman"); 
    9.   
  
  
  
  9. } 
    10.   
  
  
  
  10.  
    11.   
  
  
  
  11. =======**:匹配任意層級的路徑/目錄======= 
    12.   
  
  
  
  12. 1 match結(jié)果：/api/**/yourbatman 【成功】 /api/yourbatman 
    13.   
  
  
  
  13. 2 match結(jié)果：/api/**/yourbatman 【成功】 /api//yourbatman 
    14.   
  
  
  
  14. 3 match結(jié)果：/api/**/yourbatman 【成功】 /api/a/b/c/yourbatman 
    15.

與AntPathMatcher不同，**僅在模式末尾受支持。中間不被允許了，否則實例創(chuàng)建階段就會報錯：

 
 
 
 
      
  
  
  
  1. @Test 
    2.   
  
  
  
  2. public void test3() { 
    3.   
  
  
  
  3.     System.out.println("=======/**放在中間語法======"); 
    4.   
  
  
  
  4.     PathPattern pattern = PathPatternParser.defaultInstance.parse("/api/**/yourbatman"); 
    5.   
  
  
  
  5.  
    6.   
  
  
  
  6.     pattern.matches(PathContainer.parsePath("/api/a/b/c/yourbatman")); 
    7.   
  
  
  
  7. } 
    8.   
  
  
  
  8.  
    9.   
  
  
  
  9. =======/**放在中間語法====== 
    10.   
  
  
  
  10. org.springframework.web.util.pattern.PatternParseException: No more pattern data allowed after {*...} or ** pattern element 
    11.   
  
  
  
  11.  at org.springframework.web.util.pattern.InternalPathPatternParser.peekDoubleWildcard(InternalPathPatternParser.java:250) 
    12.   
  
  
  
  12.  ... 
    13.

從報錯中還能看出端倪：不僅**，{*xxx}也是不能放在中間而只能是末尾的

PathPattern這么做的目的是：消除歧義。

那么問題來了，如果就是想匹配中間的任意層級路徑怎么做呢?答：首先這在web環(huán)境里有這樣需求的概率極小(PathPattern只適用于web環(huán)境)，若這依舊是剛需，那就只能蛻化到借助AntPathMatcher來完成嘍。

PathPattern對比AntPathMatcher

二者目前都存在于Spring技術(shù)棧內(nèi)，做著“相同”的事。雖說現(xiàn)在還鮮有同學(xué)了解到PathPattern，我認(rèn)為淘汰掉AntPathMatcher只是時間問題(特指web環(huán)境哈)，畢竟后浪總歸有上岸的一天。

但不可否認(rèn)，二者將在較長時間內(nèi)共處，那么它倆到底有何區(qū)別呢?了解一下

出現(xiàn)時間

AntPathMatcher是一個早在2003年(Spring的第一個版本)就已存在的路徑匹配器，而PathPattern是Spring 5新增的，旨在用于替換掉較為“古老”的AntPathMatcher。

功能差異

PathPattern去掉了Ant字樣，但保持了很好的向下兼容性：除了不支持將**寫在path中間之外，其它的匹配規(guī)則從行為上均保持和AntPathMatcher一致，并且還新增了強(qiáng)大的{*pathVariable}的支持。

因此在功能上姑且可認(rèn)為二者是一致的，極特殊情況下的不兼容除外。

性能差異

Spring官方說PathPattern的性能優(yōu)于AntPathMatcher，我抱著懷疑的態(tài)度做了測試，示例代碼和結(jié)果如下：

// 匹配的模板：使用一個稍微有點復(fù)雜的模板進(jìn)行測試private static final String pattern = "/api/your?atman/{age}/**";

 
 
 
 
      
  
  
  
  1. // 匹配的模板：使用一個稍微有點復(fù)雜的模板進(jìn)行測試 
    2.   
  
  
  
  2. private static final String pattern = "/api/your?atman/{age}/**"; 
    3.  
 
 

 
 
 
 
      
  
  
  
  1. // AntPathMatcher匹配代碼：使用單例的PathMatcher，符合實際使用情況 
    2.   
  
  
  
  2. private static final PathMatcher MATCHER = new AntPathMatcher(); 
    3.   
  
  
  
  3. public static void antPathMatcher(String reqPath) { 
    4.   
  
  
  
  4.     MATCHER.match(reqPath); 
    5.   
  
  
  
  5. } 
    6.  
 
 

 
 
 
 
      
  
  
  
  1. // PathPattern代碼示例：這里的pattern由下面來定義 
    2.   
  
  
  
  2. private static final PathPattern PATTERN = PathPatternParser.defaultInstance.parse(pattern); 
    3.   
  
  
  
  3. public static void pathPattern(String reqPath) { 
    4.   
  
  
  
  4.     PATTERN.matches(PathContainer.parsePath(reqPath)); 
    5.   
  
  
  
  5. } 
    6.

匹配的測試代碼：

 
 
 
 
      
  
  
  
  1. @Test 
    2.   
  
  
  
  2. public void test1() { 
    3.   
  
  
  
  3.     Instant start = Instant.now(); 
    4.   
  
  
  
  4.     for (int i = 0; i < 100000; i++) { 
    5.   
  
  
  
  5.         String reqPath = "/api/yourBatman/" + i + "/" + i; 
    6.   
  
  
  
  6.         antPathMatcher(reqPath); 
    7.   
  
  
  
  7.         // pathPattern(reqPath); 
    8.   
  
  
  
  8.     } 
    9.   
  
  
  
  9.     System.out.println("耗時(ms)：" + Duration.between(start, Instant.now()).toMillis()); 
    10.   
  
  
  
  10. } 
    11.

不斷調(diào)整循環(huán)次數(shù)，且各執(zhí)行三次，將結(jié)果繪制成如下表格：

測試機(jī)配置為：

循環(huán)100000次：

循環(huán)1000000次：

循環(huán)10000000次：

結(jié)論：PathPattern性能比AntPathMatcher優(yōu)秀。理論上pattern越復(fù)雜，PathPattern的優(yōu)勢越明顯。

最佳實踐

既然路徑匹配器有兩種方案，那必然有最佳實踐。Spring官方對此也是持有態(tài)度的：

Web環(huán)境

如果是Servlet應(yīng)用(webmvc)，官方推薦PathPattern(只是推薦，但默認(rèn)的依舊是AntPathMatcher哈)，相關(guān)代碼體現(xiàn)在PathPattern里：

 
 
 
 
      
  
  
  
  1. // Since: 07.04.2003 
    2.   
  
  
  
  2. public abstract class AbstractHandlerMapping ... { 
    3.   
  
  
  
  3.   
    4.   
  
  
  
  4.  private UrlPathHelper urlPathHelper = new UrlPathHelper(); 
    5.   
  
  
  
  5.  private PathMatcher pathMatcher = new AntPathMatcher(); 
    6.   
  
  
  
  6.   
    7.   
  
  
  
  7.  ... 
    8.   
  
  
  
  8.   
    9.   
  
  
  
  9.  @Nullable 
    10.   
  
  
  
  10.  private PathPatternParser patternParser; 
    11.   
  
  
  
  11.  // Since: 5.3 
    12.   
  
  
  
  12.  public void setPatternParser(PathPatternParser patternParser) { 
    13.   
  
  
  
  13.   this.patternParser = patternParser; 
    14.   
  
  
  
  14.  } 
    15.   
  
  
  
  15. } 
    16.

注意：setPatternParser()從5.3版本開始才被加入，也就說雖然PathPattern從Spring 5就有了，但直到5.3版本才被加入到webmvc里，且作為可選(默認(rèn)依舊是AntPathMatcher)。換句話講：在Spring 5.3版本之前，仍舊只能用AntPathMatcher。

在WebMvc里啟用PathPattern

默認(rèn)情況下，Spring MVC依舊是使用的AntPathMatcher進(jìn)行路徑匹配的，那如何啟用效率更高的PathPattern呢?

通過上面源碼知道，就是要調(diào)用AbstractHandlerMapping的setPatternParser方法嘛，其實Spring為此是預(yù)留了擴(kuò)展點的，只需這么做即可：

 
 
 
 
      
  
  
  
  1. /** 
    2.   
  
  
  
  2.  * 在此處添加備注信息 
    3.   
  
  
  
  3.  * 
    4.   
  
  
  
  4.  * @author YourBatman. Send email to me 
    5.   
  
  
  
  5.  * @site https://yourbatman.cn 
    6.   
  
  
  
  6.  * @date 2021/6/20 18:33 
    7.   
  
  
  
  7.  * @since 0.0.1 
    8.   
  
  
  
  8.  */ 
    9.   
  
  
  
  9. @Configuration(proxyBeanMethods = false) 
    10.   
  
  
  
  10. public class WebMvcConfiguration implements WebMvcConfigurer { 
    11.   
  
  
  
  11.  
    12.   
  
  
  
  12.     @Override 
    13.   
  
  
  
  13.     public void configurePathMatch(PathMatchConfigurer configurer) { 
    14.   
  
  
  
  14.         configurer.setPatternParser(PathPatternParser.defaultInstance); 
    15.   
  
  
  
  15.     } 
    16.   
  
  
  
  16. } 
    17.

如果是Reactor應(yīng)用(webflux)，那PathPattern就是唯一解決方案。這體現(xiàn)在org.springframework.web.reactive.handler.AbstractHandlerMapping：

 
 
 
 
      
  
  
  
  1. // Since: 5.0 
    2.   
  
  
  
  2. public abstract class AbstractHandlerMapping... { 
    3.   
  
  
  
  3.  
    4.   
  
  
  
  4.  private final PathPatternParser patternParser; 
    5.   
  
  
  
  5.  ... 
    6.   
  
  
  
  6.  public AbstractHandlerMapping() { 
    7.   
  
  
  
  7.   this.patternParser = new PathPatternParser(); 
    8.   
  
  
  
  8.  } 
    9.   
  
  
  
  9. } 
    10.

webflux里早已不見AntPathMatcher的蹤影，因為webflux是從Spring 5.0開始的，因此沒有向下兼容的負(fù)擔(dān)，直接全面擁抱PathPattern了。

結(jié)論：PathPattern語法更適合于web應(yīng)用程序，其使用更方便且執(zhí)行更高效。

非Web環(huán)境

嗯，如果認(rèn)真“聽課”了的同學(xué)就知道：非Web環(huán)境依舊有且僅有一種選擇，那便是AntPathMatcher，因為PathPattern是專為Web環(huán)境設(shè)計，不能用于非Web環(huán)境。所以像上面資源加載、包名掃描之類的，底層依舊是交給AntPathMatcher去完成。

說明：由于這類URL的解析絕大多數(shù)情況下匹配一次(執(zhí)行一次)就行，所以微小的性能差異是無所謂的(對API來講收益較大)

可能有小伙伴會說：在Service層，甚至Dao層我也可以正常使用PathPattern對象呀，何解?這個問題就相當(dāng)于：HttpServletRequest屬于web層專用組件，但你依舊可以將其傳到Service層，甚至Dao層供以使用，在編譯、運(yùn)行時不會報錯。但你可深入思考下，這么做合適嗎?

舉個生活上的例子：馬桶可以裝在衛(wèi)生間，也可以安裝在臥室的床旁邊，都能完成大小便功能，但你覺得這么做合適嗎?

Java這門語言對訪問權(quán)限的控制設(shè)計得還是很優(yōu)秀的，很多隔離性的問題在編譯器就能搞定。但有很多規(guī)范性做法是無法做到強(qiáng)約束的，只能依靠工程師自身水平。這就是經(jīng)驗，也是區(qū)別初級工程師和高級工程師的重要因素。

總結(jié)

技術(shù)的日新月異，體現(xiàn)在一個個像PathPattern這個更好的API上。

Spring 5早在2017-09就已發(fā)布，可能是由于它“設(shè)計得過于優(yōu)秀”，即使大版本的發(fā)布也幾乎保持100%向下兼容，使得一般開發(fā)者感受不到它的升級。但是，這對框架二次開發(fā)者并不可能完全透明，因為二次開發(fā)經(jīng)常會用到其Low-Level的API，比如今天的主角PathPattern就算其中之一，所以說我們要與時俱進(jìn)呀o(╥﹏╥)o!

Spring 5雖然新增了(更好的)PathPattern，但它不能完全替代掉AntPathMatcher，因為前者專為web設(shè)計，所以在web領(lǐng)域是可完全替代掉AntPathMatcher的。但在非web領(lǐng)域內(nèi)，AntPathMatcher依舊不可替代。

本文轉(zhuǎn)載自微信公眾號「 BAT的烏托邦」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系 BAT的烏托邦公眾號。


新聞名稱：Spring5新寵PathPattern，AntPathMatcher：那我走？
新聞來源：http://m.5511xx.com/article/coeocde.html