原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此宣告，
簡介
在之前的OOM問題復盤之后，本周，又一Java服務出現了記憶體問題，這次問題不嚴重，只會觸發堆記憶體占用高報警，沒有觸發OOM，但好在之前的復盤中總結了dump腳本，會在堆占用高時自動執行jstack與jmap，使得我們成功保留了問題現場，
查看堆占用分布
發現有heapdump檔案后，我立馬拷貝到本機，并使用MAT分析，如下：
很顯然，好像是什么介面分配了非常大的String物件，一個String物件約200MB，那它是哪分配的呢？
查找大物件分配執行緒
這個分配行為肯定是某個執行緒做的，而執行緒是最常見的GC Root，因此只要查找物件的GC Root即可，如下：
找到了大物件對應的分配執行緒是http-nio-8088-exec-6，如下：
查看執行緒堆疊
如何查看這個執行緒在干什么呢？在MAT中摸索了一會，沒找到相關內容，回想起我們的dump腳本中記錄了jstack，打開看看，如下：
可以發現，這個執行緒正在做json序列化，但我仔細找了好一會，也沒有找到相關介面的Controller，這是因為執行緒已經執行完了Controller里面的邏輯，之后回傳介面回應資料時分配的大物件，
可是，執行緒堆疊中沒有業務代碼，就沒法定位是哪個介面有問題了，，，
檢查accesslog日志
考慮到分配大物件的介面肯定會很慢，于是我轉向查看tomcat的accesslog日志，如下：
終于，找到了問題介面，這個介面是用來查詢商品資料的，當輸入3時會查詢出所有3開頭的商品，而這有20w+資料，解決問題很簡單，加個limit完事，
排查程序復盤
然而，我一直有個習慣，就是解決一個問題后，我會反思一下問題解決程序中有多少運氣成分，
如果你經常閱讀排查問題類的技術文章，就會發現不少文章，中間突然有一步定位到了問題根因，可能是突然發現了一個線索，或是硬看代碼看出來的，或是猜測某處有問題，我覺得這種排查程序都有不少運氣成分，我希望問題是通過多年理論基礎的積累和對診斷工具的熟練使用，而有章法的一步步查出來的，
而上面通過accesslog能夠定位到問題，有一定的運氣成分，因為本次記憶體問題不極端，如果此介面請求量大，那就會瞬間觸發多次FGC，進而會影響其它介面也變慢，進而無法分辨出哪個是導致問題的介面！
我想，從理論上來說，Java堆檔案里面，應該有執行緒堆疊以及執行緒堆疊上的引數，因為執行緒是物件，引數也是物件，它們理應都在堆里，于是我找了個空閑時間，又摸索起MAT這個工具了，
MAT查看執行緒堆疊
摸索了一會，我就發現有這樣一個按鈕，可以查看執行緒資訊，如下：
找到前面說的執行緒http-nio-8088-exec-6，展開后，就可以發現執行緒堆疊以及堆疊上的引數，如下：
這就找到了請求的Request引數物件，再將Request物件多次展開后，就可以找到介面url資訊，如下：
嗯，這樣分析heapdump檔案真tm的高效啊??
MAT下載地址：https://www.eclipse.org/mat/downloads.php
VisualVM查看執行緒堆疊
考慮到不少同學習慣用VisualVM分析heapdump，這里也放一下VisualVM的使用方法，
首先，加載heapdump檔案，如下：
然后選擇相應物件，右鍵選擇Select in Threads，如下：
定位到執行緒堆疊后，找到要查看的Request物件，點擊進入，如下：
同樣，展開Request物件后，可找到url資訊，如下：
VisualVM下載地址：https://visualvm.github.io/download.html
總結
雖然我也用MAT很多次了，但每次問題都太簡單，以至于沒有深入使用過MAT，導致到現在才知道有如此便捷的分析路徑，
如果你對我們的自動dump腳本感興趣，可看看我之前寫的這兩篇文章，
一次線上OOM問題的個人復盤
jmap執行失敗了，怎么獲取heapdump？
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/550776.html
標籤：其他
下一篇：返回列表