使用JProfiler進行內存分析

在最近的工作中，通過JProfiler解決了一個內存泄漏的問題，現將檢測的步驟和一些分析記錄下來，已備今后遇到相似問題時可以作為參考。

 

運行環境：

Tomcat6，jdk6，JProfiler8

 

內存泄漏的現象：

1. 在服務器中執行某些批量操作的時候，發現內存只升不降；就算gc后，內存也不能被完全釋放；

2. 除非重啟tomcat服務器，內存永遠不會被釋放，反復執行這些操作，會導致無可用內存，tomcat死掉；

 

使用JProfiler檢查內存泄漏的步驟：

1. 初始化檢驗環境：

切換到“Live Memory-->All Objects”標簽，可以看到當前tomcat中的對象情況,注意jprofiler其他版本可能位置不一樣.

在執行操作前，需要先F4,運行“Run GC”，使jvm進行內存回收清理無效的對象.為了便於比較內存的增長情況，可以點擊右鍵--->"Mark Current",

來將當前內存使用情況作為參照；點擊后會顯示“Difference”列，該列會列出對象數量的變化和變化比率

2.打開內存記錄： 

點擊“Start Recordings”按鈕，開始記錄。執行這步的主要目的是為下面“Heap Walker”設置一個監控區間；如果不記錄的話“Heap Walker”將分析jvm虛擬機的所有內存，即耗時又不能准確的發現內存泄漏的原因。

3. 執行操作，執行gc；

 使用壓力工具訪問被測應用，執行完之后再次F4進行GC----這樣是為了消除可以回收的對象。執行內存回收后，仍然存在於內存中的對象有可能是泄漏的對象。如下圖instance count中紅色的部門為不能回收的對象，difference列列出了增加的對象數量和增。以String為例，在該操作中增加了31751個對象增幅達到了14%，隨后會在HeapWalker中觀察這些對象，分析哪些對象是泄漏的。一般引起泄漏的對象包括：String、char[]、HashMap、Concurrenthashmap等，這類對象需要重點關注下；

4. 關閉內存記錄：

點擊“Stop Recordings”關閉內存記錄，告訴jProfiler把這段記錄作為分析對象；

5. 找到增加迅速的對象類型，打開HeapWalker：

在視圖中找到增長快速的對象類型，本例Concurrenthashmap的增長速度很快。在memory視圖中找到Concurrenthashmap---點右鍵----選擇“Show Selectiion In Heap Walker”，切換到HeapWarker 視圖；切換前會彈出選項頁面，注意一定要選擇“Select recorded  objects”，這樣Heap Walker會在剛剛的那段記錄中進行分析；否則，會分析tomcat的所有內存對象，這樣既耗時又不准確；

6. 在HeapWalker中，找到泄漏的對象；

HeapWarker 會分析內存中的所有對象，包括對象的引用、創建、大小和數量；

 

HeapWarker視圖下方可以進行頁面切換：

通過切換到References頁簽，可以看到這個類的具體對象實例。

 為了在這些內存對象中，找到泄漏的對象（應該被回收），可以在該對象上點擊右鍵，選擇“Use Selected Instances”縮小對象范圍；

單擊OK按鈕

7. 通過引用分析該對象：

在References引用頁簽中，可以看到該對象的的引用關系，可以切換incoming/outcoming，顯示引用的類型：

incoming  表示顯示這個對象被誰引用；

outcoming 表示顯示這個對象引用的其他對象；

 

選擇“Show In Graph”將引用關系使用圖形方式展現；

選中該對象，點擊“Show Paths To GC Root”，會找到引用的根節點；

在上圖中，我們可以發現，這個HashMap Segment對象最終的引用是在ConcurrentHashMap和ReentranLock對象中；

8. 通過創建分析該對象：

如果第7步還不能定位內存泄露的地方，我們可以嘗試使用Allocations頁簽，該頁簽顯示對象是如何創建出來的；

我們可以從創建方法開始檢查，檢查所有用到該對象的地方，直到找到泄漏位置；