前言

不知道你有沒有遇到過這樣的場景：我們提供的某個API接口，響應時間?原本一直都很快，但在某個不經意的時間點，突然出現了接口超時。

也許你會有點懵，到底是為什么呢？

今天跟大家一起聊聊接口突然超時的10個原因，希望對你會有所幫助。?

1、網絡異常

接口原本好好的，突然出現超時，最常見的原因，可能是網絡出現異常了。比如：偶然的網絡抖動，或者是帶寬被占滿了。

（1）網絡抖動

經常上網的我們，肯定遇到過這樣的場景：大多數情況下我們訪問某個網站很快，但偶爾會出現網頁一直轉圈，加載不出來的情況。

有可能是你的網絡出現了抖動，丟包了。

網頁請求API接口，或者接口返回數據給網頁，都有可能會出現網絡丟包的情況。

網絡丟包可能會導致接口超時。

（2）帶寬被占滿

有時候，由于頁面或者接口設計不合理，用戶請求量突增的時候，可能會導致服務器的網絡帶寬被占滿的情況。

服務器帶寬?指的是在一定時間內傳輸?數據的大小，比如：1秒傳輸了10M的數據。

如果用戶請求量突然增多，超出了1秒10M的上限，比如：1秒100M，而服務器帶寬本身1秒就只能傳輸10M，這樣會導致在這1秒內，90M數據就會延遲傳輸的情況，從而導致接口超時的發生。

所以對于有些高并發請求場景，需要評估一下是否需要增加服務器帶寬。

2、線程池滿了

我們調用的API接口，有時候為了性能考慮，可能會使用線程池異步查詢數據，最后把查詢結果進行匯總，然后返回。

如下圖所示：調用遠程接口總耗時 200ms = 200ms（即耗時最長的那次遠程接口調用）

在java8之前可以通過實現Callable接口，獲取線程返回結果。

java8以后通過CompleteFuture類實現該功能。我們這里以CompleteFuture為例：

public UserInfo getUserInfo(Long id) throws InterruptedException, ExecutionException {
    final UserInfo userInfo = new UserInfo();
    CompletableFuture userFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteUserAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);

    CompletableFuture bonusFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteBonusAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);

    CompletableFuture growthFuture = CompletableFuture.supplyAsync(() -> {
        getRemoteGrowthAndFill(id, userInfo);
        return Boolean.TRUE;
    }, executor);
    CompletableFuture.allOf(userFuture, bonusFuture, growthFuture).join();

    userFuture.get();
    bonusFuture.get();
    growthFuture.get();

    return userInfo;
}

這里我用到了executor，表示自定義的線程池?，為了防止高并發場景下，出現線程過多的問題。

但如果用戶請求太多，線程池中已有的線程處理不過來，線程池會把多余的請求，放到隊列?中排隊?，等待空閑線程的去處理。

如果隊列中排隊的任務非常多，某次API請求一直在等待，沒辦法得到及時處理，就會出現接口超時問題。

這時候，我們可以考慮是否核心線程數設置太小了，或者有多種業務場景共用了同一個線程池。

如果是因為核心線程池設置太小，可以將其調大一些。

如果是因為多種業務場景共用了同一個線程池?，可以拆分成多個線程池。

3、數據庫死鎖

有時候接口超時得有點莫名其妙，特別是遇到數據庫出現死鎖的時候。

你提供的API接口中通過某個id更新某條數據，此時，正好線上在手動執行一個批量更新數據的sql語句。

該sql語句在一個事務當中，并且剛好也在更新那條數據，可能會出現死鎖的情況。

由于該sql語句執行時間很長，會導致API接口的那次更新數據操作，長時間被數據庫鎖住，沒法即使返回數據，而出現接口超時問題。

你說坑不坑？

所以建議在執行數據庫批量操作前，一定要評估數據的影響范圍，不要一次性更新太多的數據，不然可能會導致很多意想不到的問題。

