作者：樹洞君 \ 鏈接：https://juejin.cn/post/7064376361334358046 # 事故描述從6點32分開始少量用戶訪問app時會出現首頁訪問異常，到7點20分首頁服務大規模不可用，7點36分問題解決。 # 整體經過 6:58 發現報警，同時發現群里反饋首頁出現網路繁 ...

作者：樹洞君
鏈接：https://juejin.cn/post/7064376361334358046

事故描述

從6點32分開始少量用戶訪問app時會出現首頁訪問異常，到7點20分首頁服務大規模不可用，7點36分問題解決。

整體經過

6:58 發現報警，同時發現群里反饋首頁出現網路繁忙，考慮到前幾日晚上門店列表服務上線發佈過，所以考慮回滾代碼緊急處理問題。

7:07 開始先後聯繫XXX查看解決問題。

7:36 代碼回滾完，服務恢復正常。

事故根本原因-事故代碼模擬

public static void test() throws InterruptedException, ExecutionException {
    Executor executor = Executors.newFixedThreadPool(3);
    CompletionService<String> service = new ExecutorCompletionService<>(executor);
        service.submit(new Callable<String>() {
            @Override
            public String call() throws Exception {
                return "HelloWorld--" + Thread.currentThread().getName();
            }
        });
}

根源就在於ExecutorCompletionService結果沒調用take，poll方法。

正確的寫法如下所示：

public static void test() throws InterruptedException, ExecutionException {
    Executor executor = Executors.newFixedThreadPool(3);
    CompletionService<String> service = new ExecutorCompletionService<>(executor);
    service.submit(new Callable<String>() {
        @Override
        public String call() throws Exception {
            return "HelloWorld--" + Thread.currentThread().getName();
        }
    });
    service.take().get();
}

一行代碼引發的血案，而且不容易被髮現，因為oom是一個記憶體緩慢增長的過程，稍微粗心大意就會忽略，如果是這個代碼塊的調用量少的話，很可能幾天甚至幾個月後暴雷。

操作人回滾or重啟伺服器確實是最快的方式，但是如果不是事後快速分析出oom的代碼，而且不巧回滾的版本也是帶oom代碼的，就比較悲催了，如剛纔所說，流量小了，回滾或者重啟都可以釋放記憶體；但是流量大的情況下，除非回滾到正常的版本，否則GG。

推薦一個開源免費的 Spring Boot 實戰項目：https://github.com/javastacks/spring-boot-best-practice

探詢問題的根源

為了更好的理解ExecutorCompletionService的 “套路” 我們用 ExecutorService來作為對比，可以讓我們更好的清楚，什麼場景下用ExecutorCompletionService。

先看ExecutorService代碼（建議down下來跑一跑）

public static void test1() throws Exception{
    ExecutorService executorService = Executors.newCachedThreadPool();
    ArrayList<Future<String>> futureArrayList = new ArrayList<>();
    System.out.println("公司讓你通知大家聚餐 你開車去接人");
    Future<String> future10 = executorService.submit(() -> {
        System.out.println("總裁：我在家上大號 我最近拉肚子比較慢 要蹲1個小時才能出來 你等會來接我吧");
        TimeUnit.SECONDS.sleep(10);
        System.out.println("總裁：1小時了 我上完大號了。你來接吧");
        return "總裁上完大號了";

    });
    futureArrayList.add(future10);
    Future<String> future3 = executorService.submit(() -> {
        System.out.println("研發：我在家上大號 我比較快 要蹲3分鐘就可以出來 你等會來接我吧");
        TimeUnit.SECONDS.sleep(3);
        System.out.println("研發：3分鐘 我上完大號了。你來接吧");
        return "研發上完大號了";
    });
    futureArrayList.add(future3);
    Future<String> future6 = executorService.submit(() -> {
        System.out.println("中層管理：我在家上大號  要蹲10分鐘就可以出來 你等會來接我吧");
        TimeUnit.SECONDS.sleep(6);
        System.out.println("中層管理：10分鐘 我上完大號了。你來接吧");
        return "中層管理上完大號了";
    });
    futureArrayList.add(future6);
    TimeUnit.SECONDS.sleep(1);
    System.out.println("都通知完了,等著接吧。");
    try {
        for (Future<String> future : futureArrayList) {
            String returnStr = future.get();
            System.out.println(returnStr + "，你去接他");
        }
        Thread.currentThread().join();
    } catch (Exception e) {
        e.printStackTrace();
    }
}

三個任務，每個任務執行時間分別是 10s、3s、6s 。通過JDK線程池的 submit 提交這三個 Callable類型的任務。

step1 主線程把三個任務提交到線程池裡面去，把對應返回的 Future 放到 List 裡面存起來，然後執行“都通知完了,等著接吧。”這行輸出語句。
step2在迴圈裡面執行 future.get() 操作，阻塞等待。最後結果如下：

先通知到總裁，也是先接總裁足足等了1個小時，接到總裁後再去接研發和中層管理，儘管他們早就完事兒了，也得等總裁上完廁所~~

