前言

不知道你有沒有遇到過這樣的場景：我們提供的某個(gè)API接口，響應(yīng)時(shí)間?原本一直都很快，但在某個(gè)不經(jīng)意的時(shí)間點(diǎn)，突然出現(xiàn)了接口超時(shí)。

也許你會(huì)有點(diǎn)懵，到底是為什么呢？

今天跟大家一起聊聊接口突然超時(shí)的10個(gè)原因，希望對(duì)你會(huì)有所幫助。?

1、網(wǎng)絡(luò)異常

接口原本好好的，突然出現(xiàn)超時(shí)，最常見的原因，可能是網(wǎng)絡(luò)出現(xiàn)異常了。比如：偶然的網(wǎng)絡(luò)抖動(dòng)，或者是帶寬被占滿了。

（1）網(wǎng)絡(luò)抖動(dòng)

經(jīng)常上網(wǎng)的我們，肯定遇到過這樣的場景：大多數(shù)情況下我們?cè)L問某個(gè)網(wǎng)站很快，但偶爾會(huì)出現(xiàn)網(wǎng)頁一直轉(zhuǎn)圈，加載不出來的情況。

有可能是你的網(wǎng)絡(luò)出現(xiàn)了抖動(dòng)，丟包了。

網(wǎng)頁請(qǐng)求API接口，或者接口返回?cái)?shù)據(jù)給網(wǎng)頁，都有可能會(huì)出現(xiàn)網(wǎng)絡(luò)丟包的情況。

網(wǎng)絡(luò)丟包可能會(huì)導(dǎo)致接口超時(shí)。

（2）帶寬被占滿

有時(shí)候，由于頁面或者接口設(shè)計(jì)不合理，用戶請(qǐng)求量突增的時(shí)候，可能會(huì)導(dǎo)致服務(wù)器的網(wǎng)絡(luò)帶寬被占滿的情況。

服務(wù)器帶寬?指的是在一定時(shí)間內(nèi)傳輸?數(shù)據(jù)的大小，比如：1秒傳輸了10M的數(shù)據(jù)。

如果用戶請(qǐng)求量突然增多，超出了1秒10M的上限，比如：1秒100M，而服務(wù)器帶寬本身1秒就只能傳輸10M，這樣會(huì)導(dǎo)致在這1秒內(nèi)，90M數(shù)據(jù)就會(huì)延遲傳輸?shù)那闆r，從而導(dǎo)致接口超時(shí)的發(fā)生。

所以對(duì)于有些高并發(fā)請(qǐng)求場景，需要評(píng)估一下是否需要增加服務(wù)器帶寬。

2、線程池滿了

我們調(diào)用的API接口，有時(shí)候?yàn)榱诵阅芸紤]，可能會(huì)使用線程池異步查詢數(shù)據(jù)，最后把查詢結(jié)果進(jìn)行匯總，然后返回。

如下圖所示：調(diào)用遠(yuǎn)程接口總耗時(shí) 200ms = 200ms（即耗時(shí)最長的那次遠(yuǎn)程接口調(diào)用）

在java8之前可以通過實(shí)現(xiàn)Callable接口，獲取線程返回結(jié)果。

java8以后通過CompleteFuture類實(shí)現(xiàn)該功能。我們這里以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，表示自定義的線程池?，為了防止高并發(fā)場景下，出現(xiàn)線程過多的問題。

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

如果隊(duì)列中排隊(duì)的任務(wù)非常多，某次API請(qǐng)求一直在等待，沒辦法得到及時(shí)處理，就會(huì)出現(xiàn)接口超時(shí)問題。

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

如果是因?yàn)楹诵木€程池設(shè)置太小，可以將其調(diào)大一些。

如果是因?yàn)槎喾N業(yè)務(wù)場景共用了同一個(gè)線程池?，可以拆分成多個(gè)線程池。

3、數(shù)據(jù)庫死鎖

有時(shí)候接口超時(shí)得有點(diǎn)莫名其妙，特別是遇到數(shù)據(jù)庫出現(xiàn)死鎖的時(shí)候。

你提供的API接口中通過某個(gè)id更新某條數(shù)據(jù)，此時(shí)，正好線上在手動(dòng)執(zhí)行一個(gè)批量更新數(shù)據(jù)的sql語句。

該sql語句在一個(gè)事務(wù)當(dāng)中，并且剛好也在更新那條數(shù)據(jù)，可能會(huì)出現(xiàn)死鎖的情況。

由于該sql語句執(zhí)行時(shí)間很長，會(huì)導(dǎo)致API接口的那次更新數(shù)據(jù)操作，長時(shí)間被數(shù)據(jù)庫鎖住，沒法即使返回?cái)?shù)據(jù)，而出現(xiàn)接口超時(shí)問題。

你說坑不坑？

所以建議在執(zhí)行數(shù)據(jù)庫批量操作前，一定要評(píng)估數(shù)據(jù)的影響范圍，不要一次性更新太多的數(shù)據(jù)，不然可能會(huì)導(dǎo)致很多意想不到的問題。

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

