本小結(jié)將會以以下4個問題進(jìn)行探討：

• 內(nèi)存是如何分配和回收？

• 什么樣的數(shù)據(jù)需要回收？

• 什么時候進(jìn)行回收？

• 內(nèi)存中的數(shù)據(jù)如何進(jìn)行回收？

在進(jìn)行具體進(jìn)行解說這些問題的答案之前我們需要先了解一些JVM針對這些方面的一些基礎(chǔ)內(nèi)容：

1 揭開 JVM 內(nèi)存分配與回收的神秘面紗

Java 的自動內(nèi)存管理主要是針對對象內(nèi)存的回收和對象內(nèi)存的分配。同時，Java 自動內(nèi)存管理最核心的功能是 堆 內(nèi)存中對象的分配與回收。

Java 堆是垃圾收集器管理的主要區(qū)域，因此也被稱作GC 堆（Garbage Collected Heap）.從垃圾回收的角度，由于現(xiàn)在收集器基本都采用分代垃圾收集算法，所以 Java 堆還可以細(xì)分為：新生代和老年代：再細(xì)致一點有：Eden 空間、From Survivor、To Survivor 空間等。進(jìn)一步劃分的目的是更好地回收內(nèi)存，或者更快地分配內(nèi)存。

堆空間的基本結(jié)構(gòu)：

java-heap.png

上圖所示的 eden 區(qū)、s0("From") 區(qū)、s1("To") 區(qū)都屬于新生代，tenured 區(qū)屬于老年代。在絕大多數(shù)情況下，對象首先分配在eden區(qū)，在一次新生代回收之后，如果對象還存活，則進(jìn)入s0或者s1，每經(jīng)過一次新生代回收，對象如果存活，它的年齡就會加1。當(dāng)對象的年齡達(dá)到一定條件后（默認(rèn)為 15 歲,對象晉升到老年代的年齡閾值，可以通過參數(shù) -XX:MaxTenuringThreshold 來設(shè)置。），就會被認(rèn)為是老年對象，從而進(jìn)入老年代。經(jīng)過這次GC后，Eden區(qū)和"From"區(qū)已經(jīng)被清空。這個時候，"From"和"To"會交換他們的角色，也就是新的"To"就是上次GC前的“From”，新的"From"就是上次GC前的"To"(他們是兩塊大小相同、可以互換角色的內(nèi)存空間)。不管怎樣，都會保證名為To的Survivor區(qū)域是空的。Minor GC會一直重復(fù)這樣的過程，直到“To”區(qū)被填滿，"To"區(qū)被填滿之后，會將所有對象移動到年老代中。

對象常見分配策略

• 大部分情況對象優(yōu)先在Eden區(qū)進(jìn)行分配。
• 大對象直接進(jìn)入老年代。
• 長期存活的對象將進(jìn)入老年代。

1.1 對象優(yōu)先在 eden 區(qū)分配

目前主流的垃圾收集器都會采用分代回收算法，因此需要將堆內(nèi)存分為新生代和老年代，這樣我們就可以根據(jù)各個年代的特點選擇合適的垃圾收集算法。

大多數(shù)情況下，對象在新生代中 eden 區(qū)分配。當(dāng) eden 區(qū)沒有足夠空間進(jìn)行分配時，虛擬機將發(fā)起一次 Minor GC.下面我們來進(jìn)行實際測試以下。

在測試之前我們先來看看 Minor GC 和 Full GC 有什么不同呢？

