headdump 內存分析。

 

1         編寫目的

Ø  最近系統中頻繁的內存中佔用一直偏高，指望找出內存中那些對象是調用過於頻繁，或者大對象沒有被即便回收的，可能會致使內存泄漏的。

Ø  在系統在內存在一直快速增長，分析照成這個問題的緣由

Ø  GC過於頻繁。

2         GC 日誌資料

顯而易見，這裏是cms回收機制，在咱們系統中在系統內存使用率68%時執行gc 但這個gc 過於頻繁，有理由懷疑，在內存累加過程當中，多是應爲程序致使的問題。全部有咱們去分析內存日誌。

3         使用memory analysis分析內存

Memory analysis 可使用內存分析器來分析生產與數億對象堆轉儲,快速計算保留對象的大小,看看誰是阻止垃圾收集器收集對象,自動運行報告提取泄漏疑點

3.1.1            開始獲取Jvmdump 文件

3.1.1.1        使用jmap 生成堆信息

3.1.1.2        使用插件生成

在eclipse 中 fileà Acquire Heap Dump

 

 

 

3.1.1.3 在啓動文件中配置虛擬機參數當系統在OutOfMemoryError 時自動生成堆的

 

在啓動文件中配置虛擬機參數： -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/eim/heap

3.1.2            導入生產的jvmheap 文件

Eclipse –> open file 指定jvmheap 文件

進入首頁：

3.1.3            Histogram

經過精確計算 retained  heap 中的各個對象佔用的大小，這個計算會稍微慢些。

 

 

上面是經過對象的建立次數進行的一次排序， 很明顯在圈裏面的對象都是一些被引用的數據，被引用到的數據，當前信息是堆中的信息，而後咱們看代碼中的建立對象和隊中的佔用內存大小。經過咱們的包進行一次過濾可得出下圖

 

在上圖中經過shallow heap 和 retained heap 比較可得 注:  shallow heap 是當前對象自己佔用的內存大小， retained heap 是包括對象的全部引用以後所佔用的內存大小。這上圖中分析，根據咱們系統中的代碼分析的對象： 其中 JEUser ， PersonalVCard，TenementMember,TenmenetVCard,JETenement,JeDepartement,UserMetas 這些對象一直保持緩存和數據庫同步，若是用戶信息，和企業信息 在不常常變更的狀況下， 這些對象的佔用內存的大小應該是比較穩定的。 不可照成內存快速增長的情況。而後咱們預測FDFSVirtualFile 和對象 SubscribeMapperManager 兩個對象是否存在某種程序中設計不合理。在跟蹤代碼可發如今這個對象中存在的對象屬性，以下圖

帶着這個對象中的屬性，去查看是不是當前屬性中的某個引用佔了大份數據。

 

3.1.4             Leak Suspects

 

 

分析內存可能致使內存泄漏的緣由。 在系統中存在的數據量最多的CacheWrapper 這個是正常的，但在這個數據的大小不太合理，這個須要經過詳細信息來分析， 在CacheWrapper 中可能致使的這麼大數據的緣由。從前文很容易得出一個結論， 如今在內存中不是應爲對象建立的太多而致使的內存一直增加，而是由於內存中的對象爲大對象不斷的建立大對象致使的，那咱們來看累積最大的對象，所映射的是哪些對象。 以下圖操做。

 

 

如上圖所示，如今已經有理由去懷疑這個對象的使用確實在程序中存在問題。在FDFSVirtualFile這個屬性attributes 經過代碼跟蹤，存儲的都是一些圖片的二進制。 在系統中的全部的圖片，的大圖中圖小圖信息。

 

參考資料：

http://eclipsesource.com/blogs/2013/01/21/10-tips-for-using-the-eclipse-memory-analyzer/