深入理解JVM——（二）搞定JVM垃圾回收就是這麼簡單

PAce發表於2019-01-20
JVM

一、前言：JVM區域

在學習GC之前，先搞懂JVM區域。JVM分為兩大區域，deap區和非deap區，即堆與非堆。

deap區：

  • Eden Space（伊甸園）
  • Survivor Space(倖存者區)
  • Old Gen（老年代）

非deap區：

  • Code Cache(程式碼快取區)
  • Perm Gen（永久代）
  • Jvm Stack(java虛擬機器棧)
  • Local Method Statck(本地方法棧)

img

這裡我們詳細介紹一下在堆中的區域：

1.1 Eden Space

字面意思為伊甸園，當物件在堆中建立時會直接放入Eden中，當進行垃圾回收時，沒有被清除的物件會放入Survivor中。

1.2 Survivor Space

為倖存者區，存放垃圾回收時，沒有被清除的物件。注意，Survivor區具有兩個，分別為To Survivor和From Survivor，兩個區域一個為空，一個用來存放物件。

當進行垃圾回收時，會對Eden區與From Survivor區進行清理，沒有被清除的物件會複製到To Survivor中；然後Eden與From Survivor中的物件清除，From與To標記互換，這樣始終保證一個區域為空的。

1.3 新生代

Eden和Survivor都屬於新生代，新生代執行的垃圾回收被稱為Minor GC（也叫Young GC），回收速度快且頻率高，每次留下的物件age加一，為了更好的適應不同程式的記憶體情況，虛擬機器不是永遠要求物件年齡必須達到了某個值才能進入老年代，如果 Survivor 空間中相同年齡所有物件大小的總和大於 Survivor 空間的一半，年齡大於或等於該年齡的物件就可以直接進入老年代，無需達到要求的年齡。。

1.4 老年代

用於存放新生代中多次垃圾回收後依舊存活的物件，或是一些大物件會直接放入老年代，為什麼要這樣呢？為了避免為大物件分配記憶體時由於分配擔保機制帶來的複製而降低效率。在老年代中，垃圾回收的頻率比較低，當老年代被放滿的之後，虛擬機器會進行垃圾回收，稱之為Major GC。

GC名稱 介紹
Minor GC 發生在新生代，頻率高，速度快（大部分物件活不過一次Minor GC）
Major GC 發生在老年代，速度慢
Full GC 清理整個堆空間

不過實際執行中，Major GC會伴隨至少一次 Minor GC，因此也不必過多糾結於到底是哪種GC（在有些資料中看到把full GC和Minor GC等價的說法)。

二、哪些物件需要回收？

堆中幾乎放著所有的物件例項，對堆垃圾回收前的第一步就是要判斷那些物件已經死亡（即不能再被任何途徑使用的物件），即需要被回收。

img

2.1 引用計數法

給物件中新增一個引用計數器，每當有一個地方引用它，計數器就加1；當引用失效，計數器就減1；任何時候計數器為0的物件就是不可能再被使用的。

這個方法實現簡單，效率高，但是目前主流的虛擬機器中並沒有選擇這個演算法來管理記憶體，其最主要的原因是它很難解決物件之間相互迴圈引用的問題。 所謂物件之間的相互引用問題，如下面程式碼所示：除了物件objA 和 objB 相互引用著對方之外，這兩個物件之間再無任何引用。但是他們因為互相引用對方，導致它們的引用計數器都不為0，於是引用計數演算法無法通知 GC 回收器回收他們。

public class ReferenceCountingGc {
    Object instance = null;
	public static void main(String[] args) {
		ReferenceCountingGc objA = new ReferenceCountingGc();
		ReferenceCountingGc objB = new ReferenceCountingGc();
		objA.instance = objB;
		objB.instance = objA;
		objA = null;
		objB = null;

	}
}
複製程式碼

2.2 可達性分析法

