這是一篇閱讀MAT helper的筆記。Heap dump是java進程在特定時間的一個內存快照。通常在觸發heap dump之前會進行一次full gc,這樣dump出來的內容就包含的是被gc後的對象。
dump文件包含的內容:
1,全部的對象:類,域,原生值和引用;
2,全部的類:classloader,類名,超類,靜態域;
3,GC root:被JVM定義的可觸達的對象;
4,線程棧和本地變量:線程的call stack,本地對象每幀的信息。
dump文件不包含內存的分配信息,因此無法查詢誰創建了哪個對象這樣的信息。
Shallow heap是一個對象占用的內存空間,一個對象需要32或者64bits。
Retained set of X是X在被jvm gc回收後被remove的一組object。
Retained heap of X是在retained set of X中的所有對象的shallow heap size的和。換句話說就是保持X活著需要的內存空間。
通俗的講,shallow heap是一個對象在內存中的實際空間,而retained heap是一個對象被gc回收後內存釋放出來的空間。
這張圖可以看懂什麼是leading set什麼是retained set。
Dominator tree:定義一個對象x dominate 對象y,當每一條從root開始到y的路徑都經過x。說白了就是只要有y對象的存活,那麼一定會有一個x對象。Dominator tree就是將對象引用圖轉換成的樹形結構。幫助發現在對象間保持alive的依賴,同時也能識別出retained內存的最大的chunk。 Immediate dominator x of y是離y最近的dominator。
Dominator tree有幾個屬性:
1,對象x的子樹包含的對象(x dominate的對象集),代表了x的retained set;
2,如果x是y的immediate dominator,那麼x的immediate dominator同樣dominate y,以此類推;
3,dominate tree中的邊不代表對象引用圖裡對應的邊,並非嚴格的直接的對象引用。
這張圖反應了一個對象引用圖轉換成dominator tree的示例。
Gc root:一個gc根就是一個對象,這個對象從堆外可以訪問讀取。以下一些方法可以使一個對象成為gc根。
1,System class:被Bootstrap或者system類加載器加載的類,比如rt.jar裡的java.util.*;
2,JNI local:native代碼裡的local變量,比如用戶定義的JNI代碼和JVM的內部代碼;
3,JNI global:native代碼裡的global變量;
4,Thread block:當前活躍的線程block中引用的對象;
5,Thread:已經啟動並且沒有stop的線程;
6,busy monitor:被調用了wait()或者notify()或者被synchronized同步的對象,如果是synchronized方法,那麼靜態方法指的類,非靜態方法指的是對象;
7,java local:local變量,比如方法的入參和方法內創建的變量;
8,native stack:native代碼裡的出入參數,比如file/net/IO方法以及反射的參數;
9,finalizable:在一個隊列裡等待它的finalizer 運行的對象;
10,unfinalized:一個有finalize方法的對象,還沒有被finalize,同時也沒有進入finalizer隊列等待finalize;
11,unreachable:不會被觸碰到的對象,在MAT裡被標記為root用來retain object,否則是不會在分析中出現的;
12,java stack frame:java棧幀包含了本地變量,當dump被解析時且在preferences裡設置過把棧幀當做對象,這時才會產生;
13,unknown:位置的root類型。
接下來是一些獲取dump的方法:
1,在oom時dump:JVM參數:-XX:+HeapDumpOnOutOfMemoryError
2,交互式環境下dump:
1)JVM參數:-XX:+HeapDumpOnCtrlBreak
2)用外部tools:jmap -dump:format=b,file=<filename.hprof> <pid>
3)用外部tools:jconsole
4)用外部工具:MAT
5)kill -3 <pid>
6)jstack -l <pid> > <dumpfile>
一些排查方法:
1,通過top consumers查找大對象,可以按照class、classloader和package進行group by;
2,通過immediate dominator找到責任對象,對於快速定位一組對象的持有者非常有用,這個操作直接解決了“誰讓這些對象alive”的問題,而不是“誰有這些對象的引用”的問題,更直接高效;
3,運行classloader分析,這個重要性體現在亮點:第一,應用使用不同的classloader加載類,第二,不同 classloader加載的類存儲在不同的永久代,這理論上也是可以被回收的。當有一個類被不同的classloader加載時,這時要根據各自 loader下的instance數量判斷哪個loader更重要,從而要把另一個回收掉;
4,分析線程,本身heap dump裡包含了thread信息,可以通過MAT來查看threads 的overview和detail,detail中有線程的堆內存信息,也有線程棧,同時還包含了操作系統本地棧。假設不做heap dump,我們檢查到系統有問題,如何通過線程的角度來排查呢?首先top -H -p <pid>以線程的模式查看java應用的運行情況,找到占用cpu或者內存大的線程,記錄線程id,然後printf %x <tid>轉為16進制,再jstack -l <pid> > thread.log把java進程的thread dump出來,從裡面找到tid,分析是哪個線程占用了系統資源。
5,分析java容器類,因為java的容器類是最常用來存儲對象的,所以理論上發生內存洩露的風險也最高。可以從幾個角度來 看:1)array填充率查詢(填充率fill ratio是數組中非空元素的比例),打印非原生類型數組的填充率頻率分布,從而排查系統中array的利用率;2)數組按照size分組查詢,打印一個 按size分組的直方圖;3)collection的填充率查詢,ArrayList/HashMap/Hashtable/Properties /Vector/WeakHashMap/ConcurrentHashMap$Segment;4)collection按照size分組直方圖;5) 查看一個list裡的所有對象;6)查看hashmap裡的所有對象;7)查看hashset裡的對象;8)檢查map的碰撞率;9)檢查所有只有一個常 量的array。
6,分析Finalizer,1)查詢finalizer正在處理的對象;2)查詢finalizer准備處理的對象;3)直接查看finalizer線程;4)查看finalizer線程的thread local對象。