原創：扣釘日記（微信公眾號ID：codelogs），歡迎分享，非公眾號轉載保留此聲明。 簡介 在之前的OOM問題復盤之後，本周，又一Java服務出現了記憶體問題，這次問題不嚴重，只會觸發堆記憶體占用高報警，沒有觸發OOM，但好在之前的復盤中總結了dump腳本，會在堆占用高時自動執行jstack與jmap ...
原創：扣釘日記（微信公眾號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的高效啊