這個演算法的基本思想就是通過一系列的稱為 “GC Roots” 的物件作為起點，從這些節點開始向下搜尋，節點所走過的路徑稱為引用鏈，當一個物件到 GC Roots 沒有任何引用鏈相連的話，則證明此物件是不可用的。

可達性分析演算法

2.3 四種引用狀態

無論是通過引用計數法判斷物件引用數量，還是通過可達性分析法判斷物件的引用鏈是否可達，判定物件的存活都與“引用”有關。

JDK1.2之前，Java中引用的定義很傳統：如果reference型別的資料儲存的數值代表的是另一塊記憶體的起始地址，就稱這塊記憶體代表一個引用。

JDK1.2以後，Java對引用的概念進行了擴充，將引用分為強引用、軟引用、弱引用、虛引用四種（引用強度逐漸減弱）

1. 強引用

以前我們使用的大部分引用實際上都是強引用，這是使用最普遍的引用。如果一個物件具有強引用，那就類似於必不可少的生活用品，垃圾回收器絕不會回收它。當記憶體空間不足，Java虛擬機器寧願丟擲OutOfMemoryError錯誤，使程式異常終止，也不會靠隨意回收具有強引用的物件來解決記憶體不足問題。

2. 軟引用

如果一個物件只具有軟引用，那就類似於可有可無的生活用品。如果記憶體空間足夠，垃圾回收器就不會回收它，如果記憶體空間不足了，就會回收這些物件的記憶體。只要垃圾回收器沒有回收它，該物件就可以被程式使用。軟引用可用來實現記憶體敏感的快取記憶體。

軟引用可以和一個引用佇列（ReferenceQueue）聯合使用，如果軟引用所引用的物件被垃圾回收，JAVA虛擬機器就會把這個軟引用加入到與之關聯的引用佇列中。

3. 弱引用

如果一個物件只具有弱引用，那就類似於可有可無的生活用品。弱引用與軟引用的區別在於：只具有弱引用的物件擁有更短暫的生命週期。在垃圾回收器執行緒掃描它所管轄的記憶體區域的過程中，一旦發現了只具有弱引用的物件，不管當前記憶體空間足夠與否，都會回收它的記憶體。不過，由於垃圾回收器是一個優先順序很低的執行緒， 因此不一定會很快發現那些只具有弱引用的物件。

弱引用可以和一個引用佇列（ReferenceQueue）聯合使用，如果弱引用所引用的物件被垃圾回收，Java虛擬機器就會把這個弱引用加入到與之關聯的引用佇列中。

4. 虛引用

"虛引用"顧名思義，就是形同虛設，與其他幾種引用都不同，虛引用並不會決定物件的生命週期。如果一個物件僅持有虛引用，那麼它就和沒有任何引用一樣，在任何時候都可能被垃圾回收。

深入理解JAVA虛擬機器一書中有這樣一句描述：“為一個物件設定虛引用關聯的唯一目的就是能在這個物件被收集器回收時收到一個系統通知”。所以虛引用更多的是用於物件回收的監聽，能做的功能如下：

  1. 重要物件回收監聽 進行日誌統計
  2. 系統gc監聽 因為虛引用每次GC都會被回收，那麼我們就可以通過虛引用來判斷gc的頻率，如果頻率過大，記憶體使用可能存在問題，才導致了系統gc頻繁呼叫

特別注意，在程式設計中一般很少使用弱引用與虛引用，使用軟引用的情況較多，這是因為軟引用可以加速JVM對垃圾記憶體的回收速度，可以維護系統的執行安全，防止記憶體溢位（OutOfMemory）等問題的產生。

2.4 不可達的物件並非“非死不可”

對於可達性分析演算法而言，未到達的物件並非是“非死不可”的，若要宣判一個物件死亡，至少需要經歷兩次標記階段。

