咱們從頭到尾說一次 Java 垃圾回收

?? 圖片來源于網(wǎng)絡(luò)

之前上學(xué)的時候有這個一個梗，說在食堂里吃飯，吃完把餐盤端走清理的，是 C++ 程序員，吃完直接就走的，是 Java 程序員。????

確實，在 Java 的世界里，似乎我們不用對垃圾回收那么的專注，很多初學(xué)者不懂 GC，也依然能寫出一個能用甚至還不錯的程序或系統(tǒng)。但其實這并不代表 Java 的 GC 就不重要。相反，它是那么的重要和復(fù)雜，以至于出了問題，那些初學(xué)者除了打開 GC 日志，看著一堆0101的天文，啥也做不了。????

今天我們就從頭到尾完整地聊一聊 Java 的垃圾回收。

什么是垃圾回收

垃圾回收（Garbage Collection，GC），顧名思義就是釋放垃圾占用的空間，防止內(nèi)存泄露。有效的使用可以使用的內(nèi)存，對內(nèi)存堆中已經(jīng)死亡的或者長時間沒有使用的對象進(jìn)行清除和回收。

Java 語言出來之前，大家都在拼命的寫 C 或者 C++ 的程序，而此時存在一個很大的矛盾，C++ 等語言創(chuàng)建對象要不斷的去開辟空間，不用的時候又需要不斷的去釋放控件，既要寫構(gòu)造函數(shù)，又要寫析構(gòu)函數(shù)，很多時候都在重復(fù)的 allocated，然后不停的析構(gòu)。于是，有人就提出，能不能寫一段程序?qū)崿F(xiàn)這塊功能，每次創(chuàng)建，釋放控件的時候復(fù)用這段代碼，而無需重復(fù)的書寫呢？

1960年，基于 MIT 的 Lisp 首先提出了垃圾回收的概念，而這時 Java 還沒有出世呢！所以實際上 GC 并不是Java的專利，GC 的歷史遠(yuǎn)遠(yuǎn)大于 Java 的歷史！

怎么定義垃圾

既然我們要做垃圾回收，首先我們得搞清楚垃圾的定義是什么，哪些內(nèi)存是需要回收的。

引用計數(shù)算法

引用計數(shù)算法（Reachability Counting）是通過在對象頭中分配一個空間來保存該對象被引用的次數(shù)（Reference Count）。如果該對象被其它對象引用，則它的引用計數(shù)加1，如果刪除對該對象的引用，那么它的引用計數(shù)就減1，當(dāng)該對象的引用計數(shù)為0時，那么該對象就會被回收。

String m = new String("jack");

先創(chuàng)建一個字符串，這時候"jack"有一個引用，就是 m。

然后將 m 設(shè)置為 null，這時候"jack"的引用次數(shù)就等于0了，在引用計數(shù)算法中，意味著這塊內(nèi)容就需要被回收了。

m = null;

引用計數(shù)算法是將垃圾回收分?jǐn)偟秸麄€應(yīng)用程序的運行當(dāng)中了，而不是在進(jìn)行垃圾收集時，要掛起整個應(yīng)用的運行，直到對堆中所有對象的處理都結(jié)束。因此，采用引用計數(shù)的垃圾收集不屬于嚴(yán)格意義上的"Stop-The-World"的垃圾收集機(jī)制。

看似很美好，但我們知道JVM的垃圾回收就是"Stop-The-World"的，那是什么原因?qū)е挛覀冏罱K放棄了引用計數(shù)算法呢？看下面的例子。

public class ReferenceCountingGC {

    public Object instance;

    public ReferenceCountingGC(String name){}
}

public static void testGC(){

    ReferenceCountingGC a = new ReferenceCountingGC("objA");
    ReferenceCountingGC b = new ReferenceCountingGC("objB");

    a.instance = b;
    b.instance = a;

    a = null;
    b = null;
}

我們可以看到，最后這2個對象已經(jīng)不可能再被訪問了，但由于他們相互引用著對方，導(dǎo)致它們的引用計數(shù)永遠(yuǎn)都不會為0，通過引用計數(shù)算法，也就永遠(yuǎn)無法通知GC收集器回收它們。

可達(dá)性分析算法

可達(dá)性分析算法（Reachability Analysis）的基本思路是，通過一些被稱為引用鏈（GC Roots）的對象作為起點，從這些節(jié)點開始向下搜索，搜索走過的路徑被稱為（Reference Chain)，當(dāng)一個對象到 GC Roots 沒有任何引用鏈相連時（即從 GC Roots 節(jié)點到該節(jié)點不可達(dá)），則證明該對象是不可用的。

