詳解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模型採用計數器方式管理構件，它與有向圖相比，精度行低(很難處理循環參考的問題)，但執行效率很高。

什麼是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就支援這一特性。