[轉貼]垃圾收集器與Java編程

歐陽辰 (yeekee@sina.com)
周欣 (zhouxin@sei.pku.edu.cn)

垃圾收集器(Garbage Collector，GC)對Java程式員來說，基本 上是透明的，但是一個優秀的Java程式員必須瞭解GC的工作原理、如何最佳化GC的效能、如何與GC進行有限的互動，因為有一些應用程式對效能要求較高，例如嵌入式系統、即時系統等，只有全面提升記憶體的管理效率 ,才能提高整個應用程式的效能。本篇文章首先簡單介紹GC的工作原理之後，然後再對GC的幾個關鍵問題進行深入探討，最後提出一些Java程式設計建議，從GC角度提高Java程式的效能。

一GC的基本原理

Java的記憶體管理實際上就是對象的管理，其中包括對象的分配和釋放。

對於程式員來說，指派至使用new關鍵字；釋放對象時，只要將對象所有引用賦值為null，讓程式不能夠再訪問到這個對象，我們稱該對象為"不可達的"。GC將負責回收所有"不可達"對象的記憶體空間。

對於GC來說，當程式員建立對象時，GC就開始監控這個對象的地址、大小以及使用方式。通常，GC採用有向圖的方式記錄和管理堆(heap)中的所有對象(詳見參考資料1 )。通過這種方式確定哪些對象是"可達的"，哪些對象是"不可達的"。當GC確定一些對象為"不可達"時，GC就有責任回收這些記憶體空間。但是，為了保證GC能夠在不同平台實現的問題，Java規範對GC的很多行為都沒有進行嚴格的規定。例如，對於採用什麼類型的回收演算法、什麼時候進行回收等重要問題都沒有明確的規定。因此，不同的JVM的實現者往往有不同的實現演算法。這也給Java程式員的開發帶來行多不確定性。本文研究了幾個與GC工作相關的問題，努力減少這種不確定性給Java程式帶來的負面影響。

二 增量式GC( Incremental GC )

GC在JVM中通常是由一個或一組進程來實現的，它本身也和使用者程式一樣佔用heap空間，運行時也佔用CPU。當GC進程運行時，應用程式停止運行。因此，當GC已耗用時間較長時，使用者能夠感到Java程式的停頓，另外一方面，如果GC已耗用時間太短，則可能對象回收率太低，這意味著還有很多應該回收的對象沒有被回收，仍然佔用大量記憶體。因此，在設計GC的時候，就必須在停頓時間和回收率之間進行權衡。一個好的GC實現允許使用者定義自己所需要的設定，例如有些記憶體有限有裝置，對記憶體的使用量非常敏感，希望GC能夠準確的回收記憶體，它並不在意程式速度的放慢。另外一些即時網路遊戲，就不能夠允許程式有長時間的中斷。增量式GC就是通過一定的回收演算法，把一個長時間的中斷，劃分為很多個小的中斷，通過這種方式減少GC對使用者程式的影響。雖然，增量式GC在整體效能上可能不如普通GC的效率高，但是它能夠減少程式的最長停頓時間。

就表示了，增量式GC和普通GC的比較。其中灰色部分表示線程佔用CPU的時間。

Sun JDK提供的HotSpot JVM就能支援增量式GC。HotSpot JVM預設GC方式為不使用增量GC，為了啟動增量GC，我們必須在運行Java程式時增加-Xincgc的參數。HotSpot JVM增量式GC的實現是採用Train GC演算法。它的基本想法就是，將堆中的所有對象按照建立和使用方式進行分組(分層)，將使用頻繁高和具有相關性的對象放在一隊中，隨著程式的運行，不斷對組進行調整。當GC運行時，它總是先回收最老的(最近很少訪問的)的對象，如果整組都為可回收對象，GC將整組回收。這樣，每次GC運行只回收一定比例的不可達對象，保證程式的順暢運行。Train GC演算法是一個非常好的演算法，具體演算法見參考資料4。