1.如果物件在進行可達性分析後發現沒有與GCRoots相連的引用鏈，則該物件被第一次標記並進行一次篩選，篩選條件為是否有必要執行該物件的finalize方法，若物件沒有覆蓋finalize方法或者該finalize方法是否已經被虛擬機器執行過了，則均視作不必要執行該物件的finalize方法，即該物件將會被回收。反之，若物件覆蓋了finalize方法並且該finalize方法並沒有被執行過，那麼，這個物件會被放置在一個叫F-Queue的佇列中，之後會由虛擬機器自動建立的、優先順序低的Finalizer執行緒去執行，而虛擬機器不必要等待該執行緒執行結束，即虛擬機器只負責建立執行緒，其他的事情交給此執行緒去處理。

2.對F-Queue中物件進行第二次標記，如果物件在finalize方法中拯救了自己，即關聯上了GCRoots引用鏈，如把this關鍵字賦值給其他變數，那麼在第二次標記的時候該物件將從“即將回收”的集合中移除，如果物件還是沒有拯救自己，那就會被回收。如下程式碼演示了一個物件如何在finalize方法中拯救了自己，然而，它只能拯救自己一次，第二次就被回收了。具體程式碼如下：

package com.demo;

/*
 * 此程式碼演示了兩點：
 * 1.物件可以再被GC時自我拯救
 * 2.這種自救的機會只有一次，因為一個物件的finalize()方法最多隻會被系統自動呼叫一次
 * */
public class FinalizeEscapeGC {
    
    public String name;
    public static FinalizeEscapeGC SAVE_HOOK = null;

    public FinalizeEscapeGC(String name) {
        this.name = name;
    }

    public void isAlive() {
        System.out.println("yes, i am still alive :)");
    }
    
    @Override
    protected void finalize() throws Throwable {
        super.finalize();
        System.out.println("finalize method executed!");
        System.out.println(this);
        FinalizeEscapeGC.SAVE_HOOK = this;
    }

    @Override
    public String toString() {
        return name;
    }

    public static void main(String[] args) throws InterruptedException {
        SAVE_HOOK = new FinalizeEscapeGC("leesf");
        System.out.println(SAVE_HOOK);
        // 物件第一次拯救自己
        SAVE_HOOK = null;
        System.out.println(SAVE_HOOK);
        System.gc();
        // 因為finalize方法優先順序很低，所以暫停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead : (");
        }

        // 下面這段程式碼與上面的完全相同,但是這一次自救卻失敗了
        // 一個物件的finalize方法只會被呼叫一次
        SAVE_HOOK = null;
        System.gc();
        // 因為finalize方法優先順序很低，所以暫停0.5秒以等待它
        Thread.sleep(500);
        if (SAVE_HOOK != null) {
            SAVE_HOOK.isAlive();
        } else {
            System.out.println("no, i am dead : (");
        }
    }
}
複製程式碼

執行結果如下：

