深入理解JVM虛擬機2：JVM垃圾回收基本原理和算法

本文轉自互聯網，侵刪

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裏查看

https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章將同步到我的個人博客：

www.how2playlife.com

本文是微信公衆號【Java技術江湖】的《深入理解JVM虛擬機》其中一篇，本文部分內容來源於網絡，爲了把本文主題講得清晰透徹，也整合了很多我認爲不錯的技術博客內容，引用其中了一些比較好的博客文章，如有侵權，請聯繫作者。

該系列博文會告訴你如何從入門到進階，一步步地學習JVM基礎知識，並上手進行JVM調優實戰，JVM是每一個Java工程師必須要學習和理解的知識點，你必須要掌握其實現原理，才能更完整地瞭解整個Java技術體系，形成自己的知識框架。

爲了更好地總結和檢驗你的學習成果，本系列文章也會提供每個知識點對應的面試題以及參考答案。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公衆號【Java技術江湖】聯繫作者，歡迎你參與本系列博文的創作和修訂。

JVM GC基本原理與GC算法

Java的內存分配與回收全部由JVM垃圾回收進程自動完成。與C語言不同，Java開發者不需要自己編寫代碼實現垃圾回收。這是Java深受大家歡迎的衆多特性之一，能夠幫助程序員更好地編寫Java程序。

下面四篇教程是瞭解Java 垃圾回收（GC）的基礎：

這篇教程是系列第一部分。首先會解釋基本的術語，比如JDK、JVM、JRE和HotSpotVM。接着會介紹JVM結構和Java 堆內存結構。理解這些基礎對於理解後面的垃圾回收知識很重要。

Java關鍵術語

JavaAPI：一系列幫助開發者創建Java應用程序的封裝好的庫。
Java 開發工具包（JDK）：一系列工具幫助開發者創建Java應用程序。JDK包含工具編譯、運行、打包、分發和監視Java應用程序。
Java 虛擬機（JVM）：JVM是一個抽象的計算機結構。Java程序根據JVM的特性編寫。JVM針對特定於操作系統並且可以將Java指令翻譯成底層系統的指令並執行。JVM確保了Java的平臺無關性。
Java 運行環境（JRE）：JRE包含JVM實現和Java API。

Java HotSpot 虛擬機

每種JVM實現可能採用不同的方法實現垃圾回收機制。在收購SUN之前，Oracle使用的是JRockit JVM，收購之後使用HotSpot JVM。目前Oracle擁有兩種JVM實現並且一段時間後兩個JVM實現會合二爲一。

HotSpot JVM是目前Oracle SE平臺標準核心組件的一部分。在這篇垃圾回收教程中，我們將會了解基於HotSpot虛擬機的垃圾回收原則。

Java堆內存

我們有必要了解堆內存在JVM內存模型的角色。在運行時，Java的實例被存放在堆內存區域。當一個對象不再被引用時，滿足條件就會從堆內存移除。在垃圾回收進程中，這些對象將會從堆內存移除並且內存空間被回收。堆內存以下三個主要區域：

新生代（Young Generation）
- Eden空間（Eden space，任何實例都通過Eden空間進入運行時內存區域）
- S0 Survivor空間（S0 Survivor space，存在時間長的實例將會從Eden空間移動到S0 Survivor空間）
- S1 Survivor空間（存在時間更長的實例將會從S0 Survivor空間移動到S1 Survivor空間）
老年代（Old Generation）實例將從S1提升到Tenured（終身代）
永久代（Permanent Generation）包含類、方法等細節的元信息

永久代空間在Java SE8特性中已經被移除。

Java 垃圾回收是一項自動化的過程，用來管理程序所使用的運行時內存。通過這一自動化過程，JVM 解除了程序員在程序中分配和釋放內存資源的開銷。

啓動Java垃圾回收

作爲一個自動的過程，程序員不需要在代碼中顯示地啓動垃圾回收過程。System.gc()和Runtime.gc()用來請求JVM啓動垃圾回收。

