本文轉載自微信公眾號「小姐姐味道」，作者小姐姐養的狗。轉載本文請聯系小姐姐味道公眾號。

我聽說，牛x的人，都關注整體，不關注細節，因為他們覺得沒必要;我也聽說，管理的哲學，就是協調資源，讓人俯首甘為孺子牛，不達目的不罷休。

在這種環境下耳濡目染很多年，人生就有一股若有若無的錯覺：管理可以解決一切問題。如果管理解決不了，那一定是流程的問題。

但看了PDD這種企業的管理方式以后，信仰再次轉折，我又覺得這是錯誤的。PDD的管理模式，打臉了所有高校的《管理學》課程，讓所有從事管理工作的人，顏面掃地。

只要錢給夠，不需要什么管理!只有沒錢的窮B公司才在哪里文鄒鄒的搞管理。要說高能的、正統的管理學，那非傳銷莫屬。

話說的有點遠，已經進入了跑題的路上，我們需要用一個故障把它拉回來。

1. 出故障了

沒辦法，干it這一行，就得天天面對故障，大家就是傳說中的消防員，到處救火。不過，這次的故障范圍有點大，宿主機都打不開了。

好在監控系統留下了一些證據。

證據發現，機器的CPU、內存、文件句柄，隨著業務的增長，持續的上升...上升....，直到監控也無法將信息收集上來。

要命的是，這些宿主機上，部署了非常多的Java進程。沒別的原因，就是為了節省成本，混部了應用。當宿主機表現出整體性的異常時，就難以找到罪魁禍首。

因為遠程登錄也Over，暴躁的運維只能重啟機器，重啟機器之后開始重啟應用。經過漫長的等待，所有的進程都活了，但是，僅僅過了片刻，宿主機又立即死去。

業務一直處于死翹翹的狀態，真是讓人惱火啊。也讓人心急。嘗試過幾次之后，運維崩潰了，啟動了緊急預案：回滾!

最近的上線記錄有點多，而且有開發人員私自上線部署的行為，運維蒙圈了：回滾哪些呢?還好有人腦瓜一亮，想起了還有find這個命令，那就找到最近更新的所有jar包，都給它來次回滾吧。

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

如果你不知道find這個命令，那可還真的是一場災難。還好有人知道。

把十來個jar包回滾，還好沒有碰到數據庫的schema變更，系統終于正常運行了。

2. 找原因

沒別的辦法，查日志，進行代碼審查。

代碼審查要追溯到最近1周或者2周之內的代碼改動，因為有些功能代碼要沉淀一段時間，才能到線上風光一把。

看著滿屏的提交記錄“OK”，技術經理的臉都綠了。

“xjjdog說過，《80%的程序員，不會寫commit記錄》，我看你們是100%都不會寫”。

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

"系統服務中斷了接近一個小時，影響非常惡劣"，CxO說，“務必把問題徹底解決掉，這個問題投資人非常關注”!

okokok，有了釘釘的助力，大家的手勢都變得整齊劃一。

3. 線程池的參數

代碼有點多，大家對問題代碼討論了老久。包括一些使用并行流的，還有套在lamba表達式里的炫技代碼，還重點排查了一些線程池的使用代碼。

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

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

還別說，參數有模有樣的，甚至考慮到了拒絕策略。

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

• corePoolSize：核心線程數，核心線程創建后會一直存活
• maxPoolSize：最大線程數
• keepAliveTime：線程空閑時間
• workQueue：阻塞隊列
• threadFactory：線程創建工廠
• handler：拒絕策略

下面來介紹一下它們的關系。

當線程數小于核心線程數的時候，有新的任務到來，將會生成一個新的線程進行服務。當當前線程數大于核心線程數，而且阻塞隊列未滿的時候，將會把任務放在阻塞隊列中。當線程數大于核心線程數，而且阻塞隊列滿了的時候，將會創建新的線程進行服務，直到線程數到達maximumPoolSize的大小。此時，如果還有新的任務，將觸發拒絕策略。

再說一下拒絕策略。jdk默認實現了4種策略，默認實現的是AbortPolicy，也就是直接拋出異常。下面介紹其他幾種。

• DiscardPolicy 比abort更加激進，直接丟掉任務，連異常信息都沒有
• CallerRunsPolicy 由調用的線程來處理這個任務。比如一個web應用中，線程池資源占滿后，新進的任務將會在tomcat線程中運行。這種方式能夠延緩部分任務的執行壓力，但在更多情況下，會直接阻塞主線程的運行
• DiscardOldestPolicy 丟棄隊列最前面的任務，然后重新嘗試執行任務

這段線程池的代碼是新加的，參數設置還算正常，并沒有什么大的問題。唯一有可能的風險，就是使用DiscardOldestPolicy 的拒絕策略。當任務非常多的時候，這個拒絕策略會造成任務排隊，請求超時。

當然不能放過這種風險，說實話也是到現在為之能夠找到的最可能的風險代碼了。

"把DiscardOldestPolicy 改成默認的AbortPolicy吧，重新打包上線一下試試“。技術大牛在群里說。

4. 問題在哪里?

結果，服務灰度上線之后，宿主機不多時，就死掉了。是它的原因沒跑了，但是why?

線程池的大小 ，最小100，最大200，說什么也不過分。阻塞隊列的容量只有10，說什么也不會造成問題。你要說是這個線程池造成的原因，打死我都不信。

但是業務部門反饋，這段代碼加上就死，不加就沒事。技術大牛們抓耳撓腮百思不得其姐。

到最后，終于有人忍不住了，下載下業務的代碼打算調試一下。

當他打開Idea的時候，瞬間懵逼了，又瞬間領悟了。他終于明白了這段代碼為什么會產生問題了。

線程池，竟然是在方法里創建的!

當每一個請求到來的時候，它都會創建一個線程池，直到系統再也無法分配資源為止。

可真是霸道啊。

所有人都在關注線程池的參數是怎么設置的，但從來沒有人懷疑這段代碼所在的位置。

5. 結尾

問題低級又常見，現在我嚴重懷疑拒絕策略也是網上拷貝的代碼。

那么多碼農，熬夜選擇了個業務低峰期進行上線，還是躲不過命啊，躲不過豬隊友的傷害。

當然，這還說明了另外一個問題：技術能力跟不上，再牛的管理也愛莫能助。

最后，連投資人都施壓的故障，幾乎沒有人愿意去實際的翻一下業務的代碼看看。這得多大的屎山，才讓人這樣避而遠之，生怕把自己的羽毛染臭啊!

作者簡介：小姐姐味道 (xjjdog)，一個不允許程序員走彎路的公眾號。聚焦基礎架構和Linux。十年架構，日百億流量，與你探討高并發世界，給你不一樣的味道。我的個人微信xjjdog0，歡迎添加好友，進一步交流。