文章更多想說的，導致內存泄漏主要的原因是，先前申請了內存空間而忘記了釋放。如果程序中存在對無用對象的引用，那么這些對象就會駐留內存，消耗內存，因為無法讓垃圾回收器驗證這些對象是否不再需要。正如我們前面看到的，如果存在對象的引用，這個對象就被定義為“活動的”，同時不會被釋放。要確定對象所占內存將被回收，程序員就要務必確認該對象不再會被使用。典型的做法就是把對象數據成員設為null或者從集合中移除該對象。注意，當局部變量不需要時，不需明顯的設為null，因為一個方法執行完畢時，這些引用會自動被清理。

　　從更高一個層次看，這就是所有存在內存管的語言對內存泄漏所考慮的事情，剩余的對象引用將不再會被使用。

典型的泄漏
　　既然我們知道了在java中確實會存在內存泄漏，那么就讓我們看一些典型的泄漏，并找出他們發生的原因。

全局集合
　　在大型應用程序中存在各種各樣的全局數據倉庫是很普遍的，比如一個JNDI-tree或者一個session table。在這些情況下，注意力就被放在了管理數據倉庫的大小上。當然是有一些適當的機制可以將倉庫中的無用數據移除。

　　可以有很多不同的解決形式，其中最常用的是一種周期運行的清除作業。這個作業會驗證倉庫中的數據然后清除一切不需要的數據。

　　另一個辦法是計算引用的數量。集合負責跟蹤集合中每個元素的引用者數量。這要求引用者通知集合什么時候已經對元素處理完畢。當引用者的數目為零時，就可以移除集合中的相關元素。

高速緩存
　　高速緩存是一種用來快速查找已經執行過的操作結果的數據結構。因此，如果一個操作執行很慢的話，你可以先把普通輸入的數據放入高速緩存，然后過些時間再調用高速緩存中的數據。
高速緩存多少還有一點動態實現的意思，當數據操作完畢，又被送入高速緩存。一個典型的算法如下所示：
　　１． 檢查結果是否在高速緩存中，存在則返回結果；
　　２． 如果結果不在，那么計算結果；
　　３． 將結果放入高速緩存，以備將來的操作調用。

　　這個算法的問題（或者說潛在的內存泄漏）在最后一步。如果操作是分別多次輸入，那么存入高速緩存的內容將會非常大。很明顯這個方法不可取。

　　為了避免這種潛在的致命錯誤設計，程序就必須確定高速緩存在他所使用的內存中有一個上界。因此，更好的算法是：
　　１． 檢查結果是否在高速緩存中，存在則返回結果；
　　２． 如果結果不在，那么計算結果；
　　３． 如果高速緩存所占空間過大，移除緩存中舊的結果；
　　４． 將結果放入高速緩存，以備將來的操作調用。

　　通過不斷的從緩存中移除舊的結果，我們可以假設，將來，最新輸入的數據可能被重用的幾率要遠遠大于舊的結果。這通常是一個不錯的設想。

　　這個新的算法會確保高速緩存的容量在預先確定的范圍內。精確的范圍是很難計算的，因為緩存中的對象存在引用時將繼續有效。正確的劃分高速緩存的大小是一個復雜的任務，你必須權衡可使用內存大小和數據快速存取之間的矛盾。

　　另一個解決這個問題的途徑是使用java.lang.ref.SoftReference類來將對象放入高速緩存。這個方法可以保證當虛擬機用完內存或者需要更多堆的時候，可以釋放這些對象的引用。

類裝載器
　　Java類裝載器創建就存在很多導致內存泄漏的漏洞。由于類裝載器的復雜結構，使得很難得到內存泄漏的透視圖。這些困難不僅僅是由于類裝載器只與“普通的”對象引用有關，同時也和對象內部的引用有關，比如數據變量，方法和各種類。這意味著只要存在對數據變量，方法，各種類和對象的類裝載器，那么類裝載器將駐留在JVM中。既然類裝載器可以同很多的類關聯，同時也可以和靜態數據變量關聯，那么相當多的內存就可能發生泄漏。


定位內存泄漏
　　常常地，程序內存泄漏的最初跡象發生在出錯之后，在你的程序中得到一個OutOfMemoryError。這種典型的情況發生在產品環境中，而在那里，你希望內存泄漏盡可能的少，調試的可能性也達到最小。

Figure 1. The JRockit Management Console

　　管理控制臺甚至可以配置成在堆使用量出現問題（或者其他的事件發生）時向你發送郵件。這個顯然使得監控內存泄漏更加容易。

內存泄漏探測工具
　　有很多專門的內存泄漏探測工具。其中The JRockit Memory Leak Detector可以供來觀察內存泄漏也可以針對性地找到泄漏的原因。這個強大的工具被緊密地集成在JRockit JVM中，可以提供最低可能的內存事務也可以輕松的訪問虛擬機的堆。


專門工具的優勢
　　一旦你知道程序中存在內存泄漏，你需要更專業的工具來查明為什么這里會有泄漏。而JVM是不可能告訴你的。現在有很多工具可以利用了。這些工具本質上主要通過兩種方法來得到JVM的存儲系統信息的：JVMTI和字節碼儀器。

