深入理解JVM——（二）搞定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(本地方法棧)

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

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等價的說法)。

二、哪些對象需要回收？

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

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虛擬機一書中有這樣一句描述：“爲一個對象設置虛引用關聯的唯一目的就是能在這個對象被收集器回收時收到一個系統通知”。所以虛引用更多的是用於對象回收的監聽，能做的功能如下：

重要對象回收監聽進行日誌統計
系統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 標記-清除算法

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

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

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

3.2 複製算法

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

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

3.3 標記-整理算法

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

3.4 分代回收算法

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

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

四、垃圾回收器

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

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

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

4.1 Serial收集器

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

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

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

特點：

需要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參數來限制垃圾收集的線程數。

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收集器。

4.6 CMS收集器（重點）

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

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

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

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

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

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

對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 有什麼不同呢？

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

文章目錄

一、前言：JVM區域

1.1 Eden Space

1.2 Survivor Space

1.3 新生代

1.4 老年代

二、哪些對象需要回收？

2.1 引用計數法

2.2 可達性分析法

2.3 四種引用狀態

1. 強引用

2. 軟引用

3. 弱引用

4. 虛引用

2.4 不可達的對象並非“非死不可”

2.5 方法區的垃圾回收

1. 廢棄常量：

2. 無用的類

三、垃圾回收算法

3.1 標記-清除算法

3.2 複製算法

3.3 標記-整理算法

3.4 分代回收算法

四、垃圾回收器

4.1 Serial收集器

4.2 ParNew收集器

4.3 Parallel Scavenge收集器

4.4.Serial Old收集器

4.5 Parallel Old收集器

4.6 CMS收集器（重點）

4.7 G1收集器（重點）

五、面試題思考

本節常見面試題：