測試場景：高可用場景--限流測試；
被測交易：查詢類交易，HTTP協議；
交易鏈路：jmeter - web - coimpre(前置服務) -- coimbp -- cobp （coimbp 、coimpre 都會訪問同一個資料庫）；
注：cobp 為合肥機房，其他服務均為北京機房，要注意跨網段存在網路延遲（會導致TPS波動情況）；
場景配置：配置coimpre 服務的限流引數；
場景執行：執行場景使TPS 大於 限流引數，出發限流報錯，可透過日誌以及服務返回確認是否成功觸發限流；
測試問題：交易觸發限流後，監控coimpre服務CPU資源，從5% 上升至 90%以上，兩次i驗證執行，確認問題存在；
排查思路：
1. 使用top命令監控消耗CPU高的程序是否為java服務，（程式為java開發）；
2. 使用top -Hp pid 檢視程序下的執行緒消耗進一步確認是哪個執行緒消耗；
3. 列印執行緒dump檔案，分析dump檔案檢視該執行緒此時的業務操作‘（第一個圖是 linux下 jcmd生成的，第二個是使用的 java VisualVM 生成的）
4. 定位問題，給出最佳化意見，測試驗證；
4.1 透過dump檔案分析，有問題的執行緒主要是在java net.URClassLoader.findResouce()方法，透過第一個圖可以看到java util.zip,ziprile getentry，結合兩個方法，並透過和開發溝通是否對某個 ZIP 檔案中檔案檔案有操作。
4.2 專案組確認，交易報錯後，日誌會列印錯誤資訊並帶出是哪個jar包導致的錯誤，從而就會遍歷整個jar目錄。
4.3 共同認定是該問題導致的cpu升高，開發人員修改此處程式碼，不再遍歷jar。
4.4 修改後，重新部署版本，再次驗證限流，cpu資源下降至10%