• 新生代 GC（Minor GC）:指發(fā)生新生代的的垃圾收集動作，Minor GC 非常頻繁，回收速度一般也比較快。

  • 當(dāng) JVM 無法為一個新的對象分配空間時會觸發(fā) Minor GC，比如當(dāng) Eden 區(qū)滿了。所以分配率越高，越頻繁執(zhí)行 Minor GC。
  • 內(nèi)存池被填滿的時候，其中的內(nèi)容全部會被復(fù)制，指針會從0開始跟蹤空閑內(nèi)存。Eden 和 Survivor 區(qū)進(jìn)行了標(biāo)記和復(fù)制操作，取代了經(jīng)典的標(biāo)記、掃描、壓縮、清理操作。所以 Eden 和 Survivor 區(qū)不存在內(nèi)存碎片。寫指針總是停留在所使用內(nèi)存池的頂部。
  • 執(zhí)行 Minor GC 操作時，不會影響到永久代。從永久代到年輕代的引用被當(dāng)成 GC roots，從年輕代到永久代的引用在標(biāo)記階段被直接忽略掉。
  • 質(zhì)疑常規(guī)的認(rèn)知，所有的 Minor GC 都會觸發(fā)“全世界的暫停（stop-the-world）”，停止應(yīng)用程序的線程。對于大部分應(yīng)用程序，停頓導(dǎo)致的延遲都是可以忽略不計的。其中的真相就 是，大部分 Eden 區(qū)中的對象都能被認(rèn)為是垃圾，永遠(yuǎn)也不會被復(fù)制到 Survivor 區(qū)或者老年代空間。如果正好相反，Eden 區(qū)大部分新生對象不符合 GC 條件，Minor GC 執(zhí)行時暫停的時間將會長很多。
  • 所以 Minor GC 的情況就相當(dāng)清楚了——每次 Minor GC 會清理年輕代的內(nèi)存。

• 老年代 GC（Major GC/Full GC）:指發(fā)生在老年代的 GC，出現(xiàn)了 Major GC 經(jīng)常會伴隨至少一次的 Minor GC（并非絕對），Major GC 的速度一般會比 Minor GC 的慢 10 倍以上。

  • Full GC: 是清理整個堆空間—包括年輕代和永久代。當(dāng)年老代滿時會引發(fā)Full GC，F(xiàn)ull GC將會同時回收年輕代、年老代 ；當(dāng)永久代滿時也會引發(fā)Full GC，會導(dǎo)致Class、Method元信息的卸載 。
  • 垃圾收集機制會清理部分永久代空間,不用去關(guān)心到底是叫 Major GC 還是 Full GC，應(yīng)該關(guān)注當(dāng)前的 GC 是否停止了所有應(yīng)用程序的線程，還是能夠并發(fā)的處理而不用停掉應(yīng)用程序的線程。

測試：

public class GCTest {

    public static void main(String[] args) {
        byte[] allocation1, allocation2,allocation3,allocation4,allocation5;
        allocation1 = new byte[60000*1024];
        //allocation2 = new byte[1000*1024];
        //allocation3 = new byte[1000*1024];
        //allocation4 = new byte[1000*1024];
        //allocation5 = new byte[1000*1024];
    }
}

添加的參數(shù)：-XX:+PrintGCDetails

idea-rintGCDetails.png

運行結(jié)果：

jvm-heap1.png

從上圖我們可以看出 eden 區(qū)內(nèi)存幾乎已經(jīng)被分配完全（即使程序什么也不做，新生代也會使用 5248K 內(nèi)存:mac idea獲取的數(shù)據(jù)）。假如我們再為 allocation2 分配內(nèi)存會出現(xiàn)什么情況呢？

jvm-heap2.png

簡單解釋一下為什么會出現(xiàn)這種情況： 因為給 allocation2 分配內(nèi)存的時候 eden 區(qū)內(nèi)存幾乎已經(jīng)被分配完了，我們剛剛講了當(dāng) Eden 區(qū)沒有足夠空間進(jìn)行分配時，虛擬機將發(fā)起一次 Minor GC.GC 期間虛擬機又發(fā)現(xiàn) allocation1 無法存入 Survivor 空間，所以只好通過 分配擔(dān)保機制 把新生代的對象提前轉(zhuǎn)移到老年代中去，老年代上的空間足夠存放 allocation1，所以不會出現(xiàn) Full GC。執(zhí)行 Minor GC 后，后面分配的對象如果能夠存在 eden 區(qū)的話，還是會在 eden 區(qū)分配內(nèi)存。

1.2 大對象直接進(jìn)入老年代

