JAVA記憶體流失分析(四)

怎麼解決Java記憶體流失<二>文章出處:http://hi.baidu.com/robin300/blog/item/472aeccd6295c7510fb34588.html

記憶體流失探測工具 　　有很多專門的記憶體流失探測工具。其中The JRockit Memory Leak Detector可以供來觀察記憶體流失也可以針對性地找到泄漏的原因。這個強大的工具被緊密地整合在JRockit JVM中，可以提供最低可能的記憶體事務也可以輕鬆的訪問虛擬機器的堆。 　　專門工具的優勢 　　一旦你知道程式中存在記憶體流失，你需要更專業的工具來查明為什麼這裡會有泄漏。而JVM是不可能告訴你的。現在有很多工具可以利用了。這些工具本質上主要通過兩種方法來得到JVM的儲存系統資訊的：JVMTI和位元組碼使用儀器。Java虛擬機器工具介面（JVMTI）和他的原有形式JVMPI（壓型介面）都是標準介面，作為外部工具同JVM進行通訊，搜集JVM的資訊。位元組碼使用儀器則是引用通過探針獲得工具所需的位元組資訊的預先處理技術。 　　通過這些技術來偵測記憶體流失存在兩個缺點，而這使得他們在產品級環境中的運用不夠理想。首先，根據兩者對記憶體的使用量和記憶體事務效能的降級是不可以忽略的。從JVM 獲得的堆的使用量資訊需要在工具中匯出，收集和處理。這意味著要分配記憶體。按照JVM的效能匯出資訊是需要開銷的，記憶體回收行程在搜集資訊的時候是啟動並執行非常緩慢的。另一個缺點就是，這些工具所需要的資訊是關係到JVM的。讓工具在JVM開始啟動並執行時候和它關聯，而在分析的時候，分離工具而保持JVM運行，這顯然是不可能的。 　　既然JRockit Memory Leak Detector是被整合到JVM中的，那麼以上兩種缺點就不再適用。首先，大部分的處理和分析都是在JVM中完成的，所以就不再需要傳送或重建任何資料。處理也可以在記憶體回收行程的背上，他的意思是提高速度。再有，記憶體流失偵測器可以同一個啟動並執行JVM關聯和分離，只要JVM在開始的時候伴隨著 -Xmanagement選項（這個允許監聽和管理JVM通過遠程JMX介面）。當工具分離以後，工具不會遺留任何東西在JVM中；JVM就可以全速運行代碼就好像工具關聯之前一樣。 　　趨勢分析 　　讓我們更深一步來觀察這個工具，瞭解他如何捕捉到記憶體流失。在你瞭解到代碼中存在記憶體流失，第一步就是嘗試計算出什麼資料在泄漏--哪個對象類導致泄露。The JRockit Memory Leak Detector通過在記憶體回收的時候，計算每個類所包含的現有的對象來達到目的。如果某一個類的對象成員數目隨著時間增長（增長率），那麼這裡很可能存在泄漏。 Figure 2. The trend analysis view of the Memory Leak Detector 　　因為一個泄漏很可能只是像水滴一樣小，所以趨勢分析必須運行足夠長的一段時間。在每個短暫的時間段裡，局部類的增加會使得泄漏發生延遲。但是，記憶體事務是非常小的（最大的記憶體事務是由在每個記憶體回收時從JRockit向記憶體流失探測器發送的一個資料包組成的）。記憶體事務不應該成為任何系統的問題--甚至一個在產品階段全速啟動並執行程式。 　　一開始，數字會有很大的跳轉，隨時間的推進，這些數字會變得穩定，而後顯示哪些類會不斷的增大。 　　尋找根本原因 　　知道那些對象的類會導致泄露，有時候足夠制止泄露問題。這個類也許只是被用在非常有限的部分，通過快速的視察就可以找到問題所在。不幸的是，這些資訊是不夠的。比方說，經常導致記憶體流失的對象類java.lang.String，然而String類被應用於整個程式，這就變得有些無助。 　　我們想知道的是其他的對象是否會導致記憶體流失，好比上面提到的String類，為什麼這些導致泄漏的對象還是存在周圍？那些引用是指向這些對象的？這裡一列的對象存有對String類的引用，就會變得太大而沒有實際意義。為了限制資料的數量，我們可以通過類把他們編成一個組，這樣我們就可以看到，那些其他類的對象會依然泄漏對象（String類）。比如，將一個String類放入Hashtable，那裡我們可以看到關聯到String類的 Hashtable入口。從Hashtable入口向後運行，我們終於找到那些關聯到String類的Hashtable對象（參看圖三如下）。 Figure 3. Sample view of the type graph as seen in the tool