Java基礎 - 從頭至尾說一次 Java 垃圾回收（轉）

以前上學的時候有這個一個梗，說在食堂裏吃飯，吃完把餐盤端走清理的，是 C++ 程序員，吃完直接就走的，是 Java 程序員。🤔

確實，在 Java 的世界裏，彷佛咱們不用對垃圾回收那麼的專一，不少初學者不懂 GC，也依然能寫出一個能用甚至還不錯的程序或系統。但其實這並不表明 Java 的 GC 就不重要。相反，它是那麼的重要和複雜，以致於出了問題，那些初學者除了打開 GC 日誌，看着一堆0101的天文，啥也作不了。😯

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

什麼是垃圾回收

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

Java 語言出來以前，你們都在拼命的寫 C 或者 C++ 的程序，而此時存在一個很大的矛盾，C++ 等語言建立對象要不斷的去開闢空間，不用的時候又須要不斷的去釋放控件，既要寫構造函數，又要寫析構函數，不少時候都在重複的 allocated，而後不停的析構。因而，有人就提出，能不能寫一段程序實現這塊功能，每次建立，釋放控件的時候複用這段代碼，而無需重複的書寫呢？

1960年，基於 MIT 的 Lisp 首先提出了垃圾回收的概念，而這時 Java 尚未出世呢！因此實際上 GC 並非Java的專利，GC 的歷史遠遠大於 Java 的歷史！

怎麼定義垃圾

既然咱們要作垃圾回收，首先咱們得搞清楚垃圾的定義是什麼，哪些內存是須要回收的。

引用計數算法

引用計數算法（Reachability Counting）是經過在對象頭中分配一個空間來保存該對象被引用的次數（Reference Count）。若是該對象被其它對象引用，則它的引用計數加1，若是刪除對該對象的引用，那麼它的引用計數就減1，當該對象的引用計數爲0時，那麼該對象就會被回收。

String m = new String("jack");

 

而後將 m 設置爲 null，這時候"jack"的引用次數就等於0了，在引用計數算法中，意味着這塊內容就須要被回收了。

m = null;

引用計數算法是將垃圾回收分攤到整個應用程序的運行當中了，而不是在進行垃圾收集時，要掛起整個應用的運行，直到對堆中全部對象的處理都結束。所以，採用引用計數的垃圾收集不屬於嚴格意義上的"Stop-The-World"的垃圾收集機制。

看似很美好，但咱們知道JVM的垃圾回收就是"Stop-The-World"的，那是什麼緣由致使咱們最終放棄了引用計數算法呢？看下面的例子。

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;
}

1. 定義2個對象
2. 相互引用
3. 置空各自的聲明引用

咱們能夠看到，最後這2個對象已經不可能再被訪問了，但因爲他們相互引用着對方，致使它們的引用計數永遠都不會爲0，經過引用計數算法，也就永遠沒法通知GC收集器回收它們。

可達性分析算法

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

經過可達性算法，成功解決了引用計數所沒法解決的問題-「循環依賴」，只要你沒法與 GC Root 創建直接或間接的鏈接，系統就會斷定你爲可回收對象。那這樣就引伸出了另外一個問題，哪些屬於 GC Root。

Java 內存區域

在 Java 語言中，可做爲 GC Root 的對象包括如下4種：

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

虛擬機棧（棧幀中的本地變量表）中引用的對象

此時的 s，即爲 GC Root，當s置空時，localParameter 對象也斷掉了與 GC Root 的引用鏈，將被回收。

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

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

方法區中類靜態屬性引用的對象

s 爲 GC Root，s 置爲 null，通過 GC 後，s 所指向的 properties 對象因爲沒法與 GC Root 創建關係被回收。

而 m 做爲類的靜態屬性，也屬於 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;
}

方法區中常量引用的對象

m 即爲方法區中的常量引用，也爲 GC Root，s 置爲 null 後，final 對象也不會因沒有與 GC Root 創建聯繫而被回收。

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 接口都會使用某種本地方法棧，實現的本地方法接口是使用 C 鏈接模型的話，那麼它的本地方法棧就是 C 棧。當線程調用 Java 方法時，虛擬機會建立一個新的棧幀並壓入 Java 棧。然而當它調用的是本地方法時，虛擬機會保持 Java 棧不變，再也不在線程的 Java 棧中壓入新的幀，虛擬機只是簡單地動態鏈接並直接調用指定的本地方法。