大對象就是需要大量連續(xù)內(nèi)存空間的對象（比如：字符串、數(shù)組）。

為什么要這樣呢？

為了避免為大對象分配內(nèi)存時由于分配擔(dān)保機制帶來的復(fù)制而降低效率。

1.3 長期存活的對象將進(jìn)入老年代

既然虛擬機采用了分代收集的思想來管理內(nèi)存，那么內(nèi)存回收時就必須能識別哪些對象應(yīng)放在新生代，哪些對象應(yīng)放在老年代中。為了做到這一點，虛擬機給每個對象一個對象年齡（Age）計數(shù)器。

如果對象首先分配在eden區(qū)，在一次新生代回收之后，如果對象還存活，并且能被 Survivor 容納的話，將被移動到 Survivor 空間中，每經(jīng)過一次新生代回收（MinorGC），對象如果存活，它的年齡就會加1。當(dāng)它的年齡增加到一定程度（默認(rèn)為 15 歲），就會被晉升到老年代中。對象晉升到老年代的年齡閾值，可以通過參數(shù) -XX:MaxTenuringThreshold 來設(shè)置。

1.4 動態(tài)對象年齡判定

為了更好的適應(yīng)不同程序的內(nèi)存情況，虛擬機不是永遠(yuǎn)要求對象年齡必須達(dá)到了某個值才能進(jìn)入老年代，如果 Survivor 空間中相同年齡所有對象大小的總和大于 Survivor 空間的一半，年齡大于或等于該年齡的對象就可以直接進(jìn)入老年代，無需達(dá)到要求的年齡。

至此對象內(nèi)存的分配機制介紹到此為止了

2 對象已經(jīng)死亡？

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

image

2.1 引用計數(shù)法

給對象中添加一個引用計數(shù)器，每當(dāng)有一個地方引用它，計數(shù)器就加 1；當(dāng)引用失效，計數(shù)器就減 1；任何時候計數(shù)器為 0 的對象就是不可能再被使用的。

這個方法實現(xiàn)簡單，效率高，但是目前主流的虛擬機中并沒有選擇這個算法來管理內(nèi)存，其最主要的原因是它很難解決對象之間相互循環(huán)引用的問題。 所謂對象之間的相互引用問題，如下面代碼所示：除了對象 objA 和 objB 相互引用著對方之外，這兩個對象之間再無任何引用。但是他們因為互相引用對方，導(dǎo)致它們的引用計數(shù)器都不為 0，于是引用計數(shù)算法無法通知 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 可達(dá)性分析算法

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

可達(dá)性分析算法

2.3 再談引用

無論是通過引用計數(shù)法判斷對象引用數(shù)量，還是通過可達(dá)性分析法判斷對象的引用鏈?zhǔn)欠窨蛇_(dá)，判定對象的存活都與“引用”有關(guān)。

JDK1.2 之前，Java 中引用的定義很傳統(tǒng)：如果 reference 類型的數(shù)據(jù)存儲的數(shù)值代表的是另一塊內(nèi)存的起始地址，就稱這塊內(nèi)存代表一個引用。

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

1．強引用

以前我們使用的大部分引用實際上都是強引用，這是使用最普遍的引用。如果一個對象具有強引用，那就類似于必不可少的生活用品，垃圾回收器絕不會回收它。當(dāng)內(nèi)存空 間不足，Java 虛擬機寧愿拋出 OutOfMemoryError 錯誤，使程序異常終止，也不會靠隨意回收具有強引用的對象來解決內(nèi)存不足問題。

2．軟引用（SoftReference）

如果一個對象只具有軟引用，那就類似于可有可無的生活用品。如果內(nèi)存空間足夠，垃圾回收器就不會回收它，如果內(nèi)存空間不足了，就會回收這些對象的內(nèi)存。只要垃圾回收器沒有回收它，該對象就可以被程序使用。軟引用可用來實現(xiàn)內(nèi)存敏感的高速緩存。

軟引用可以和一個引用隊列（ReferenceQueue）聯(lián)合使用，如果軟引用所引用的對象被垃圾回收，JAVA 虛擬機就會把這個軟引用加入到與之關(guān)聯(lián)的引用隊列中。

