Java 虛擬機垃圾收集機制詳解

本文摘自深入理解 Java 虛擬機第三版

垃圾收集發生的區域

之前我們介紹過 Java 內存運行時區域的各個部分，其中程序計數器、虛擬機棧、本地方法棧三個區域隨線程共存亡。棧中的每一個棧幀分配多少內存基本上在類結構確定下來時就已知，因此這幾個區域的內存分配和回收都具有確定性，不需要考慮如何回收的問題，當方法結束或線程結束，內存自然也跟着回收了

而 Java 堆和方法區這兩個區域則有顯著的不確定性，只有在程序運行時我們才能知道程序究竟創建了哪些對象，創建了多少對象，所以這部分內存的分配和回收是動態的，垃圾收集器所關注的正是這部分內存該如何管理

如何判定需要被回收的對象？

如果一個對象沒有被其他對象引用，則證明這個對象可以被回收，因爲它已經沒有實際用途了。那我們怎麼去判斷一個對象是否可回收呢？業界主要有兩種判斷方式：

1. 引用計數法

在對象中添加一個引用計數器，每當有一個地方引用它時，計數器值加一；當引用失效，計數器值減一；任何時刻計數器值都爲零的對象就是不可能再被使用了。這種方法雖然會佔用額外的內存空間用於計數，但它的原理簡單，判定效率也高，大多數情況下它都是一個不錯的算法。然而，這個看似簡單的算法卻需要考慮很多額外情況，否則將無法保證其正確工作，例如單純的引用計數法就很難解決對象之間相互循環引用的問題

2. 可達性分析算法

該算法的基本思路是通過一系列稱爲 GC Roots 的根對象作爲起始節點集，從這些節點開始，根據引用關係向下搜索，搜索過程走過的路徑稱爲引用鏈。如果某個對象到 GC Roots 間沒有任何引用鏈相連，則證明此對象是不可能再被使用，可以回收

在 Java 技術體系中，可以作爲 GC Roots 的對象包括：

• 在虛擬機棧（棧幀中的本地變量表）中引用的對象
• 方法區中類靜態屬性引用的對象
• 方法區中常量引用的對象
• 本地方法棧中 JNI（即通常所說的 Native 方法）引用的對象
• Java 虛擬機內部的引用，如基本數據類型對應的 Class 對象，一些常駐的異常對象（NullPointException、OutOfMemoryError）
• 所有被同步鎖持有的對象
• 反映 Java 虛擬機內部情況的 JMXBean、JVMTI 中註冊的回調、本地代碼緩存等

除了這些固定的 GC Roots 集合外，根據用戶所選用的垃圾收集器以及當前回收的內存區域的不同，還可以有其他對象臨時加入，共同構成完整的 GC Roots 集合

四種引用類型

無論是通過引用計數法還是可達性分析算法，判斷對象是否存活都和引用離不開關係。在 JDK1.2 以前，Java 裏的引用是很傳統的定義：如果 reference 類型的數據中存儲的數值代表的是另外一塊內存的起始地址，就稱該 reference 數據是代表某塊內存、某個對象的引用。這種定義當然沒有什麼不對，但現在看來顯得太狹隘了，比如我們希望描述一類對象：當內存空間足夠時，能保留在內存中，如果內存空間在進行了垃圾收集後仍然緊張，則可以拋棄這些對象，很多系統的緩存功能都符合這樣的應用場景

JDK1.2 對引用的概念作了補充，將引用分爲強引用（Strongly Reference）、軟引用（SoftReference）、弱引用（Weak Reference）和虛引用（Phantom Reference），強度依次減弱

• 強引用

  形如 Object obj = new Object() 這種引用關係就是我們常說的強引用。無論什麼情況，只要強引用關係存在，對象就永遠不會被回收

• 軟引用

  用來描述一些有用但非必須的對象。此類對象只有在進行一次垃圾收集仍然沒有足夠內存時，纔會在第二次垃圾收集時被回收。JDK1.2 之後提供了 SoftReference 類來實現軟引用

• 弱引用

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

• 虛引用

  最弱的一種引用關係，一個對象是否存在虛引用，絲毫不會對其生存時間造成任何影響，也無法通過虛引用來取得一個對象實例。設置虛引用關聯的唯一目的就是讓這個對象被回收時能收到一個系統通知。JDK1.2 之後提供了 PhantomReference 類來實現軟引用

finalize() 方法