leesf
null
finalize method executed!
leesf
yes, i am still alive :)
no, i am dead : (
複製程式碼

  由結果可知，該物件拯救了自己一次，第二次沒有拯救成功，因為物件的finalize方法最多被虛擬機器呼叫一次。此外，從結果我們可以得知，一個堆物件的this（放在區域性變數表中的第一項）引用會永遠存在，在方法體內可以將this引用賦值給其他變數，這樣堆中物件就可以被其他變數所引用，即不會被回收。

2.5 方法區的垃圾回收

方法區的垃圾回收主要回收兩部分內容：1. 廢棄常量。2. 無用的類。既然進行垃圾回收，就需要判斷哪些是廢棄常量，哪些是無用的類。

1. 廢棄常量：

執行時常量池主要回收的是廢棄的常量。那麼，我們如何判斷一個常量是廢棄常量呢？

假如在常量池中存在字串 "abc"，如果當前沒有任何String物件引用該字串常量的話，就說明常量 "abc" 就是廢棄常量，如果這時發生記憶體回收的話而且有必要的話，"abc" 就會被系統清理出常量池。

2. 無用的類

如何判斷無用的類呢？需要滿足以下三個條件

1. 該類的所有例項都已經被回收，即Java堆中不存在該類的任何例項。

2. 載入該類的ClassLoader已經被回收。

3. 該類對應的java.lang.Class物件沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

滿足以上三個條件的類可以進行垃圾回收，但是並不是無用就被回收，虛擬機器提供了一些引數供我們配置。

三、垃圾回收演算法

3.1 標記-清除演算法

這是最基礎的演算法，標記-清除演算法就如同它的名字樣，分為“標記”和“清除”兩個階段：首先標記出所有需要回收的物件，標記完成後統一回收所有被標記的物件。

這種演算法的不足主要體現在效率和空間：

  • 從效率的角度：標記和清除兩個過程的效率都不高
  • 從空間的角度：標記清除後會產生大量不連續的記憶體碎片， 記憶體碎片太多可能會導致以後程式執行過程中在需要分配較大物件時，無法找到足夠的連續記憶體而不得不提前觸發一次垃圾收集動作

img

3.2 複製演算法

複製演算法是為了解決效率問題而出現的，它將可用的記憶體分為兩塊，每次只用其中一塊，當這一塊記憶體用完了，就將還存活著的物件複製到另外一塊上面，然後再把已經使用過的記憶體空間一次性清理掉。這樣每次只需要對整個半區進行記憶體回收，記憶體分配時也不需要考慮記憶體碎片等複雜情況，只需要移動指標，按照順序分配即可。

img

不過這種演算法有個缺點，記憶體縮小為了原來的一半，這樣代價太高了。現在的商用虛擬機器都採用這種演算法來回收新生代，不過研究表明1:1的比例非常不科學，因此新生代的記憶體被劃分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor。每次回收時，將Eden和Survivor中還存活著的物件一次性複製到另外一塊Survivor空間上，最後清理掉Eden和剛才用過的Survivor空間。HotSpot虛擬機器預設Eden區和Survivor區的比例為8:1，意思是每次新生代中可用記憶體空間為整個新生代容量的90%。當然，我們沒有辦法保證每次回收都只有不多於10%的物件存活，當Survivor空間不夠用時，需要依賴老年代進行分配擔保（Handle Promotion）。

3.3 標記-整理演算法

複製演算法在物件存活率較高的場景下要進行大量的複製操作，效率很低。萬一物件100%存活，那麼需要有額外的空間進行分配擔保。老年代都是不易被回收的物件，物件存活率高，因此一般不能直接選用複製演算法。根據老年代的特點，有人提出了另外一種標記-整理演算法，過程與標記-清除演算法一樣，不過不是直接對可回收物件進行清理，而是讓所有存活物件都向一端移動，然後直接清理掉邊界以外的記憶體。

img

3.4 分代回收演算法

根據上面的內容，用一張圖概括一下堆記憶體的佈局

img

​ 現代商用虛擬機器基本都採用分代收集演算法來進行垃圾回收。這種演算法沒什麼特別的，無非是上面內容的結合罷了，根據物件的生命週期的不同將記憶體劃分為幾塊，然後根據各塊的特點採用最適當的收集演算法。大批物件死去、少量物件存活的（新生代），使用複製演算法，複製成本低；物件存活率高、沒有額外空間進行分配擔保的（老年代），採用標記-清理演算法或者標記-整理演算法。

四、垃圾回收器

垃圾收集器就是上面講的理論知識的具體實現了。不同虛擬機器所提供的垃圾收集器可能會有很大差別，我們使用的是HotSpot，HotSpot這個虛擬機器所包含的所有收集器如圖：

img

上圖展示了7種作用於不同分代的收集器，如果兩個收集器之間存在連線，那說明它們可以搭配使用。虛擬機器所處的區域說明它是屬於新生代收集器還是老年代收集器。

我們必須明確一個觀點：沒有最好的垃圾收集器，更加沒有萬能的收集器，只能選擇對具體應用最合適的收集器。這也是HotSpot為什麼要實現這麼多收集器的原因。OK，下面一個一個看一下收集器。

4.1 Serial收集器

最基本、發展歷史最久的收集器，這個收集器是一個採用複製演算法的單執行緒的收集器，單執行緒一方面意味著它只會使用一個CPU或一條執行緒去完成垃圾收集工作，另一方面也意味著它進行垃圾收集時必須暫停其他執行緒的所有工作，直到它收集結束為止。後者意味著，在使用者不可見的情況下要把使用者正常工作的執行緒全部停掉，這對很多應用是難以接受的。

新生代採用複製演算法，老年代採用標記-整理演算法。

不過實際上到目前為止，Serial收集器依然是虛擬機器執行在Client模式下的預設新生代收集器，因為它簡單而高效。使用者桌面應用場景中，分配給虛擬機器管理的記憶體一般來說不會很大，收集幾十兆甚至一兩百兆的新生代停頓時間在幾十毫秒最多一百毫秒，只要不是頻繁發生，這點停頓是完全可以接受的。

img

特點：

  • 需要STW（Stop The World），停頓時間長
  • 簡單高效，對於單個CPU環境而言，Serial收集器由於沒有執行緒互動開銷，可以獲取最高的單執行緒收集效率。

4.2 ParNew收集器

ParNew收集器其實就是Serial收集器的多執行緒版本，除了使用多條執行緒進行垃圾收集外，其餘行為和Serial收集器完全一樣，包括使用的也是複製演算法。ParNew收集器除了多執行緒以外和Serial收集器並沒有太多創新的地方，但是它卻是Server模式下的虛擬機器首選的新生代收集器，其中有一個很重要的和效能無關的原因是，除了Serial收集器外，目前只有它能與CMS收集器配合工作（看圖）。

新生代採用複製演算法，老年代採用標記-整理演算法。

ParNew收集器在單CPU的環境中絕對不會有比Serial收集器更好的效果，甚至由於執行緒互動的開銷，該收集器在兩個CPU的環境中都不能百分之百保證可以超越Serial收集器。當然，隨著可用CPU數量的增加，它對於GC時系統資源的有效利用還是很有好處的。它預設開啟的收集執行緒數與CPU數量相同，在CPU數量非常多的情況下，可以使用-XX:ParallelGCThreads引數來限制垃圾收集的執行緒數。

img

4.3 Parallel Scavenge收集器

Parallel Scavenge 收集器類似於ParNew 收集器。 那麼它有什麼特別之處呢？

-XX:+UseParallelGC 

    使用Parallel收集器+ 老年代序列

-XX:+UseParallelOldGC

    使用Parallel收集器+ 老年代並行
複製程式碼

Parallel Scavenge收集器關注點是吞吐量（高效率的利用CPU）。CMS等垃圾收集器的關注點更多的是使用者執行緒的停頓時間（提高使用者體驗）。所謂吞吐量就是CPU中用於執行使用者程式碼的時間與CPU總消耗時間的比值。 Parallel Scavenge收集器提供了很多引數供使用者找到最合適的停頓時間或最大吞吐量，如果對於收集器運作不太瞭解的話，手工優化存在的話可以選擇把記憶體管理優化交給虛擬機器去完成也是一個不錯的選擇。

新生代採用複製演算法，老年代採用標記-整理演算法。

4.4.Serial Old收集器

Serial收集器的老年代版本，同樣是一個單執行緒收集器，使用“標記-整理演算法”，這個收集器的主要意義也是在於給Client模式下的虛擬機器使用。

4.5 Parallel Old收集器

Parallel Scavenge收集器的老年代版本。使用多執行緒和“標記-整理”演算法。在注重吞吐量以及CPU資源的場合，都可以優先考慮 Parallel Scavenge收集器和Parallel Old收集器。

img

4.6 CMS收集器（重點）

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。它而非常符合在注重使用者體驗的應用上使用。

CMS收集器是HotSpot虛擬機器第一款真正意義上的併發收集器，它第一次實現了讓垃圾收集執行緒與使用者執行緒（基本上）同時工作。

從名字中的Mark Sweep這兩個詞可以看出，CMS收集器是一種 “標記-清除”演算法實現的，它的運作過程相比於前面幾種垃圾收集器來說更加複雜一些。整個過程分為四個步驟：

  • 初始標記： 暫停所有的其他執行緒，並記錄下直接與root相連的物件，速度很快
  • 併發標記： 同時開啟GC和使用者執行緒，用一個閉包結構去記錄可達物件。但在這個階段結束，這個閉包結構並不能保證包含當前所有的可達物件。因為使用者執行緒可能會不斷的更新引用域，所以GC執行緒無法保證可達性分析的實時性。所以這個演算法裡會跟蹤記錄這些發生引用更新的地方。時間很長
  • 重新標記： 重新標記階段就是為了修正併發標記期間因為使用者程式繼續執行而導致標記產生變動的那一部分物件的標記記錄，這個階段的停頓時間一般會比初始標記階段的時間稍長，遠遠比並發標記階段時間短
  • 併發清除： 開啟使用者執行緒，同時GC執行緒開始對為標記的區域做清掃。時間很長

其中，併發標記與併發清除兩個階段耗時最長，但是可以與使用者執行緒併發執行。執行過程如下圖所示:

img

從它的名字就可以看出它是一款優秀的垃圾收集器，主要優點：併發收集、低停頓。但是它有下面三個明顯的缺點：

  • 對CPU資源敏感；
  • 無法處理浮動垃圾；
  • 它使用的回收演算法-“標記-清除”演算法會導致收集結束時會有大量空間碎片產生。

4.7 G1收集器（重點）

G1 (Garbage-First)是一款面向伺服器的垃圾收集器,主要針對配備多顆處理器及大容量記憶體的機器. 以極高概率滿足GC停頓時間要求的同時,還具備高吞吐量效能特徵.

被視為JDK1.7中HotSpot虛擬機器的一個重要進化特徵。它具備一下特點：

  • 並行與併發：G1能充分利用CPU、多核環境下的硬體優勢，使用多個CPU（CPU或者CPU核心）來縮短Stop-The-World停頓時間。部分其他收集器原本需要停頓Java執行緒執行的GC動作，G1收集器仍然可以通過併發的方式讓java程式繼續執行。
  • 分代收集：雖然G1可以不需要其他收集器配合就能獨立管理整個GC堆，但是還是保留了分代的概念。
  • 空間整合：與CMS的“標記--清理”演算法不同，G1從整體來看是基於“標記整理”演算法實現的收集器；從區域性上來看是基於“複製”演算法實現的。
  • 可預測的停頓：這是G1相對於CMS的另一個大優勢，降低停頓時間是G1 和 CMS 共同的關注點，但G1 除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度為M毫秒的時間片段內。

G1收集器的運作大致分為以下幾個步驟：

  • 初始標記
  • 併發標記
  • 最終標記
  • 篩選回收

G1收集器在後臺維護了一個優先列表，每次根據允許的收集時間，優先選擇回收價值最大的Region(這也就是它的名字Garbage-First的由來)。這種使用Region劃分記憶體空間以及有優先順序的區域回收方式，保證了GF收集器在有限時間內可以儘可能高的收集效率（把記憶體化整為零）。

五、面試題思考

本節常見面試題：

問題答案在文中都有提到

  • 如何判斷物件是否死亡（兩種方法）。
  • 簡單的介紹一下強引用、軟引用、弱引用、虛引用（虛引用與軟引用和弱引用的區別、使用軟引用能帶來的好處）。
  • 如何判斷一個常量是廢棄常量
  • 如何判斷一個類是無用的類
  • 垃圾收集有哪些演算法，各自的特點？
  • HotSpot為什麼要分為新生代和老年代？
  • 常見的垃圾回收器有那些？
  • 介紹一下CMS,G1收集器。
  • Minor Gc和Full GC 有什麼不同呢？

相關文章