3．弱引用（WeakReference）

如果一個對象只具有弱引用，那就類似于可有可無的生活用品。弱引用與軟引用的區(qū)別在于：只具有弱引用的對象擁有更短暫的生命周期。在垃圾回收器線程掃描它 所管轄的內(nèi)存區(qū)域的過程中，一旦發(fā)現(xiàn)了只具有弱引用的對象，不管當(dāng)前內(nèi)存空間足夠與否，都會回收它的內(nèi)存。不過，由于垃圾回收器是一個優(yōu)先級很低的線程， 因此不一定會很快發(fā)現(xiàn)那些只具有弱引用的對象。

弱引用可以和一個引用隊列（ReferenceQueue）聯(lián)合使用，如果弱引用所引用的對象被垃圾回收，Java 虛擬機就會把這個弱引用加入到與之關(guān)聯(lián)的引用隊列中。

4．虛引用（PhantomReference）

"虛引用"顧名思義，就是形同虛設(shè)，與其他幾種引用都不同，虛引用并不會決定對象的生命周期。如果一個對象僅持有虛引用，那么它就和沒有任何引用一樣，在任何時候都可能被垃圾回收。

虛引用主要用來跟蹤對象被垃圾回收的活動。

虛引用與軟引用和弱引用的一個區(qū)別在于： 虛引用必須和引用隊列（ReferenceQueue）聯(lián)合使用。當(dāng)垃 圾回收器準(zhǔn)備回收一個對象時，如果發(fā)現(xiàn)它還有虛引用，就會在回收對象的內(nèi)存之前，把這個虛引用加入到與之關(guān)聯(lián)的引用隊列中。程序可以通過判斷引用隊列中是 否已經(jīng)加入了虛引用，來了解被引用的對象是否將要被垃圾回收。程序如果發(fā)現(xiàn)某個虛引用已經(jīng)被加入到引用隊列，那么就可以在所引用的對象的內(nèi)存被回收之前采取必要的行動。

特別注意，在程序設(shè)計中一般很少使用弱引用與虛引用，使用軟引用的情況較多，這是因為軟引用可以加速 JVM 對垃圾內(nèi)存的回收速度，可以維護(hù)系統(tǒng)的運行安全，防止內(nèi)存溢出（OutOfMemory）等問題的產(chǎn)生。

2.4 不可達(dá)的對象并非“非死不可”

即使在可達(dá)性分析法中不可達(dá)的對象，也并非是“非死不可”的，這時候它們暫時處于“緩刑階段”，要真正宣告一個對象死亡，至少要經(jīng)歷兩次標(biāo)記過程；可達(dá)性分析法中不可達(dá)的對象被第一次標(biāo)記并且進(jìn)行一次篩選，篩選的條件是此對象是否有必要執(zhí)行 finalize 方法。當(dāng)對象沒有覆蓋 finalize 方法，或 finalize 方法已經(jīng)被虛擬機調(diào)用過時，虛擬機將這兩種情況視為沒有必要執(zhí)行。

被判定為需要執(zhí)行的對象將會被放在一個隊列中進(jìn)行第二次標(biāo)記，除非這個對象與引用鏈上的任何一個對象建立關(guān)聯(lián)，否則就會被真的回收。

2.5 如何判斷一個常量是廢棄常量

運行時常量池主要回收的是廢棄的常量。那么，我們?nèi)绾闻袛嘁粋€常量是廢棄常量呢？

假如在常量池中存在字符串 "abc"，如果當(dāng)前沒有任何 String 對象引用該字符串常量的話，就說明常量 "abc" 就是廢棄常量，如果這時發(fā)生內(nèi)存回收的話而且有必要的話，"abc" 就會被系統(tǒng)清理出常量池。

注意：我們在 可能是把 Java 內(nèi)存區(qū)域講的最清楚的一篇文章 也講了 JDK1.7 及之后版本的 JVM 已經(jīng)將運行時常量池從方法區(qū)中移了出來，在 Java 堆（Heap）中開辟了一塊區(qū)域存放運行時常量池。

