開發致使的內存泄露問題,這樣排查不背鍋!


做者:枕邊書
來源:https://zhenbianshu.github.iojava

前些日子小組內安排值班,輪流看顧咱們的服務,主要作一些報警郵件處理、Bug排查、運營issue處理的事。工做日還好,不管幹什麼都要上班的,如果輪到週末,那這一天算是毀了。git

不知道是公司網絡廣了就這樣仍是網絡運維組不給力,網絡總有問題,不是這邊交換機脫網了,就是那邊路由器壞了,還偶發地各類超時,而咱們靈敏地服務探測服務總能準確地抓住偶現的小問題,給美好的工做加點料。github

好幾回值班組的小夥伴們一塊兒吐槽,商量着怎麼避過服務保活機制,偷偷停了探測服務而不讓人發現(雖然也並不敢)。web

前些天我就在週末處理了一次探測服務的鍋。本文會持續修訂,你們能夠繼續關注。服務器

1、問題網絡

網絡問題?多線程

晚上七點多開始,我就開始不停地收到報警郵件,郵件顯示探測的幾個接口有超時狀況。 多數執行棧都在:運維

這個線程棧的報錯我見得多了,咱們設置的HTTP DNS超時是1s,connect超時是2s,read超時是3s,這種報錯都是探測服務正常發送了HTTP請求,服務器也在收到請求正常處理後正常響應了,但數據包在網絡層層轉發中丟失了,因此請求線程的執行棧會停留在獲取接口響應的地方。jvm

這種狀況的典型特徵就是能在服務器上查找到對應的日誌記錄。並且日誌會顯示服務器響應徹底正常。與它相對的還有線程棧停留在Socket connect處的,這是在建連時就失敗了,服務端徹底無感知。工具

我注意到其中一個接口報錯更頻繁一些,這個接口須要上傳一個4M的文件到服務器,而後通過一連串的業務邏輯處理,再返回2M的文本數據,而其餘的接口則是簡單的業務邏輯,我猜想多是須要上傳下載的數據太多,因此超時致使丟包的機率也更大吧。

根據這個猜測,羣登上服務器,使用請求的request_id在近期服務日誌中搜索一下,果不其然,就是網絡丟包問題致使的接口超時了。

固然這樣leader是不會滿意的,這個結論還得有人接鍋才行。因而趕忙聯繫運維和網絡組,向他們確認一下當時的網絡狀態。網絡組同窗回覆說是咱們探測服務所在機房的交換機老舊,存在未知的轉發瓶頸,正在優化,這讓我更放心了,因而在部門羣裏簡單交待一下,算是完成任務。

問題爆發

本覺得此次值班就起這麼一個小波浪,結果在晚上八點多,各類接口的報警郵件蜂擁而至,打得準備收拾東西過週日單休的我措手不及。

此次幾乎全部的接口都在超時,而咱們那個大量網絡I/O的接口則是每次探測必超時,難道是整個機房故障了麼?

我再次經過服務器和監控看到各個接口的指標都很正常,本身測試了下接口也徹底OK,既然不影響線上服務,我準備先經過探測服務的接口把探測任務停掉再慢慢排查。

結果給暫停探測任務的接口發請求很久也沒有響應,這時候我才知道沒這麼簡單。

2、解決

內存泄漏

因而趕快登錄探測服務器,首先是top free df三連,結果還真發現了些異常。

咱們的探測進程CPU佔用率特別高,達到了900%。

咱們的Java進程,並不作大量CPU運算,正常狀況下,CPU應該在100~200%之間,出現這種CPU飆升的狀況,要麼走到了死循環,要麼就是在作大量的GC。

使用jstat -gc pid [interval]命令查看了java進程的GC狀態,果真,FULL GC達到了每秒一次。

這麼多的FULL GC,應該是內存泄漏沒跑了,因而使用jstack pid > jstack.log保存了線程棧的現場,使用jmap -dump:format=b,file=heap.log pid保存了堆現場,而後重啓了探測服務,報警郵件終於中止了。

jstat

jstat是一個很是強大的JVM監控工具,通常用法是:jstat [-options] pid interval

它支持的查看項有:

  • class查看類加載信息
  • compile編譯統計信息
  • gc垃圾回收信息
  • gcXXX各區域GC的詳細信息,如-gcold

使用它,對定位JVM的內存問題頗有幫助。

3、排查

問題雖然解決了,但爲了防止它再次發生,仍是要把根源揪出來。

分析棧

棧的分析很簡單,看一下線程數是否是過多,多數棧都在幹嗎。

才四百多線程,並沒有異常。

線程狀態好像也無異常,接下來分析堆文件。

下載堆dump文件

堆文件都是一些二進制數據,在命令行查看很是麻煩,Java爲咱們提供的工具都是可視化的,Linux服務器上又無法查看,那麼首先要把文件下載到本地。

因爲咱們設置的堆內存爲4G,因此dump出來的堆文件也很大,下載它確實很是費事,不過咱們能夠先對它進行一次壓縮。

gzip是個功能很強大的壓縮命令,特別是咱們能夠設置-1~-9來指定它的壓縮級別,數據越大壓縮比率越大,耗時也就越長,推薦使用-6~7,-9實在是太慢了,且收益不大,有這個壓縮的時間,多出來的文件也下載好了。

使用MAT分析jvm heap

MAT是分析Java堆內存的利器,使用它打開咱們的堆文件(將文件後綴改成 .hprof), 它會提示咱們要分析的種類,對於此次分析,果斷選擇memory leak suspect。

從上面的餅圖中能夠看出,絕大多數堆內存都被同一個內存佔用了,再查看堆內存詳情,向上層追溯,很快就發現了罪魁禍首。

分析代碼

找到內存泄漏的對象了,在項目裏全局搜索對象名,它是一個Bean對象,而後定位到它的一個類型爲Map的屬性。

這個Map根據類型用ArrayList存儲了每次探測接口響應的結果,每次探測完都塞到ArrayList裏去分析,因爲Bean對象不會被回收,這個屬性又沒有清除邏輯,因此在服務十來天沒有上線重啓的狀況下,這個Map愈來愈大,直至將內存佔滿。

內存滿了以後,沒法再給HTTP響應結果分配內存了,因此一直卡在readLine那。而咱們那個大量I/O的接口報警次數特別多,估計跟響應太大須要更多內存有關。

給代碼owner提了PR,問題圓滿解決。

4、小結

其實仍是要檢討一下本身的,一開始報警郵件裏還有這樣的線程棧:

看到這種報錯線程棧卻沒有細想,要知道TCP是能保證消息完整性的,何況消息沒有接收完也不會把值賦給變量,這種很明顯的是內部錯誤,若是留意後細查是能提早查出問題所在的,查問題真是差了哪一環都不行啊。

相關文章
相關標籤/搜索