Java記憶體回收機制

標籤：native   一段   儲存   設定   發展   也有   建立對象   nbsp   建立   

大部分轉自：http://blog.csdn.net/zsuguangh/article/details/6429592

1. 記憶體回收的意義
　　在C++中，對象所佔的記憶體在程式結束運行之前一直被佔用，在明確釋放之前不能分配給其它對象；而在Java中，當沒有對象引用指向原先分配給某個對象的記憶體時，該記憶體便成為垃圾。JVM的一個系統級線程會自動釋放該記憶體塊。記憶體回收意味著程式不再需要的對象是"無用資訊"，這些資訊將被丟棄。當一個對象不再被引用的時候，記憶體回收它佔領的空間，以便空間被後來的新對象使用。事實上，除了釋放沒用的對象，記憶體回收也可以清除記憶體記錄片段。由於建立對象和記憶體回收行程釋放丟棄對象所佔的記憶體空間，記憶體會出現片段。片段是分配給對象的記憶體塊之間的空閑記憶體洞。磁碟重組將所佔用的堆記憶體移到堆的一端，JVM將整理出的記憶體配置給新的對象。
　　記憶體回收能自動釋放記憶體空間，減輕編程的負擔。這使JAVA 虛擬機器具有一些優點。首先，它能使編程效率提高。在沒有記憶體回收機制的時候，可能要花許多時間來解決一個難懂的儲存空間問題。在用Java語言編程的時候，靠記憶體回收機制可大大縮短時間。其次是它保護程式的完整性， 記憶體回收是Java語言安全性策略的一個重要部份。
　　記憶體回收的一個潛在的缺點是它的開銷影響程式效能。Java虛擬機器必須追蹤運行程式中有用的對象，而且最終釋放沒用的對象。這一個過程需要花費處理器的時間。其次記憶體回收演算法的不完備性，早先採用的某些記憶體回收演算法就不能保證100%收集到所有的廢棄記憶體。當然隨著記憶體回收演算法的不斷改進以及軟硬體運行效率的不斷提升，這些問題都可以迎刃而解。
2. 垃圾收集的演算法分析
　　Java語言規範沒有明確地說明JVM使用哪種記憶體回收演算法，但是任何一種記憶體回收演算法一般要做2件基本的事情：（1）發現無用資訊對象；（2）回收被無用對象佔用的記憶體空間，使該空間可被程式再次使用。
　　大多數記憶體回收演算法使用了根集(root set)這個概念；所謂根集就是正在執行的Java程式可以訪問的引用變數的集合(包括局部變數、參數、類變數)，程式可以使用引用變數訪問對象的屬性和調用對象的方法。記憶體回收首先需要確定從根開始哪些是可達的和哪些是不可達的，從根集可達的對象都是使用中的物件，它們不能作為垃圾被回收，這也包括從根集間接可達的對象。而根集通過任意路徑不可達的對象符合垃圾收集的條件，應該被回收。下面介紹幾個常用的演算法。
　　2.1. 引用計數法(Reference Counting Collector)
　　引用計數法是唯一沒有使用根集的記憶體回收的法，該演算法使用引用計數器來區分存活對象和不再使用的對象。一般來說，堆中的每個對象對應一個引用計數器。當每一次建立一個對象並賦給一個變數時，引用計數器置為1。當對象被賦給任意變數時，引用計數器每次加1當對象出了範圍後(該對象丟棄不再使用)，引用計數器減1，一旦引用計數器為0，對象就滿足了垃圾收集的條件。
　　基於引用計數器的垃圾收集器運行較快，不會長時間中斷程式執行，適宜地必須即時啟動並執行程式。但引用計數器增加了程式執行的開銷，因為每次對象賦給新的變數，計數器加1，而每次現有對象出了範圍生，計數器減1。
　　2.2. tracing演算法(Tracing Collector)
　　tracing演算法是為瞭解決引用計數法的問題而提出，它使用了根集的概念。基於tracing演算法的垃圾收集器從根集開始掃描，識別出哪些對象可達，哪些對象不可達，並用某種方式標記可達對象，例如對每個可達對象設定一個或多個位。在掃描識別過程中，基於tracing演算法的垃圾收集也稱為標記和清除(mark-and-sweep)垃圾收集器.
　　2.3. compacting演算法(Compacting Collector)
　　為瞭解決堆片段問題，基於tracing的記憶體回收吸收了Compacting演算法的思想，在清除的過程中，演算法將所有的對象移到堆的一端，堆的另一端就變成了一個相鄰的空閑記憶體區，收集器會對它移動的所有對象的所有引用進行更新，使得這些引用在新的位置能識別原來的對象。在基於Compacting演算法的收集器的實現中，一般增加控制代碼和控制代碼表。
　　2.4. copying演算法(Coping Collector)
　　該演算法的提出是為了克服控制代碼的開銷和解決堆片段的記憶體回收。它開始時把堆分成一個對象區和多個空閑區，程式從對象區為對象分配空間，當對象滿了，基於coping演算法的記憶體回收就從根集中掃描使用中的物件，並將每個使用中的物件複製到空閑區(使得使用中的物件所佔的記憶體之間沒有空閑間隔)，這樣空閑區變成了對象區，原來的對象區變成了空閑區，程式會在新的對象區中分配記憶體。
　　一種典型的基於coping演算法的記憶體回收是stop-and-copy演算法，它將堆分成對象區和空閑地區區，在對象區與空閑地區的切換過程中，程式暫停執行。
　　2.5. generation演算法(Generational Collector)
　　stop-and-copy垃圾收集器的一個缺陷是收集器必須複製所有的使用中的物件，這增加了程式等待時間，這是coping演算法低效的原因。在程式設計中有這樣的規律：多數對象存在的時間比較短，少數的存在時間比較長。因此，generation演算法將堆分成兩個或多個，每個子堆作為對象的一代 (generation)。由於多數對象存在的時間比較短，隨著程式丟棄不使用的對象，垃圾收集器將從最年輕的子堆中收集這些對象。在分代式的垃圾收集器運行後，上次運行存活下來的對象移到下一最高代的子堆中，由於老一代的子堆不會經常被回收，因而節省了時間。
　　2.6. adaptive演算法(Adaptive Collector)
　　在特定的情況下，一些垃圾收集演算法會優於其它演算法。基於Adaptive演算法的垃圾收集器就是監控當前堆的使用方式，並將選擇適當演算法的垃圾收集器。

