7月安卓手機(jī)性價(jià)比榜：努比亞+紅魔兩款新機(jī)入榜
7月登場(chǎng)的新機(jī)有努比亞Z50S Pro和紅魔8S Pro，除了三星之外目前唯二的兩款搭載超頻版驍龍8Gen2處理器的產(chǎn)品，而且努比亞和紅魔也一貫有著不錯(cuò)的性價(jià)比，所以在本次的性價(jià)比榜單
線程池用多了總會(huì)出現(xiàn)些詭異問(wèn)題，特別是當(dāng)任務(wù)間的關(guān)系比較復(fù)雜時(shí)，經(jīng)常會(huì)出現(xiàn)讓你想象不到問(wèn)題，比如這次出現(xiàn)的這個(gè)問(wèn)題。
突然間，系統(tǒng)出現(xiàn)大量報(bào)警，具體信息如下：
圖片
從拋出的異常可知，提交量較大導(dǎo)致線程池資源被耗盡，從而觸發(fā)了線程池的拒絕策略，直接拋出了 RejectedExecutionException。
開(kāi)始的時(shí)候，小艾認(rèn)為等高峰流量過(guò)去后，系統(tǒng)便能恢復(fù)正常。可出乎意料的是，系統(tǒng)一直沒(méi)有恢復(fù)，那么流量已經(jīng)將至個(gè)位數(shù)，請(qǐng)求也是 100% 失敗，同時(shí)該節(jié)點(diǎn)的大量后臺(tái)任務(wù)都出現(xiàn)異常。沒(méi)有辦法，為了快速止損，不得已對(duì)異常節(jié)點(diǎn)進(jìn)行重啟，系統(tǒng)隨之恢復(fù)正常，日志輸入如下：
圖片
其他的后臺(tái)任務(wù)也恢復(fù)正常。
驚魂初定的小艾找到出問(wèn)題的代碼如下：
@GetMapping("syncSubmit")public RestResult<String> syncSubmit(String taskName){ this.executeService.submit(new ParentTask()); return RestResult.success("提交成功");}class ParentTask implements Callable<Boolean>{ @Override public Boolean call() throws Exception { Future<A> aFuture = executeService.submit(new FetchAChildTask()); doSomeThing(500); Future<B> bFuture = executeService.submit(new FetchBChildTask()); doSomeThing(500); C c = buildC(aFuture.get(), bFuture.get()); Future<Boolean> cFuture = executeService.submit(new SaveCChildTask(c)); return cFuture.get(); }}代碼的邏輯非常簡(jiǎn)單，核心流程如下圖所示：
圖片
核心流程為：
邏輯非常簡(jiǎn)單，唯一的復(fù)雜點(diǎn)在于：==多處任務(wù)提交使用了統(tǒng)一線程池。==
【背景】考慮到線程池是系統(tǒng)中最寶貴的資源，公司“大牛”封裝了一個(gè)全局的 GlobalExecuteService 服務(wù)，并制定規(guī)范要求所有異步任務(wù)統(tǒng)一使用 GlobalExecuteService 來(lái)完成。如果需要構(gòu)建自己的線程池，需要向他提交審批，只有在審批后才能創(chuàng)建新的線程池。
線程池處于什么狀態(tài)？為什么所有異步任務(wù)都無(wú)法提交？
這是一個(gè)比較燒腦的問(wèn)題，單盤(pán)邏輯沒(méi)有什么頭緒，沒(méi)有辦法只能將現(xiàn)場(chǎng) dump 下來(lái)進(jìn)行分析。
第一個(gè)問(wèn)題：線程池線程都處于什么狀態(tài)，線程棧信息如下：
圖片
從日志中可知：
接下來(lái)，需要進(jìn)一步確認(rèn) FutureTask#10 具體處于什么狀態(tài)，從內(nèi)存堆中找到 FutureTask#10 對(duì)象，詳細(xì)信息如下：
圖片
從日志中可以看出：
排查到這里，真相浮出水面：GlobalExecuteService 中的線程，正在等待 GlobalExecuteService 阻塞隊(duì)列的任務(wù)完成。
具體如下圖所示：
圖片
線程池中的所有工作線程都在等待阻塞隊(duì)列的任務(wù)完成，由于沒(méi)有可用的工作線程，阻塞隊(duì)列中的任務(wù)永遠(yuǎn)都不會(huì)被執(zhí)行。
這就是典型的死鎖！！！
費(fèi)了老大勁終于定位問(wèn)題，解決思路也就變的明了：不要向自己運(yùn)行的線程池提交任務(wù)。
圖解如下：
圖片
線程池不會(huì)向自己提交任務(wù)，而是將任務(wù)提交到其他線程池。
問(wèn)題修復(fù)變的簡(jiǎn)單，我們需要：
具體代碼如下：
@Autowiredprivate GlobalExecuteService executeService;// 創(chuàng)建新的線程池服務(wù)@Autowiredprivate SubExecuteService subExecuteService;@GetMapping("syncSubmit")public RestResult<String> syncSubmit(String taskName){ this.executeService.submit(new ParentTask()); return RestResult.success("提交成功");}class ParentTask implements Callable<Boolean>{ @Override public Boolean call() throws Exception { log.info("Begin to Run Parent Task"); // 向新的線程池服務(wù)提交任務(wù) Future<A> aFuture = subExecuteService.submit(new FetchAChildTask()); doSomeThing(500); // 向新的線程池服務(wù)提交任務(wù) Future<B> bFuture = subExecuteService.submit(new FetchBChildTask()); doSomeThing(500); C c = buildC(aFuture.get(), bFuture.get()); // 向新的線程池服務(wù)提交任務(wù) Future<Boolean> cFuture = subExecuteService.submit(new SaveCChildTask(c)); Boolean result = cFuture.get(); log.info("End to Run Parent Task"); return result; }}手工拆分線程池確實(shí)能解決這個(gè)場(chǎng)景的問(wèn)題，但由于 GlobalExecuteService 服務(wù)已經(jīng)使用很長(zhǎng)時(shí)間，任務(wù)間的關(guān)系錯(cuò)綜復(fù)雜，很難一次性排查并修復(fù)所有問(wèn)題，同時(shí)隨著邏輯的變化未來(lái)仍舊會(huì)出現(xiàn)類似的問(wèn)題。
那最佳方案是什么？
讓 GlobalExecuteService 具備多級(jí)管理能力。核心代碼如下：
@Servicepublic class GlobalExecuteServiceV2 { // 記錄當(dāng)前線程運(yùn)行級(jí)別，默認(rèn) 0，表示當(dāng)前線程非該類管理的線程池線程 private static final ThreadLocal<Integer> LEVEL_HOLDER = ThreadLocal.withInitial(()->0); // 一級(jí)線程池 private ExecutorService executorServiceLeve1; // 二級(jí)線程池 private ExecutorService executorServiceLeve2; // 默認(rèn)線程池 private ExecutorService defExecutorService; @PostConstruct public void init() { // 省略線程池初始化邏輯 } public <T> Future<T> submit(Callable<T> callable){ // 獲取當(dāng)前線程的運(yùn)行級(jí)別 Integer level = LEVEL_HOLDER.get(); // 根據(jù)當(dāng)前運(yùn)行級(jí)別，計(jì)算子任務(wù)所使用的線程池 ExecutorService executorService = getNextExecutorServiceByLevel(level); // 為子任務(wù)分配運(yùn)行級(jí)別 CallableWrapper<T> callableWrapper = new CallableWrapper<>(level + 1, callable); // 提交任務(wù) return executorService.submit(callableWrapper); } private ExecutorService getNextExecutorServiceByLevel(Integer level) { if (level == 0){ return executorServiceLeve1; } if (level == 1){ return executorServiceLeve2; } return defExecutorService; } class CallableWrapper<T> implements Callable<T>{ private final Integer level; private final Callable<T> callable; CallableWrapper(Integer level, Callable<T> callable) { this.level = level; this.callable = callable; } @Override public T call() throws Exception { try { // 為線程池綁定運(yùn)行級(jí)別 LEVEL_HOLDER.set(level); return callable.call(); }finally { // 清理線程池運(yùn)行級(jí)別 LEVEL_HOLDER.remove(); } } }}核心設(shè)計(jì)如下：
為了演示方便，僅定義了 3 級(jí)線程池，通常情況下足夠業(yè)務(wù)使用，但需要注意：
- 超過(guò)三級(jí)提交，仍舊有可以出現(xiàn)死鎖的情況，可以通過(guò)日志方式及時(shí)暴露問(wèn)題
- 如不放心，可以升級(jí)為 “無(wú)限極” 設(shè)計(jì)，及使用 List<ExecutorService> 對(duì)線程池進(jìn)行統(tǒng)一管理，并根據(jù) Level 完成線程池的動(dòng)態(tài)創(chuàng)建
代碼倉(cāng)庫(kù)：
https://gitee.com/litao851025/learnFromBug
代碼地址：
https://gitee.com/litao851025/learnFromBug/tree/master/src/main/java/com/geekhalo/demo/thread/deadlock
本文鏈接：http://www.www897cc.com/showinfo-26-70483-0.html故障現(xiàn)場(chǎng) | 這個(gè)死鎖出奇的詭異
聲明：本網(wǎng)頁(yè)內(nèi)容旨在傳播知識(shí)，若有侵權(quán)等問(wèn)題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系，我們將在第一時(shí)間刪除處理。郵件：2376512515@qq.com
上一篇： CSS 和 SVG 實(shí)現(xiàn)彩色圖片陰影
下一篇： 我們一起聊聊React列表渲染與Key
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請(qǐng)聯(lián)系：2376512515@qq.com 津ICP備18001702號(hào)
津公網(wǎng)安備 12010102000574號(hào)