Java虛擬機工具接口（JVMTI）和他的原有形式JVMPI（壓型接口，profiling Interface）都是標準接口，作為外部工具同JVM進行通信，搜集JVM的信息。字節碼儀器則是引用通過探針獲得工具所需的字節信息的預處理技術。

　　通過這些技術來偵測內存泄漏存在兩個缺點，而這使得他們在產品級環境中的運用不夠理想。首先，根據兩者對內存的使用量和內存事務性能的降級是不可以忽略的。從JVM獲得的堆的使用量信息需要在工具中導出，收集和處理。這意味著要分配內存。按照JVM的性能導出信息是需要開銷的，垃圾回收器在搜集信息的時候是運行的非常緩慢的。另一個缺點就是，這些工具所需要的信息是關系到JVM的。讓工具在JVM開始運行的時候和它關聯，而在分析的時候，分離工具而保持 JVM運行，這顯然是不可能的。

　　既然JRockit Memory Leak Detector是被集成到JVM中的，那么以上兩種缺點就不再存在。首先，大部分的處理和分析都是在JVM中完成的，所以就不再需要傳送或重建任何數據。處理也可以建立在垃圾回收器的基礎上，即提高速度。再有，內存泄漏偵測器可以同一個運行的JVM關聯和分離，只要JVM在開始的時候伴隨著 –Xmanagement選項（通過遠程JMX接口允許監聽和管理JVM）。當工具分離以后，工具不會遺留任何東西在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

向后工作
　　自從開始我們就一直著眼于對象類，而不是單獨的對象，我們不知道那個Hashtable存在泄漏。如果我們可以找出所有的Hashtable在系統中有多大，我們可以假設最大的那個Hashtable存在泄漏（因為它可以聚集足夠的泄漏而變得很大）。因此，所有Hashtable，同時有和所有他們所涉及的數據，可以幫助我們查明導致泄露的精確的Hashtable。

Figure 4. Screenshot of the list of Hashtable objects and the size of the data they are holding live

　　計算一個對象所涉及的數據的開銷是非常大的（這要求引用圖表伴隨著那個對象作為根運行）而且如果對每一個對象都這樣處理，就需要很多時間。知道一些關于Hashtable內部的實現機制可以帶來捷徑。在內部，一個 Hashtable有一個Hashtable的數組入口。數組的增長伴隨著Hashtable中對象的增長。因此，要找到最大的Hashtable，我們可以把搜索限制在尋找包含Hashtable引用入口的最大的數組。這樣就更快捷了。

Figure 5. Screenshot of the listing of the largest Hashtable entry arrays, as well as their sizes.

向下深入
　　當我們發現了存在泄漏的Hashtable的實例，就可以順藤摸瓜找到其他的引用這些Hashtable的實例，然后用上面的方法來找到是那個Hashtable存在問題。

Figure 6. This is what an instance graph can look like in the tool.

　　舉個例子，一個Hashtable可以有一個來自MyServer的對象的引用，而MyServer包含一個activeSessions數據成員。這些信息就足夠深入代碼找出問題所在。

Figure 7. Inspecting an object and its references to other objects

找出分配點
　　當發現了內存泄漏問題，找到那些泄漏的對象在何處是非常有用的。也許沒有足夠的信息知道他們同其他相關對象之間的聯系，但是關于他們在那里被創建的信息還是很有幫助的。當然，你不會愿意創建一個工具來打印出所有分配的堆棧路徑。你也不會愿意在模擬環境中運行程序只是為了捕捉到一個內存泄漏。

　　有了JRockit Memory Leak Detector，程序代碼可以動態的在內存分配出創建堆棧路徑。這些堆棧路徑可以在工具中累積，分析。如果你不啟用這個工具，這個特征就不會有任何消耗，這就意味著時刻準備著開始。當需要分配路徑時，JRockit的編譯器可以讓代碼不工作，而監視內存分配，但只對需要的特定類有效。更好的是，當做完數據分析后，生成的機械代碼會完全被移除，不會引起任何執行上的效率衰退。

Figure 8. The allocation stack traces for String during execution of a sample program

總結
　　內存泄漏查找起來非常困難，文章中的一些避免泄漏的好的實踐，包括了要時刻記住把什么放進了數據結構中，更接近的監視內存中意外的增長。

　　我們同時也看到了JRockit Memory Leak Detector是如何捕捉產品級系統中的內存泄漏的。該工具通過三步的方法發現泄漏。一，通過趨勢分析發現那些對象類存在泄漏；二，找出同泄漏對象相關的其他類；三，向下發掘，觀察獨立的對象之間是如何相互聯系的。同時，該工具也可以動態的，找出所有內存分配的堆棧路徑。利用這三個特性，將該工具緊緊地集成在JVM中，那么就可以安全的，有效的捕捉和修復內存泄漏了。

資源
　　JRockit Tools Download
　　BEA JRockit 5.0 Documentation
　　New Features and Tools in JRockit 5.0
　　BEA JRockit DevCenter

Staffan Larsen是JRockit項目的工程師之一，這個項目是在1998年底他與別人聯合創建的。