這是個比較典型的java記憶體使用問題，定位過程也比較直接，但對新人還是有點參考價值的，所以就紀錄了一下。

下面介紹一下在不瞭解系統程式碼的情況下，如何一步步分析和定位到具體程式碼的排查過程
（以便新人蔘考和自己回顧）

初步的現象

業務系統消費MQ中訊息速度變慢，積壓了200多萬條訊息，通過jstat觀察到業務系統fullgc比較頻繁,到最後乾脆OOM了：



進一步分析

既然知道了記憶體使用存在問題，那麼就要知道是哪些物件佔用了大量記憶體.

很多人都會想到把堆dump下來再用MAT等工具進行分析，但dump堆要花較長的時間，並且檔案巨大，再從伺服器上拖回本地匯入工具，這個過程太折騰不到萬不得已最好別這麼幹。

可以用更輕量級的線上分析，用jmap檢視存活的物件情況（jmap -histo:live [pid]），可以看出HashTable中的元素有5000多萬，佔用記憶體大約1.5G的樣子：

定位到程式碼

現在已經知道了是HashTable的問題，那麼就要定位出什麼程式碼引起的

接下來自然要看看是什麼程式碼往HashTable裡瘋狂的put資料，於是用神器btrace跟蹤Hashtable.put呼叫的堆疊。

首先寫btrace指令碼TracingHashTable.java：

import com.sun.btrace.annotations.*;
import static com.sun.btrace.BTraceUtils.*;

@BTrace
public class TracingHashTable {
        /*指明要檢視的方法，類*/
        @OnMethod(
            clazz="java.util.Hashtable",
            method="put",
            
 
[email protected](Kind.RETURN))
        public static void traceExecute(@Self java.util.Hashtable object){
                println("呼叫堆疊！！");
                jstack();
        }
}

然後執行：
bin/btrace -cp build 4947 TracingHashTable.java

看到有大量類似下圖的呼叫堆疊



可以看出是在接收到訊息後查詢入庫的程式碼造成的，業務方法呼叫ibatis再到mysql jdbc驅動執行statement時put了大量的屬性到HashTable中。

通過以上排查已基本定位了由那塊程式碼引起的，接下來就是開啟程式碼工程進行白盒化改造了，對相應程式碼進行優化（不在本文範圍內了。幾個圖中的pid不一致就別糾結了，有些是系統重啟過再截圖的）.

更多精彩內容請訪問首發部落格http://jenwang.me

進一步交流：

- Email：[email protected]

- 對於本部落格某些話題感興趣，希望進一步交流的，請加 qq 群：2825967

- 更多技術交流分享在圈子「架構雜談」，跟老司機們聊聊網際網路前沿技術、架構、工具、解決方案等