3. System.gc()方法

      命令列參數透視垃圾收集器的運行
　　使用System.gc()可以不管JVM使用的是哪一種記憶體回收的演算法，都可以請求Java的記憶體回收。在命令列中有一個參數-verbosegc可以查看Java使用的堆記憶體的情況，它的格式如下：
　　java -verbosegc classfile
　　可以看個例子：

class TestGC  {      public static void main(String[] args)      {          new TestGC();          System.gc();          System.runFinalization();      }  }          

 

      
　　在這個例子中，一個新的對象被建立，由於它沒有使用，所以該對象迅速地變為不可達，程式編譯後，執行命令： java -verbosegc TestGC 後結果為：
　　[Full GC 168K->97K(1984K)， 0.0253873 secs]
　　機器的環境為，Windows 2000 + JDK1.3.1，箭頭前後的資料168K和97K分別表示垃圾收集GC前後所有存活對象使用的記憶體容量，說明有168K-97K=71K的對象容量被回收，括弧內的資料1984K為堆記憶體的總容量，收集所需要的時間是0.0253873秒（這個時間在每次執行的時候會有所不同）。

      需要注意的是，調用System.gc()也僅僅是一個請求(建議)。JVM接受這個訊息後，並不是立即做記憶體回收，而只是對幾個記憶體回收演算法做了加權，使記憶體回收操作容易發生，或提早發生，或回收較多而已。

4. finalize()方法

      在JVM記憶體回收行程收集一個對象之前，一般要求程式調用適當的方法釋放資源，但在沒有明確釋放資源的情況下，Java提供了預設機制來終止該對象心釋放資源，這個方法就是finalize（）。它的原型為：