4、傳入?yún)?shù)太多

有時(shí)候，偶爾的一次接口超時(shí)，是由于參數(shù)傳入太多導(dǎo)致的。

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

但如果接口調(diào)用方，一次性傳入幾千個(gè)，甚至幾萬個(gè)id，批量查詢分類，也可能會(huì)出現(xiàn)接口超時(shí)問題。

因?yàn)閿?shù)據(jù)庫在執(zhí)行sql語句之前，會(huì)評(píng)估一下耗時(shí)情況，查詢條件太多，有可能走全表掃描更快。

所以這種情況下sql語句可能會(huì)丟失索引，讓執(zhí)行時(shí)間變慢，出現(xiàn)接口超時(shí)問題。

因此我們?cè)谠O(shè)計(jì)批量接口的時(shí)候，建議要限制傳入的集合的大小，比如：500。

如果超過我們?cè)O(shè)置最大的集合大小，則接口直接返回失敗，并提示給用戶：一次性傳入?yún)?shù)過多。

該限制一定要寫到接口文檔中，避免接口調(diào)用方，在生產(chǎn)環(huán)境調(diào)用接口失敗而踩坑。要在接口開發(fā)階段通知到位。

此外，如果接口調(diào)用方要傳入的參數(shù)就是很多怎么辦？

答：可能是需求不合理，或者系統(tǒng)設(shè)計(jì)有問題，我們要盡量在系統(tǒng)設(shè)計(jì)階段就規(guī)避這個(gè)問題。

如果我們重新進(jìn)行系統(tǒng)設(shè)計(jì)改動(dòng)比較大的話，有個(gè)臨時(shí)的解決方案：在接口調(diào)用方中多線程分批調(diào)用該接口，最后將結(jié)果進(jìn)行匯總。

5、超時(shí)時(shí)間設(shè)置過短

通常情況下，建議我們?cè)谡{(diào)用遠(yuǎn)程API接口時(shí)，要設(shè)置連接超時(shí)時(shí)間和讀超時(shí)時(shí)間這兩個(gè)參數(shù)，并且可以動(dòng)態(tài)配置。

這樣做的好處是，可以防止調(diào)用遠(yuǎn)程API接口萬一出現(xiàn)了性能問題，響應(yīng)時(shí)間很長，把我們自己的服務(wù)拖掛的情況發(fā)生。

比如：你調(diào)用的遠(yuǎn)程API接口，要100秒才返回?cái)?shù)據(jù)，而你設(shè)置的超時(shí)時(shí)間是100秒。這時(shí)1000個(gè)請(qǐng)求過來，去請(qǐng)求該API接口，這樣會(huì)導(dǎo)致tomcat線程池很快被占滿，導(dǎo)致整個(gè)服務(wù)暫時(shí)不可用，至少新的請(qǐng)求過來，是沒法即使響應(yīng)的。

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

并發(fā)量不大的業(yè)務(wù)場景，可以將這兩個(gè)超時(shí)時(shí)間設(shè)置稍微長一點(diǎn)，比如：連接超時(shí)時(shí)間?為10秒，讀超時(shí)時(shí)間為20秒。

并發(fā)量大的業(yè)務(wù)場景，可以設(shè)置成秒級(jí)?或者毫秒級(jí)。

有些小伙伴為了開發(fā)方便，在多種業(yè)務(wù)場景共用這兩個(gè)超時(shí)時(shí)間。

某一天，在并發(fā)量大的業(yè)務(wù)場景中，你將該超時(shí)時(shí)間改短了。

但直接導(dǎo)致并發(fā)量不大的業(yè)務(wù)場景中，出現(xiàn)調(diào)用API接口超時(shí)的問題。

因此，不建議多種業(yè)務(wù)場景共用同一個(gè)超時(shí)時(shí)間，最好根據(jù)并發(fā)量的不同，單獨(dú)設(shè)置不同的超時(shí)時(shí)間。

6、一次性返回?cái)?shù)據(jù)太多

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

由于第三方每天更新的數(shù)據(jù)不多，所以該API接口響應(yīng)時(shí)間還是比較快的。

但突然有一天，該API接口卻出現(xiàn)了接口超時(shí)問題。

查看日志發(fā)現(xiàn)，該API接口一次性返回的數(shù)據(jù)太多，而且該數(shù)據(jù)的更新時(shí)間相同。

這就可以斷定，該API接口提供方進(jìn)行了批量更新操作，修改了大量的數(shù)據(jù)，導(dǎo)致該問題的發(fā)生。

即使我們?cè)趈ob中加了失敗重試機(jī)制，但由于該API一次性返回?cái)?shù)據(jù)實(shí)在太多太多，重試也很有可能會(huì)接口超時(shí)，這樣會(huì)導(dǎo)致一直獲取不到第三方前一天最新的數(shù)據(jù)。

所以第三方這種根據(jù)日期查詢?cè)隽繑?shù)據(jù)的接口，建議做成分頁查詢的，不然后面沒準(zhǔn)哪一天，遇到批量更新的操作，就可能出現(xiàn)接口超時(shí)的問題。