通過可達(dá)性算法，成功解決了引用計數(shù)所無法解決的問題-“循環(huán)依賴”，只要你無法與 GC Root 建立直接或間接的連接，系統(tǒng)就會判定你為可回收對象。那這樣就引申出了另一個問題，哪些屬于 GC Root。

Java 內(nèi)存區(qū)域

在 Java 語言中，可作為 GC Root 的對象包括以下4種：

• 虛擬機(jī)棧（棧幀中的本地變量表）中引用的對象

• 方法區(qū)中類靜態(tài)屬性引用的對象

• 方法區(qū)中常量引用的對象

• 本地方法棧中 JNI（即一般說的 Native 方法）引用的對象

虛擬機(jī)棧（棧幀中的本地變量表）中引用的對象
此時的 s，即為 GC Root，當(dāng)s置空時，localParameter 對象也斷掉了與 GC Root 的引用鏈，將被回收。

public class StackLocalParameter {
    public StackLocalParameter(String name){}
}

public static void testGC(){
    StackLocalParameter s = new StackLocalParameter("localParameter");
    s = null;
}

方法區(qū)中類靜態(tài)屬性引用的對象
s 為 GC Root，s 置為 null，經(jīng)過 GC 后，s 所指向的 properties 對象由于無法與 GC Root 建立關(guān)系被回收。

而 m 作為類的靜態(tài)屬性，也屬于 GC Root，parameter 對象依然與 GC root 建立著連接，所以此時 parameter 對象并不會被回收。

public class MethodAreaStaicProperties {
    public static MethodAreaStaicProperties m;
    public MethodAreaStaicProperties(String name){}
}

public static void testGC(){
    MethodAreaStaicProperties s = new MethodAreaStaicProperties("properties");
    s.m = new MethodAreaStaicProperties("parameter");
    s = null;
}

方法區(qū)中常量引用的對象
m 即為方法區(qū)中的常量引用，也為 GC Root，s 置為 null 后，final 對象也不會因沒有與 GC Root 建立聯(lián)系而被回收。

public class MethodAreaStaicProperties {
    public static final MethodAreaStaicProperties m = MethodAreaStaicProperties("final");
    public MethodAreaStaicProperties(String name){}
}

public static void testGC(){
    MethodAreaStaicProperties s = new MethodAreaStaicProperties("staticProperties");
    s = null;
}

本地方法棧中引用的對象
任何 Native 接口都會使用某種本地方法棧，實現(xiàn)的本地方法接口是使用 C 連接模型的話，那么它的本地方法棧就是 C 棧。當(dāng)線程調(diào)用 Java 方法時，虛擬機(jī)會創(chuàng)建一個新的棧幀并壓入 Java 棧。然而當(dāng)它調(diào)用的是本地方法時，虛擬機(jī)會保持 Java 棧不變，不再在線程的 Java 棧中壓入新的幀，虛擬機(jī)只是簡單地動態(tài)連接并直接調(diào)用指定的本地方法。

怎么回收垃圾

在確定了哪些垃圾可以被回收后，垃圾收集器要做的事情就是開始進(jìn)行垃圾回收，但是這里面涉及到一個問題是：如何高效地進(jìn)行垃圾回收。由于Java虛擬機(jī)規(guī)范并沒有對如何實現(xiàn)垃圾收集器做出明確的規(guī)定，因此各個廠商的虛擬機(jī)可以采用不同的方式來實現(xiàn)垃圾收集器，這里我們討論幾種常見的垃圾收集算法的核心思想。

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

標(biāo)記清除算法（Mark-Sweep）是最基礎(chǔ)的一種垃圾回收算法，它分為2部分，先把內(nèi)存區(qū)域中的這些對象進(jìn)行標(biāo)記，哪些屬于可回收標(biāo)記出來，然后把這些垃圾拎出來清理掉。就像上圖一樣，清理掉的垃圾就變成未使用的內(nèi)存區(qū)域，等待被再次使用。

這邏輯再清晰不過了，并且也很好操作，但它存在一個很大的問題，那就是內(nèi)存碎片。

上圖中等方塊的假設(shè)是 2M，小一些的是 1M，大一些的是 4M。等我們回收完，內(nèi)存就會切成了很多段。我們知道開辟內(nèi)存空間時，需要的是連續(xù)的內(nèi)存區(qū)域，這時候我們需要一個 2M的內(nèi)存區(qū)域，其中有2個 1M 是沒法用的。這樣就導(dǎo)致，其實我們本身還有這么多的內(nèi)存的，但卻用不了。

復(fù)制算法