三 詳解finalize函數

finalize是位於Object類的一個方法，該方法的存取修飾詞為protected，由於所有類為Object的子類，因此使用者類很容易訪問到這個方法。由於，finalize函數沒有自動實現鏈式調用，我們必須手動的實現，因此finalize函數的最後一個語句通常是super.finalize()。通過這種方式，我們可以實現從下到上實現finalize的調用，即先釋放自己的資源，然後再釋放父類的資源。

根據Java語言規範，JVM保證調用finalize函數之前，這個對象是不可達的，但是JVM不保證這個函數一定會被調用。另外，規範還保證finalize函數最多運行一次。

很多Java初學者會認為這個方法類似與C++中的解構函式，將很多個物件、資源的釋放都放在這一函數裡面。其實，這不是一種很好的方式。原因有三，其一，GC為了能夠支援finalize函數，要對覆蓋這個函數的對象作很多附加的工作。其二，在finalize運行完成之後，該對象可能變成可達的，GC還要再檢查一次該對象是否是可達的。因此，使用finalize會降低GC的運行效能。其三，由於GC調用finalize的時間是不確定的，因此通過這種方式釋放資源也是不確定的。

通常，finalize用於一些不容易控制、並且非常重要資源的釋放，例如一些I/O的操作，資料的串連。這些資源的釋放對整個應用程式是非常關鍵的。在這種情況下，程式員應該以通過程式本身管理(包括釋放)這些資源為主，以finalize函數釋放資源方式為輔，形成一種雙保險的管理機制，而不應該僅僅依靠finalize來釋放資源。

下面給出一個例子說明，finalize函數被調用以後，仍然可能是可達的，同時也可說明一個對象的finalize只可能運行一次。

