1. 程式人生 > >深入理解Java垃圾回收機制

深入理解Java垃圾回收機制

               

一、垃圾回收機制的意義

  Java語言中一個顯著的特點就是引入了垃圾回收機制,使c++程式設計師最頭疼的記憶體管理的問題迎刃而解,它使得Java程式設計師在編寫程式的時候不再需要考慮記憶體管理。由於有個垃圾回收機制,Java中的物件不再有“作用域”的概念,只有物件的引用才有“作用域”。垃圾回收可以有效的防止記憶體洩露,有效的使用空閒的記憶體。

  ps:記憶體洩露是指該記憶體空間使用完畢之後未回收,在不涉及複雜資料結構的一般情況下,Java 的記憶體洩露表現為一個記憶體物件的生命週期超出了程式需要它的時間長度,我們有時也將其稱為“物件遊離”。

二、垃圾回收機制中的演算法

  Java語言規範沒有明確地說明JVM使用哪種垃圾回收演算法,但是任何一種垃圾回收演算法一般要做2件基本的事情:(1)發現無用資訊物件;(2)回收被無用物件佔用的記憶體空間,使該空間可被程式再次使用。  

1.引用計數法(Reference Counting Collector)

1.1演算法分析

  引用計數是垃圾收集器中的早期策略。在這種方法中,堆中每個物件例項都有一個引用計數。當一個物件被建立時,且將該物件例項分配給一個變數,該變數計數設定為1。當任何其它變數被賦值為這個物件的引用時,計數加1(a = b,則b引用的物件例項的計數器+1),但當一個物件例項的某個引用超過了生命週期或者被設定為一個新值時,物件例項的引用計數器減1。任何引用計數器為0的物件例項可以被當作垃圾收集。當一個物件例項被垃圾收集時,它引用的任何物件例項的引用計數器減1。

1.2優缺點

優點:

  引用計數收集器可以很快的執行,交織在程式執行中。對程式需要不被長時間打斷的實時環境比較有利。

缺點:

  無法檢測出迴圈引用。如父物件有一個對子物件的引用,子物件反過來引用父物件。這樣,他們的引用計數永遠不可能為0.

1引用計數演算法無法解決迴圈引用問題,例如:

public class Main {    public static void main(String[] args) {        MyObject object1 = new MyObject();        MyObject object2 = new MyObject();                object1.object = object2;        object2.object = object1;                object1 = null;        object2 = null;    }}

最後面兩句將object1和object2賦值為null,也就是說object1和object2指向的物件已經不可能再被訪問,但是由於它們互相引用對方,導致它們的引用計數器都不為0,那麼垃圾收集器就永遠不會回收它們。

2.tracing演算法(Tracing Collector) 或 標記-清除演算法(mark and sweep)

2.1根搜尋演算法

  根搜尋演算法是從離散數學中的圖論引入的,程式把所有的引用關係看作一張圖,從一個節點GC ROOT開始,尋找對應的引用節點,找到這個節點以後,繼續尋找這個節點的引用節點,當所有的引用節點尋找完畢之後,剩餘的節點則被認為是沒有被引用到的節點,即無用的節點。

java中可作為GC Root的物件有

  1.虛擬機器棧中引用的物件(本地變量表)

  2.方法區中靜態屬性引用的物件

  3. 方法區中常量引用的物件

  4.本地方法棧中引用的物件(Native物件)

2.2tracing演算法的示意圖

2.3 標記-清除演算法分析

  標記-清除演算法採用從根集合進行掃描,對存活的物件物件標記,標記完畢後,再掃描整個空間中未被標記的物件,進行回收,如上圖所示。標記-清除演算法不需要進行物件的移動,並且僅對不存活的物件進行處理,在存活物件比較多的情況下極為高效,但由於標記-清除演算法直接回收不存活的物件,因此會造成記憶體碎片。