復(fù)制算法（Copying）是在標(biāo)記清除算法上演化而來，解決標(biāo)記清除算法的內(nèi)存碎片問題。它將可用內(nèi)存按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當(dāng)這一塊的內(nèi)存用完了，就將還存活著的對象復(fù)制到另外一塊上面，然后再把已使用過的內(nèi)存空間一次清理掉。保證了內(nèi)存的連續(xù)可用，內(nèi)存分配時也就不用考慮內(nèi)存碎片等復(fù)雜情況，邏輯清晰，運行高效。

上面的圖很清楚，也很明顯的暴露了另一個問題，合著我這140平的大三房，只能當(dāng)70平米的小兩房來使？代價實在太高。

標(biāo)記整理算法

標(biāo)記整理算法（Mark-Compact）標(biāo)記過程仍然與標(biāo)記 --- 清除算法一樣，但后續(xù)步驟不是直接對可回收對象進(jìn)行清理，而是讓所有存活的對象都向一端移動，再清理掉端邊界以外的內(nèi)存區(qū)域。

標(biāo)記整理算法一方面在標(biāo)記-清除算法上做了升級，解決了內(nèi)存碎片的問題，也規(guī)避了復(fù)制算法只能利用一半內(nèi)存區(qū)域的弊端。看起來很美好，但從上圖可以看到，它對內(nèi)存變動更頻繁，需要整理所有存活對象的引用地址，在效率上比復(fù)制算法要差很多。

分代收集算法分代收集算法（Generational Collection）嚴(yán)格來說并不是一種思想或理論，而是融合上述3種基礎(chǔ)的算法思想，而產(chǎn)生的針對不同情況所采用不同算法的一套組合拳。對象存活周期的不同將內(nèi)存劃分為幾塊。一般是把 Java 堆分為新生代和老年代，這樣就可以根據(jù)各個年代的特點采用最適當(dāng)?shù)氖占惴ā?/span>在新生代中，每次垃圾收集時都發(fā)現(xiàn)有大批對象死去，只有少量存活，那就選用復(fù)制算法，只需要付出少量存活對象的復(fù)制成本就可以完成收集。而老年代中因為對象存活率高、沒有額外空間對它進(jìn)行分配擔(dān)保，就必須使用標(biāo)記-清理或者標(biāo)記 --- 整理算法來進(jìn)行回收。so，另一個問題來了，那內(nèi)存區(qū)域到底被分為哪幾塊，每一塊又有什么特別適合什么算法呢？

內(nèi)存模型與回收策略

Java 堆（Java Heap）是JVM所管理的內(nèi)存中最大的一塊，堆又是垃圾收集器管理的主要區(qū)域，這里我們主要分析一下 Java 堆的結(jié)構(gòu)。

Java 堆主要分為2個區(qū)域-年輕代與老年代，其中年輕代又分 Eden 區(qū)和 Survivor 區(qū)，其中 Survivor 區(qū)又分 From 和 To 2個區(qū)。可能這時候大家會有疑問，為什么需要 Survivor 區(qū)，為什么Survivor 還要分2個區(qū)。不著急，我們從頭到尾，看看對象到底是怎么來的，而它又是怎么沒的。

Eden 區(qū)

IBM 公司的專業(yè)研究表明，有將近98%的對象是朝生夕死，所以針對這一現(xiàn)狀，大多數(shù)情況下，對象會在新生代 Eden 區(qū)中進(jìn)行分配，當(dāng) Eden 區(qū)沒有足夠空間進(jìn)行分配時，虛擬機(jī)會發(fā)起一次 Minor GC，Minor GC 相比 Major GC 更頻繁，回收速度也更快。

通過 Minor GC 之后，Eden 會被清空，Eden 區(qū)中絕大部分對象會被回收，而那些無需回收的存活對象，將會進(jìn)到 Survivor 的 From 區(qū)（若 From 區(qū)不夠，則直接進(jìn)入 Old 區(qū)）。

Survivor 區(qū)

Survivor 區(qū)相當(dāng)于是 Eden 區(qū)和 Old 區(qū)的一個緩沖，類似于我們交通燈中的黃燈。Survivor 又分為2個區(qū)，一個是 From 區(qū)，一個是 To 區(qū)。每次執(zhí)行 Minor GC，會將 Eden 區(qū)和 From 存活的對象放到 Survivor 的 To 區(qū)（如果 To 區(qū)不夠，則直接進(jìn)入 Old 區(qū)）。

為啥需要？

不就是新生代到老年代么，直接 Eden 到 Old 不好了嗎，為啥要這么復(fù)雜。想想如果沒有 Survivor 區(qū)，Eden 區(qū)每進(jìn)行一次 Minor GC，存活的對象就會被送到老年代，老年代很快就會被填滿。而有很多對象雖然一次 Minor GC 沒有消滅，但其實也并不會蹦跶多久，或許第二次，第三次就需要被清除。這時候移入老年區(qū)，很明顯不是一個明智的決定。

