這邊文章的根源可以了解成spring是何如路徑解析的
背景：在公司還沒有服務化的時候，在整個db層上架構了一個系統作為資料通路層（封裝業務系統對資料層的調用，實作對資料庫的分庫分表，實作對資料的緩存）對外提供的是restful接口
restful：
用戶端請求： get /list/cityid/1
非restful
用戶端請求： get /list/cityid?cityid=1
在接口越來越多的情況下，系統的性能在降低
從結果上可以看出，url的數量越多，springmvc的性能越差，檢視源碼，依然從dispatcherservlet#dodispatch方法入手
（1）abstracthandlermapping #gethandler
（2）abstracthandlermethodmapping #gethandlerinternal
（3）abstracthandlermethodmapping #lookuphandlermethod
springmvc首先對http請求中的path與已注冊的requestmappinginfo（經解析的@requestmapping）中的path進行一個完全比對來查找對應的handlermethod，即處理該請求的方法，這個比對就是一個map#get方法。若找不到則會周遊所有的requestmappinginfo進行查找。這個查找是不會提前停止的，直到周遊完全部的requestmappinginfo
springmvc的比對邏輯：
comparator comparator = new matchcomparator(getmappingcomparator(request))
string match = getmatchingpattern(pattern, lookuppath);
path的比對首先會把url按照“／”分割，然後對于每一部分都會使用到正規表達式，即使該字元串是定長的靜态的。是以該比對邏輯的性能可能會很差
至于解決方案，公司的文章裡面有寫到，我正好趁這次機會把原理重新熟悉了一遍