3.compacting演算法 或 標記-整理演算法

  標記-整理演算法採用標記-清除演算法一樣的方式進行物件的標記,但在清除時不同,在回收不存活的物件佔用的空間後,會將所有的存活物件往左端空閒空間移動,並更新對應的指標。標記-整理演算法是在標記-清除演算法的基礎上,又進行了物件的移動,因此成本更高,但是卻解決了記憶體碎片的問題。在基於Compacting演算法的收集器的實現中,一般增加控制代碼和控制代碼表。

4.copying演算法(Compacting Collector)

  該演算法的提出是為了克服控制代碼的開銷和解決堆碎片的垃圾回收。它開始時把堆分成 一個物件 面和多個空閒面, 程式從物件面為物件分配空間,當物件滿了,基於copying演算法的垃圾 收集就從根集中掃描活動物件,並將每個 活動物件複製到空閒面(使得活動物件所佔的記憶體之間沒有空閒洞),這樣空閒面變成了物件面,原來的物件面變成了空閒面,程式會在新的物件面中分配記憶體。一種典型的基於coping演算法的垃圾回收是stop-and-copy演算法,它將堆分成物件面和空閒區域面,在物件面與空閒區域面的切換過程中,程式暫停執行。

5.generation演算法(Generational Collector)

  分代的垃圾回收策略,是基於這樣一個事實:不同的物件的生命週期是不一樣的。因此,不同生命週期的物件可以採取不同的回收演算法,以便提高回收效率。

年輕代(Young Generation)

  1.所有新生成的物件首先都是放在年輕代的。年輕代的目標就是儘可能快速的收集掉那些生命週期短的物件。

  2.新生代記憶體按照8:1:1的比例分為一個eden區和兩個survivor(survivor0,survivor1)區。一個Eden區,兩個 Survivor區(一般而言)。大部分物件在Eden區中生成。回收時先將eden區存活物件複製到一個survivor0區,然後清空eden區,當這個survivor0區也存放滿了時,則將eden區和survivor0區存活物件複製到另一個survivor1區,然後清空eden和這個survivor0區,此時survivor0區是空的,然後將survivor0區和survivor1區交換,即保持survivor1區為空, 如此往復。

  3.當survivor1區不足以存放 eden和survivor0的存活物件時,就將存活物件直接存放到老年代。若是老年代也滿了就會觸發一次Full GC,也就是新生代、老年代都進行回收

  4.新生代發生的GC也叫做Minor GC,MinorGC發生頻率比較高(不一定等Eden區滿了才觸發)

年老點(Old Generation)

  1.在年輕代中經歷了N次垃圾回收後仍然存活的物件,就會被放到年老代中。因此,可以認為年老代中存放的都是一些生命週期較長的物件。

  2.記憶體比新生代也大很多(大概比例是1:2),當老年代記憶體滿時觸發Major GC即Full GC,Full GC發生頻率比較低,老年代物件存活時間比較長,存活率標記高。

持久代(Permanent Generation)

  用於存放靜態檔案,如Java類、方法等。持久代對垃圾回收沒有顯著影響,但是有些應用可能動態生成或者呼叫一些class,例如Hibernate 等,在這種時候需要設定一個比較大的持久代空間來存放這些執行過程中新增的類。

6. adaptive演算法(Adaptive Collector)  在特定的情況下,一些垃圾收集演算法會優於其它演算法。基於Adaptive演算法的垃圾收集器就是監控當前堆的使用情況,並將選擇適當演算法的垃圾收集器。

三.GC(垃圾收集器)

新生代收集器使用的收集器:Serial、PraNew、Parallel Scavenge

老年代收集器使用的收集器:Serial Old、Parallel Old、CMS

Serial收集器(複製演算法)

  新生代單執行緒收集器,標記和清理都是單執行緒,優點是簡單高效。

Serial Old收集器(標記-整理演算法)

  老年代單執行緒收集器,Serial收集器的老年代版本。

ParNew收集器(停止-複製演算法) 

  新生代收集器,可以認為是Serial收集器的多執行緒版本,在多核CPU環境下有著比Serial更好的表現。