雖然這個請求機制提供給程序員一個啓動 GC 過程的機會，但是啓動由 JVM負責。JVM可以拒絕這個請求，所以並不保證這些調用都將執行垃圾回收。啓動時機的選擇由JVM決定，並且取決於堆內存中Eden區是否可用。JVM將這個選擇留給了Java規範的實現，不同實現具體使用的算法不盡相同。

毋庸置疑，我們知道垃圾回收過程是不能被強制執行的。我剛剛發現了一個調用System.gc()有意義的場景。通過這篇文章瞭解一下適合調用System.gc() 這種極端情況。

各種GC的觸發時機(When)

GC類型

說到GC類型，就更有意思了，爲什麼呢，因爲業界沒有統一的嚴格意義上的界限，也沒有嚴格意義上的GC類型，都是左邊一個教授一套名字，右邊一個作者一套名字。爲什麼會有這個情況呢，因爲GC類型是和收集器有關的，不同的收集器會有自己獨特的一些收集類型。所以作者在這裏引用R大關於GC類型的介紹，作者覺得還是比較妥當準確的。如下:

Partial GC：並不收集整個GC堆的模式
- Young GC(Minor GC)：只收集young gen的GC
- Old GC：只收集old gen的GC。只有CMS的concurrent collection是這個模式
- Mixed GC：收集整個young gen以及部分old gen的GC。只有G1有這個模式
Full GC(Major GC)：收集整個堆，包括young gen、old gen、perm gen（如果存在的話）等所有部分的模式。

觸發時機

上面大家也看到了，GC類型分分類是和收集器有關的，那麼當然了，對於不同的收集器，GC觸發時機也是不一樣的，作者就針對默認的serial GC來說:

young GC：當young gen中的eden區分配滿的時候觸發。注意young GC中有部分存活對象會晉升到old gen，所以young GC後old gen的佔用量通常會有所升高。
full GC：當準備要觸發一次young GC時，如果發現統計數據說之前young GC的平均晉升大小比目前old gen剩餘的空間大，則不會觸發young GC而是轉爲觸發full GC（因爲HotSpot VM的GC裏，除了CMS的concurrent collection之外，其它能收集old gen的GC都會同時收集整個GC堆，包括young gen，所以不需要事先觸發一次單獨的young GC）；或者，如果有perm gen的話，要在perm gen分配空間但已經沒有足夠空間時，也要觸發一次full GC；或者System.gc()、heap dump帶GC，默認也是觸發full GC。

FULL GC觸發條件詳解

除直接調用System.gc外，觸發Full GC執行的情況有如下四種。

1. 舊生代空間不足

舊生代空間只有在新生代對象轉入及創建爲大對象、大數組時纔會出現不足的現象，當執行Full GC後空間仍然不足，則拋出如下錯誤：

java.lang.OutOfMemoryError: Java heap space

爲避免以上兩種狀況引起的Full GC，調優時應儘量做到讓對象在Minor GC階段被回收、讓對象在新生代多存活一段時間及不要創建過大的對象及數組。

2. Permanet Generation空間滿

Permanet Generation中存放的爲一些class的信息等，當系統中要加載的類、反射的類和調用的方法較多時，Permanet Generation可能會被佔滿，在未配置爲採用CMS GC的情況下會執行Full GC。如果經過Full GC仍然回收不了，那麼JVM會拋出如下錯誤信息：

java.lang.OutOfMemoryError: PermGen space

爲避免Perm Gen佔滿造成Full GC現象，可採用的方法爲增大Perm Gen空間或轉爲使用CMS GC。

3. CMS GC時出現promotion failed和concurrent mode failure

對於採用CMS進行舊生代GC的程序而言，尤其要注意GC日誌中是否有promotion failed和concurrent mode failure兩種狀況，當這兩種狀況出現時可能會觸發Full GC。

