一. 什么是Java中的內存泄露

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

在Java中，內存泄漏就是存在一些被分配的對象，這些對象有下面兩個特點，首先，這些對象是有被引用的，即在有向樹形圖中，存在樹枝通路可以與其相連；其次，這些對象是無用的，即程序以后不會再使用這些對象。如果對象滿足這兩個條件，這些對象就可以判定為Java中的內存泄漏，這些對象不會被GC所回收，然而它卻占用內存。

這里引用一個常看到的例子，在下面的代碼中，循環申請Object對象，并將所申請的對象放入一個Vector中，如果僅僅釋放對象本身，但因為 Vector仍然引用該對象，所以這個對象對GC來說是不可回收的。因此，如果對象加入到Vector后，還必須從Vector中刪除，最簡單的方法就是將Vector對象設置為null。

            
Vector v = new Vector(10);
            for (int i = 1; i < 100; i++)
            ......{
            　Object o = new Object();
            　v.add(o);
            　o = null;
            }//此時，所有的Object對象都沒有被釋放，因為變量v引用這些對象。 
            

實際上這些對象已經是無用的，但還被引用，GC就無能為力了(事實上GC認為它還有用)，這一點是導致內存泄漏最重要的原因。再引用另一個例子來說明Java的內存泄漏。假設有一個日志類Logger，其提供一個靜態的log(String msg)，任何其它類都可以調用Logger.Log(message)來將message的內容記錄到系統的日志文件中。

Logger類有一個類型為HashMap的靜態變量temp，每次在執行log(message)的時候，都首先將message的值寫入temp中 (以當前線程+當前時間為鍵)，在退出之前再從temp中將以當前線程和當前時間為鍵的條目刪除。注意，這里當前時間是不斷變化的，所以log在退出之前執行刪除條目的操作并不能刪除執行之初寫入的條目。這樣，任何一個作為參數傳給log的字符串最終由于被Logger的靜態變量temp引用，而無法得到回收，這種對象保持就是我們所說的Java內存泄漏。 總的來說，內存管理中的內存泄漏產生的主要原因：保留下來卻永遠不再使用的對象引用。

三. 幾種典型的內存泄漏

我們知道了在Java中確實會存在內存泄漏，那么就讓我們看一看幾種典型的泄漏，并找出他們發生的原因和解決方法。

3.1 全局集合
在大型應用程序中存在各種各樣的全局數據倉庫是很普遍的，比如一個JNDI-tree或者一個session table。在這些情況下，必須注意管理儲存庫的大小。必須有某種機制從儲存庫中移除不再需要的數據。

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

另一種管理儲存庫的方法是使用反向鏈接(referrer)計數。然后集合負責統計集合中每個入口的反向鏈接的數目。這要求反向鏈接告訴集合何時會退出入口。當反向鏈接數目為零時，該元素就可以從集合中移除了。
　　
3.2 緩存
緩存一種用來快速查找已經執行過的操作結果的數據結構。因此，如果一個操作執行需要比較多的資源并會多次被使用，通常做法是把常用的輸入數據的操作結果進行緩存，以便在下次調用該操作時使用緩存的數據。緩存通常都是以動態方式實現的,如果緩存設置不正確而大量使用緩存的話則會出現內存溢出的后果，因此需要將所使用的內存容量與檢索數據的速度加以平衡。

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

3.3 類裝載器
Java類裝載器的使用為內存泄漏提供了許多可乘之機。一般來說類裝載器都具有復雜結構，因為類裝載器不僅僅是只與"常規"對象引用有關，同時也和對象內部的引用有關。比如數據變量，方法和各種類。這意味著只要存在對數據變量，方法，各種類和對象的類裝載器，那么類裝載器將駐留在JVM中。既然類裝載器可以同很多的類關聯，同時也可以和靜態數據變量關聯，那么相當多的內存就可能發生泄漏。

四. 如何檢測和處理內存泄漏
如何查找引起內存泄漏的原因一般有兩個步驟:第一是安排有經驗的編程人員對代碼進行走查和分析，找出內存泄漏發生的位置;第二是使用專門的內存泄漏測試工具進行測試。

第一個步驟在代碼走查的工作中，可以安排對系統業務和開發語言工具比較熟悉的開發人員對應用的代碼進行了交叉走查，盡量找出代碼中存在的數據庫連接聲明和結果集未關閉、代碼冗余等故障代碼。

第二個步驟就是檢測Java的內存泄漏。在這里我們通常使用一些工具來檢查Java程序的內存泄漏問題。市場上已有幾種專業檢查Java內存泄漏的工具，它們的基本工作原理大同小異，都是通過監測Java程序運行時，所有對象的申請、釋放等動作，將內存管理的所有信息進行統計、分析、可視化。開發人員將根據這些信息判斷程序是否有內存泄漏問題。這些工具包括Optimizeit Profiler，JProbe Profiler，JinSight , Rational 公司的Purify等。

4.1檢測內存泄漏的存在
這里我們將簡單介紹我們在使用Optimizeit檢查的過程。通常在知道發生內存泄漏之后，第一步是要弄清楚泄漏了什么數據和哪個類的對象引起了泄漏。

一般說來，一個正常的系統在其運行穩定后其內存的占用量是基本穩定的，不應該是無限制的增長的。同樣，對任何一個類的對象的使用個數也有一個相對穩定的上限，不應該是持續增長的。根據這樣的基本假設，我們持續地觀察系統運行時使用的內存的大小和各實例的個數，如果內存的大小持續地增長，則說明系統存在內存泄漏，如果特定類的實例對象個數隨時間而增長（就是所謂的“增長率”），則說明這個類的實例可能存在泄漏情況。

另一方面通常發生內存泄漏的第一個跡象是：在應用程序中出現了OutOfMemoryError。在這種情況下，需要使用一些開銷較低的工具來監控和查找內存泄漏。雖然OutOfMemoryError也有可能應用程序確實正在使用這么多的內存；對于這種情況則可以增加JVM可用的堆的數量，或者對應用程序進行某種更改，使它使用較少的內存。

但是，在許多情況下，OutOfMemoryError都是內存泄漏的信號。一種查明方法是不間斷地監控GC的活動，確定內存使用量是否隨著時間增加。如果確實如此，就可能發生了內存泄漏。