　　protected void finalize() throws Throwable
　　在finalize()方法返回之後，對象消失，垃圾收集開始執行。原型中的throws Throwable表示它可以拋出任何類型的異常。
　　之所以要使用finalize()，是存在著記憶體回收行程不能處理的特殊情況。假定你的對象（並非使用new方法）獲得了一塊“特殊”的記憶體地區，由於記憶體回收行程只知道那些顯示地經由new分配的記憶體空間，所以它不知道該如何釋放這塊“特殊”的記憶體地區，那麼這個時候java允許在類中定義一個由finalize()方法。

      特殊的地區例如：1）由於在分配記憶體的時候可能採用了類似 C語言的做法，而非JAVA的通常new做法。這種情況主要發生在native method中，比如native method調用了C/C++方法malloc()函數系列來分配儲存空間，但是除非調用free()函數，否則這些記憶體空間將不會得到釋放，那麼這個時候就可能造成記憶體流失。但是由於free()方法是在C/C++中的函數，所以finalize()中可以用本地方法來調用它。以釋放這些“特殊”的記憶體空間。2）又或者開啟的檔案資源，這些資源不屬於記憶體回收行程的回收範圍。
      換言之，finalize()的主要用途是釋放一些其他做法開闢的記憶體空間，以及做一些清理工作。因為在JAVA中並沒有提夠像“析構”函數或者類似概念的函數，要做一些類似清理工作的時候，必須自己動手建立一個執行清理工作的普通方法，也就是override Object這個類中的finalize()方法。例如，假設某一個對象在建立過程中會將自己繪製到螢幕上，如果不是明確地從螢幕上將其擦出，它可能永遠都不會被清理。如果在finalize()加入某一種擦除功能，當GC工作時，finalize()得到了調用，映像就會被擦除。要是GC沒有發生，那麼這個映像就會

被一直儲存下來。

      一旦記憶體回收行程準備好釋放對象佔用的儲存空間，首先會去調用finalize()方法進行一些必要的清理工作。只有到下一次再進行記憶體回收動作的時候，才會真正釋放這個對象所佔用的記憶體空間。
　　在普通的清除工作中，為清除一個對象，那個對象的使用者必須在希望進行清除的地點調用一個清除方法。這與C++"解構函式"的概念稍有抵觸。在C++中，所有對象都會破壞（清除）。或者換句話說，所有對象都"應該"破壞。若將C++對象建立成一個本機物件，比如在堆棧中建立（在Java中是不可能的，Java都在堆中），那麼清除或破壞工作就會在"結束花括弧"所代表的、建立這個對象的範圍的末尾進行。若對象是用new建立的（類似於Java），那麼當程式員調用C++的 delete命令時（Java沒有這個命令），就會調用相應的解構函式。若程式員忘記了，那麼永遠不會調用解構函式，我們最終得到的將是一個記憶體"漏洞"，另外還包括對象的其他部分永遠不會得到清除。
　　相反，Java不允許我們建立本地（局部）對象--無論如何都要使用new。但在Java中，沒有"delete"命令來釋放對象，因為記憶體回收行程會協助我們自動釋放儲存空間。所以如果站在比較簡化的立場，我們可以說正是由於存在記憶體回收機制，所以Java沒有解構函式。然而，隨著以後學習的深入，就會知道垃圾收集器的存在並不能完全消除對解構函式的需要，或者說不能消除對解構函式代表的那種機制的需要（原因見下一段。另外finalize()函數是在記憶體回收行程準備釋放對象佔用的儲存空間的時候被調用的，絕對不能直接調用finalize()，所以應盡量避免用它）。若希望執行除釋放儲存空間之外的其他某種形式的清除工作，仍然必須調用Java中的一個方法。它等價於C++的解構函式，只是沒後者方便。
      在C++中所有的對象運用delete()一定會被銷毀，而JAVA裡的對象並非總會被記憶體回收行程回收。In another word, 1 對象可能不被記憶體回收，2 記憶體回收並不等於“析構”，3 記憶體回收只與記憶體有關。也就是說，並不是如果一個對象不再被使用，是不是要在finalize()中釋放這個對象中含有的其它對象呢？不是的。因為無論對象是如何建立的，記憶體回收行程都會負責釋放那些對象佔有的記憶體。

5. 觸發主GC（Garbage Collector）的條件

　　JVM進行次GC的頻率很高,但因為這種GC佔用時間極短,所以對系統產生的影響不大。更值得關注的是主GC的觸發條件,因為它對系統影響很明顯。總的來說,有兩個條件會觸發主GC:

　　1)當應用程式空閑時,即沒有應用線程在運行時,GC會被調用。因為GC在優先順序最低的線程中進行,所以當應用忙時,GC線程就不會被調用,但以下條件除外。

　　2)Java堆記憶體不足時,GC會被調用。當應用線程在運行,並在運行過程中建立新對象,若這時記憶體空間不足,JVM就會強制地調用GC線程,以便回收記憶體用於新的分配。若GC一次之後仍不能滿足記憶體配置的要求,JVM會再進行兩次GC作進一步的嘗試,若仍無法滿足要求,則 JVM將報“out of memory”的錯誤,Java應用將停止。