2.6 如何判斷一個類是無用的類

方法區(qū)主要回收的是無用的類，那么如何判斷一個類是無用的類的呢？

判定一個常量是否是“廢棄常量”比較簡單，而要判定一個類是否是“無用的類”的條件則相對苛刻許多。類需要同時滿足下面 3 個條件才能算是 “無用的類” ：

• 該類所有的實例都已經(jīng)被回收，也就是 Java 堆中不存在該類的任何實例。
• 加載該類的 ClassLoader 已經(jīng)被回收。
• 該類對應(yīng)的 java.lang.Class 對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。

虛擬機可以對滿足上述 3 個條件的無用類進(jìn)行回收，這里說的僅僅是“可以”，而并不是和對象一樣不使用了就會必然被回收。

3 垃圾收集算法

垃圾收集算法分類

3.1 標(biāo)記-清除算法

算法分為“標(biāo)記”和“清除”階段：首先標(biāo)記出所有需要回收的對象，在標(biāo)記完成后統(tǒng)一回收所有被標(biāo)記的對象。它是最基礎(chǔ)的收集算法，效率也很高，但是會帶來兩個明顯的問題：

1. 效率問題
2. 空間問題（標(biāo)記清除后會產(chǎn)生大量不連續(xù)的碎片）

標(biāo)記-清除算法.png

3.2 復(fù)制算法

為了解決效率問題，“復(fù)制”收集算法出現(xiàn)了。它可以將內(nèi)存分為大小相同的兩塊，每次使用其中的一塊。當(dāng)這一塊的內(nèi)存使用完后，就將還存活的對象復(fù)制到另一塊去，然后再把使用的空間一次清理掉。這樣就使每次的內(nèi)存回收都是對內(nèi)存區(qū)間的一半進(jìn)行回收。

復(fù)制算法.png

3.3 標(biāo)記-整理算法

根據(jù)老年代的特點特出的一種標(biāo)記算法，標(biāo)記過程仍然與“標(biāo)記-清除”算法一樣，但后續(xù)步驟不是直接對可回收對象回收，而是讓所有存活的對象向一端移動，然后直接清理掉端邊界以外的內(nèi)存。

標(biāo)記-整理算法

3.4 分代收集算法

當(dāng)前虛擬機的垃圾收集都采用分代收集算法，這種算法沒有什么新的思想，只是根據(jù)對象存活周期的不同將內(nèi)存分為幾塊。一般將 java 堆分為新生代和老年代，這樣我們就可以根據(jù)各個年代的特點選擇合適的垃圾收集算法。

比如在新生代中，每次收集都會有大量對象死去，所以可以選擇復(fù)制算法，只需要付出少量對象的復(fù)制成本就可以完成每次垃圾收集。而老年代的對象存活幾率是比較高的，而且沒有額外的空間對它進(jìn)行分配擔(dān)保，所以我們必須選擇“標(biāo)記-清除”或“標(biāo)記-整理”算法進(jìn)行垃圾收集。

延伸面試問題： HotSpot 為什么要分為新生代和老年代？

根據(jù)上面的對分代收集算法的介紹回答。

4 垃圾收集器

垃圾收集器分類

如果說收集算法是內(nèi)存回收的方法論，那么垃圾收集器就是內(nèi)存回收的具體實現(xiàn)。

雖然我們對各個收集器進(jìn)行比較，但并非要挑選出一個最好的收集器。因為知道現(xiàn)在為止還沒有最好的垃圾收集器出現(xiàn)，更加沒有萬能的垃圾收集器，我們能做的就是根據(jù)具體應(yīng)用場景選擇適合自己的垃圾收集器。試想一下：如果有一種四海之內(nèi)、任何場景下都適用的完美收集器存在，那么我們的 HotSpot 虛擬機就不會實現(xiàn)那么多不同的垃圾收集器了。

4.1 Serial 收集器

