這是個比較典型的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",

            location=@Location(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不一致就別糾結了，有些是系統重啟過再截圖的）.

總結

以上是生活随笔為你收集整理的一个java内存泄漏的排查案例的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。