7、死循環(huán)

死循環(huán)也會(huì)導(dǎo)致接口超時(shí)？

死循環(huán)不應(yīng)該在接口測試階段?就發(fā)現(xiàn)了，為什么要到生產(chǎn)環(huán)境才發(fā)現(xiàn)？

確實(shí)，絕大部分死循環(huán)問題，在測試階段可以發(fā)現(xiàn)。

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

死循環(huán)其實(shí)有兩種：

1. 普通死循環(huán)
2. 無限遞歸

（1）普通死循環(huán)

有時(shí)候死循環(huán)是我們自己寫的，例如下面這段代碼：

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

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

當(dāng)滿足condition等于true的時(shí)候，則自動(dòng)退出該循環(huán)。

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

出現(xiàn)死循環(huán)，大概率是開發(fā)人員人為的bug導(dǎo)致的，不過這種情況很容易被測出來。

還有一種隱藏的比較深的死循環(huán)，是由于代碼寫的不太嚴(yán)謹(jǐn)導(dǎo)致的。如果用正常數(shù)據(jù)，可能測不出問題，但一旦出現(xiàn)異常數(shù)據(jù)，就會(huì)立即出現(xiàn)死循環(huán)。

（2）無限遞歸

如果想要打印某個(gè)分類的所有父分類，可以用類似這樣的遞歸方法實(shí)現(xiàn)：

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);
}

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

但如果某次有人誤操作，把某個(gè)分類的parentId指向了它自己，這樣就會(huì)出現(xiàn)無限遞歸?的情況。導(dǎo)致接口一直不能返回?cái)?shù)據(jù)，最終會(huì)發(fā)生堆棧溢出。

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

8、sql語句沒走索引

你有沒有遇到過這樣一種情況：明明是同一條sql，只有入?yún)⒉煌选Ｓ械臅r(shí)候走的索引a，有的時(shí)候卻走的索引b？

沒錯(cuò)，有時(shí)候mysql會(huì)選錯(cuò)索引，甚至有時(shí)會(huì)不走索引。

mysql在執(zhí)行某條sql語句之前，會(huì)通過抽樣統(tǒng)計(jì)來估算掃描行數(shù)，根據(jù)影響行數(shù)、區(qū)分度、基數(shù)、數(shù)據(jù)頁等信息，最后綜合評(píng)估走哪個(gè)索引。

有時(shí)候傳入?yún)?shù)1，sql語句走了索引a，執(zhí)行時(shí)間很快。但有時(shí)候傳入?yún)?shù)2，sql語句走了索引b，執(zhí)行時(shí)間明顯慢了很多。

這樣有可能會(huì)導(dǎo)致API接口出現(xiàn)超時(shí)問題。

必要時(shí)可以使用force index來強(qiáng)制查詢sql走某個(gè)索引。

9、服務(wù)OOM

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

我當(dāng)時(shí)覺得有點(diǎn)不可思議，因?yàn)檫@個(gè)接口平均耗時(shí)只有十幾毫秒，怎么可能會(huì)出現(xiàn)超時(shí)呢？

但從當(dāng)時(shí)的日志看，接口響應(yīng)時(shí)間有5秒，的確出現(xiàn)了接口超時(shí)問題。

最后從Prometheus的服務(wù)內(nèi)存監(jiān)控中，查到了OOM問題。

其實(shí)該API接口部署的服務(wù)當(dāng)時(shí)由于OOM內(nèi)存溢出，其實(shí)掛了一段時(shí)間。

當(dāng)時(shí)所有的接口都出現(xiàn)了請(qǐng)求超時(shí)問題。

但由于K8S?集群有監(jiān)控?，它自動(dòng)會(huì)將掛掉的服務(wù)節(jié)點(diǎn)kill?掉，并且在容器中重新部署了一個(gè)新的服務(wù)節(jié)點(diǎn)，幸好對(duì)用戶沒造成太大的影響。

10、在debug

我們有時(shí)候需要在本地開發(fā)工具，比如：idea中，直接連接測試環(huán)境的數(shù)據(jù)庫，調(diào)試某個(gè)API接口的業(yè)務(wù)邏輯。

因?yàn)樵陂_發(fā)環(huán)境，某些問題不太好復(fù)現(xiàn)。

為了排查某個(gè)bug，你在請(qǐng)求某個(gè)本地接口時(shí)，開啟了debug模式，一行行的跟蹤代碼，排查問題。

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

此時(shí)，測試同學(xué)在相關(guān)的業(yè)務(wù)頁面中，操作更新了相同的數(shù)據(jù)。

這種也可能會(huì)出現(xiàn)數(shù)據(jù)庫死鎖的問題。

由于你在idea的debug模式中，一直都沒有提交事務(wù)，會(huì)導(dǎo)致死鎖的時(shí)間變得很長，從而導(dǎo)致業(yè)務(wù)頁面請(qǐng)求的API接口出現(xiàn)超時(shí)問題。