Serial（串行）收集器收集器是最基本、歷史最悠久的垃圾收集器了。大家看名字就知道這個收集器是一個單線程收集器了。它的 “單線程” 的意義不僅僅意味著它只會使用一條垃圾收集線程去完成垃圾收集工作，更重要的是它在進(jìn)行垃圾收集工作的時候必須暫停其他所有的工作線程（ "Stop The World" ），直到它收集結(jié)束。

新生代采用復(fù)制算法，老年代采用標(biāo)記-整理算法。

Serial 收集器

虛擬機的設(shè)計者們當(dāng)然知道 Stop The World 帶來的不良用戶體驗，所以在后續(xù)的垃圾收集器設(shè)計中停頓時間在不斷縮短（仍然還有停頓，尋找最優(yōu)秀的垃圾收集器的過程仍然在繼續(xù)）。

但是 Serial 收集器有沒有優(yōu)于其他垃圾收集器的地方呢？當(dāng)然有，它簡單而高效（與其他收集器的單線程相比）。Serial 收集器由于沒有線程交互的開銷，自然可以獲得很高的單線程收集效率。Serial 收集器對于運行在 Client 模式下的虛擬機來說是個不錯的選擇。

4.2 ParNew 收集器

ParNew 收集器其實就是 Serial 收集器的多線程版本，除了使用多線程進(jìn)行垃圾收集外，其余行為（控制參數(shù)、收集算法、回收策略等等）和 Serial 收集器完全一樣。

新生代采用復(fù)制算法，老年代采用標(biāo)記-整理算法。

ParNew 收集器

它是許多運行在 Server 模式下的虛擬機的首要選擇，除了 Serial 收集器外，只有它能與 CMS 收集器（真正意義上的并發(fā)收集器，后面會介紹到）配合工作。

并行和并發(fā)概念補充：

• 并行（Parallel） ：指多條垃圾收集線程并行工作，但此時用戶線程仍然處于等待狀態(tài)。

• 并發(fā)（Concurrent）：指用戶線程與垃圾收集線程同時執(zhí)行（但不一定是并行，可能會交替執(zhí)行），用戶程序在繼續(xù)運行，而垃圾收集器運行在另一個 CPU 上。

4.3 Parallel Scavenge 收集器

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

-XX:+UseParallelGC 

    使用 Parallel 收集器+ 老年代串行

-XX:+UseParallelOldGC

    使用 Parallel 收集器+ 老年代并行

Parallel Scavenge 收集器關(guān)注點是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的關(guān)注點更多的是用戶線程的停頓時間（提高用戶體驗）。所謂吞吐量就是 CPU 中用于運行用戶代碼的時間與 CPU 總消耗時間的比值。 Parallel Scavenge 收集器提供了很多參數(shù)供用戶找到最合適的停頓時間或最大吞吐量，如果對于收集器運作不太了解的話，手工優(yōu)化存在的話可以選擇把內(nèi)存管理優(yōu)化交給虛擬機去完成也是一個不錯的選擇。

新生代采用復(fù)制算法，老年代采用標(biāo)記-整理算法。

ParNew 收集器

4.4.Serial Old 收集器

Serial 收集器的老年代版本，它同樣是一個單線程收集器。它主要有兩大用途：一種用途是在 JDK1.5 以及以前的版本中與 Parallel Scavenge 收集器搭配使用，另一種用途是作為 CMS 收集器的后備方案。

4.5 Parallel Old 收集器

Parallel Scavenge 收集器的老年代版本。使用多線程和“標(biāo)記-整理”算法。在注重吞吐量以及 CPU 資源的場合，都可以優(yōu)先考慮 Parallel Scavenge 收集器和 Parallel Old 收集器。

4.6 CMS 收集器

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

CMS（Concurrent Mark Sweep）收集器是 HotSpot 虛擬機第一款真正意義上的并發(fā)收集器，它第一次實現(xiàn)了讓垃圾收集線程與用戶線程（基本上）同時工作。

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