在可達性分析中被判定爲不可達的對象，並不是立即赴死，至少要經歷兩次標記過程：如果對象在進行可達性分析後發現沒有與 GC Root 相連接的引用鏈，那麼它將被第一次標記，隨後再進行一次篩選，篩選條件是對象是否有必要執行 finalize() 方法，如果對象沒有覆蓋 finalize() 方法或是 finalize() 方法已經被調用過，則都視爲“沒有必要執行”

如果對象被判定爲有必要執行 finalize() 方法，那麼該對象將會被放置在一個名爲 F-Queue 的隊列之中，並在稍後由一條由虛擬機自動創建的、低調度優先級的 Finalizer 線程去執行它們的 finalize() 方法。注意這裏所說的執行是指虛擬機會觸發這個方法開始運行，但並不承諾一定會等待它運行結束。這樣做的原因是防止某個對象的 finalize() 方法執行緩慢，或者發生死循環，導致 F-Queue 隊列中的其他對象永久處於等待狀態

finalize() 方法是對象逃脫死亡命運的最後一次機會，稍後收集器將對 F-Queue 中的對象進行第二次小規模標記，如果對象希望在 finalize() 方法中成功拯救自己，只要重新與引用鏈上的任何一個對象建立關聯即可，那麼在第二次標記時它將被移出“即將回收”的集合；如果對象這時候還沒有逃脫，那基本上就真的要被回收了

任何一個對象的 finalize() 方法都只會被系統自動調用一次，如果對象面臨下一次回收，它的 finalize() 方法將不會再執行。finalize() 方法運行代價高，不確定性大，無法保證各個對象的調用順序，因此已被官方明確聲明爲不推薦使用的語法

回收方法區

方法區的垃圾收集主要回收兩部分：廢棄的常量和不再使用的類型。判定一個常量是否廢棄相對簡單，與對象類似，只要某個常量不再被引用，就會被清理。而判定一個類型是否屬於“不再被使用的類”的條件就比較苛刻了，需要同時滿足下面三個條件：

• 該類的所有實例都已經被回收，即 Java 堆中不存在該類及其任何派生子類的實例
• 加載該類的類加載器已經被回收
• 該類對應的 java.lang.Class 對象沒有在任何地方被引用，無法再任何地方通過反射訪問該類的方法

Java 虛擬機允許對滿足上述三個條件的無用類進行回收，但並不是說必然被回收，僅僅是允許而已。關於是否要對類型進行回收，HotSpot 虛擬機提供了 -Xnoclassgc 參數進行控制

分代收集理論

當前商業虛擬機的垃圾收集器大多數都遵循了“分代收集”的設計理論，分代收集理論其實是一套符合大多數程序運行實際情況的經驗法則，主要建立在兩個分代假說之上：

• 弱分代假說：絕大多數對象都是朝生夕滅的
• 強分代假說：熬過越多次垃圾收集過程的對象就越難以消亡

這兩個分代假說共同奠定了多款常用垃圾收集器的一致設計原則：收集器應該將 Java 堆劃分出不同的區域，將回收對象依據年齡（即對象熬過垃圾收集過程的次數）分配到不同的區域之中存儲，把存活時間短的對象集中在一起，每次回收只關注如何保留少量存活的對象，即新生代（Young Generation）；把難以消亡的對象集中在一起，虛擬機就可以使用較低的頻率來回收這個區域，即老年代（Old Generation）

正因爲劃出了不同的區域，垃圾收集器纔可以每次只回收其中一個或多個區域，因此纔有了“Minor GC”、“Major GC”、“Full GC”這樣的回收類型劃分，也才能夠針對不同的區域採用不同的垃圾收集算法，因而有了“標記-複製”算法、“標記-清除”算法、“標記-整理”算法

分代收集並非只是簡單劃分一下內存區域，它至少存在一個明顯的困難：對象之間不是孤立的，對象之間會存在跨代引用。假如現在要進行只侷限於新生代的垃圾收集，根據前面可達性分析的知識，與 GC Roots 之間不存在引用鏈即爲可回收，但新生代的對象很有可能會被老年代所引用，那麼老年代對象將臨時加入 GC Roots 集合中，我們不得不再額外遍歷整個老年代中的所有對象來確保可達性分析結果的正確性，這無疑爲內存回收帶來很大的性能負擔。爲了解決這個問題，就需要對分代收集理論添加第三條經驗法則：

