作者：jenwang
原文地址：http://jenwang.me/14853486232080.html
緣由
這是個比較典型的java內(nèi)存使用問題吝岭，定位過程也比較直接卫漫，但對新人還是有點參考價值的，所以就紀(jì)錄了一下。
下面介紹一下在不了解系統(tǒng)代碼的情況下，如何一步步分析和定位到具體代碼的排查過程
（以便新人參考和自己回顧）
初步的現(xiàn)象
業(yè)務(wù)系統(tǒng)消費MQ中消息速度變慢，積壓了200多萬條消息丁鹉，通過jstat觀察到業(yè)務(wù)系統(tǒng)fullgc比較頻繁,到最后干脆OOM了：
進一步分析
既然知道了內(nèi)存使用存在問題，那么就要知道是哪些對象占用了大量內(nèi)存.
很多人都會想到把堆dump下來再用MAT等工具進行分析悴能，但dump堆要花較長的時間揣钦，并且文件巨大，再從服務(wù)器上拖回本地導(dǎo)入工具漠酿，這個過程太折騰不到萬不得已最好別這么干冯凹。
可以用更輕量級的在線分析，用jmap查看存活的對象情況（jmap -histo:live [pid]）炒嘲，可以看出HashTable中的元素有5000多萬宇姚，占用內(nèi)存大約1.5G的樣子：
定位到代碼
現(xiàn)在已經(jīng)知道了是HashTable的問題，那么就要定位出什么代碼引起的
接下來自然要看看是什么代碼往HashTable里瘋狂的put數(shù)據(jù)夫凸，于是用神器btrace跟蹤Hashtable.put調(diào)用的堆棧浑劳。
首先寫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("調(diào)用堆棧Ｘ舶琛魔熏！");
jstack();
}}
然后運行：
bin/btrace -cp build 4947 TracingHashTable.java
看到有大量類似下圖的調(diào)用堆棧
可以看出是在接收到消息后查詢?nèi)霂斓拇a造成的衷咽，業(yè)務(wù)方法調(diào)用ibatis再到mysql jdbc驅(qū)動執(zhí)行statement時put了大量的屬性到HashTable中。
通過以上排查已基本定位了由那塊代碼引起的蒜绽，接下來就是打開代碼工程進行白盒化改造了镶骗，對相應(yīng)代碼進行優(yōu)化（不在本文范圍內(nèi)了。幾個圖中的pid不一致就別糾結(jié)了躲雅，有些是系統(tǒng)重啟過再截圖的）.
https://blog.csdn.net/xingbear/article/details/78091851 安裝
https://www.cnblogs.com/rwxwsblog/p/6248210.html 原理實例
