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

標籤：java   架構   

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

1，未掌握log日誌的精髓

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

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

　　關於這裡，我想說的是，會的架構再多，spark，flink，hadoop，訊息中介軟體等各種上層架構配置的在溜只是花拳繡腿，log日誌是內功，它是日後面對各種線上問題能夠快速排查的一種手段。

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

2，核心參數不做判斷

　　方法返回的資料不做null或""字串判斷，導致各種情況的null 指標異常。項目的功能都是理想化，預想我就是需要這些資料才能給你正確的結果，否則哪裡出錯我不知道。這個問題導致我在還原案例現場時給我造成極大的困惑，一不留神一個null 指標錯誤，我必須對這個錯誤進行加強的判斷處理，好方便我類比出登入多次後無法登入的情況。

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

很明顯的roleid為"‘字串的話，這條sql語句的文法是由問題的。

3，局部變數提升為靜態變數

　　這個是文章開頭提的問題的原因，因為登入要向單點系統驗證使用者的身份，所以它採用httpclient架構來發送http請求，它在這裡把httpclient的變數作為一個靜態變數，然後在方法裡面複用該對象，然後方法裡面調用完該對象又沒有釋放資源合理的close，這個架構預設會維護一個串連池，如果你申請一個資源使用後不釋放，那麼該資源將不被下一個請求使用，新的請求必須在等待隊列中等待，然後當使用者登入20次後，把資源集區中的請求都耗盡了，新的請求拿不到資源位於等待隊列中不斷等待，導致伺服器逾時，登入失敗504錯誤。
如果想學習Java工程化、高效能及分布式、深入淺出。微服務、Spring，MyBatis，Netty源碼分析的朋友可以加我的Java進階群：582505643，群裡有阿里大牛直播講解技術，以及Java大型互連網技術的視頻免費分享給大家。

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

改造後:

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

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

5，亂用try catch

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

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

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