此外，批量更新操作建議在用戶訪問少的時段執行，比如：凌晨。

4、傳入參數太多

有時候，偶爾的一次接口超時，是由于參數傳入太多導致的。

例如：根據id集合批量查詢分類接口，如果傳入的id集合數據量不多，傳入幾十個或上百個id，不會出現性能問題。畢竟id是分類表的主鍵?，可以走主鍵索引，數據庫的查找速度是非常快的。

但如果接口調用方，一次性傳入幾千個，甚至幾萬個id，批量查詢分類，也可能會出現接口超時問題。

因為數據庫在執行sql語句之前，會評估一下耗時情況，查詢條件太多，有可能走全表掃描更快。

所以這種情況下sql語句可能會丟失索引，讓執行時間變慢，出現接口超時問題。

因此我們在設計批量接口的時候，建議要限制傳入的集合的大小，比如：500。

如果超過我們設置最大的集合大小，則接口直接返回失敗，并提示給用戶：一次性傳入參數過多。

該限制一定要寫到接口文檔中，避免接口調用方，在生產環境調用接口失敗而踩坑。要在接口開發階段通知到位。

此外，如果接口調用方要傳入的參數就是很多怎么辦？

答：可能是需求不合理，或者系統設計有問題，我們要盡量在系統設計階段就規避這個問題。

如果我們重新進行系統設計改動比較大的話，有個臨時的解決方案：在接口調用方中多線程分批調用該接口，最后將結果進行匯總。

5、超時時間設置過短

通常情況下，建議我們在調用遠程API接口時，要設置連接超時時間和讀超時時間這兩個參數，并且可以動態配置。

這樣做的好處是，可以防止調用遠程API接口萬一出現了性能問題，響應時間很長，把我們自己的服務拖掛的情況發生。

比如：你調用的遠程API接口，要100秒才返回數據，而你設置的超時時間是100秒。這時1000個請求過來，去請求該API接口，這樣會導致tomcat線程池很快被占滿，導致整個服務暫時不可用，至少新的請求過來，是沒法即使響應的。

所以我們需要設置超時時間，并且超時時間還不能設置太長。

并發量不大的業務場景，可以將這兩個超時時間設置稍微長一點，比如：連接超時時間?為10秒，讀超時時間為20秒。

并發量大的業務場景，可以設置成秒級?或者毫秒級。

有些小伙伴為了開發方便，在多種業務場景共用這兩個超時時間。

某一天，在并發量大的業務場景中，你將該超時時間改短了。

但直接導致并發量不大的業務場景中，出現調用API接口超時的問題。

因此，不建議多種業務場景共用同一個超時時間，最好根據并發量的不同，單獨設置不同的超時時間。

6、一次性返回數據太多

不知道你有沒有遇到過這樣的需求：我們有個job，每天定時調用第三方API查詢接口，獲取昨天更新的數據，然后更新到我們自己的數據庫表中。

由于第三方每天更新的數據不多，所以該API接口響應時間還是比較快的。

但突然有一天，該API接口卻出現了接口超時問題。

查看日志發現，該API接口一次性返回的數據太多，而且該數據的更新時間相同。

這就可以斷定，該API接口提供方進行了批量更新操作，修改了大量的數據，導致該問題的發生。

即使我們在job中加了失敗重試機制，但由于該API一次性返回數據實在太多太多，重試也很有可能會接口超時，這樣會導致一直獲取不到第三方前一天最新的數據。

所以第三方這種根據日期查詢增量數據的接口，建議做成分頁查詢的，不然后面沒準哪一天，遇到批量更新的操作，就可能出現接口超時的問題。

7、死循環

死循環也會導致接口超時？

死循環不應該在接口測試階段?就發現了，為什么要到生產環境才發現？

確實，絕大部分死循環問題，在測試階段可以發現。

但有些無限遞歸隱藏的比較深，比如下面的情況。