耗時最久的-10s非同步任務最先進入list執行，所以在迴圈過程中獲取這個10s的任務結果的時候，get操作會一直阻塞，直到10s非同步任務執行完畢。即使 3s、5s的任務早就執行完了，也得阻塞等待10s任務執行完。

看到這裡尤其是做網關業務的同學可能會產生共鳴，一般來說網關RPC會調用下游N多個介面，如下圖

如果都按照ExecutorService這種方式，並且恰巧前幾個任務調用的介面耗時比較久，同時阻塞等待，那就比較悲催了。所以ExecutorCompletionService應景而出。它作為任務線程的合理管控者，“任務規劃師”的稱號名副其實。

相同場景 ExecutorCompletionService代碼

public static void test2() throws Exception {
    ExecutorService executorService = Executors.newCachedThreadPool();
    ExecutorCompletionService<String> completionService = new ExecutorCompletionService<>(executorService);
    System.out.println("公司讓你通知大家聚餐 你開車去接人");
    completionService.submit(() -> {
        System.out.println("總裁：我在家上大號 我最近拉肚子比較慢 要蹲1個小時才能出來 你等會來接我吧");
        TimeUnit.SECONDS.sleep(10);
        System.out.println("總裁：1小時了 我上完大號了。你來接吧");
        return "總裁上完大號了";
    });
    completionService.submit(() -> {
        System.out.println("研發：我在家上大號 我比較快 要蹲3分鐘就可以出來 你等會來接我吧");
        TimeUnit.SECONDS.sleep(3);
        System.out.println("研發：3分鐘 我上完大號了。你來接吧");
        return "研發上完大號了";
    });
    completionService.submit(() -> {
        System.out.println("中層管理：我在家上大號  要蹲10分鐘就可以出來 你等會來接我吧");
        TimeUnit.SECONDS.sleep(6);
        System.out.println("中層管理：10分鐘 我上完大號了。你來接吧");
        return "中層管理上完大號了";
    });
    TimeUnit.SECONDS.sleep(1);
    System.out.println("都通知完了,等著接吧。");
    //提交了3個非同步任務）
    for (int i = 0; i < 3; i++) {
        String returnStr = completionService.take().get();
        System.out.println(returnStr + "，你去接他");
    }
    Thread.currentThread().join();
}

跑完結果如下：

這次就相對高效了一些，雖然先通知的總裁，但是根據大家上大號的速度，誰先拉完先去接誰，不用等待上大號最久的總裁了（現實生活里建議採用第一種不等總裁的後果 emmm 哈哈哈）。

放在一起對比下輸出結果：

兩段代碼的差異非常小獲取結果的時候ExecutorCompletionService 使用了

completionService.take().get();

為什麼要用take() 然後再get()呢？？？？我們看看源碼

CompletionService介面以及介面的實現類

1、ExecutorCompletionService是CompletionService介面的實現類

2、接著跟一下ExecutorCompletionService的構造方法，可以看到入參需要傳一個線程池對象，預設使用的隊列是 LinkedBlockingQueue，不過還有另外一個構造方法可以指定隊列類型，如下兩張圖，兩個構造方法。

預設LinkedBlockingQueue的構造方法

可選隊列類型的構造方法

3、submit任務提交的兩種方式，都是有返回值的，我們例子中用到的就是第一種Callable類型的方法。

4、對比ExecutorService 和 ExecutorCompletionService submit方法可以看出區別（1）ExecutorService

（2）ExecutorCompletionService

5、差異就在 QueueingFuture，這個到底作用是啥，我們繼續跟進去看

QueueingFuture 繼承自 FutureTask，而且紅線部分標註的位置，重寫了done()方法。
把 task 放到 completionQueue 隊列裡面，當任務執行完成後，task就會被放到隊列裡面去了。
此時此刻completionQueue隊列裡面的 task 都是已經 done()完成了的 task，而這個 task 就是我們拿到的一個個的future結果。
如果調用 completionQueue 的 task 方法，會阻塞等待任務。等到的一定是完成了的 future，我們調用 .get()方法就能立馬獲得結果。

看到這裡相信大家伙都應該多少明白點了

我們在使用ExecutorService submit提交任務後需要關註每個任務返回的future，然而CompletionService 對這些 future 進行了追蹤，並且重寫了done方法，讓你等的completionQueue 隊列裡面一定是完成了的task。
作為網關RPC層，我們不用因為某一個介面的響應慢拖累所有的請求，可以在處理最快響應的業務場景里使用CompletionService。

but 註意、註意、註意也是本次事故的核心

當只有調用了ExecutorCompletionService下麵的3個方法的任意一個時，阻塞隊列中的task執行結果才會從隊列中移除掉,釋放堆記憶體，由於該業務不需要使用任務的返回值，則沒進行調用take，poll方法。從而導致沒有釋放堆記憶體，堆記憶體會隨著調用量的增加一直增長。