promotion failed是在進行Minor GC時，survivor space放不下、對象只能放入舊生代，而此時舊生代也放不下造成的；concurrent mode failure是在執行CMS GC的過程中同時有對象要放入舊生代，而此時舊生代空間不足造成的。

應對措施爲：增大survivor space、舊生代空間或調低觸發併發GC的比率，但在JDK 5.0+、6.0+的版本中有可能會由於JDK的bug29導致CMS在remark完畢後很久才觸發sweeping動作。對於這種狀況，可通過設置-XX: CMSMaxAbortablePrecleanTime=5（單位爲ms）來避免。

4. 統計得到的Minor GC晉升到舊生代的平均大小大於舊生代的剩餘空間

這是一個較爲複雜的觸發情況，Hotspot爲了避免由於新生代對象晉升到舊生代導致舊生代空間不足的現象，在進行Minor GC時，做了一個判斷，如果之前統計所得到的Minor GC晉升到舊生代的平均大小大於舊生代的剩餘空間，那麼就直接觸發Full GC。

例如程序第一次觸發Minor GC後，有6MB的對象晉升到舊生代，那麼當下一次Minor GC發生時，首先檢查舊生代的剩餘空間是否大於6MB，如果小於6MB，則執行Full GC。

當新生代採用PS GC時，方式稍有不同，PS GC是在Minor GC後也會檢查，例如上面的例子中第一次Minor GC後，PS GC會檢查此時舊生代的剩餘空間是否大於6MB，如小於，則觸發對舊生代的回收。

除了以上4種狀況外，對於使用RMI來進行RPC或管理的Sun JDK應用而言，默認情況下會一小時執行一次Full GC。可通過在啓動時通過- java -Dsun.rmi.dgc.client.gcInterval=3600000來設置Full GC執行的間隔時間或通過-XX:+ DisableExplicitGC來禁止RMI調用System.gc。

總結

Minor GC ，Full GC 觸發條件

Minor GC觸發條件：當Eden區滿時，觸發Minor GC。

Full GC觸發條件：

（1）調用System.gc時，系統建議執行Full GC，但是不必然執行

（2）老年代空間不足

（3）方法去空間不足

（4）通過Minor GC後進入老年代的平均大小大於老年代的可用內存

（5）由Eden區、From Space區向To Space區複製時，對象大小大於To Space可用內存，則把該對象轉存到老年代，且老年代的可用內存小於該對象大小

什麼是Stop the world

Java中Stop-The-World機制簡稱STW，是在執行垃圾收集算法時，Java應用程序的其他所有線程都被掛起（除了垃圾收集幫助器之外）。Java中一種全局暫停現象，全局停頓，所有Java代碼停止，native代碼可以執行，但不能與JVM交互；這些現象多半是由於gc引起。

GC時的Stop the World(STW)是大家最大的敵人。但可能很多人還不清楚，除了GC，JVM下還會發生停頓現象。

JVM裏有一條特殊的線程－－VM Threads，專門用來執行一些特殊的VM Operation，比如分派GC，thread dump等，這些任務，都需要整個Heap，以及所有線程的狀態是靜止的，一致的才能進行。所以JVM引入了安全點(Safe Point)的概念，想辦法在需要進行VM Operation時，通知所有的線程進入一個靜止的安全點。

除了GC，其他觸發安全點的VM Operation包括：

1. JIT相關，比如Code deoptimization, Flushing code cache ；

2. Class redefinition (e.g. javaagent，AOP代碼植入的產生的instrumentation) ；

3. Biased lock revocation 取消偏向鎖；

4. Various debug operation (e.g. thread dump or deadlock check)；

Java垃圾回收過程

垃圾回收是一種回收無用內存空間並使其對未來實例可用的過程。

Eden 區：當一個實例被創建了，首先會被存儲在堆內存年輕代的 Eden 區中。

注意：如果你不能理解這些詞彙，我建議你閱讀這篇垃圾回收介紹，這篇教程詳細地介紹了內存模型、JVM 架構以及這些術語。