class MyObject{ Test main; //記錄Test對象，在finalize中時用於恢複可達性 public MyObject(Test t) { main=t; //儲存Test 對象 } protected void finalize() { main.ref=this;// 恢複本對象，讓本對象可達 System.out.println("This is finalize");//用於測試finalize只運行一次 } } class Test { MyObject ref; public static void main(String[] args) { Test test=new Test(); test.ref=new MyObject(test); test.ref=null; //MyObject對象為不可達對象，finalize將被調用 System.gc(); if (test.ref!=null) System.out.println("My Object還活著"); } }

運行結果：
This is finalize
MyObject還活著

此例子中，需要注意的是雖然MyObject對象在finalize中變成可達對象，但是下次回收時候，finalize卻不再被調用，因為finalize函數最多隻調用一次。

四 程式如何與GC進行互動

Java2增強了記憶體管理功能， 增加了一個java.lang.ref包，其中定義了三種引用類。這三種引用類分別為SoftReference、WeakReference和PhantomReference。通過使用這些引用類，程式員可以在一定程度與GC進行互動，以便改善GC的工作效率。這些引用類的引用強度介於可達對象和不可達對象之間。它們的引用強度如所示：

建立一個引用對象也非常容易，例如如果你需要建立一個Soft Reference對象，那麼首先建立一個對象，並採用普通引用方式(可達對象)；然後再建立一個SoftReference引用該對象；最後將普通引用設定為null。通過這種方式，這個對象就只有一個Soft Reference引用。同時，我們稱這個對象為Soft Reference 對象。

Soft Reference的主要特點是據有較強的引用功能。只有當記憶體不夠的時候，才進行回收這類記憶體，因此在記憶體足夠的時候，它們通常不被回收。另外，這些引用對象還能保證在Java拋出OutOfMemory 異常之前，被設定為null。它可以用於實現一些常用圖片的緩衝，實現Cache的功能，保證最大限度的使用記憶體而不引起OutOfMemory。以下給出這種參考型別的使用虛擬碼；

//申請一個映像對象 Image image=new Image();//建立Image對象 … //使用 image … //使用完了image，將它設定為soft 參考型別，並且釋放強引用； SoftReference sr=new SoftReference(image); image=null; … //下次使用時 if (sr!=null) image=sr.get(); else{ //由於GC由於低記憶體，已釋放image，因此需要重新裝載； image=new Image(); sr=new SoftReference(image); }

Weak引用對象與Soft引用對象的最大不同就在於：GC在進行回收時，需要通過演算法檢查是否回收Soft引用對象，而對於Weak引用對象，GC總是進行回收。Weak引用對象更容易、更快被GC回收。雖然，GC在運行時一定回收Weak對象，但是複雜關係的Weak對象群常常需要好幾次GC的運行才能完成。Weak引用對象常常用於Map結構中，引用資料量較大的對象，一旦該對象的強引用為null時，GC能夠快速地回收該對象空間。該例子見參考資料4;

Phantom引用的用途較少，主要用於輔助finalize函數的使用。Phantom對象指一些對象，它們執行完了finalize函數，並為不可達對象，但是它們還沒有被GC回收。這種對象可以輔助finalize進行一些後期的回收工作，我們通過覆蓋Reference的clear()方法，增強資源回收機制的靈活性。

五一些Java編碼的建議

根據GC的工作原理，我們可以通過一些技巧和方式，讓GC運行更加有效率，更加符合應用程式的要求。以下就是一些程式設計的幾點建議。

1. 最基本的建議就是儘早釋放無用對象的引用。大多數程式員在使用臨時變數的時候，都是讓引用變數在退出活動域(scope)後，自動化佈建為null。我們在使用這種方式時候，必須特別注意一些複雜的對象圖，例如數組，隊列，樹，圖等，這些對象之間有相互參考關聯性較為複雜。對於這類對象，GC回收它們一般效率較低。如果程式允許，儘早將不用的引用對象賦為null。這樣可以加速GC的工作。
2. 盡量少用finalize函數。finalize函數是Java提供給程式員一個釋放對象或資源的機會。但是，它會加大GC的工作量，因此盡量少採用finalize方式回收資源。
3. 如果需要使用經常使用的圖片，可以使用soft應用類型。它可以儘可能將圖片儲存在記憶體中，供程式調用，而不引起OutOfMemory。
4. 注意集合資料類型，包括數組，樹，圖，鏈表等資料結構，這些資料結構對GC來說，回收更為複雜。另外，注意一些全域的變數，以及一些靜態變數。這些變數往往容易引起懸掛對象(dangling reference)，造成記憶體浪費。
5. 當程式有一定的等待時間，程式員可以手動執行System.gc()，通知GC運行，但是Java語言規範並不保證GC一定會執行。使用增量式GC可以縮短Java程式的暫停時間。

參考資料

文章

1. 歐陽辰，周欣 "Java與記憶體流失" http://www-900.ibm.com/developerWorks/cn/java/l-JavaMemoryLeak/index.shtml
2. Y. Srinivas Ramakrishna "Atuomatic Memory Management in the Java HotSpot Virtual Machine"，此文章JavaOne2002的演講材料, http://java.sun.com/javaone
3. Monica Pawlan "Reference Objects and Garbage Collector" 此文章為JDC的文章，可在http://developer.java.sun.com/上找到
4. Bill Venners Chapter 9 of "Inside the Java 2 Virtual Machine" http://www.artima.com/insidejvm/ed2/ch09GarbageCollectionPrint.html
5. Sun Microsystems, "Java Language Specification, Second Version"

關於作者 歐陽辰，北京大學電腦碩士畢業，98年起開始研究基於java的軟體開發、測試，參與開發、測試過多個基於Java的應用程式和Web服務項目。連絡方式yeekee@sina.com 周欣，北京大學電腦系在讀博士生，主要研究方向：程式理解、逆向工程及軟體度量，連絡方式 zhouxin@sei.pku.edu.cn。