死循環其實有兩種：

1. 普通死循環
2. 無限遞歸

（1）普通死循環

有時候死循環是我們自己寫的，例如下面這段代碼：

while(true) {
    if(condition) {
        break;
    }
    System.out.println("do samething");
}

這里使用了while(true)?的循環調用，這種寫法在CAS自旋鎖中使用比較多。

當滿足condition等于true的時候，則自動退出該循環。

如果condition條件非常復雜，一旦出現判斷不正確，或者少寫了一些邏輯判斷，就可能在某些場景下出現死循環的問題。

出現死循環，大概率是開發人員人為的bug導致的，不過這種情況很容易被測出來。

還有一種隱藏的比較深的死循環，是由于代碼寫的不太嚴謹導致的。如果用正常數據，可能測不出問題，但一旦出現異常數據，就會立即出現死循環。

（2）無限遞歸

如果想要打印某個分類的所有父分類，可以用類似這樣的遞歸方法實現：

public void printCategory(Category category){
  if(category == null 
      || category.getParentId() == null) {
     return;
  } 
  System.out.println("父分類名稱："+ category.getName());
  Category parent = categoryMapper.getCategoryById(category.getParentId());
  printCategory(parent);
}

正常情況下，這段代碼是沒有問題的。

但如果某次有人誤操作，把某個分類的parentId指向了它自己，這樣就會出現無限遞歸?的情況。導致接口一直不能返回數據，最終會發生堆棧溢出。

建議寫遞歸方法時，設定一個遞歸的深度，比如：分類最大等級有4級，則深度可以設置為4。然后在遞歸方法中做判斷，如果深度大于4時，則自動返回，這樣就能避免無限遞歸的情況。

8、sql語句沒走索引

你有沒有遇到過這樣一種情況：明明是同一條sql，只有入參不同而已。有的時候走的索引a，有的時候卻走的索引b？

沒錯，有時候mysql會選錯索引，甚至有時會不走索引。

mysql在執行某條sql語句之前，會通過抽樣統計來估算掃描行數，根據影響行數、區分度、基數、數據頁等信息，最后綜合評估走哪個索引。

有時候傳入參數1，sql語句走了索引a，執行時間很快。但有時候傳入參數2，sql語句走了索引b，執行時間明顯慢了很多。

這樣有可能會導致API接口出現超時問題。

必要時可以使用force index來強制查詢sql走某個索引。

9、服務OOM

我之前遇到過這樣一種場景：一個根據id查詢分類的接口，該id是主鍵，sql語句可以走主鍵索引，竟然也出現了接口超時問題。

我當時覺得有點不可思議，因為這個接口平均耗時只有十幾毫秒，怎么可能會出現超時呢？

但從當時的日志看，接口響應時間有5秒，的確出現了接口超時問題。

最后從Prometheus的服務內存監控中，查到了OOM問題。

其實該API接口部署的服務當時由于OOM內存溢出，其實掛了一段時間。

當時所有的接口都出現了請求超時問題。

但由于K8S?集群有監控?，它自動會將掛掉的服務節點kill?掉，并且在容器中重新部署了一個新的服務節點，幸好對用戶沒造成太大的影響。

10、在debug

我們有時候需要在本地開發工具，比如：idea中，直接連接測試環境的數據庫，調試某個API接口的業務邏輯。

因為在開發環境，某些問題不太好復現。

為了排查某個bug，你在請求某個本地接口時，開啟了debug模式，一行行的跟蹤代碼，排查問題。

走到某一行代碼的時候，停留了很長一段時間，該行代碼主要是更新某條數據。

此時，測試同學在相關的業務頁面中，操作更新了相同的數據。

這種也可能會出現數據庫死鎖的問題。

由于你在idea的debug模式中，一直都沒有提交事務，會導致死鎖的時間變得很長，從而導致業務頁面請求的API接口出現超時問題。