一個畢生難忘的BUG

記得之前接手過一個Java項目，服務器程序，直接讓Jar在linux上跑的那種，

 

這個項目由兩個web服務組成，也就是兩條Java進程，主進程 xxx.jar，輔助進程 xxx_helper.jar。主進程程序中某些功能依賴於輔助進程提供的服務。

 

困擾咱們的BUG是在生產環境中輔助進程xxx_helpler.jar不定時無端崩潰，且無jvm錯誤日誌產生，也無被系統自己由於資源損耗嚴重問題而殺死的記錄。 百思不得其解之下咱們只能把問題歸因因而程序存在性能問題而被殺死，至於爲何沒有殺死記錄沒人知道。 當時團隊中沒有linux玩的很溜的人，也不會查記錄，經過咱們那點粗淺的經驗，咱們想固然的覺得程序崩潰就是由於消耗內存過多被系統殺死的，由於當時跑這個程序的機器內存異常緊張，全部人的思路都往這個方向被帶了過去。

 

我開始優化xxx_helper.jar程序的性能，什麼緩存、多線程、jvm啓動參數調優、下降代碼算法事件複雜的，反正各類折騰，幾乎把代碼所有重寫一遍， 可程序無辜崩潰問題依舊存在 。

 

爲了這個問題我連着好多天吃很差睡不香，作夢都在想辦法解決這個問題。 寫代碼多年，這個問題讓我體驗到史無前例的無力感。 然而，正當我機關用盡之際， 起色來了。 我無心間打開了重啓主進程xxx.jar的腳本，發現裏面有這麼一段

 

ps aux | grep xxx | awk  '{print $2}' | xargs kill -9

 

這段腳本的做用是，提取進程名稱中有xxx關鍵字的進程ID， 而後kill之。由於整個腳本的邏輯是先關閉存在的進程，而後再啓動。

 

而個人項目主進程xxx.jar和輔助進程xxx_helper.jar名稱中都存在xxx關鍵字， 也就是說以前xxx_helper.jar這個進程無辜崩潰並非由於程序自己的緣由，而是由於主進程啓動腳本在殺死主進程xxx.jar時一道把xxx_helper.jar也給殺了。

 

看到這段腳本我整我的呆了，就由於一時疏忽，卻浪費了好幾天的時間， 這跟花了幾千塊錢買到價值幾塊錢的東西是同樣的感覺，並且我這仍是本身坑本身，這種滋味別提有多難受了。 我當時就用38碼的手狠狠的抽打本身40碼的臉，以發泄心裏悔恨自責的情緒。

 

後來，等冷靜下來之後，我只能安慰本身花了這麼多功夫也不是一無所得，至少程序的性能是被我實實在在優化了。 雖然， 這種優化對於這個項目是毫無心義的。

 

經過這個事故我領悟到，對於某些頑固的程序BUG，當咱們根據本身想固然的經驗難以找到造成緣由時， 就應該跳出問題的自己或者本身尋找BUG的思惟框架來思考， 由於形成BUG的緣由每每和以前尋找BUG的路徑八竿子打不着。