Survivor 區（S0 和 S1）：作爲年輕代 GC（Minor GC）週期的一部分，存活的對象（仍然被引用的）從 Eden 區被移動到 Survivor 區的 S0 中。類似的，垃圾回收器會掃描 S0 然後將存活的實例移動到 S1 中。

（譯註：此處不應該是Eden和S0中存活的都移到S1麼，爲什麼會先移到S0再從S0移到S1？）

死亡的實例（不再被引用）被標記爲垃圾回收。根據垃圾回收器（有四種常用的垃圾回收器，將在下一教程中介紹它們）選擇的不同，要麼被標記的實例都會不停地從內存中移除，要麼回收過程會在一個單獨的進程中完成。

老年代：老年代（Old or tenured generation）是堆內存中的第二塊邏輯區。當垃圾回收器執行 Minor GC 週期時，在 S1 Survivor 區中的存活實例將會被晉升到老年代，而未被引用的對象被標記爲回收。

老年代 GC（Major GC）：相對於 Java 垃圾回收過程，老年代是實例生命週期的最後階段。Major GC 掃描老年代的垃圾回收過程。如果實例不再被引用，那麼它們會被標記爲回收，否則它們會繼續留在老年代中。

內存碎片：一旦實例從堆內存中被刪除，其位置就會變空並且可用於未來實例的分配。這些空出的空間將會使整個內存區域碎片化。爲了實例的快速分配，需要進行碎片整理。基於垃圾回收器的不同選擇，回收的內存區域要麼被不停地被整理，要麼在一個單獨的GC進程中完成。

垃圾回收中實例的終結

在釋放一個實例和回收內存空間之前，Java 垃圾回收器會調用實例各自的 finalize() 方法，從而該實例有機會釋放所持有的資源。雖然可以保證 finalize() 會在回收內存空間之前被調用，但是沒有指定的順序和時間。多個實例間的順序是無法被預知，甚至可能會並行發生。程序不應該預先調整實例之間的順序並使用 finalize() 方法回收資源。

任何在 finalize過程中未被捕獲的異常會自動被忽略，然後該實例的 finalize 過程被取消。
JVM 規範中並沒有討論關於弱引用的垃圾回收機制，也沒有很明確的要求。具體的實現都由實現方決定。
垃圾回收是由一個守護線程完成的。

對象什麼時候符合垃圾回收的條件？

所有實例都沒有活動線程訪問。
沒有被其他任何實例訪問的循環引用實例。

Java 中有不同的引用類型。判斷實例是否符合垃圾收集的條件都依賴於它的引用類型。

引用類型	垃圾收集
強引用（Strong Reference）	不符合垃圾收集
軟引用（Soft Reference）	垃圾收集可能會執行，但會作爲最後的選擇
弱引用（Weak Reference）	符合垃圾收集
虛引用（Phantom Reference）	符合垃圾收集

在編譯過程中作爲一種優化技術，Java 編譯器能選擇給實例賦 null 值，從而標記實例爲可回收。

class Animal {

    public static void main(String[] args) {

        Animal lion = new Animal();

        System.out.println("Main is completed.");

    }

    protected void finalize() {

        System.out.println("Rest in Peace!");

    }

}

在上面的類中，lion 對象在實例化行後從未被使用過。因此 Java 編譯器作爲一種優化措施可以直接在實例化行後賦值lion = null。因此，即使在 SOP 輸出之前， finalize 函數也能夠打印出 'Rest in Peace!'。我們不能證明這確定會發生，因爲它依賴JVM的實現方式和運行時使用的內存。然而，我們還能學習到一點：如果編譯器看到該實例在未來再也不會被引用，能夠選擇並提早釋放實例空間。