• 跨代引用假說：跨代引用相對於同代引用僅佔少數

存在互相引用的兩個對象，應該是傾向於同時生存或同時消亡的，舉個例子，如果某個新生代對象存在跨代引用，由於老年代對象難以消亡，會使得新生代對象同樣在收集時得以存活，進而年齡增長後晉升到老年代，那麼跨代引用也隨之消除了。既然跨帶引用只是少數，那麼就沒必要去掃描整個老年代，也不必專門記錄每一個對象是否存在哪些跨代引用，只需在新生代上建立一個全局的數據結構，稱爲記憶集（Remembered Set），這個結構把老年代劃分爲若干個小塊，標識出老年代的哪一塊內存會存在跨代引用。此後當發生 Minor GC 時，只有包含了跨代引用的小塊內存裏的對象纔會被加入 GC Roots 進行掃描

標記 - 清除算法

如其名，算法分爲標記和清除兩個階段：首先標記出所有需要回收的對象，在標記完成之後，統一回收所有被標記的對象，也可以反過來，標記存活的對象，統一回收所有未被標記的對象。標記過程就是對象是否屬於垃圾的判定過程。標記 - 清除算法執行過程如圖所示：

標記 - 清除算法是最基礎的算法，後續的收集算法都是以標記 - 清除算法爲基礎，對其缺點進行改進，它的主要缺點有兩個：

• 執行效率不穩定

  如果 Java 堆中包含大量對象且大部分需要回收，則必須進行大量標記和清除的動作‘

• 內存空間碎片化問題

  標記、清除之後會產生大量不連續的內存碎片，內存碎片太多會導致下次分配較大對象時無法找到足夠的連續內存，從而不得不提前觸發一次垃圾收集動作

標記 - 複製算法

爲了解決標記 - 清除算法面對大量可回收對象時執行效率低的問題，複製算法將可用內存按容量劃分爲大小相等的兩塊，每次只使用其中一塊，當這一塊內存用完了，就將還存活着的對象複製到另外一內存上，再把已使用過的內存空間一次清理掉

如果內存中多數對象都是存活的，這種算法無疑會產生大量內存間複製的開銷，但對於多數對象都是可回收的情況，算法需要複製的就是佔少數的存活對象，而且每次都是針對整個半區進行內存回收，分配內存時也不用考慮空間碎片的問題，只要移動堆頂指針，按順序分配即可。不過這種算法的缺陷也顯而易見，可用內存被縮小爲原來的一半

標記 - 複製算法大多用於新生代。實際上，新生代中的對象大多數都熬不過第一輪收集，因此不需要按 1:1 的比例來劃分新生代的內存空間。具體做法是將新生代劃分爲一塊較大的 Eden 區和兩塊較小的 Survivor 區，每次分配只使用 Eden 區和其中一塊 Survivor 區。發生垃圾收集時，將 Eden 區和 Survivor 區中仍然存活的對象一次性複製到另一個 Survivor 區，然後直接清理掉 Eden 區和已經用過的 Survivor 區。HotSpot 虛擬機默認 Eden 和 Survivor 的大小比例是 8:1:1

當 Survivor 空間不足以容納一次 Minor GC 之後存活的對象時，就需要依賴其他內存區域（大多是老年代）進行分配擔保，上一次新生代存活下來的對象直接進入老年代

標記 - 整理算法

標記 - 複製算法不適合用在對象存活率高的區域，而且會浪費一半的空間，因此老年代一般不採用這種算法，取而代之的是有針對性的標記 - 整理算法。標記 - 整理算法的標記過程與標記 - 清除算法一樣，但後續步驟不是直接清理可回收對象，而是讓所有存活對象都向內存空間的一側移動，然後直接清理掉邊界以外的內存

是否移動回收後的存活對象是一項優缺點並存的風險決策，尤其是在老年代這種每次回收都有大量對象存活的區域，移動存活對象並更新其引用將會是一個極爲繁重的操作，必須暫停用戶應用程序線程才能進行，像這樣的停頓行爲被稱爲“Stop the World”。但如果不考慮移動存活對象，又會影響內存分配和訪問的效率，爲此使用者必須小心權衡其中的得失。一種和稀泥式的解決方案就是讓虛擬機平時採用標記 - 清除算法，直到內存空間碎片化程度大到影響對象分配時，再採用標記 - 整理算法收集一次，已獲得規整的內存空間