介面超時問題彙總
1.網路異常
1.1 網路抖動 網路丟包可能會導致介面超時。
2.1 頻寬被佔滿
伺服器頻寬指的是在一定時間內傳輸資料的大小，比如：1秒傳輸了10M的資料。
所以對於有些高併發請求場景，需要評估一下是否需要增加伺服器頻寬。
2.執行緒池滿了
在java8之前可以透過實現Callable介面，獲取執行緒返回結果。
java8以後透過CompleteFuture類實現該功能。我們這裡以CompleteFuture為例：
如果是因為核心執行緒池設定太小，可以將其調大一些。
如果是因為多種業務場景共用了同一個執行緒池，可以拆分成多個執行緒池。
3.資料庫死鎖
你提供的API介面中透過某個id更新某條資料，此時，正好線上在手動執行一個批次更新資料的sql語句。
該sql語句在一個事務當中，並且剛好也在更新那條資料，可能會出現死鎖的情況。
所以建議在執行資料庫批次操作前，一定要評估資料的影響範圍，不要一次性更新太多的資料，不然可能會導致很多意想不到的問題。
此外，批次更新操作建議在使用者訪問少的時段執行，比如：凌晨。
4.傳入引數太多
因為資料庫在執行sql語句之前，會評估一下耗時情況，查詢條件太多，有可能走全表掃描更快。
所以這種情況下sql語句可能會丟失索引，讓執行時間變慢，出現介面超時問題。
因此我們在設計批次介面的時候，建議要限制傳入的集合的大小，比如：500。
該限制一定要寫到介面文件中，避免介面呼叫方，在生產環境呼叫介面失敗而踩坑。要在介面開發階段通知到位。
如果我們重新進行系統設計改動比較大的話，有個臨時的解決方案：在介面呼叫方中多執行緒分批呼叫該介面，最後將結果進行彙總。
5.超時時間設定過短
通常情況下，建議我們在呼叫遠端API介面時，要設定連線超時時間和讀超時時間這兩個引數，並且可以動態配置。
併發量不大的業務場景，可以將這兩個超時時間設定稍微長一點，比如：連線超時時間為10秒，讀超時時間為20秒。
併發量大的業務場景，可以設定成秒級或者毫秒級。
因此，不建議多種業務場景共用同一個超時時間，最好根據併發量的不同，單獨設定不同的超時時間。
6.一次性返回資料太多
檢視日誌發現，該API介面一次性返回的資料太多，而且該資料的更新時間相同。
這就可以斷定，該API介面提供方進行了批次更新操作，修改了大量的資料，導致該問題的發生。
所以第三方這種根據日期查詢增量資料的介面，建議做成分頁查詢的，不然後面沒準哪一天，遇到批次更新的操作，就可能出現介面超時的問題。
7. 死迴圈
死迴圈其實有兩種：
普通死迴圈
無限遞迴
7.1 普通死迴圈
還有一種隱藏的比較深的死迴圈，是由於程式碼寫的不太嚴謹導致的。如果用正常資料，可能測不出問題，但一旦出現異常資料，就會立即出現死迴圈。
7.2 無限遞迴
建議寫遞迴方法時，設定一個遞迴的深度，比如：分類最大等級有4級，則深度可以設定為4。然後在遞迴方法中做判斷，如果深度大於4時，則自動返回，這樣就能避免無限遞迴的情況。
8.sql語句沒走索引
mysql在執行某條sql語句之前，會透過抽樣統計來估算掃描行數，根據影響行數、區分度、基數、資料頁等資訊，最後綜合評估走哪個索引。
必要時可以使用force index來強制查詢sql走某個索引。
9.服務OOM
link: ElasticSearch服務Java記憶體異常分析和排查解決OOM
https://www.cnblogs.com/oktokeep/p/18205278
10.在debug
由於你在idea的debug模式中，一直都沒有提交事務，會導致死鎖的時間變得很長，從而導致業務頁面請求的API介面出現超時問題。