所以，Survivor 的存在意義就是減少被送到老年代的對象，進(jìn)而減少 Major GC 的發(fā)生。Survivor 的預(yù)篩選保證，只有經(jīng)歷16次 Minor GC 還能在新生代中存活的對象，才會被送到老年代。

為啥需要倆？

設(shè)置兩個 Survivor 區(qū)最大的好處就是解決內(nèi)存碎片化。

我們先假設(shè)一下，Survivor 如果只有一個區(qū)域會怎樣。Minor GC 執(zhí)行后，Eden 區(qū)被清空了，存活的對象放到了 Survivor 區(qū)，而之前 Survivor 區(qū)中的對象，可能也有一些是需要被清除的。問題來了，這時候我們怎么清除它們？在這種場景下，我們只能標(biāo)記清除，而我們知道標(biāo)記清除最大的問題就是內(nèi)存碎片，在新生代這種經(jīng)常會消亡的區(qū)域，采用標(biāo)記清除必然會讓內(nèi)存產(chǎn)生嚴(yán)重的碎片化。因為 Survivor 有2個區(qū)域，所以每次 Minor GC，會將之前 Eden 區(qū)和 From 區(qū)中的存活對象復(fù)制到 To 區(qū)域。第二次 Minor GC 時，F(xiàn)rom 與 To 職責(zé)兌換，這時候會將 Eden 區(qū)和 To 區(qū)中的存活對象再復(fù)制到 From 區(qū)域，以此反復(fù)。

這種機(jī)制最大的好處就是，整個過程中，永遠(yuǎn)有一個 Survivor space 是空的，另一個非空的 Survivor space 是無碎片的。那么，Survivor 為什么不分更多塊呢？比方說分成三個、四個、五個?顯然，如果 Survivor 區(qū)再細(xì)分下去，每一塊的空間就會比較小，容易導(dǎo)致 Survivor 區(qū)滿，兩塊 Survivor 區(qū)可能是經(jīng)過權(quán)衡之后的最佳方案。

Old 區(qū)

老年代占據(jù)著2/3的堆內(nèi)存空間，只有在 Major GC 的時候才會進(jìn)行清理，每次 GC 都會觸發(fā)“Stop-The-World”。內(nèi)存越大，STW 的時間也越長，所以內(nèi)存也不僅僅是越大就越好。由于復(fù)制算法在對象存活率較高的老年代會進(jìn)行很多次的復(fù)制操作，效率很低，所以老年代這里采用的是標(biāo)記 --- 整理算法。

除了上述所說，在內(nèi)存擔(dān)保機(jī)制下，無法安置的對象會直接進(jìn)到老年代，以下幾種情況也會進(jìn)入老年代。

大對象

大對象指需要大量連續(xù)內(nèi)存空間的對象，這部分對象不管是不是“朝生夕死”，都會直接進(jìn)到老年代。這樣做主要是為了避免在 Eden 區(qū)及2個 Survivor 區(qū)之間發(fā)生大量的內(nèi)存復(fù)制。當(dāng)你的系統(tǒng)有非常多“朝生夕死”的大對象時，得注意了。

長期存活對象

虛擬機(jī)給每個對象定義了一個對象年齡（Age）計數(shù)器。正常情況下對象會不斷的在 Survivor 的 From 區(qū)與 To 區(qū)之間移動，對象在 Survivor 區(qū)中每經(jīng)歷一次 Minor GC，年齡就增加1歲。當(dāng)年齡增加到15歲時，這時候就會被轉(zhuǎn)移到老年代。當(dāng)然，這里的15，JVM 也支持進(jìn)行特殊設(shè)置。

動態(tài)對象年齡

虛擬機(jī)并不重視要求對象年齡必須到15歲，才會放入老年區(qū)，如果 Survivor 空間中相同年齡所有對象大小的總合大于 Survivor 空間的一半，年齡大于等于該年齡的對象就可以直接進(jìn)去老年區(qū)，無需等你“成年”。

這其實有點類似于負(fù)載均衡，輪詢是負(fù)載均衡的一種，保證每臺機(jī)器都分得同樣的請求。看似很均衡，但每臺機(jī)的硬件不通，健康狀況不同，我們還可以基于每臺機(jī)接受的請求數(shù)，或每臺機(jī)的響應(yīng)時間等，來調(diào)整我們的負(fù)載均衡算法。

本文部分內(nèi)容參考自書籍：《深入理解Java虛擬機(jī)》。

 本文作者：

聶曉龍（花名：率鴿），阿里巴巴高級開發(fā)工程。