ImportNew - 多線程使用不當導致的 OOM－鑽石舞台

Jun 29 Wed 2022 01:00
ImportNew - 多線程使用不當導致的 OOM

（給ImportNew加星標，提高Java技能）

事故描述

從 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方法。

正確的寫法如下所示：

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

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

探尋問題根源

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

先看 ExecutorService 代碼（建議下載後自己跑一跑）

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 類型的任務。

第一步：主線程把三個任務提交到線程池裡面去，把對應返回的 Future 放到 List 裡面存起來，然後執行「都通知完了,等着接吧。」這行輸出語句；

第二步：在循環裡面執行 future.get() 操作，阻塞等待。

最後結果如下：

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

耗時最久的-10s 異步任務最先進入 list 執行。所以在循環過程中獲取這個 10 s的任務結果的時候，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();}

跑完結果如下：