Parallel Scavenge收集器(停止-複製演算法)

  並行收集器,追求高吞吐量,高效利用CPU。吞吐量一般為99%, 吞吐量= 使用者執行緒時間/(使用者執行緒時間+GC執行緒時間)。適合後臺應用等對互動相應要求不高的場景。

Parallel Old收集器(停止-複製演算法)

  Parallel Scavenge收集器的老年代版本,並行收集器,吞吐量優先

CMS(Concurrent Mark Sweep)收集器(標記-清理演算法)

  高併發、低停頓,追求最短GC回收停頓時間,cpu佔用比較高,響應時間快,停頓時間短,多核cpu 追求高響應時間的選擇

四、GC的執行機制

  由於物件進行了分代處理,因此垃圾回收區域、時間也不一樣。GC有兩種型別:Scavenge GC和Full GC。

Scavenge GC

一般情況下,當新物件生成,並且在Eden申請空間失敗時,就會觸發Scavenge GC,對Eden區域進行GC,清除非存活物件,並且把尚且存活的物件移動到Survivor區。然後整理Survivor的兩個區。這種方式的GC是對年輕代的Eden區進行,不會影響到年老代。因為大部分物件都是從Eden區開始的,同時Eden區不會分配的很大,所以Eden區的GC會頻繁進行。因而,一般在這裡需要使用速度快、效率高的演算法,使Eden去能儘快空閒出來。

Full GC

對整個堆進行整理,包括Young、Tenured和Perm。Full GC因為需要對整個對進行回收,所以比Scavenge GC要慢,因此應該儘可能減少Full GC的次數。在對JVM調優的過程中,很大一部分工作就是對於FullGC的調節。有如下原因可能導致Full GC:

  1.年老代(Tenured)被寫滿

  2.持久代(Perm)被寫滿

  3.System.gc()被顯示呼叫

  4.上一次GC之後Heap的各域分配策略動態變化

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接受這個訊息後,並不是立即做垃圾回收,而只是對幾個垃圾回收演算法做了加權,使垃圾回收操作容易發生,或提早發生,或回收較多而已。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()中釋放這個物件中含有的其它物件呢?不是的。因為無論物件是如何建立的,垃圾回收器都會負責釋放那些物件佔有的記憶體。

五、Java有了GC同樣會出現記憶體洩露問題

1.靜態集合類像HashMap、Vector等的使用最容易出現記憶體洩露,這些靜態變數的生命週期和應用程式一致,所有的物件Object也不能被釋放,因為他們也將一直被Vector等應用著。

Static Vector v = new Vector(); for (int i = 1; i<100; i++) {     Object o = new Object();     v.add(o);     o = null; }

在這個例子中,程式碼棧中存在Vector 物件的引用 v 和 Object 物件的引用 o 。在 For 迴圈中,我們不斷的生成新的物件,然後將其新增到 Vector 物件中,之後將 o 引用置空。問題是當 o 引用被置空後,如果發生 GC,我們建立的 Object 物件是否能夠被 GC 回收呢?答案是否定的。因為, GC 在跟蹤程式碼棧中的引用時,會發現 v 引用,而繼續往下跟蹤,就會發現 v 引用指向的記憶體空間中又存在指向 Object 物件的引用。也就是說盡管o 引用已經被置空,但是 Object 物件仍然存在其他的引用,是可以被訪問到的,所以 GC 無法將其釋放掉。如果在此迴圈之後, Object 物件對程式已經沒有任何作用,那麼我們就認為此 Java 程式發生了記憶體洩漏。

2.各種連線,資料庫連線,網路連線,IO連線等沒有顯示呼叫close關閉,不被GC回收導致記憶體洩露。

3.監聽器的使用,在釋放物件的同時沒有相應刪除監聽器的時候也可能導致記憶體洩露。

六. 減少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" + "java 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物件的建立過程。