【轉】Java的記憶體洩漏
一 問題的提出
Java的一個重要優點就是透過垃圾收集器 (Garbage Collection,GC)自動管理記憶體的回收,程式設計師不需要透過呼叫函式來釋放記憶體。因此,很多程式設計師認為Java不存在記憶體洩漏問題,或者認為即使有記憶體洩漏也不是程式的責任,而是GC或JVM的問題。其實,這種想法是不正確的,因為Java也存在記憶體洩露,但它的表現與C++不同。
隨著越來越多的伺服器程式採用Java技術,例如JSP,Servlet, EJB等,伺服器程式往往長期執行。另外,在很多嵌入式系統中,記憶體的總量非常有限。記憶體洩露問題也就變得十分關鍵,即使每次執行少量洩漏,長期執行之後,系統也是面臨崩潰的危險。
二 Java是如何管理記憶體
為了判斷Java中是否有記憶體洩露,我們首先必須瞭解Java是如何管理記憶體的。Java的記憶體管理就是物件的分配和釋放問題。在Java中,程式設計師需要透過關鍵字new為每個物件申請記憶體空間 (基本型別除外),所有的物件都在堆 (Heap)中分配空間。另外,物件的釋放是由GC決定和執行的。在Java中,記憶體的分配是由程式完成的,而記憶體的釋放是有GC完成的,這種收支兩條線的方法確實簡化了程式設計師的工作。但同時,它也加重了JVM的工作。這也是Java程式執行速度較慢的原因之一。因為,GC為了能夠正確釋放物件,GC必須監控每一個物件的執行狀態,包括物件的申請、引用、被引用、賦值等,GC都需要進行監控。
監視物件狀態是為了更加準確地、及時地釋放物件,而釋放物件的根本原則就是該物件不再被引用。
為了更好理解GC的工作原理,我們可以將物件考慮為有向圖的頂點,將引用關係考慮為圖的有向邊,有向邊從引用者指向被引物件。另外,每個執行緒物件可以作為一個圖的起始頂點,例如大多程式從main程式開始執行,那麼該圖就是以main程式頂點開始的一棵根樹。在這個有向圖中,根頂點可達的物件都是有效物件, GC將不回收這些物件。如果某個物件 (連通子圖)與這個根頂點不可達(注意,該圖為有向圖),那麼我們認為這個(這些)物件不再被引用,可以被GC回收。
以下,我們舉一個例子說明如何用有向圖表示記憶體管理。對於程式的每一個時刻,我們都有一個有向圖表示JVM的記憶體分配情況。以下右圖,就是左邊程式執行到第6行的示意圖。
Java 使用有向圖的方式進行記憶體管理,可以消除引用迴圈的問題,例如有三個物件,相互引用,只要它們和根程式不可達的,那麼GC也是可以回收它們的。這種方式的優點是管理記憶體的精度很高,但是效率較低。另外一種常用的記憶體管理技術是使用計數器,例如COM模型採用計數器方式管理構件,它與有向圖相比,精度行低 (很難處理迴圈引用的問題),但執行效率很高。[@more@]三 什麼是Java中的記憶體洩露
下面,我們就可以描述什麼是記憶體洩漏。在 Java中,記憶體洩漏就是存在一些被分配的物件,這些物件有下面兩個特點,首先,這些物件是可達的,即在有向圖中,存在通路可以與其相連;其次,這些物件是無用的,即程式以後不會再使用這些物件。如果物件滿足這兩個條件,這些物件就可以判定為Java中的記憶體洩漏,這些物件不會被GC所回收,然而它卻佔用記憶體。
在C++中,記憶體洩漏的範圍更大一些。有些物件被分配了記憶體空間,然後卻不可達,由於C++中沒有GC,這些記憶體將永遠收不回來。在Java中,這些不可達的物件都由GC負責回收,因此程式設計師不需要考慮這部分的記憶體洩露。
透過分析,我們得知,對於C++,程式設計師需要自己管理邊和頂點,而對於Java程式設計師只需要管理邊就可以了(不需要管理頂點的釋放)。透過這種方式,Java提高了程式設計的效率。
因此,透過以上分析,我們知道在Java中也有記憶體洩漏,但範圍比C++要小一些。因為Java從語言上保證,任何物件都是可達的,所有的不可達物件都由GC管理。
對於程式設計師來說,GC基本是透明的,不可見的。雖然,我們只有幾個函式可以訪問GC,例如執行GC的函式System.gc(),但是根據Java語言規範定義,該函式不保證JVM的垃圾收集器一定會執行。因為,不同的JVM實現者可能使用不同的演算法管理GC。通常,GC的執行緒的優先順序別較低。JVM呼叫GC的策略也有很多種,有的是記憶體使用到達一定程度時,GC才開始工作,也有定時執行的,有的是平緩執行GC,有的是中斷式執行GC。但通常來說,我們不需要關心這些。除非在一些特定的場合,GC的執行影響應用程式的效能,例如對於基於Web的實時系統,如網路遊戲等,使用者不希望GC突然中斷應用程式執行而進行垃圾回收,那麼我們需要調整GC的引數,讓GC能夠透過平緩的方式釋放記憶體,例如將垃圾回收分解為一系列的小步驟執行,Sun提供的HotSpot JVM就支援這一特性。
下面給出了一個簡單的記憶體洩露的例子。在這個例子中,我們迴圈申請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引用這些物件。
四 如何檢測記憶體洩漏
最後一個重要的問題,就是如何檢測Java的記憶體洩漏。目前,我們通常使用一些工具來檢查Java程式的記憶體洩漏問題。市場上已有幾種專業檢查Java記憶體洩漏的工具,它們的基本工作原理大同小異,都是透過監測Java程式執行時,所有物件的申請、釋放等動作,將記憶體管理的所有資訊進行統計、分析、視覺化。開發人員將根據這些資訊判斷程式是否有記憶體洩漏問題。這些工具包括Optimizeit Profiler,JProbe Profiler,JinSight , Rational 公司的Purify等。
下面,我們將簡單介紹Optimizeit的基本功能和工作原理。
Optimizeit Profiler版本4.11支援Application,Applet,Servlet和Romote Application四類應用,並且可以支援大多數型別的JVM,包括SUN JDK系列,IBM的JDK系列,和Jbuilder的JVM等。並且,該軟體是由Java編寫,因此它支援多種作業系統。Optimizeit系列還包括Thread Debugger和Code Coverage兩個工具,分別用於監測執行時的執行緒狀態和程式碼覆蓋面。
當設定好所有的引數了,我們就可以在OptimizeIt環境下執行被測程式,在程式執行過程中,Optimizeit可以監視記憶體的使用曲線(如下圖),包括JVM申請的堆(heap)的大小,和實際使用的記憶體大小。另外,在執行過程中,我們可以隨時暫停程式的執行,甚至強行呼叫GC,讓GC進行記憶體回收。透過記憶體使用曲線,我們可以整體瞭解程式使用記憶體的情況。這種監測對於長期執行的應用程式非常有必要,也很容易發現記憶體洩露。
在執行過程中,我們還可以從不同視角觀查記憶體的使用情況,Optimizeit提供了四種方式:
堆視角。 這是一個全面的視角,我們可以瞭解堆中的所有的物件資訊(數量和種類),並進行統計、排序,過濾。瞭解相關物件的變化情況。
方法視角。透過方法視角,我們可以得知每一種類的物件,都分配在哪些方法中,以及它們的數量。
物件視角。給定一個物件,透過物件視角,我們可以顯示它的所有出引用和入引用物件,我們可以瞭解這個物件的所有引用關係。
引用圖。 給定一個根,透過引用圖,我們可以顯示從該頂點出發的所有出引用。
在執行過程中,我們可以隨時觀察記憶體的使用情況,透過這種方式,我們可以很快找到那些長期不被釋放,並且不再使用的物件。我們透過檢查這些物件的生存週期,確認其是否為記憶體洩露。在實踐當中,尋找記憶體洩露是一件非常麻煩的事情,它需要程式設計師對整個程式的程式碼比較清楚,並且需要豐富的除錯經驗,但是這個過程對於很多關鍵的Java程式都是十分重要的。
綜上所述,Java也存在記憶體洩露問題,其原因主要是一些物件雖然不再被使用,但它們仍然被引用。為了解決這些問題,我們可以透過軟體工具來檢查記憶體洩露,檢查的主要原理就是暴露出所有堆中的物件,讓程式設計師尋找那些無用但仍被引用的物件。
Java的一個重要優點就是透過垃圾收集器 (Garbage Collection,GC)自動管理記憶體的回收,程式設計師不需要透過呼叫函式來釋放記憶體。因此,很多程式設計師認為Java不存在記憶體洩漏問題,或者認為即使有記憶體洩漏也不是程式的責任,而是GC或JVM的問題。其實,這種想法是不正確的,因為Java也存在記憶體洩露,但它的表現與C++不同。
隨著越來越多的伺服器程式採用Java技術,例如JSP,Servlet, EJB等,伺服器程式往往長期執行。另外,在很多嵌入式系統中,記憶體的總量非常有限。記憶體洩露問題也就變得十分關鍵,即使每次執行少量洩漏,長期執行之後,系統也是面臨崩潰的危險。
二 Java是如何管理記憶體
為了判斷Java中是否有記憶體洩露,我們首先必須瞭解Java是如何管理記憶體的。Java的記憶體管理就是物件的分配和釋放問題。在Java中,程式設計師需要透過關鍵字new為每個物件申請記憶體空間 (基本型別除外),所有的物件都在堆 (Heap)中分配空間。另外,物件的釋放是由GC決定和執行的。在Java中,記憶體的分配是由程式完成的,而記憶體的釋放是有GC完成的,這種收支兩條線的方法確實簡化了程式設計師的工作。但同時,它也加重了JVM的工作。這也是Java程式執行速度較慢的原因之一。因為,GC為了能夠正確釋放物件,GC必須監控每一個物件的執行狀態,包括物件的申請、引用、被引用、賦值等,GC都需要進行監控。
監視物件狀態是為了更加準確地、及時地釋放物件,而釋放物件的根本原則就是該物件不再被引用。
為了更好理解GC的工作原理,我們可以將物件考慮為有向圖的頂點,將引用關係考慮為圖的有向邊,有向邊從引用者指向被引物件。另外,每個執行緒物件可以作為一個圖的起始頂點,例如大多程式從main程式開始執行,那麼該圖就是以main程式頂點開始的一棵根樹。在這個有向圖中,根頂點可達的物件都是有效物件, GC將不回收這些物件。如果某個物件 (連通子圖)與這個根頂點不可達(注意,該圖為有向圖),那麼我們認為這個(這些)物件不再被引用,可以被GC回收。
以下,我們舉一個例子說明如何用有向圖表示記憶體管理。對於程式的每一個時刻,我們都有一個有向圖表示JVM的記憶體分配情況。以下右圖,就是左邊程式執行到第6行的示意圖。
Java 使用有向圖的方式進行記憶體管理,可以消除引用迴圈的問題,例如有三個物件,相互引用,只要它們和根程式不可達的,那麼GC也是可以回收它們的。這種方式的優點是管理記憶體的精度很高,但是效率較低。另外一種常用的記憶體管理技術是使用計數器,例如COM模型採用計數器方式管理構件,它與有向圖相比,精度行低 (很難處理迴圈引用的問題),但執行效率很高。[@more@]三 什麼是Java中的記憶體洩露
下面,我們就可以描述什麼是記憶體洩漏。在 Java中,記憶體洩漏就是存在一些被分配的物件,這些物件有下面兩個特點,首先,這些物件是可達的,即在有向圖中,存在通路可以與其相連;其次,這些物件是無用的,即程式以後不會再使用這些物件。如果物件滿足這兩個條件,這些物件就可以判定為Java中的記憶體洩漏,這些物件不會被GC所回收,然而它卻佔用記憶體。
在C++中,記憶體洩漏的範圍更大一些。有些物件被分配了記憶體空間,然後卻不可達,由於C++中沒有GC,這些記憶體將永遠收不回來。在Java中,這些不可達的物件都由GC負責回收,因此程式設計師不需要考慮這部分的記憶體洩露。
透過分析,我們得知,對於C++,程式設計師需要自己管理邊和頂點,而對於Java程式設計師只需要管理邊就可以了(不需要管理頂點的釋放)。透過這種方式,Java提高了程式設計的效率。
因此,透過以上分析,我們知道在Java中也有記憶體洩漏,但範圍比C++要小一些。因為Java從語言上保證,任何物件都是可達的,所有的不可達物件都由GC管理。
對於程式設計師來說,GC基本是透明的,不可見的。雖然,我們只有幾個函式可以訪問GC,例如執行GC的函式System.gc(),但是根據Java語言規範定義,該函式不保證JVM的垃圾收集器一定會執行。因為,不同的JVM實現者可能使用不同的演算法管理GC。通常,GC的執行緒的優先順序別較低。JVM呼叫GC的策略也有很多種,有的是記憶體使用到達一定程度時,GC才開始工作,也有定時執行的,有的是平緩執行GC,有的是中斷式執行GC。但通常來說,我們不需要關心這些。除非在一些特定的場合,GC的執行影響應用程式的效能,例如對於基於Web的實時系統,如網路遊戲等,使用者不希望GC突然中斷應用程式執行而進行垃圾回收,那麼我們需要調整GC的引數,讓GC能夠透過平緩的方式釋放記憶體,例如將垃圾回收分解為一系列的小步驟執行,Sun提供的HotSpot JVM就支援這一特性。
下面給出了一個簡單的記憶體洩露的例子。在這個例子中,我們迴圈申請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引用這些物件。
四 如何檢測記憶體洩漏
最後一個重要的問題,就是如何檢測Java的記憶體洩漏。目前,我們通常使用一些工具來檢查Java程式的記憶體洩漏問題。市場上已有幾種專業檢查Java記憶體洩漏的工具,它們的基本工作原理大同小異,都是透過監測Java程式執行時,所有物件的申請、釋放等動作,將記憶體管理的所有資訊進行統計、分析、視覺化。開發人員將根據這些資訊判斷程式是否有記憶體洩漏問題。這些工具包括Optimizeit Profiler,JProbe Profiler,JinSight , Rational 公司的Purify等。
下面,我們將簡單介紹Optimizeit的基本功能和工作原理。
Optimizeit Profiler版本4.11支援Application,Applet,Servlet和Romote Application四類應用,並且可以支援大多數型別的JVM,包括SUN JDK系列,IBM的JDK系列,和Jbuilder的JVM等。並且,該軟體是由Java編寫,因此它支援多種作業系統。Optimizeit系列還包括Thread Debugger和Code Coverage兩個工具,分別用於監測執行時的執行緒狀態和程式碼覆蓋面。
當設定好所有的引數了,我們就可以在OptimizeIt環境下執行被測程式,在程式執行過程中,Optimizeit可以監視記憶體的使用曲線(如下圖),包括JVM申請的堆(heap)的大小,和實際使用的記憶體大小。另外,在執行過程中,我們可以隨時暫停程式的執行,甚至強行呼叫GC,讓GC進行記憶體回收。透過記憶體使用曲線,我們可以整體瞭解程式使用記憶體的情況。這種監測對於長期執行的應用程式非常有必要,也很容易發現記憶體洩露。
在執行過程中,我們還可以從不同視角觀查記憶體的使用情況,Optimizeit提供了四種方式:
堆視角。 這是一個全面的視角,我們可以瞭解堆中的所有的物件資訊(數量和種類),並進行統計、排序,過濾。瞭解相關物件的變化情況。
方法視角。透過方法視角,我們可以得知每一種類的物件,都分配在哪些方法中,以及它們的數量。
物件視角。給定一個物件,透過物件視角,我們可以顯示它的所有出引用和入引用物件,我們可以瞭解這個物件的所有引用關係。
引用圖。 給定一個根,透過引用圖,我們可以顯示從該頂點出發的所有出引用。
在執行過程中,我們可以隨時觀察記憶體的使用情況,透過這種方式,我們可以很快找到那些長期不被釋放,並且不再使用的物件。我們透過檢查這些物件的生存週期,確認其是否為記憶體洩露。在實踐當中,尋找記憶體洩露是一件非常麻煩的事情,它需要程式設計師對整個程式的程式碼比較清楚,並且需要豐富的除錯經驗,但是這個過程對於很多關鍵的Java程式都是十分重要的。
綜上所述,Java也存在記憶體洩露問題,其原因主要是一些物件雖然不再被使用,但它們仍然被引用。為了解決這些問題,我們可以透過軟體工具來檢查記憶體洩露,檢查的主要原理就是暴露出所有堆中的物件,讓程式設計師尋找那些無用但仍被引用的物件。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/12058779/viewspace-1015891/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- Java記憶體洩漏Java記憶體
- 【轉】java中的記憶體溢位和記憶體洩漏Java記憶體溢位
- Perfdog 玩轉記憶體洩漏記憶體
- 記憶體洩漏記憶體
- 納尼,Java 存在記憶體洩洩洩洩洩洩漏嗎?Java記憶體
- 介紹Java中的記憶體洩漏Java記憶體
- 關於java中的記憶體洩漏Java記憶體
- Java記憶體洩漏解決之道Java記憶體
- 【Java面試題】之記憶體洩漏Java面試題記憶體
- 分析記憶體洩漏和goroutine洩漏記憶體Go
- 記憶體洩漏的原因記憶體
- java記憶體溢位和記憶體洩漏的區別Java記憶體溢位
- js記憶體洩漏JS記憶體
- webView 記憶體洩漏WebView記憶體
- Javascript記憶體洩漏JavaScript記憶體
- [Java基礎]記憶體洩漏和記憶體溢位Java記憶體溢位
- Java棧溢位|記憶體洩漏|記憶體溢位Java記憶體溢位
- 一次 Java 記憶體洩漏的排查Java記憶體
- 翻譯 | 理解Java中的記憶體洩漏Java記憶體
- 深入理解Java中的記憶體洩漏Java記憶體
- 如何識別Java中的記憶體洩漏Java記憶體
- Java應用程式中的記憶體洩漏及記憶體管理Java記憶體
- 檢測並排除記憶體洩漏 (轉)記憶體
- WebView引起的記憶體洩漏WebView記憶體
- ARC下的記憶體洩漏記憶體
- 記憶體分析與記憶體洩漏定位記憶體
- 記憶體洩漏和記憶體溢位記憶體溢位
- valgrind 記憶體洩漏分析記憶體
- Android 記憶體洩漏Android記憶體
- Android記憶體洩漏Android記憶體
- 淺談記憶體洩漏記憶體
- JavaScript 記憶體洩漏教程JavaScript記憶體
- 說說 記憶體洩漏記憶體
- 記憶體的分配與釋放,記憶體洩漏記憶體
- VCL 中的一個記憶體洩漏 Bug (轉)記憶體
- 防範JAVA記憶體洩漏解決方案Java記憶體
- JVM——記憶體洩漏與記憶體溢位JVM記憶體溢位
- Swift的ARC和記憶體洩漏Swift記憶體