作者：樹(shù)洞君
鏈接：https://juejin.cn/post/7064376361334358046
事故描述
從6點(diǎn)32分開(kāi)始少量用戶(hù)訪問(wèn)app時(shí)會(huì)出現(xiàn)首頁(yè)訪問(wèn)異常，到7點(diǎn)20分首頁(yè)服務(wù)大規(guī)模不可用，7點(diǎn)36分問(wèn)題解決。
整體經(jīng)過(guò)
6:58 發(fā)現(xiàn)報(bào)警，同時(shí)發(fā)現(xiàn)群里反饋首頁(yè)出現(xiàn)網(wǎng)絡(luò)繁忙，考慮到前幾日晚上門(mén)店列表服務(wù)上線發(fā)布過(guò)，所以考慮回滾代碼緊急處理問(wèn)題。
7:07 開(kāi)始先后聯(lián)系XXX查看解決問(wèn)題。
7:36 代碼回滾完，服務(wù)恢復(fù)正常。
事故根本原因-事故代碼模擬
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結(jié)果沒(méi) 調(diào)用take，poll方法。
正確的寫(xiě)法如下所示：
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();
}
一行代碼引發(fā)的血案，而且不容易被發(fā)現(xiàn)，因?yàn)閛om是一個(gè)內(nèi)存緩慢增長(zhǎng)的過(guò)程，稍微粗心大意就會(huì)忽略，如果是這個(gè)代碼塊的調(diào)用量少的話，很可能幾天甚至幾個(gè)月后暴雷。
操作人回滾or重啟服務(wù)器確實(shí)是最快的方式，但是如果不是事后快速分析出oom的代碼，而且不巧回滾的版本也是帶oom代碼的，就比較悲催了，如剛才所說(shuō)，流量小了，回滾或者重啟都可以釋放內(nèi)存；但是流量大的情況下，除非回滾到正常的版本，否則GG。
推薦一個(gè)開(kāi)源免費(fèi)的 Spring Boot 實(shí)戰(zhàn)項(xiàng)目：https://github.com/javastacks/spring-boot-best-practice
探詢(xún)問(wèn)題的根源
為了更好的理解ExecutorCompletionService的 “套路” 我們用 ExecutorService來(lái)作為對(duì)比，可以讓我們更好的清楚，什么場(chǎng)景下用ExecutorCompletionService。
先看ExecutorService代碼（建議down下來(lái)跑一跑）
public static void test1() throws Exception{
ExecutorService executorService = Executors.newCachedThreadPool();
ArrayList<Future<String>> futureArrayList = new ArrayList<>();
System.out.println("公司讓你通知大家聚餐 你開(kāi)車(chē)去接人");
Future<String> future10 = executorService.submit(() -> {
System.out.println("總裁：我在家上大號(hào) 我最近拉肚子比較慢 要蹲1個(gè)小時(shí)才能出來(lái) 你等會(huì)來(lái)接我吧");
TimeUnit.SECONDS.sleep(10);
System.out.println("總裁：1小時(shí)了 我上完大號(hào)了。你來(lái)接吧");
return "總裁上完大號(hào)了";
});
futureArrayList.add(future10);
Future<String> future3 = executorService.submit(() -> {
System.out.println("研發(fā)：我在家上大號(hào) 我比較快 要蹲3分鐘就可以出來(lái) 你等會(huì)來(lái)接我吧");
TimeUnit.SECONDS.sleep(3);
System.out.println("研發(fā)：3分鐘 我上完大號(hào)了。你來(lái)接吧");
return "研發(fā)上完大號(hào)了";
});
futureArrayList.add(future3);
Future<String> future6 = executorService.submit(() -> {
System.out.println("中層管理：我在家上大號(hào) 要蹲10分鐘就可以出來(lái) 你等會(huì)來(lái)接我吧");
TimeUnit.SECONDS.sleep(6);
System.out.println("中層管理：10分鐘 我上完大號(hào)了。你來(lái)接吧");
return "中層管理上完大號(hào)了";
});
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();
}
}
三個(gè)任務(wù)，每個(gè)任務(wù)執(zhí)行時(shí)間分別是 10s、3s、6s 。通過(guò)JDK線程池的 submit 提交這三個(gè) Callable類(lèi)型的任務(wù)。
- step1 主線程把三個(gè)任務(wù)提交到線程池里面去，把對(duì)應(yīng)返回的 Future 放到 List 里面存起來(lái)，然后執(zhí)行“都通知完了,等著接吧?！边@行輸出語(yǔ)句。
- step2在循環(huán)里面執(zhí)行 future.get() 操作，阻塞等待。 最后結(jié)果如下：
先通知到總裁，也是先接總裁 足足等了1個(gè)小時(shí)，接到總裁后再去接研發(fā)和中層管理，盡管他們?cè)缇屯晔聝毫?，也得等總裁上完廁所~~
耗時(shí)最久的-10s異步任務(wù)最先進(jìn)入list執(zhí)行，所以在循環(huán)過(guò)程中獲取這個(gè)10s的任務(wù)結(jié)果的時(shí)候，get操作會(huì)一直阻塞，直到10s異步任務(wù)執(zhí)行完畢。即使 3s、5s的任務(wù)早就執(zhí)行完了，也得阻塞等待10s任務(wù)執(zhí)行完。
看到這里 尤其是做網(wǎng)關(guān)業(yè)務(wù)的同學(xué)可能會(huì)產(chǎn)生共鳴，一般來(lái)說(shuō)網(wǎng)關(guān)RPC會(huì)調(diào)用下游N多個(gè)接口，如下圖
如果都按照ExecutorService這種方式，并且恰巧前幾個(gè)任務(wù)調(diào)用的接口耗時(shí)比較久，同時(shí)阻塞等待，那就比較悲催了。所以ExecutorCompletionService應(yīng)景而出。它作為任務(wù)線程的合理管控者，“任務(wù)規(guī)劃師”的稱(chēng)號(hào)名副其實(shí)。
相同場(chǎng)景 ExecutorCompletionService代碼
public static void test2() throws Exception {
ExecutorService executorService = Executors.newCachedThreadPool();
ExecutorCompletionService<String> completionService = new ExecutorCompletionService<>(executorService);
System.out.println("公司讓你通知大家聚餐 你開(kāi)車(chē)去接人");
completionService.submit(() -> {
System.out.println("總裁：我在家上大號(hào) 我最近拉肚子比較慢 要蹲1個(gè)小時(shí)才能出來(lái) 你等會(huì)來(lái)接我吧");
TimeUnit.SECONDS.sleep(10);
System.out.println("總裁：1小時(shí)了 我上完大號(hào)了。你來(lái)接吧");
return "總裁上完大號(hào)了";
});
completionService.submit(() -> {
System.out.println("研發(fā)：我在家上大號(hào) 我比較快 要蹲3分鐘就可以出來(lái) 你等會(huì)來(lái)接我吧");
TimeUnit.SECONDS.sleep(3);
System.out.println("研發(fā)：3分鐘 我上完大號(hào)了。你來(lái)接吧");
return "研發(fā)上完大號(hào)了";
});
completionService.submit(() -> {
System.out.println("中層管理：我在家上大號(hào) 要蹲10分鐘就可以出來(lái) 你等會(huì)來(lái)接我吧");
TimeUnit.SECONDS.sleep(6);
System.out.println("中層管理：10分鐘 我上完大號(hào)了。你來(lái)接吧");
return "中層管理上完大號(hào)了";
});
TimeUnit.SECONDS.sleep(1);
System.out.println("都通知完了,等著接吧。");
//提交了3個(gè)異步任務(wù)）
for (int i = 0; i < 3; i++) {
String returnStr = completionService.take().get();
System.out.println(returnStr + "，你去接他");
}
Thread.currentThread().join();
}
跑完結(jié)果如下：
這次就相對(duì)高效了一些，雖然先通知的總裁，但是根據(jù)大家上大號(hào)的速度，誰(shuí)先拉完先去接誰(shuí)，不用等待上大號(hào)最久的總裁了（現(xiàn)實(shí)生活里 建議采用第一種 不等總裁的后果 emmm 哈哈哈）。
放在一起對(duì)比下輸出結(jié)果：
兩段代碼的差異非常小 獲取結(jié)果的時(shí)候ExecutorCompletionService 使用了
completionService.take().get();
為什么要用take() 然后再get()呢？？？？我們看看源碼
CompletionService接口 以及接口的實(shí)現(xiàn)類(lèi)
1、ExecutorCompletionService是CompletionService接口的實(shí)現(xiàn)類(lèi) 
2、接著跟一下ExecutorCompletionService的構(gòu)造方法，可以看到入?yún)⑿枰獋饕粋€(gè)線程池對(duì)象，默認(rèn)使用的隊(duì)列是 LinkedBlockingQueue，不過(guò)還有另外一個(gè)構(gòu)造方法可以指定隊(duì)列類(lèi)型，如下兩張圖，兩個(gè)構(gòu)造方法。
默認(rèn)LinkedBlockingQueue的構(gòu)造方法 
可選隊(duì)列類(lèi)型的構(gòu)造方法 
3、submit任務(wù)提交的兩種方式，都是有返回值的，我們例子中用到的就是第一種Callable類(lèi)型的方法。 
4、對(duì)比ExecutorService 和 ExecutorCompletionService submit方法 可以看出區(qū)別 （1）ExecutorService
（2）ExecutorCompletionService
5、差異就在 QueueingFuture，這個(gè)到底作用是啥，我們繼續(xù)跟進(jìn)去看
- QueueingFuture 繼承自 FutureTask，而且紅線部分標(biāo)注的位置，重寫(xiě)了done()方法。
- 把 task 放到 completionQueue 隊(duì)列里面，當(dāng)任務(wù)執(zhí)行完成后，task就會(huì)被放到隊(duì)列里面去了。
- 此時(shí)此刻completionQueue隊(duì)列里面的 task 都是已經(jīng) done()完成了的 task，而這個(gè) task 就是我們拿到的一個(gè)個(gè)的future結(jié)果。
- 如果調(diào)用 completionQueue 的 task 方法，會(huì)阻塞等待任務(wù)。等到的一定是完成了的 future，我們調(diào)用 .get()方法 就能立馬獲得結(jié)果。
看到這里 相信大家伙都應(yīng)該多少明白點(diǎn)了
- 我們?cè)谑褂肊xecutorService submit提交任務(wù)后需要關(guān)注每個(gè)任務(wù)返回的future，然而CompletionService 對(duì)這些 future 進(jìn)行了追蹤，并且重寫(xiě)了done方法，讓你等的completionQueue 隊(duì)列里面 一定是完成了的task。
- 作為網(wǎng)關(guān)RPC層，我們不用因?yàn)槟骋粋€(gè)接口的響應(yīng)慢拖累所有的請(qǐng)求，可以在處理最快響應(yīng)的業(yè)務(wù)場(chǎng)景里使用CompletionService。
but 注意、注意、注意 也是本次事故的核心
當(dāng)只有調(diào)用了ExecutorCompletionService下面的3個(gè)方法的任意一個(gè)時(shí)，阻塞隊(duì)列中的task執(zhí)行結(jié)果才會(huì)從隊(duì)列中移除掉,釋放堆內(nèi)存，由于該業(yè)務(wù)不需要使用任務(wù)的返回值，則沒(méi)進(jìn)行調(diào)用take，poll方法。從而導(dǎo)致沒(méi)有釋放堆內(nèi)存，堆內(nèi)存會(huì)隨著調(diào)用量的增加一直增長(zhǎng)。
所以，業(yè)務(wù)場(chǎng)景中不需要使用任務(wù)返回值的 別沒(méi)事兒使用CompletionService，假如使用了，記得一定要從阻塞隊(duì)列中 移除掉task執(zhí)行結(jié)果，避免OOM！
總結(jié)
知道事故的原因，我們來(lái)總結(jié)下方法論，畢竟孔子他老人家說(shuō)過(guò)：自省吾身，常思己過(guò)，善修其身！
上線前：
- 嚴(yán)格的代碼review習(xí)慣，一定要交給back人去看，畢竟自己寫(xiě)的代碼自己是看不出問(wèn)題的，相信每個(gè)程序猿都有這個(gè)自信（這個(gè)后續(xù)事故里可能會(huì)反復(fù)提到！很重要）
- 上線記錄-備注好上一個(gè)可回滾的包版本（給自己留一個(gè)后路）
- 上線前確認(rèn)回滾后，業(yè)務(wù)是否可降級(jí)，如果不可降級(jí)，一定要嚴(yán)格拉長(zhǎng)這次上線的監(jiān)控周期 上線后：
- 持續(xù)關(guān)注內(nèi)存增長(zhǎng)情況（這部分極容易被忽略，大家對(duì)內(nèi)存的重視度不如cpu使用率）
- 持續(xù)關(guān)注cpu使用率增長(zhǎng)情況
- gc情況、線程數(shù)是否增長(zhǎng)、是否有頻繁的fullgc等
- 關(guān)注服務(wù)性能報(bào)警，tp99、999 、max是否出現(xiàn)明顯的增高
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
2.勁爆！Java 協(xié)程要來(lái)了。。。
3.Spring Boot 2.x 教程，太全了！
4.別再寫(xiě)滿(mǎn)屏的爆爆爆炸類(lèi)了，試試裝飾器模式，這才是優(yōu)雅的方式！！
5.《Java開(kāi)發(fā)手冊(cè)（嵩山版）》最新發(fā)布，速速下載！文章來(lái)源：http://www.zghlxwxcb.cn/news/detail-632276.html
覺(jué)得不錯(cuò)，別忘了隨手點(diǎn)贊+轉(zhuǎn)發(fā)哦！文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-632276.html
到了這里，關(guān)于同事寫(xiě)了個(gè)驚天 bug，還不容易被發(fā)現(xiàn)。。的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