　　由於是否進行主GC由JVM根據系統內容決定,而系統內容在不斷的變化當中,所以主GC的運行具有不確定性,無法預計它何時必然出現,但可以確定的是對一個長期啟動並執行應用來說,其主GC是反覆進行的。

6. 減少GC開銷的措施

　　根據上述GC的機制,程式的運行會直接影響系統內容的變化,從而影響GC的觸發。若不針對GC的特點進行設計和編碼,就會出現記憶體駐留等一系列負面影響。為了避免這些影響,基本的原則就是儘可能地減少垃圾和減少GC過程中的開銷。具體措施包括以下幾個方面:

　　(1)不要顯式調用System.gc()

　　此函數建議JVM進行主GC,雖然只是建議而非一定,但很多情況下它會觸發主GC,從而增加主GC的頻率,也即增加了間歇性停頓的次數。

　　(2)盡量減少臨時對象的使用

　　臨時對象在跳出函數調用後,會成為垃圾,少用臨時變數就相當於減少了垃圾的產生,從而延長了出現上述第二個觸發條件出現的時間,減少了主GC的機會。

　　(3)對象不用時最好顯式置為Null

　　一般而言,為Null的對象都會被作為垃圾處理,所以將不用的對象顯式地設為Null,有利於GC收集器判定垃圾,從而提高了GC的效率。

　　(4)盡量使用StringBuffer,而不用String來累加字串

　　由於String是固定長的字串對象,累加String對象時,並非在一個String對象中擴增,而是重新建立新的String對象,如Str5=Str1+Str2+Str3+Str4,這條語句執行過程中會產生多個垃圾對象,因為對次作“+”操作時都必須建立新的String對象,但這些過渡對象對系統來說是沒有實際意義的,只會增加更多的垃圾。避免這種情況可以改用StringBuffer來累加字串,因StringBuffer是可變長的,它在原有基礎上進行擴增,不會產生中間對象。

　　(5)能用基本類型如Int,Long,就不用Integer,Long對象

　　基本類型變數佔用的記憶體資源比相應對象佔用的少得多,如果沒有必要,最好使用基本變數。

　　(6)盡量少用靜態物件變數

　　靜態變數屬於全域變數,不會被GC回收,它們會一直佔用記憶體。

　　(7)分散對象建立或刪除的時間

　　集中在短時間內大量建立新對象,特別是大對象,會導致突然需要大量記憶體,JVM在面臨這種情況時,只能進行主GC,以回收記憶體或整合記憶體片段,從而增加主GC的頻率。集中刪除對象,道理也是一樣的。它使得突然出現了大量的垃圾對象,空閑空間必然減少,從而大大增加了下一次建立新對象時強制主GC的機會。

 

      下面這個例子向大家展示了垃圾收集所經曆的過程，並對前面的陳述進行了總結。

   

