這是個比較典型的java記憶體使用問題,定位過程也比較直接,但對新人還是有點參考價值的,是以就紀錄了一下。
下面介紹一下在不了解系統代碼的情況下,如何一步步分析和定位到具體代碼的排查過程
(以便新人參考和自己回顧)
初步的現象
業務系統消費MQ中消息速度變慢,積壓了200多萬條消息,通過jstat觀察到業務系統fullgc比較頻繁,到最後幹脆OOM了:
![](https://img.laitimes.com/img/__Qf2AjLwojIjJCLyojI0JCLicmbw5SOxETOzAjM0EjZ0Q2MwQWYhBDNwkTOyYzYiBDNykjYy8CX0JXZ252bj91Ztl2Lc52YucWbp5GZzNmLn9Gbi1yZtl2Lc9CX6MHc0RHaiojIsJye.png)
進一步分析
既然知道了記憶體使用存在問題,那麼就要知道是哪些對象占用了大量記憶體.
很多人都會想到把堆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.*;
@BTracepublic classTracingHashTable {@OnMethod(
clazz="java.util.Hashtable",
method="put",
loc[email protected](Kind.RETURN))public static voidtraceExecute(@Self java.util.Hashtable object){
println("調用堆棧!!");
jstack();
}
}
然後運作:
bin/btrace -cp build 4947 TracingHashTable.java
看到有大量類似下圖的調用堆棧
可以看出是在接收到消息後查詢入庫的代碼造成的,業務方法調用ibatis再到mysql jdbc驅動執行statement時put了大量的屬性到HashTable中。
通過以上排查已基本定位了由那塊代碼引起的,接下來就是打開代碼工程進行白盒化改造了,對相應代碼進行優化(不在本文範圍内了。幾個圖中的pid不一緻就别糾結了,有些是系統重新開機過再截圖的).