怎麼回收垃圾

在肯定了哪些垃圾能夠被回收後，垃圾收集器要作的事情就是開始進行垃圾回收，可是這裏面涉及到一個問題是：如何高效地進行垃圾回收。因爲Java虛擬機規範並無對如何實現垃圾收集器作出明確的規定，所以各個廠商的虛擬機能夠採用不一樣的方式來實現垃圾收集器，這裏咱們討論幾種常見的垃圾收集算法的核心思想。

標記-清除 算法

標記清除算法（Mark-Sweep）是最基礎的一種垃圾回收算法，它分爲2部分，先把內存區域中的這些對象進行標記，哪些屬於可回收標記出來，而後把這些垃圾拎出來清理掉。就像上圖同樣，清理掉的垃圾就變成未使用的內存區域，等待被再次使用。

這邏輯再清晰不過了，而且也很好操做，但它存在一個很大的問題，那就是內存碎片。

上圖中等方塊的假設是 2M，小一些的是 1M，大一些的是 4M。等咱們回收完，內存就會切成了不少段。咱們知道開闢內存空間時，須要的是連續的內存區域，這時候咱們須要一個 2M的內存區域，其中有2個 1M 是無法用的。這樣就致使，其實咱們自己還有這麼多的內存的，但卻用不了。

複製算法

複製算法（Copying）是在標記清除算法上演化而來，解決標記清除算法的內存碎片問題。它將可用內存按容量劃分爲大小相等的兩塊，每次只使用其中的一塊。當這一塊的內存用完了，就將還存活着的對象複製到另一塊上面，而後再把已使用過的內存空間一次清理掉。保證了內存的連續可用，內存分配時也就不用考慮內存碎片等複雜狀況，邏輯清晰，運行高效。

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

標記-整理 算法 

標記整理算法（Mark-Compact）標記過程仍然與標記 --- 清除算法同樣，但後續步驟不是直接對可回收對象進行清理，而是讓全部存活的對象都向一端移動，再清理掉端邊界之外的內存區域。

標記整理算法一方面在標記-清除算法上作了升級，解決了內存碎片的問題，也規避了複製算法只能利用一半內存區域的弊端。看起來很美好，但從上圖能夠看到，它對內存變更更頻繁，須要整理全部存活對象的引用地址，在效率上比複製算法要差不少。

分代收集算法

分代收集算法（Generational Collection）嚴格來講並非一種思想或理論，而是融合上述3種基礎的算法思想，而產生的針對不一樣狀況所採用不一樣算法的一套組合拳。對象存活週期的不一樣將內存劃分爲幾塊。通常是把 Java 堆分爲新生代和老年代，這樣就能夠根據各個年代的特色採用最適當的收集算法。在新生代中，每次垃圾收集時都發現有大批對象死去，只有少許存活，那就選用複製算法，只須要付出少許存活對象的複製成本就能夠完成收集。而老年代中由於對象存活率高、沒有額外空間對它進行分配擔保，就必須使用標記-清理或者標記 --- 整理算法來進行回收。so，另外一個問題來了，那內存區域到底被分爲哪幾塊，每一塊又有什麼特別適合什麼算法呢？

內存模型與回收策略

Java 堆（Java Heap）是JVM所管理的內存中最大的一塊，堆又是垃圾收集器管理的主要區域，這裏咱們主要分析一下 Java 堆的結構。

Java 堆主要分爲2個區域-年輕代與老年代，其中年輕代又分 Eden 區和 Survivor 區，其中 Survivor 區又分 From 和 To 2個區。可能這時候你們會有疑問，爲何須要 Survivor區，爲何Survivor還要分2個區。不着急，咱們從頭至尾，看看對象究竟是怎麼來的，而它又是怎麼沒的。

Eden 區

IBM 公司的專業研究代表，有將近98%的對象是朝生夕死，因此針對這一現狀，大多數狀況下，對象會在新生代 Eden 區中進行分配，當 Eden 區沒有足夠空間進行分配時，虛擬機會發起一次 Minor GC，Minor GC 相比 Major GC 更頻繁，回收速度也更快。

經過 Minor GC 以後，Eden 會被清空，Eden 區中絕大部分對象會被回收，而那些無需回收的存活對象，將會進到 Survivor 的 From 區（若 From 區不夠，則直接進入 Old 區）。