關於對象什麼時候符合垃圾回收有一個更好的例子。實例的所有屬性能被存儲在寄存器中，隨後寄存器將被訪問並讀取內容。無一例外，這些值將被寫回到實例中。雖然這些值在將來能被使用，這個實例仍然能被標記爲符合垃圾回收。這是一個很經典的例子，不是嗎？
當被賦值爲null時，這是很簡單的一個符合垃圾回收的示例。當然，複雜的情況可以像上面的幾點。這是由 JVM 實現者所做的選擇。目的是留下儘可能小的內存佔用，加快響應速度，提高吞吐量。爲了實現這一目標， JVM 的實現者可以選擇一個更好的方案或算法在垃圾回收過程中回收內存空間。
當 finalize() 方法被調用時，JVM 會釋放該線程上的所有同步鎖。

GC Scope 示例程序

Class GCScope {

    GCScope t;

    static int i = 1;

    public static void main(String args[]) {

        GCScope t1 = new GCScope();

        GCScope t2 = new GCScope();

        GCScope t3 = new GCScope();

        // No Object Is Eligible for GC

        t1.t = t2; // No Object Is Eligible for GC

        t2.t = t3; // No Object Is Eligible for GC

        t3.t = t1; // No Object Is Eligible for GC

        t1 = null;

        // No Object Is Eligible for GC (t3.t still has a reference to t1)

        t2 = null;

        // No Object Is Eligible for GC (t3.t.t still has a reference to t2)

        t3 = null;

        // All the 3 Object Is Eligible for GC (None of them have a reference.

        // only the variable t of the objects are referring each other in a

        // rounded fashion forming the Island of objects with out any external

        // reference)

    }

    protected void finalize() {

        System.out.println("Garbage collected from object" + i);

        i++;

    }

class GCScope {

    GCScope t;

    static int i = 1;

    public static void main(String args[]) {

        GCScope t1 = new GCScope();

        GCScope t2 = new GCScope();

        GCScope t3 = new GCScope();

        // 沒有對象符合GC

        t1.t = t2; // 沒有對象符合GC

        t2.t = t3; // 沒有對象符合GC

        t3.t = t1; // 沒有對象符合GC

        t1 = null;

        // 沒有對象符合GC (t3.t 仍然有一個到 t1 的引用)

        t2 = null;

        // 沒有對象符合GC (t3.t.t 仍然有一個到 t2 的引用)

        t3 = null;

        // 所有三個對象都符合GC (它們中沒有一個擁有引用。

        // 只有各對象的變量 t 還指向了彼此，

        // 形成了一個由對象組成的環形的島，而沒有任何外部的引用。)

    }

    protected void finalize() {

        System.out.println("Garbage collected from object" + i);

        i++;

    }

JVM GC算法

在判斷哪些內存需要回收和什麼時候回收用到GC 算法，本文主要對GC 算法進行講解。

JVM垃圾判定算法

常見的JVM垃圾判定算法包括：引用計數算法、可達性分析算法。

引用計數算法(Reference Counting)

引用計數算法是通過判斷對象的引用數量來決定對象是否可以被回收。

給對象中添加一個引用計數器，每當有一個地方引用它時，計數器值就加1；當引用失效時，計數器值就減1；任何時刻計數器爲0的對象就是不可能再被使用的。

優點：簡單，高效，現在的objective-c用的就是這種算法。

缺點：很難處理循環引用，相互引用的兩個對象則無法釋放。因此目前主流的Java虛擬機都摒棄掉了這種算法。

舉個簡單的例子，對象objA和objB都有字段instance，賦值令objA.instance=objB及objB.instance=objA，除此之外，這兩個對象沒有任何引用，實際上這兩個對象已經不可能再被訪問，但是因爲互相引用，導致它們的引用計數都不爲0，因此引用計數算法無法通知GC收集器回收它們。


public class ReferenceCountingGC {
    public 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;

        System.gc();//GC
    }
}

運行結果


[GC (System.gc()) [PSYoungGen: 3329K->744K(38400K)] 3329K->752K(125952K), 0.0341414 secs] [Times: user=0.00 sys=0.00, real=0.06 secs] 
[Full GC (System.gc()) [PSYoungGen: 744K->0K(38400K)] [ParOldGen: 8K->628K(87552K)] 752K->628K(125952K), [Metaspace: 3450K->3450K(1056768K)], 0.0060728 secs] [Times: user=0.05 sys=0.00, real=0.01 secs] 
Heap
 PSYoungGen      total 38400K, used 998K [0x00000000d5c00000, 0x00000000d8680000, 0x0000000100000000)
  eden space 33280K, 3% used [0x00000000d5c00000,0x00000000d5cf9b20,0x00000000d7c80000)
  from space 5120K, 0% used [0x00000000d7c80000,0x00000000d7c80000,0x00000000d8180000)
  to   space 5120K, 0% used [0x00000000d8180000,0x00000000d8180000,0x00000000d8680000)
 ParOldGen       total 87552K, used 628K [0x0000000081400000, 0x0000000086980000, 0x00000000d5c00000)
  object space 87552K, 0% used [0x0000000081400000,0x000000008149d2c8,0x0000000086980000)
 Metaspace       used 3469K, capacity 4496K, committed 4864K, reserved 1056768K
  class space    used 381K, capacity 388K, committed 512K, reserved 1048576K

Process finished with exit code 0

從運行結果看，GC日誌中包含“3329K->744K”,意味着虛擬機並沒有因爲這兩個對象互相引用就不回收它們，說明虛擬機不是通過引用技術算法來判斷對象是否存活的。

可達性分析算法（根搜索算法）

可達性分析算法是通過判斷對象的引用鏈是否可達來決定對象是否可以被回收。

從GC Roots（每種具體實現對GC Roots有不同的定義）作爲起點，向下搜索它們引用的對象，可以生成一棵引用樹，樹的節點視爲可達對象，反之視爲不可達。

在Java語言中，可以作爲GC Roots的對象包括下面幾種：

虛擬機棧（棧幀中的本地變量表）中的引用對象。
方法區中的類靜態屬性引用的對象。
方法區中的常量引用的對象。
本地方法棧中JNI（Native方法）的引用對象

真正標記以爲對象爲可回收狀態至少要標記兩次。

四種引用

強引用就是指在程序代碼之中普遍存在的，類似"Object obj = new Object()"這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的對象。


Object obj = new Object();

軟引用是用來描述一些還有用但並非必需的對象，對於軟引用關聯着的對象，在系統將要發生內存溢出異常之前，將會把這些對象列進回收範圍進行第二次回收。如果這次回收還沒有足夠的內存，纔會拋出內存溢出異常。在JDK1.2之後，提供了SoftReference類來實現軟引用。


Object obj = new Object();
SoftReference<Object> sf = new SoftReference<Object>(obj);

弱引用也是用來描述非必需對象的，但是它的強度比軟引用更弱一些，被弱引用關聯的對象，只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時，無論當前內存是否足夠，都會回收掉只被弱引用關聯的對象。在JDK1.2之後，提供了WeakReference類來實現弱引用。


Object obj = new Object();
WeakReference<Object> wf = new WeakReference<Object>(obj);

虛引用也成爲幽靈引用或者幻影引用，它是最弱的一中引用關係。一個對象是否有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個對象實例。爲一個對象設置虛引用關聯的唯一目的就是能在這個對象被收集器回收時收到一個系統通知。在JDK1.2之後，提供給了PhantomReference類來實現虛引用。


Object obj = new Object();
PhantomReference<Object> pf = new PhantomReference<Object>(obj);

JVM垃圾回收算法

常見的垃圾回收算法包括：標記-清除算法，複製算法，標記-整理算法，分代收集算法。

在介紹JVM垃圾回收算法前，先介紹一個概念。

Stop-the-World

Stop-the-world意味着 JVM由於要執行GC而停止了應用程序的執行，並且這種情形會在任何一種GC算法中發生。當Stop-the-world發生時，除了GC所需的線程以外，所有線程都處於等待狀態直到GC任務完成。事實上，GC優化很多時候就是指減少Stop-the-world發生的時間，從而使系統具有高吞吐、低停頓的特點。

標記—清除算法（Mark-Sweep）

之所以說標記/清除算法是幾種GC算法中最基礎的算法，是因爲後續的收集算法都是基於這種思路並對其不足進行改進而得到的。標記/清除算法的基本思想就跟它的名字一樣，分爲“標記”和“清除”兩個階段：首先標記出所有需要回收的對象，在標記完成後統一回收所有被標記的對象。

標記階段：標記的過程其實就是前面介紹的可達性分析算法的過程，遍歷所有的GC Roots對象，對從GC Roots對象可達的對象都打上一個標識，一般是在對象的header中，將其記錄爲可達對象；

清除階段：清除的過程是對堆內存進行遍歷，如果發現某個對象沒有被標記爲可達對象（通過讀取對象header信息），則將其回收。

不足：

標記和清除過程效率都不高
會產生大量碎片，內存碎片過多可能導致無法給大對象分配內存。

複製算法（Copying）

將內存劃分爲大小相等的兩塊，每次只使用其中一塊，當這一塊內存用完了就將還存活的對象複製到另一塊上面，然後再把使用過的內存空間進行一次清理。

現在的商業虛擬機都採用這種收集算法來回收新生代，但是並不是將內存劃分爲大小相等的兩塊，而是分爲一塊較大的 Eden 空間和兩塊較小的 Survior 空間，每次使用 Eden 空間和其中一塊 Survivor。在回收時，將 Eden 和 Survivor 中還存活着的對象一次性複製到另一塊 Survivor 空間上，最後清理 Eden 和使用過的那一塊 Survivor。HotSpot 虛擬機的 Eden 和 Survivor 的大小比例默認爲 8:1，保證了內存的利用率達到 90 %。如果每次回收有多於 10% 的對象存活，那麼一塊 Survivor 空間就不夠用了，此時需要依賴於老年代進行分配擔保，也就是借用老年代的空間。

不足：

將內存縮小爲原來的一半，浪費了一半的內存空間，代價太高；如果不想浪費一半的空間，就需要有額外的空間進行分配擔保，以應對被使用的內存中所有對象都100%存活的極端情況，所以在老年代一般不能直接選用這種算法。
複製收集算法在對象存活率較高時就要進行較多的複製操作，效率將會變低。

標記—整理算法（Mark-Compact）

標記—整理算法和標記—清除算法一樣，但是標記—整理算法不是把存活對象複製到另一塊內存，而是把存活對象往內存的一端移動，然後直接回收邊界以外的內存，因此其不會產生內存碎片。標記—整理算法提高了內存的利用率，並且它適合在收集對象存活時間較長的老年代。

不足：

效率不高，不僅要標記存活對象，還要整理所有存活對象的引用地址，在效率上不如複製算法。

分代收集算法(Generational Collection)

分代回收算法實際上是把複製算法和標記整理法的結合，並不是真正一個新的算法，一般分爲：老年代（Old Generation）和新生代（Young Generation），老年代就是很少垃圾需要進行回收的，新生代就是有很多的內存空間需要回收，所以不同代就採用不同的回收算法，以此來達到高效的回收算法。

新生代：由於新生代產生很多臨時對象，大量對象需要進行回收，所以採用複製算法是最高效的。

老年代：回收的對象很少，都是經過幾次標記後都不是可回收的狀態轉移到老年代的，所以僅有少量對象需要回收，故採用標記清除或者標記整理算法。

參考文章

<https://segmentfault.com/a/1190000009707894>

<https://www.cnblogs.com/hysum/p/7100874.html>

<http://c.biancheng.net/view/939.html>

<https://www.runoob.com/>

https://blog.csdn.net/android_hl/article/details/53228348