原文出處：
http://dev2dev.bea.com/pub/a/2005/06/memory_leaks.html
垃圾收集器的作用
??????? 雖然垃圾收集器處理了大多數(shù)內(nèi)存管理問題，從而使編程人員的生活變得更輕松了，但是編程人員還是可能犯錯而導致出現(xiàn)內(nèi)存問題。簡單地說，GC循環(huán)地跟蹤所有來自“根”對象（堆棧對象、靜態(tài)對象、JNI句柄指向的對象，諸如此類）的引用，并將所有它所能到達的對象標記為活動的。程序只可以操縱這些對象；其他的對象都被刪除了。因為GC使程序不可能到達已被刪除的對象，這么做就是安全的。
雖然內(nèi)存管理可以說是自動化的，但是這并不能使編程人員免受思考內(nèi)存管理問題之苦。例如，分配（以及釋放）內(nèi)存總會有開銷，雖然這種開銷對編程人員來說是不可見的。創(chuàng)建了太多對象的程序?qū)韧瓿赏瑯拥墓δ芏鴦?chuàng)建的對象卻比較少的程序更慢一些（在其他條件相同的情況下）。
而且，與本文更為密切相關(guān)的是，如果忘記“釋放”先前分配的內(nèi)存，就可能造成內(nèi)存泄漏。如果程序保留對永遠不再使用的對象的引用，這些對象將會占用并耗盡內(nèi)存，這是因為自動化的垃圾收集器無法證明這些對象將不再使用。正如我們先前所說的，如果存在一個對對象的引用，對象就被定義為活動的，因此不能刪除。為了確保能回收對象占用的內(nèi)存，編程人員必須確保該對象不能到達。這通常是通過將對象字段設置為null或者從集合(collection)中移除對象而完成的。但是，注意，當局部變量不再使用時，沒有必要將其顯式地設置為null。對這些變量的引用將隨著方法的退出而自動清除。
概括地說，這就是內(nèi)存托管語言中的內(nèi)存泄漏產(chǎn)生的主要原因：保留下來卻永遠不再使用的對象引用。
典型泄漏
既然我們知道了在Java中確實有可能發(fā)生內(nèi)存泄漏，就讓我們來看一些典型的內(nèi)存泄漏及其原因。
全局集合
在大的應用程序中有某種全局的數(shù)據(jù)儲存庫是很常見的，例如一個JNDI樹或一個會話表。在這些情況下，必須注意管理儲存庫的大小。必須有某種機制從儲存庫中移除不再需要的數(shù)據(jù)。
這可能有多種方法，但是最常見的一種是周期性運行的某種清除任務。該任務將驗證儲存庫中的數(shù)據(jù)，并移除任何不再需要的數(shù)據(jù)。
另一種管理儲存庫的方法是使用反向鏈接(referrer)計數(shù)。然后集合負責統(tǒng)計集合中每個入口的反向鏈接的數(shù)目。這要求反向鏈接告訴集合何時會退出入口。當反向鏈接數(shù)目為零時，該元素就可以從集合中移除了。
緩存
緩存是一種數(shù)據(jù)結(jié)構(gòu)，用于快速查找已經(jīng)執(zhí)行的操作的結(jié)果。因此，如果一個操作執(zhí)行起來很慢，對于常用的輸入數(shù)據(jù)，就可以將操作的結(jié)果緩存，并在下次調(diào)用該操作時使用緩存的數(shù)據(jù)。
緩存通常都是以動態(tài)方式實現(xiàn)的，其中新的結(jié)果是在執(zhí)行時添加到緩存中的。典型的算法是：
檢查結(jié)果是否在緩存中，如果在，就返回結(jié)果。
如果結(jié)果不在緩存中，就進行計算。
將計算出來的結(jié)果添加到緩存中，以便以后對該操作的調(diào)用可以使用。
該算法的問題（或者說是潛在的內(nèi)存泄漏）出在最后一步。如果調(diào)用該操作時有相當多的不同輸入，就將有相當多的結(jié)果存儲在緩存中。很明顯這不是正確的方法。
為了預防這種具有潛在破壞性的設計，程序必須確保對于緩存所使用的內(nèi)存容量有一個上限。因此，更好的算法是：
檢查結(jié)果是否在緩存中，如果在，就返回結(jié)果。
如果結(jié)果不在緩存中，就進行計算。
如果緩存所占的空間過大，就移除緩存最久的結(jié)果。
將計算出來的結(jié)果添加到緩存中，以便以后對該操作的調(diào)用可以使用。
通過始終移除緩存最久的結(jié)果，我們實際上進行了這樣的假設：在將來，比起緩存最久的數(shù)據(jù)，最近輸入的數(shù)據(jù)更有可能用到。這通常是一個不錯的假設。
新算法將確保緩存的容量處于預定義的內(nèi)存范圍之內(nèi)。確切的范圍可能很難計算，因為緩存中的對象在不斷變化，而且它們的引用包羅萬象。為緩存設置正確的大小是一項非常復雜的任務，需要將所使用的內(nèi)存容量與檢索數(shù)據(jù)的速度加以平衡。
解決這個問題的另一種方法是使用java.lang.ref.SoftReference類跟蹤緩存中的對象。這種方法保證這些引用能夠被移除，如果虛擬機的內(nèi)存用盡而需要更多堆的話。
ClassLoader
Java ClassLoader結(jié)構(gòu)的使用為內(nèi)存泄漏提供了許多可乘之機。正是該結(jié)構(gòu)本身的復雜性使ClassLoader在內(nèi)存泄漏方面存在如此多的問題。ClassLoader的特別之處在于它不僅涉及“常規(guī)”的對象引用，還涉及元對象引用，比如：字段、方法和類。這意味著只要有對字段、方法、類或ClassLoader的對象的引用，ClassLoader就會駐留在JVM中。因為ClassLoader本身可以關(guān)聯(lián)許多類及其靜態(tài)字段，所以就有許多內(nèi)存被泄漏了。
確定泄漏的位置
通常發(fā)生內(nèi)存泄漏的第一個跡象是：在應用程序中出現(xiàn)了OutOfMemoryError。這通常發(fā)生在您最不愿意它發(fā)生的生產(chǎn)環(huán)境中，此時幾乎不能進行調(diào)試。有可能是因為測試環(huán)境運行應用程序的方式與生產(chǎn)系統(tǒng)不完全相同，因而導致泄漏只出現(xiàn)在生產(chǎn)中。在這種情況下，需要使用一些開銷較低的工具來監(jiān)控和查找內(nèi)存泄漏。還需要能夠無需重啟系統(tǒng)或修改代碼就可以將這些工具連接到正在運行的系統(tǒng)上。可能最重要的是，當進行分析時，需要能夠斷開工具而保持系統(tǒng)不受干擾。
雖然OutOfMemoryError通常都是內(nèi)存泄漏的信號，但是也有可能應用程序確實正在使用這么多的內(nèi)存；對于后者，或者必須增加JVM可用的堆的數(shù)量，或者對應用程序進行某種更改，使它使用較少的內(nèi)存。但是，在許多情況下，OutOfMemoryError都是內(nèi)存泄漏的信號。一種查明方法是不間斷地監(jiān)控GC的活動，確定內(nèi)存使用量是否隨著時間增加。如果確實如此，就可能發(fā)生了內(nèi)存泄漏。
詳細輸出
有許多監(jiān)控垃圾收集器活動的方法。而其中使用最廣泛的可能是使用-Xverbose:gc選項啟動JVM，并觀察輸出。
[memory ] 10.109-10.235: GC 65536K->16788K (65536K), 126.000 ms
箭頭后面的值（本例中是16788K）是垃圾收集所使用的堆的容量。
控制臺
查看連續(xù)不斷的GC的詳細統(tǒng)計信息的輸出將是非常乏味的。幸好有這方面的工具。JRockit Management Console可以顯示堆使用量的圖示。借助于該圖，可以很容易地看出堆使用量是否隨時間增加。
圖1. JRockit Management Console
甚至可以配置該管理控制臺，以便如果發(fā)生堆使用量過大的情況（或基于其他的事件），控制臺能夠向您發(fā)送電子郵件。這明顯使內(nèi)存泄漏的查看變得更容易了。
內(nèi)存泄漏檢測工具
還有其他的專門進行內(nèi)存泄漏檢測的工具。JRockit Memory Leak Detector可以用來查看內(nèi)存泄漏，并可以更深入地查出泄漏的根源。這個強大的工具是緊密集成到JRockit JVM中的，其開銷非常小，對虛擬機的堆的訪問也很容易。
專業(yè)工具的優(yōu)點
一旦知道確實發(fā)生了內(nèi)存泄漏，就需要更專業(yè)的工具來查明為什么會發(fā)生泄漏。JVM自己是不會告訴您的。這些專業(yè)工具從JVM獲得內(nèi)存系統(tǒng)信息的方法基本上有兩種：JVMTI和字節(jié)碼技術(shù)(byte code instrumentation)。Java虛擬機工具接口(Java Virtual Machine Tools Interface，JVMTI)及其前身Java虛擬機監(jiān)視程序接口(Java Virtual Machine Profiling Interface，JVMPI)是外部工具與JVM通信并從JVM收集信息的標準化接口。字節(jié)碼技術(shù)是指使用探測器處理字節(jié)碼以獲得工具所需的信息的技術(shù)。
對于內(nèi)存泄漏檢測來說，這兩種技術(shù)有兩個缺點，這使它們不太適合用于生產(chǎn)環(huán)境。首先，它們在內(nèi)存占用和性能降低方面的開銷不可忽略。有關(guān)堆使用量的信息必須以某種方式從JVM導出，并收集到工具中進行處理。這意味著要為工具分配內(nèi)存。信息的導出也影響了JVM的性能。例如，當收集信息時，垃圾收集器將運行得比較慢。另外一個缺點是需要始終將工具連在JVM上。這是不可能的：將工具連在一個已經(jīng)啟動的JVM上，進行分析，斷開工具，并保持JVM運行。
因為JRockit Memory Leak Detector是集成到JVM中的，就沒有這兩個缺點了。首先，許多處理和分析工作是在JVM內(nèi)部進行的，所以沒有必要轉(zhuǎn)換或重新創(chuàng)建任何數(shù)據(jù)。處理還可以背負(piggyback)在垃圾收集器本身上而進行，這意味著提高了速度。其次，只要JVM是使用-Xmanagement選項（允許通過遠程JMX接口監(jiān)控和管理JVM）啟動的，Memory Leak Detector就可以與運行中的JVM進行連接或斷開。當該工具斷開時，沒有任何東西遺留在JVM中，JVM又將以全速運行代碼，正如工具連接之前一樣。
趨勢分析
讓我們深入地研究一下該工具以及它是如何用來跟蹤內(nèi)存泄漏的。在知道發(fā)生內(nèi)存泄漏之后，第一步是要弄清楚泄漏了什么數(shù)據(jù)--哪個類的對象引起了泄漏？JRockit Memory Leak Detector是通過在每次垃圾收集時計算每個類的現(xiàn)有對象的數(shù)目來實現(xiàn)這一步的。如果特定類的對象數(shù)目隨時間而增長（“增長率”），就可能發(fā)生了內(nèi)存泄漏。
圖2. Memory Leak Detector的趨勢分析視圖
因為泄漏可能像細流一樣非常小，所以趨勢分析必須運行很長一段時間。在短時間內(nèi)，可能會發(fā)生一些類的局部增長，而之后它們又會跌落。但是趨勢分析的開銷很小（最大開銷也不過是在每次垃圾收集時將數(shù)據(jù)包由JRockit發(fā)送到Memory Leak Detector）。開銷不應該成為任何系統(tǒng)的問題——即使是一個全速運行的生產(chǎn)中的系統(tǒng)。
起初數(shù)目會跳躍不停，但是一段時間之后它們就會穩(wěn)定下來，并顯示出哪些類的數(shù)目在增長。
找出根本原因
有時候知道是哪些類的對象在泄漏就足以說明問題了。這些類可能只用于代碼中的非常有限的部分，對代碼進行一次快速檢查就可以顯示出問題所在。遺憾地是，很有可能只有這類信息還并不夠。例如，常見到泄漏出在類java.lang.String的對象上，但是因為字符串在整個程序中都使用，所以這并沒有多大幫助。
我們想知道的是，另外還有哪些對象與泄漏對象關(guān)聯(lián)？在本例中是String。為什么泄漏的對象還存在？哪些對象保留了對這些對象的引用？但是能列出的所有保留對String的引用的對象將會非常多，以至于沒有什么實際用處。為了限制數(shù)據(jù)的數(shù)量，可以將數(shù)據(jù)按類分組，以便可以看出其他哪些對象的類與泄漏對象(String)關(guān)聯(lián)。例如，String在Hashtable中是很常見的，因此我們可能會看到與String關(guān)聯(lián)的Hashtable數(shù)據(jù)項對象。由Hashtable數(shù)據(jù)項倒推，我們最終可以找到與這些數(shù)據(jù)項有關(guān)的Hashtable對象以及String（如圖3所示）。
圖3. 在工具中看到的類型圖的示例視圖
倒推
因為我們?nèi)匀皇且灶惖膶ο蠖皇菃为毜膶ο髞砜创龑ο螅晕覀儾恢朗悄膫€Hashtable在泄漏。如果我們可以弄清楚系統(tǒng)中所有的Hashtable都有多大，我們就可以假定最大的Hashtable就是正在泄漏的那一個（因為隨著時間的流逝它會累積泄漏而增長得相當大）。因此，一份有關(guān)所有Hashtable對象以及它們引用了多少數(shù)據(jù)的列表，將會幫助我們指出造成泄漏的確切Hashtabl。
圖4. 界面：Hashtable對象以及它們所引用數(shù)據(jù)的數(shù)量的列表
對對象引用數(shù)據(jù)數(shù)目的計算開銷非常大（需要以該對象作為根遍歷引用圖），如果必須對許多對象都這么做，將會花很多時間。如果了解一點Hashtable的內(nèi)部實現(xiàn)原理就可以找到一條捷徑。Hashtable的內(nèi)部有一個Hashtable數(shù)據(jù)項的數(shù)組。該數(shù)組隨著Hashtable中對象數(shù)目的增長而增長。因此，為找出最大的Hashtable，我們只需找出引用Hashtable數(shù)據(jù)項的最大數(shù)組。這樣要快很多。
圖5. 界面：最大的Hashtable數(shù)據(jù)項數(shù)組及其大小的清單
更進一步
當找到發(fā)生泄漏的Hashtable實例時，我們可以看到其他哪些實例在引用該Hashtable，并倒推回去看看是哪個Hashtable在泄漏。
圖 6. 這就是工具中的實例圖
例如，該Hashtable可能是由MyServer類型的對象在名為activeSessions的字段中引用的。這種信息通常就足以查找源代碼以定位問題所在了。
圖7. 檢查對象以及它對其他對象的引用
找出分配位置
當跟蹤內(nèi)存泄漏問題時，查看對象分配到哪里是很有用的。只知道它們?nèi)绾闻c其他對象相關(guān)聯(lián)（即哪些對象引用了它們）是不夠的，關(guān)于它們在何處創(chuàng)建的信息也很有用。當然了，您并不想創(chuàng)建應用程序的輔助構(gòu)件，以打印每次分配的堆棧跟蹤(stack trace)。您也不想僅僅為了跟蹤內(nèi)存泄漏而在運行應用程序時將一個分析程序連接到生產(chǎn)環(huán)境中。
借助于JRockit Memory Leak Detector，應用程序中的代碼可以在分配時進行動態(tài)添加，以創(chuàng)建堆棧跟蹤。這些堆棧跟蹤可以在工具中進行累積和分析。只要不啟用就不會因該功能而產(chǎn)生成本，這意味著隨時可以進行分配跟蹤。當請求分配跟蹤時，JRockit 編譯器動態(tài)插入代碼以監(jiān)控分配，但是只針對所請求的特定類。更好的是，在進行數(shù)據(jù)分析時，添加的代碼全部被移除，代碼中沒有留下任何會引起應用程序性能降低的更改。
圖8. 示例程序執(zhí)行期間String的分配的堆棧跟蹤
結(jié)束語
內(nèi)存泄漏是難以發(fā)現(xiàn)的。本文重點介紹了幾種避免內(nèi)存泄漏的最佳實踐，包括要始終記住在數(shù)據(jù)結(jié)構(gòu)中所放置的內(nèi)容，以及密切監(jiān)控內(nèi)存使用量以發(fā)現(xiàn)突然的增長。
我們都已經(jīng)看到了JRockit Memory Leak Detector是如何用于生產(chǎn)中的系統(tǒng)以跟蹤內(nèi)存泄漏的。該工具使用一種三步式的方法來找出泄漏。首先，進行趨勢分析，找出是哪個類的對象在泄漏。接下來，看看有哪些其他的類與泄漏的類的對象相關(guān)聯(lián)。最后，進一步研究單個對象，看看它們是如何互相關(guān)聯(lián)的。也有可能對系統(tǒng)中所有對象分配進行動態(tài)的堆棧跟蹤。這些功能以及該工具緊密集成到JVM中的特性使您可以以一種安全而強大的方式跟蹤內(nèi)存泄漏并進行修復。
參考資料
JRockit工具下載
BEA JRockit 5.0說明文檔
JRockit 5.0中的新功能和新工具
BEA JRockit DevCenter