Survivor 區

Survivor 區至關因而 Eden 區和 Old 區的一個緩衝，相似於咱們交通燈中的黃燈。Survivor 又分爲2個區，一個是 From 區，一個是 To 區。每次執行 Minor GC，會將 Eden 區和 From 存活的對象放到 Survivor 的 To 區（若是 To 區不夠，則直接進入 Old 區）。

爲啥須要？

不就是新生代到老年代麼，直接 Eden 到 Old 很差了嗎，爲啥要這麼複雜。想一想若是沒有 Survivor 區，Eden 區每進行一次 Minor GC，存活的對象就會被送到老年代，老年代很快就會被填滿。而有不少對象雖然一次 Minor GC 沒有消滅，但其實也並不會蹦躂多久，或許第二次，第三次就須要被清除。這時候移入老年區，很明顯不是一個明智的決定。

因此，Survivor 的存在乎義就是減小被送到老年代的對象，進而減小 Major GC 的發生。Survivor 的預篩選保證，只有經歷16次 Minor GC 還能在新生代中存活的對象，纔會被送到老年代。

爲啥須要倆？

設置兩個 Survivor 區最大的好處就是解決內存碎片化。

咱們先假設一下，Survivor 若是隻有一個區域會怎樣。Minor GC 執行後，Eden 區被清空了，存活的對象放到了 Survivor 區，而以前 Survivor 區中的對象，可能也有一些是須要被清除的。問題來了，這時候咱們怎麼清除它們？在這種場景下，咱們只能標記清除，而咱們知道標記清除最大的問題就是內存碎片，在新生代這種常常會消亡的區域，採用標記清除必然會讓內存產生嚴重的碎片化。由於 Survivor 有2個區域，因此每次 Minor GC，會將以前 Eden 區和 From 區中的存活對象複製到 To 區域。第二次 Minor GC 時，From 與 To 職責兌換，這時候會將 Eden 區和 To 區中的存活對象再複製到 From 區域，以此反覆。

這種機制最大的好處就是，整個過程當中，永遠有一個 Survivor space 是空的，另外一個非空的 Survivor space 是無碎片的。那麼，Survivor 爲何不分更多塊呢？比方說分紅三個、四個、五個?顯然，若是 Survivor 區再細分下去，每一塊的空間就會比較小，容易致使 Survivor 區滿，兩塊 Survivor 區多是通過權衡以後的最佳方案。

Old 區

老年代佔據着2/3的堆內存空間，只有在 Major GC 的時候纔會進行清理，每次 GC 都會觸發「Stop-The-World」。內存越大，STW 的時間也越長，因此內存也不只僅是越大就越好。因爲複製算法在對象存活率較高的老年代會進行不少次的複製操做，效率很低，因此老年代這裏採用的是標記-整理算法。

除了上述所說，在內存擔保機制下，沒法安置的對象會直接進到老年代，如下幾種狀況也會進入老年代。

大對象

大對象指須要大量連續內存空間的對象，這部分對象無論是否是「朝生夕死」，都會直接進到老年代。這樣作主要是爲了不在 Eden 區及2個 Survivor 區之間發生大量的內存複製。當你的系統有很是多「朝生夕死」的大對象時，得注意了。

長期存活對象

虛擬機給每一個對象定義了一個對象年齡（Age）計數器。正常狀況下對象會不斷的在 Survivor 的 From 區與 To 區之間移動，對象在 Survivor 區中每經歷一次 Minor GC，年齡就增長1歲。當年齡增長到15歲時，這時候就會被轉移到老年代。固然，這裏的15，JVM 也支持進行特殊設置。

動態對象年齡

虛擬機並不重視要求對象年齡必須到15歲，纔會放入老年區，若是 Survivor 空間中相同年齡全部對象大小的總合大於 Survivor 空間的一半，年齡大於等於該年齡的對象就能夠直接進去老年區，無需等你「成年」。

 

這其實有點相似於負載均衡，輪詢是負載均衡的一種，保證每臺機器都分得一樣的請求。看似很均衡，但每臺機的硬件不通，健康情況不一樣，咱們還能夠基於每臺機接受的請求數，或每臺機的響應時間等，來調整咱們的負載均衡算法。

 

 

文章轉載自公衆號：阿里巴巴中間件，做者：率鴿