java線程池參數(shù)位置導(dǎo)致的奪命故障宿主機(jī)打不開(kāi)

更新時(shí)間：2022年06月14日 11:09:40 作者：小姐姐味道

這篇文章主要為大家介紹了java線程池參數(shù)位置導(dǎo)致的奪命故障宿主機(jī)打不開(kāi)的問(wèn)題解決，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪

1. 出故障了

沒(méi)辦法，干it這一行，就得天天面對(duì)故障，大家就是傳說(shuō)中的消防員，到處救火。不過(guò)，這次的故障范圍有點(diǎn)大，宿主機(jī)都打不開(kāi)了。

好在監(jiān)控系統(tǒng)留下了一些證據(jù)。

證據(jù)發(fā)現(xiàn)，機(jī)器的CPU、內(nèi)存、文件句柄，隨著業(yè)務(wù)的增長(zhǎng)，持續(xù)的上升...上升....，直到監(jiān)控也無(wú)法將信息收集上來(lái)。

要命的是，這些宿主機(jī)上，部署了非常多的Java進(jìn)程。沒(méi)別的原因，就是為了節(jié)省成本，混部了應(yīng)用。當(dāng)宿主機(jī)表現(xiàn)出整體性的異常時(shí)，就難以找到罪魁禍?zhǔn)住?/p>

因?yàn)檫h(yuǎn)程登錄也Over，暴躁的運(yùn)維只能重啟機(jī)器，重啟機(jī)器之后開(kāi)始重啟應(yīng)用。經(jīng)過(guò)漫長(zhǎng)的等待，所有的進(jìn)程都活了，但是，僅僅過(guò)了片刻，宿主機(jī)又立即死去。

業(yè)務(wù)一直處于死翹翹的狀態(tài)，真是讓人惱火啊。也讓人心急。嘗試過(guò)幾次之后，運(yùn)維崩潰了，啟動(dòng)了緊急預(yù)案：回滾！

最近的上線記錄有點(diǎn)多，而且有開(kāi)發(fā)人員私自上線部署的行為，運(yùn)維蒙圈了：回滾哪些呢？還好有人腦瓜一亮，想起了還有find這個(gè)命令，那就找到最近更新的所有jar包，都給它來(lái)次回滾吧。

find?/apps/deploy?-mtime?+3?|?grep?jar$

如果你不知道find這個(gè)命令，那可還真的是一場(chǎng)災(zāi)難。還好有人知道。

把十來(lái)個(gè)jar包回滾，還好沒(méi)有碰到數(shù)據(jù)庫(kù)的schema變更，系統(tǒng)終于正常運(yùn)行了。

2. 找原因

沒(méi)別的辦法，查日志，進(jìn)行代碼審查。

代碼審查要追溯到最近1周或者2周之內(nèi)的代碼改動(dòng)，因?yàn)橛行┕δ艽a要沉淀一段時(shí)間，才能到線上風(fēng)光一把。

看著滿屏的提交記錄“OK”，技術(shù)經(jīng)理的臉都綠了。

“xjjdog說(shuō)過(guò)，《80%的程序員，不會(huì)寫commit記錄》，我看你們是100%都不會(huì)寫”。

大家都靜悄悄的，忍著痛翻查歷史變更。經(jīng)過(guò)大家的不懈努力，終于在屎山之間，找到了一些問(wèn)題代碼。CxO親自建了個(gè)群，大家一股腦的把可能會(huì)出問(wèn)題的代碼，扔到了群里面。

"系統(tǒng)服務(wù)中斷了接近一個(gè)小時(shí)，影響非常惡劣"，CxO說(shuō)，“務(wù)必把問(wèn)題徹底解決掉，這個(gè)問(wèn)題投資人非常關(guān)注”！

okokok，有了釘釘?shù)闹?，大家的手?shì)都變得整齊劃一。

3. 線程池的參數(shù)

代碼有點(diǎn)多，大家對(duì)問(wèn)題代碼討論了老久。包括一些使用并行流的，還有套在lamba表達(dá)式里的炫技代碼，還重點(diǎn)排查了一些線程池的使用代碼。

最后大家決定還是對(duì)線程池的代碼再過(guò)一遍。其中有一段是這么寫的。

RejectedExecutionHandler?handler?=?new?ThreadPoolExecutor.DiscardOldestPolicy();
ThreadPoolExecutor?executor?=?new?ThreadPoolExecutor(100,200,
????????????????60000,
????????????????TimeUnit.MILLISECONDS,
????????????????new?LinkedBlockingDeque<>(10),
????????????????handler);

還別說(shuō)，參數(shù)有模有樣的，甚至考慮到了拒絕策略。

Java的線程池，使得編程變的非常簡(jiǎn)單。它有很多參數(shù)，如上圖，我們一一介紹一下，否則代碼是無(wú)法審查的。

corePoolSize：核心線程數(shù)，核心線程創(chuàng)建后會(huì)一直存活

maxPoolSize：最大線程數(shù)

keepAliveTime：線程空閑時(shí)間

workQueue：阻塞隊(duì)列

threadFactory：線程創(chuàng)建工廠

handler：拒絕策略

下面來(lái)介紹一下它們的關(guān)系。

當(dāng)線程數(shù)小于核心線程數(shù)的時(shí)候，有新的任務(wù)到來(lái)，將會(huì)生成一個(gè)新的線程進(jìn)行服務(wù)。當(dāng)當(dāng)前線程數(shù)大于核心線程數(shù)，而且阻塞隊(duì)列未滿的時(shí)候，將會(huì)把任務(wù)放在阻塞隊(duì)列中。當(dāng)線程數(shù)大于核心線程數(shù)，而且阻塞隊(duì)列滿了的時(shí)候，將會(huì)創(chuàng)建新的線程進(jìn)行服務(wù)，直到線程數(shù)到達(dá)maximumPoolSize的大小。此時(shí)，如果還有新的任務(wù)，將觸發(fā)拒絕策略。

再說(shuō)一下拒絕策略。jdk默認(rèn)實(shí)現(xiàn)了4種策略，默認(rèn)實(shí)現(xiàn)的是AbortPolicy，也就是直接拋出異常。下面介紹其他幾種。

DiscardPolicy 比abort更加激進(jìn)，直接丟掉任務(wù)，連異常信息都沒(méi)有

CallerRunsPolicy 由調(diào)用的線程來(lái)處理這個(gè)任務(wù)。比如一個(gè)web應(yīng)用中，線程池資源占滿后，新進(jìn)的任務(wù)將會(huì)在tomcat線程中運(yùn)行。這種方式能夠延緩部分任務(wù)的執(zhí)行壓力，但在更多情況下，會(huì)直接阻塞主線程的運(yùn)行

DiscardOldestPolicy 丟棄隊(duì)列最前面的任務(wù)，然后重新嘗試執(zhí)行任務(wù)

這段線程池的代碼是新加的，參數(shù)設(shè)置還算正常，并沒(méi)有什么大的問(wèn)題。唯一有可能的風(fēng)險(xiǎn)，就是使用DiscardOldestPolicy 的拒絕策略。當(dāng)任務(wù)非常多的時(shí)候，這個(gè)拒絕策略會(huì)造成任務(wù)排隊(duì)，請(qǐng)求超時(shí)。

當(dāng)然不能放過(guò)這種風(fēng)險(xiǎn)，說(shuō)實(shí)話也是到現(xiàn)在為之能夠找到的最可能的風(fēng)險(xiǎn)代碼了。

"把DiscardOldestPolicy 改成默認(rèn)的AbortPolicy吧，重新打包上線一下試試“。技術(shù)大牛在群里說(shuō)。