• 初始標(biāo)記： 暫停所有的其他線程，并記錄下直接與 root 相連的對象，速度很快 ；
• 并發(fā)標(biāo)記： 同時開啟 GC 和用戶線程，用一個閉包結(jié)構(gòu)去記錄可達(dá)對象。但在這個階段結(jié)束，這個閉包結(jié)構(gòu)并不能保證包含當(dāng)前所有的可達(dá)對象。因為用戶線程可能會不斷的更新引用域，所以 GC 線程無法保證可達(dá)性分析的實時性。所以這個算法里會跟蹤記錄這些發(fā)生引用更新的地方。
• 重新標(biāo)記： 重新標(biāo)記階段就是為了修正并發(fā)標(biāo)記期間因為用戶程序繼續(xù)運行而導(dǎo)致標(biāo)記產(chǎn)生變動的那一部分對象的標(biāo)記記錄，這個階段的停頓時間一般會比初始標(biāo)記階段的時間稍長，遠(yuǎn)遠(yuǎn)比并發(fā)標(biāo)記階段時間短
• 并發(fā)清除： 開啟用戶線程，同時 GC 線程開始對為標(biāo)記的區(qū)域做清掃。

CMS 垃圾收集器

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

• 對 CPU 資源敏感；
• 無法處理浮動垃圾；
• 它使用的回收算法-“標(biāo)記-清除”算法會導(dǎo)致收集結(jié)束時會有大量空間碎片產(chǎn)生。

4.7 G1 收集器

G1 (Garbage-First) 是一款面向服務(wù)器的垃圾收集器,主要針對配備多顆處理器及大容量內(nèi)存的機器. 以極高概率滿足 GC 停頓時間要求的同時,還具備高吞吐量性能特征.

被視為 JDK1.7 中 HotSpot 虛擬機的一個重要進(jìn)化特征。它具備一下特點：

• 并行與并發(fā)：G1 能充分利用 CPU、多核環(huán)境下的硬件優(yōu)勢，使用多個 CPU（CPU 或者 CPU 核心）來縮短 Stop-The-World 停頓時間。部分其他收集器原本需要停頓 Java 線程執(zhí)行的 GC 動作，G1 收集器仍然可以通過并發(fā)的方式讓 java 程序繼續(xù)執(zhí)行。
• 分代收集：雖然 G1 可以不需要其他收集器配合就能獨立管理整個 GC 堆，但是還是保留了分代的概念。
• 空間整合：與 CMS 的“標(biāo)記--清理”算法不同，G1 從整體來看是基于“標(biāo)記整理”算法實現(xiàn)的收集器；從局部上來看是基于“復(fù)制”算法實現(xiàn)的。
• 可預(yù)測的停頓：這是 G1 相對于 CMS 的另一個大優(yōu)勢，降低停頓時間是 G1 和 CMS 共同的關(guān)注點，但 G1 除了追求低停頓外，還能建立可預(yù)測的停頓時間模型，能讓使用者明確指定在一個長度為 M 毫秒的時間片段內(nèi)。

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

• 初始標(biāo)記
• 并發(fā)標(biāo)記
• 最終標(biāo)記
• 篩選回收

G1 收集器在后臺維護(hù)了一個優(yōu)先列表，每次根據(jù)允許的收集時間，優(yōu)先選擇回收價值最大的 Region(這也就是它的名字 Garbage-First 的由來)。這種使用 Region 劃分內(nèi)存空間以及有優(yōu)先級的區(qū)域回收方式，保證了 GF 收集器在有限時間內(nèi)可以盡可能高的收集效率（把內(nèi)存化整為零）。

JDK版本默認(rèn)垃圾收集器

jdk1.7 默認(rèn)垃圾收集器Parallel Scavenge（新生代）+Serial Old（老年代）

jdk1.8 默認(rèn)垃圾收集器Parallel Scavenge（新生代）+Serial Old（老年代）

jdk1.9 默認(rèn)垃圾收集器G1

jdk10 默認(rèn)垃圾收集器G1

-XX:+PrintCommandLineFlags jvm參數(shù)可查看默認(rèn)設(shè)置收集器類型

-XX:+PrintGCDetails 亦可通過打印的GC日志的新生代、老年代名稱判斷