class Chair {　　static boolean gcrun = false;　　static boolean f = false;　　static int created = 0;　　static int finalized = 0;　　int i;　　Chair() {　　    i = ++created;　　    if(created == 47)　　　      System.out.println("Created 47");　　}　　protected void finalize() {　　    if(!gcrun) {　　　      gcrun = true;　　　      System.out.println("Beginning to finalize after " + created + " Chairs have been created");　　    }　　    if(i == 47) {　　　      System.out.println("Finalizing Chair #47， " +"Setting flag to stop Chair creation");　　　      f = true;　　    }　　    finalized++;　　    if(finalized >= created)　　　      System.out.println("All " + finalized + " finalized");　　}}public class Garbage {　　public static void main(String[] args) {　　if(args.length == 0) {　　　  System.err.println("Usage: /n" + "<a href="http://lib.csdn.net/base/java" class=‘replace_word‘ title="Java 知識庫" target=‘_blank‘ style=‘color:#df3434; font-weight:bold;‘>Java </a>Garbage before/n or:/n" + "java Garbage after");　　　  return;　　}　　while(!Chair.f) {　　　  new Chair();　　　  new String("To take up space");　　}　　System.out.println("After all Chairs have been created:/n" + "total created = " + Chair.created +　　"， total finalized = " + Chair.finalized);　　if(args[0].equals("before")) {　　　　System.out.println("gc():");　　　　System.gc();　　　　System.out.println("runFinalization():");　　　　System.runFinalization();　　}　　System.out.println("bye!");　　if(args[0].equals("after"))　　　  System.runFinalizersOnExit(true);　　}}

 

      上面這個程式建立了許多Chair對象，而且在垃圾收集器開始運行後的某些時候，程式會停止建立Chair。由於垃圾收集器可能在任何時間運行，所以我們不能準確知道它在何時啟動。因此，程式用一個名為gcrun的標記來指出垃圾收集器是否已經開始運行。利用第二個標記f，Chair可告訴main()它應停止對象的產生。這兩個標記都是在finalize()內部設定的，它調用於垃圾收集期間。另兩個static變數--created以及 finalized--分別用於跟蹤已建立的對象數量以及垃圾收集器已進行完收尾工作的對象數量。最後，每個Chair都有它自己的（非 static）int i，所以能跟蹤瞭解它具體的編號是多少。編號為47的Chair進行完收尾工作後，標記會設為true，最終結束Chair對象的建立過程。

7. 關於記憶體回收的幾點補充
　　經過上述的說明，可以發現記憶體回收有以下的幾個特點：
　　（1）垃圾收集發生的不可預知性：由於實現了不同的記憶體回收演算法和採用了不同的收集機制，所以它有可能是定時發生，有可能是當出現系統空閑CPU資源時發生，也有可能是和原始的垃圾收集一樣，等到記憶體消耗出現極限時發生，這與垃圾收集器的選擇和具體的設定都有關係。
　　（2）垃圾收集的精確性：主要包括2 個方面：（a）垃圾收集器能夠精確標記活著的對象；（b）垃圾收集器能夠精確地定位對象之間的參考關聯性。前者是完全地回收所有廢棄對象的前提，否則就可能造成記憶體流失。而後者則是實現歸併和複製等演算法的必要條件。所有不可達對象都能夠可靠地得到回收，所有對象都能夠重新分配，允許對象的複製和對象記憶體的縮並，這樣就有效地防止記憶體的支離破碎。
　　（3）現在有許多種不同的垃圾收集器，每種有其演算法且其表現各異，既有當垃圾收集開始時就停止應用程式的運行，又有當垃圾收集開始時也允許應用程式的線程運行，還有在同一時間垃圾收集多線程運行。
　　（4）垃圾收集的實現和具體的JVM 以及JVM的記憶體模型有非常緊密的關係。不同的JVM 可能採用不同的垃圾收集，而JVM 的記憶體模型決定著該JVM可以採用哪些類型垃圾收集。現在，HotSpot 系列JVM中的記憶體系統都採用先進的物件導向的架構設計，這使得該系列JVM都可以採用最先進的垃圾收集。
　　（5）隨著技術的發展，現代垃圾收集技術提供許多可選的垃圾收集器，而且在配置每種收集器的時候又可以設定不同的參數，這就使得根據不同的應用環境獲得最優的應用效能成為可能。
　　針對以上特點，我們在使用的時候要注意：
　　（1）不要試圖去假定垃圾收集發生的時間，這一切都是未知的。比如，方法中的一個臨時對象在方法調用完畢後就變成了無用對象，這個時候它的記憶體就可以被釋放。
　　（2）Java中提供了一些和垃圾收集打交道的類，而且提供了一種強行執行垃圾收集的方法--調用System.gc()，但這同樣是個不確定的方法。Java 中並不保證每次調用該方法就一定能夠啟動垃圾收集，它只不過會向JVM發出這樣一個申請，到底是否真正執行垃圾收集，一切都是個未知數。
　　（3）挑選適合自己的垃圾收集器。一般來說，如果系統沒有特殊和苛刻的效能要求，可以採用JVM的預設選項。否則可以考慮使用有針對性的垃圾收集器，比如增量收集器就比較適合即時性要求較高的系統之中。系統具有較高的配置，有比較多的閑置資源，可以考慮使用並行標記/清除收集器。
　　（4）關鍵的也是難把握的問題是記憶體流失。良好的編程習慣和嚴謹的編程態度永遠是最重要的，不要讓自己的一個小錯誤導致記憶體出現大漏洞。
　　（5）儘早釋放無用對象的引用。大多數程式員在使用臨時變數的時候，都是讓引用變數在退出活動域(scope)後，自動化佈建為null，暗示垃圾收集器來收集該對象，還必須注意該引用的對象是否被監聽，如果有，則要去掉監聽器，然後再賦空值。

Java記憶體回收機制