五年java開發生涯中一次吐血的項目救火（程序員何苦難爲程序員）

我如今就任於一家中型的互聯網企業，去年年末入職的薪資和待遇都很不錯，可是總結起來講的好聽就是全村人的但願，說的很差聽就是一我的幾乎幹了一個項目組的事。下面是個人一次項目救火經歷（背鍋經歷）。就是年後的一個合做公司上線了一個子業務系統，對接公司內部的單點系統。我收到該公司的技術諮詢:項目啓動後沒有規律的忽然沒法登陸了,從新啓動後，登陸一斷時間後又沒法從新登陸，對方技術人員一頭霧水不知道什麼緣由，後臺日誌沒有任何錯誤信息。我臨危受命，趕往該項目進行撲火工做，其實原本2天均可以解決的問題，讓我花了5天解決。具體緣由待我一一解釋。

1，未掌握log日誌的精髓

　　log日誌的debug，info，error信息亂打，該用debug的用info,該用info的用debug......，致使的結果就是一個登錄成功請求，後臺日誌打了300行代碼，嚴重影響了排查追蹤問題的效率，項目線上日誌級別仍爲debug級別，換成info級別呢，結果好多關鍵信息又沒有打印。

　　日誌輸出格式的關鍵信息不完善，該日誌是在哪類目名、發生的線程，以及在代碼中的行數都沒有清楚的顯示出來，這個日誌是哪裏打印的都無從知曉。

　　關於這裏，我想說的是，會的框架再多，spark，flink，hadoop，消息中間件等各類上層框架配置的在溜只是花拳繡腿，log日誌是內功，它是往後面對各類線上問題可以快速排查的一種手段。

　　下面這個是他的日誌輸出:

2，核心參數不作判斷

　　方法返回的數據不作null或""字符串判斷，致使各類狀況的空指針異常。項目的功能都是理想化，預想我就是須要這些數據才能給你正確的結果，不然哪裏出錯我不知道。這個問題致使我在還原案件現場時給我形成極大的困惑，一不留神一個空指針錯誤，我必須對這個錯誤進行增強的判斷處理，好方便我模擬出登陸屢次後沒法登陸的狀況。

　　另外項目中sql語句的in的使用不規範，結合前面的null判斷沒有，出現一種:"咦，我用這個帳號登陸就成功了，sql是正確的，用這我的的帳號登陸，怎麼就報sql語法不正確啊，明明調用的是同一塊的代碼啊"

很明顯的roleid爲"'字符串的話，這條sql語句的語法是由問題的。

3，局部變量提高爲靜態變量

　　這個是文章開頭提的問題的緣由，由於登陸要向單點系統驗證用戶的身份，因此它採用httpclient框架來發送http請求，它在這裏把httpclient的變量做爲一個靜態變量，而後在方法裏面複用該對象，而後方法裏面調用完該對象又沒有釋放資源合理的close，這個框架默認會維護一個鏈接池，若是你申請一個資源使用後不釋放，那麼該資源將不被下一個請求使用，新的請求必須在等待隊列中等待，而後當用戶登陸20次後，把資源池中的請求都耗盡了，新的請求拿不到資源位於等待隊列中不斷等待，致使服務器超時，登陸失敗504錯誤。

當時我看到這個類的靜態變量時httpclient的時候，我心中就飄起很差的預感，此處是一個容易出錯的地方，若是是我，對這個框架，這個類沒有十足的把握，我會它把整成局部變量，這樣在低併發下，就讓GC去幫我回收吧。

改造後:

4，攔截器的路徑規劃混亂

　　這個問題也爲我排查問題形成了阻礙，排查登陸問題，我首先要把它一次登陸成功後後端走的方法軌跡追蹤出來，看究竟是哪個環節的代碼問題，由於沒有任務錯誤信息。他的攔截器呢，一個登陸請求成功攔截器反覆執行了三次，中間至少有一次攔截器是沒有作任何有效出來，出現這的問題是他前端業務發送無關的請求，被攔截致使的，這個逼得我經過日誌插樁計數來還原勾勒出它的完整路徑，爲我審查代碼找到調用httpclient這一塊的代碼問題提供的機會。

5，亂用try catch

　　這個也很噁心，它的代碼忽然try catch包裝一下，咦，這個傢伙得不錯，還對某些異常進行特殊打標記錄，我仔細看了一下代碼，這是什麼鬼啊，catch中怎麼把異常信息吃了，吃了就吃了，你爲啥也不打印異常信息，也不throws異常，就這樣兇猛的將異常吃了，明明有問題，它不報，經過它來引起一個新的異常來雪藏真正的問題。

最後我想說，程序員何苦難爲程序員，代碼留一線， 往後好相見啥。你也不想本身給本身挖坑後，解決不了，而後來一句"大哥，你忙嗎，我這有個小問題，幫忙看下唄(嗑瓜子)"。

若是對java微服務、分佈式、高併發、高可用、大型互聯網架構技術、面試經驗交流。感興趣能夠關注個人微信公衆號，我會在公衆號不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。歡迎分享，歡迎評論，歡迎轉發。