【搞定Jvm面試】 JVM 垃圾回收揭祕附常見面試題解析
JVM 垃圾回收
寫在前面
本節常見面試題
問題答案在文中都有提到
- 如何判斷物件是否死亡（兩種方法）。
- 簡單的介紹一下強引用、軟引用、弱引用、虛引用（虛引用與軟引用和弱引用的區別、使用軟引用能帶來的好處）。
- 如何判斷一個常量是廢棄常量
- 如何判斷一個類是無用的類
- 垃圾收集有哪些演算法，各自的特點？
- HotSpot 為什麼要分為新生代和老年代？
- 常見的垃圾回收器有那些？
- 介紹一下 CMS,G1 收集器。
- Minor Gc 和 Full GC 有什麼不同呢？
本文導火索
當需要排查各種記憶體溢位問題、當垃圾收整合為系統達到更高併發的瓶頸時，我們就需要對這些“自動化”的技術實施必要的監控和調節。
1 揭開 JVM 記憶體分配與回收的神祕面紗
Java 的自動記憶體管理主要是針對物件記憶體的回收和物件記憶體的分配。同時，Java 自動記憶體管理最核心的功能是 堆 記憶體中物件的分配與回收。
Java 堆是垃圾收集器管理的主要區域，因此也被稱作GC 堆（Garbage Collected Heap）.從垃圾回收的角度，由於現在收集器基本都採用分代垃圾收集演算法，所以 Java 堆還可以細分為：新生代和老年代：再細緻一點有：Eden 空間、From Survivor、To Survivor 空間等。進一步劃分的目的是更好地回收記憶體，或者更快地分配記憶體。
堆空間的基本結構：
上圖所示的 eden 區、s0("From") 區、s1("To") 區都屬於新生代，tentired 區屬於老年代。大部分情況，物件都會首先在 Eden 區域分配，在一次新生代垃圾回收後，如果物件還存活，則會進入 s1("To")，並且物件的年齡還會加 1(Eden 區->Survivor 區後物件的初始年齡變為 1)，當它的年齡增加到一定程度（預設為 15 歲），就會被晉升到老年代中。物件晉升到老年代的年齡閾值，可以通過引數 -XX:MaxTenuringThreshold
1.1 物件優先在 eden 區分配
目前主流的垃圾收集器都會採用分代回收演算法，因此需要將堆記憶體分為新生代和老年代，這樣我們就可以根據各個年代的特點選擇合適的垃圾收集演算法。
大多數情況下，物件在新生代中 eden 區分配。當 eden 區沒有足夠空間進行分配時，虛擬機器將發起一次 Minor GC.下面我們來進行實際測試以下。
在測試之前我們先來看看 Minor GC 和 Full GC 有什麼不同呢？
- 新生代 GC（Minor GC）:指發生新生代的的垃圾收集動作，Minor GC 非常頻繁，回收速度一般也比較快。
- 老年代 GC（Major GC/Full GC）:指發生在老年代的 GC，出現了 Major GC 經常會伴隨至少一次的 Minor GC（並非絕對），Major GC 的速度一般會比 Minor GC 的慢 10 倍以上。
測試：
public class GCTest {
public static void main(String[] args) {
byte[] allocation1, allocation2;
allocation1 = new byte[30900*1024];
//allocation2 = new byte[900*1024];
}
}通過以下方式執行：
新增的引數：-XX:+PrintGCDetails
執行結果 (紅色字型描述有誤，應該是對應於 JDK1.7 的永久代)：
從上圖我們可以看出 eden 區記憶體幾乎已經被分配完全（即使程式什麼也不做，新生代也會使用 2000 多 k 記憶體）。假如我們再為 allocation2 分配記憶體會出現什麼情況呢？
allocation2 = new byte[900*1024];
簡單解釋一下為什麼會出現這種情況： 因為給 allocation2 分配記憶體的時候 eden 區記憶體幾乎已經被分配完了，我們剛剛講了當 Eden 區沒有足夠空間進行分配時，虛擬機器將發起一次 Minor GC.GC 期間虛擬機器又發現 allocation1 無法存入 Survivor 空間，所以只好通過 分配擔保機制 把新生代的物件提前轉移到老年代中去，老年代上的空間足夠存放 allocation1，所以不會出現 Full GC。執行 Minor GC 後，後面分配的物件如果能夠存在 eden 區的話，還是會在 eden 區分配記憶體。可以執行如下程式碼驗證：
public class GCTest {
public static void main(String[] args) {
byte[] allocation1, allocation2,allocation3,allocation4,allocation5;
allocation1 = new byte[32000*1024];
allocation2 = new byte[1000*1024];
allocation3 = new byte[1000*1024];
allocation4 = new byte[1000*1024];
allocation5 = new byte[1000*1024];
}
}
1.2 大物件直接進入老年代
大物件就是需要大量連續記憶體空間的物件（比如：字串、陣列）。
為什麼要這樣呢？
為了避免為大物件分配記憶體時由於分配擔保機制帶來的複製而降低效率。
1.3 長期存活的物件將進入老年代
既然虛擬機器採用了分代收集的思想來管理記憶體，那麼記憶體回收時就必須能識別哪些物件應放在新生代，哪些物件應放在老年代中。為了做到這一點，虛擬機器給每個物件一個物件年齡（Age）計數器。
如果物件在 Eden 出生並經過第一次 Minor GC 後仍然能夠存活，並且能被 Survivor 容納的話，將被移動到 Survivor 空間中，並將物件年齡設為 1.物件在 Survivor 中每熬過一次 MinorGC,年齡就增加 1 歲，當它的年齡增加到一定程度（預設為 15 歲），就會被晉升到老年代中。物件晉升到老年代的年齡閾值，可以通過引數 -XX:MaxTenuringThreshold 來設定。
1.4 動態物件年齡判定
為了更好的適應不同程式的記憶體情況，虛擬機器不是永遠要求物件年齡必須達到了某個值才能進入老年代，如果 Survivor 空間中相同年齡所有物件大小的總和大於 Survivor 空間的一半，年齡大於或等於該年齡的物件就可以直接進入老年代，無需達到要求的年齡。
2 物件已經死亡？
堆中幾乎放著所有的物件例項，對堆垃圾回收前的第一步就是要判斷那些物件已經死亡（即不能再被任何途徑使用的物件）。
2.1 引用計數法
給物件中新增一個引用計數器，每當有一個地方引用它，計數器就加 1；當引用失效，計數器就減 1；任何時候計數器為 0 的物件就是不可能再被使用的。
這個方法實現簡單，效率高，但是目前主流的虛擬機器中並沒有選擇這個演算法來管理記憶體，其最主要的原因是它很難解決物件之間相互迴圈引用的問題。 所謂物件之間的相互引用問題，如下面程式碼所示：除了物件 objA 和 objB 相互引用著對方之外，這兩個物件之間再無任何引用。但是他們因為互相引用對方，導致它們的引用計數器都不為 0，於是引用計數演算法無法通知 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 可達性分析演算法
這個演算法的基本思想就是通過一系列的稱為 “GC Roots” 的物件作為起點，從這些節點開始向下搜尋，節點所走過的路徑稱為引用鏈，當一個物件到 GC Roots 沒有任何引用鏈相連的話，則證明此物件是不可用的。
2.3 再談引用
無論是通過引用計數法判斷物件引用數量，還是通過可達性分析法判斷物件的引用鏈是否可達，判定物件的存活都與“引用”有關。
JDK1.2 之前，Java 中引用的定義很傳統：如果 reference 型別的資料儲存的數值代表的是另一塊記憶體的起始地址，就稱這塊記憶體代表一個引用。
JDK1.2 以後，Java 對引用的概念進行了擴充，將引用分為強引用、軟引用、弱引用、虛引用四種（引用強度逐漸減弱）
1．強引用（StrongReference）
以前我們使用的大部分引用實際上都是強引用，這是使用最普遍的引用。如果一個物件具有強引用，那就類似於必不可少的生活用品，垃圾回收器絕不會回收它。當記憶體空間不足，Java 虛擬機器寧願丟擲 OutOfMemoryError 錯誤，使程式異常終止，也不會靠隨意回收具有強引用的物件來解決記憶體不足問題。
2．軟引用（SoftReference）
如果一個物件只具有軟引用，那就類似於可有可無的生活用品。如果記憶體空間足夠，垃圾回收器就不會回收它，如果記憶體空間不足了，就會回收這些物件的記憶體。只要垃圾回收器沒有回收它，該物件就可以被程式使用。軟引用可用來實現記憶體敏感的快取記憶體。
軟引用可以和一個引用佇列（ReferenceQueue）聯合使用，如果軟引用所引用的物件被垃圾回收，JAVA 虛擬機器就會把這個軟引用加入到與之關聯的引用佇列中。
3．弱引用（WeakReference）
如果一個物件只具有弱引用，那就類似於可有可無的生活用品。弱引用與軟引用的區別在於：只具有弱引用的物件擁有更短暫的生命週期。在垃圾回收器執行緒掃描它所管轄的記憶體區域的過程中，一旦發現了只具有弱引用的物件，不管當前記憶體空間足夠與否，都會回收它的記憶體。不過，由於垃圾回收器是一個優先順序很低的執行緒， 因此不一定會很快發現那些只具有弱引用的物件。
弱引用可以和一個引用佇列（ReferenceQueue）聯合使用，如果弱引用所引用的物件被垃圾回收，Java 虛擬機器就會把這個弱引用加入到與之關聯的引用佇列中。
4．虛引用（PhantomReference）
"虛引用"顧名思義，就是形同虛設，與其他幾種引用都不同，虛引用並不會決定物件的生命週期。如果一個物件僅持有虛引用，那麼它就和沒有任何引用一樣，在任何時候都可能被垃圾回收。
虛引用主要用來跟蹤物件被垃圾回收的活動。
虛引用與軟引用和弱引用的一個區別在於： 虛引用必須和引用佇列（ReferenceQueue）聯合使用。當垃圾回收器準備回收一個物件時，如果發現它還有虛引用，就會在回收物件的記憶體之前，把這個虛引用加入到與之關聯的引用佇列中。程式可以通過判斷引用佇列中是否已經加入了虛引用，來了解被引用的物件是否將要被垃圾回收。程式如果發現某個虛引用已經被加入到引用佇列，那麼就可以在所引用的物件的記憶體被回收之前採取必要的行動。
特別注意，在程式設計中一般很少使用弱引用與虛引用，使用軟引用的情況較多，這是因為軟引用可以加速 JVM 對垃圾記憶體的回收速度，可以維護系統的執行安全，防止記憶體溢位（OutOfMemory）等問題的產生。
2.4 不可達的物件並非“非死不可”
即使在可達性分析法中不可達的物件，也並非是“非死不可”的，這時候它們暫時處於“緩刑階段”，要真正宣告一個物件死亡，至少要經歷兩次標記過程；可達性分析法中不可達的物件被第一次標記並且進行一次篩選，篩選的條件是此物件是否有必要執行 finalize 方法。當物件沒有覆蓋 finalize 方法，或 finalize 方法已經被虛擬機器呼叫過時，虛擬機器將這兩種情況視為沒有必要執行。
被判定為需要執行的物件將會被放在一個佇列中進行第二次標記，除非這個物件與引用鏈上的任何一個物件建立關聯，否則就會被真的回收。
2.5 如何判斷一個常量是廢棄常量
執行時常量池主要回收的是廢棄的常量。那麼，我們如何判斷一個常量是廢棄常量呢？
假如在常量池中存在字串 "abc"，如果當前沒有任何 String 物件引用該字串常量的話，就說明常量 "abc" 就是廢棄常量，如果這時發生記憶體回收的話而且有必要的話，"abc" 就會被系統清理出常量池。
注意：我們在 可能是把 Java 記憶體區域講的最清楚的一篇文章 也講了 JDK1.7 及之後版本的 JVM 已經將執行時常量池從方法區中移了出來，在 Java 堆（Heap）中開闢了一塊區域存放執行時常量池。
2.6 如何判斷一個類是無用的類
方法區主要回收的是無用的類，那麼如何判斷一個類是無用的類的呢？
判定一個常量是否是“廢棄常量”比較簡單，而要判定一個類是否是“無用的類”的條件則相對苛刻許多。類需要同時滿足下面 3 個條件才能算是 “無用的類” ：
- 該類所有的例項都已經被回收，也就是 Java 堆中不存在該類的任何例項。
- 載入該類的 ClassLoader 已經被回收。
- 該類對應的 java.lang.Class 物件沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。
虛擬機器可以對滿足上述 3 個條件的無用類進行回收，這裡說的僅僅是“可以”，而並不是和物件一樣不使用了就會必然被回收。
3 垃圾收集演算法
3.1 標記-清除演算法
該演算法分為“標記”和“清除”階段：首先標記出所有需要回收的物件，在標記完成後統一回收所有被標記的物件。它是最基礎的收集演算法，後續的演算法都是對其不足進行改進得到。這種垃圾收集演算法會帶來兩個明顯的問題：
- 效率問題
- 空間問題（標記清除後會產生大量不連續的碎片）
3.2 複製演算法
為了解決效率問題，“複製”收集演算法出現了。它可以將記憶體分為大小相同的兩塊，每次使用其中的一塊。當這一塊的記憶體使用完後，就將還存活的物件複製到另一塊去，然後再把使用的空間一次清理掉。這樣就使每次的記憶體回收都是對記憶體區間的一半進行回收。
3.3 標記-整理演算法
根據老年代的特點提出的一種標記演算法，標記過程仍然與“標記-清除”演算法一樣，但後續步驟不是直接對可回收物件回收，而是讓所有存活的物件向一端移動，然後直接清理掉端邊界以外的記憶體。
3.4 分代收集演算法
當前虛擬機器的垃圾收集都採用分代收集演算法，這種演算法沒有什麼新的思想，只是根據物件存活週期的不同將記憶體分為幾塊。一般將 java 堆分為新生代和老年代，這樣我們就可以根據各個年代的特點選擇合適的垃圾收集演算法。
比如在新生代中，每次收集都會有大量物件死去，所以可以選擇複製演算法，只需要付出少量物件的複製成本就可以完成每次垃圾收集。而老年代的物件存活機率是比較高的，而且沒有額外的空間對它進行分配擔保，所以我們必須選擇“標記-清除”或“標記-整理”演算法進行垃圾收集。
延伸面試問題： HotSpot 為什麼要分為新生代和老年代？
根據上面的對分代收集演算法的介紹回答。
4 垃圾收集器
如果說收集演算法是記憶體回收的方法論，那麼垃圾收集器就是記憶體回收的具體實現。
雖然我們對各個收集器進行比較，但並非要挑選出一個最好的收集器。因為直到現在為止還沒有最好的垃圾收集器出現，更加沒有萬能的垃圾收集器，我們能做的就是根據具體應用場景選擇適合自己的垃圾收集器。試想一下：如果有一種四海之內、任何場景下都適用的完美收集器存在，那麼我們的 HotSpot 虛擬機器就不會實現那麼多不同的垃圾收集器了。
4.1 Serial 收集器
Serial（序列）收集器收集器是最基本、歷史最悠久的垃圾收集器了。大家看名字就知道這個收集器是一個單執行緒收集器了。它的 “單執行緒” 的意義不僅僅意味著它只會使用一條垃圾收集執行緒去完成垃圾收集工作，更重要的是它在進行垃圾收集工作的時候必須暫停其他所有的工作執行緒（ "Stop The World" ），直到它收集結束。
新生代採用複製演算法，老年代採用標記-整理演算法。
虛擬機器的設計者們當然知道 Stop The World 帶來的不良使用者體驗，所以在後續的垃圾收集器設計中停頓時間在不斷縮短（仍然還有停頓，尋找最優秀的垃圾收集器的過程仍然在繼續）。
但是 Serial 收集器有沒有優於其他垃圾收集器的地方呢？當然有，它簡單而高效（與其他收集器的單執行緒相比）。Serial 收集器由於沒有執行緒互動的開銷，自然可以獲得很高的單執行緒收集效率。Serial 收集器對於執行在 Client 模式下的虛擬機器來說是個不錯的選擇。
4.2 ParNew 收集器
ParNew 收集器其實就是 Serial 收集器的多執行緒版本，除了使用多執行緒進行垃圾收集外，其餘行為（控制引數、收集演算法、回收策略等等）和 Serial 收集器完全一樣。
新生代採用複製演算法，老年代採用標記-整理演算法。
它是許多執行在 Server 模式下的虛擬機器的首要選擇，除了 Serial 收集器外，只有它能與 CMS 收集器（真正意義上的併發收集器，後面會介紹到）配合工作。
並行和併發概念補充：
並行（Parallel） ：指多條垃圾收集執行緒並行工作，但此時使用者執行緒仍然處於等待狀態。
併發（Concurrent）：指使用者執行緒與垃圾收集執行緒同時執行（但不一定是並行，可能會交替執行），使用者程式在繼續執行，而垃圾收集器執行在另一個 CPU 上。
4.3 Parallel Scavenge 收集器
Parallel Scavenge 收集器也是使用複製演算法的多執行緒收集器，它看上去幾乎和ParNew都一樣。 那麼它有什麼特別之處呢？
-XX:+UseParallelGC
使用 Parallel 收集器+ 老年代序列
-XX:+UseParallelOldGC
使用 Parallel 收集器+ 老年代並行
Parallel Scavenge 收集器關注點是吞吐量（高效率的利用 CPU）。CMS 等垃圾收集器的關注點更多的是使用者執行緒的停頓時間（提高使用者體驗）。所謂吞吐量就是 CPU 中用於執行使用者程式碼的時間與 CPU 總消耗時間的比值。 Parallel Scavenge 收集器提供了很多引數供使用者找到最合適的停頓時間或最大吞吐量，如果對於收集器運作不太瞭解的話，手工優化存在困難的話可以選擇把記憶體管理優化交給虛擬機器去完成也是一個不錯的選擇。
新生代採用複製演算法，老年代採用標記-整理演算法。
4.4.Serial Old 收集器
Serial 收集器的老年代版本，它同樣是一個單執行緒收集器。它主要有兩大用途：一種用途是在 JDK1.5 以及以前的版本中與 Parallel Scavenge 收集器搭配使用，另一種用途是作為 CMS 收集器的後備方案。
4.5 Parallel Old 收集器
Parallel Scavenge 收集器的老年代版本。使用多執行緒和“標記-整理”演算法。在注重吞吐量以及 CPU 資源的場合，都可以優先考慮 Parallel Scavenge 收集器和 Parallel Old 收集器。
4.6 CMS 收集器
CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。它非常符合在注重使用者體驗的應用上使用。
CMS（Concurrent Mark Sweep）收集器是 HotSpot 虛擬機器第一款真正意義上的併發收集器，它第一次實現了讓垃圾收集執行緒與使用者執行緒（基本上）同時工作。
從名字中的Mark Sweep這兩個詞可以看出，CMS 收集器是一種 “標記-清除”演算法實現的，它的運作過程相比於前面幾種垃圾收集器來說更加複雜一些。整個過程分為四個步驟：
- 初始標記： 暫停所有的其他執行緒，並記錄下直接與 root 相連的物件，速度很快 ；
- 併發標記： 同時開啟 GC 和使用者執行緒，用一個閉包結構去記錄可達物件。但在這個階段結束，這個閉包結構並不能保證包含當前所有的可達物件。因為使用者執行緒可能會不斷的更新引用域，所以 GC 執行緒無法保證可達性分析的實時性。所以這個演算法裡會跟蹤記錄這些發生引用更新的地方。
- 重新標記： 重新標記階段就是為了修正併發標記期間因為使用者程式繼續執行而導致標記產生變動的那一部分物件的標記記錄，這個階段的停頓時間一般會比初始標記階段的時間稍長，遠遠比並發標記階段時間短
- 併發清除： 開啟使用者執行緒，同時 GC 執行緒開始對為標記的區域做清掃。
從它的名字就可以看出它是一款優秀的垃圾收集器，主要優點：併發收集、低停頓。但是它有下面三個明顯的缺點：
- 對 CPU 資源敏感；
- 無法處理浮動垃圾；
- 它使用的回收演算法-“標記-清除”演算法會導致收集結束時會有大量空間碎片產生。
4.7 G1 收集器
G1 (Garbage-First) 是一款面向伺服器的垃圾收集器,主要針對配備多顆處理器及大容量記憶體的機器. 以極高概率滿足 GC 停頓時間要求的同時,還具備高吞吐量效能特徵.
被視為 JDK1.7 中 HotSpot 虛擬機器的一個重要進化特徵。它具備一下特點：
- 並行與併發：G1 能充分利用 CPU、多核環境下的硬體優勢，使用多個 CPU（CPU 或者 CPU 核心）來縮短 Stop-The-World 停頓時間。部分其他收集器原本需要停頓 Java 執行緒執行的 GC 動作，G1 收集器仍然可以通過併發的方式讓 java 程式繼續執行。
- 分代收集：雖然 G1 可以不需要其他收集器配合就能獨立管理整個 GC 堆，但是還是保留了分代的概念。
- 空間整合：與 CMS 的“標記--清理”演算法不同，G1 從整體來看是基於“標記整理”演算法實現的收集器；從區域性上來看是基於“複製”演算法實現的。
- 可預測的停頓：這是 G1 相對於 CMS 的另一個大優勢，降低停頓時間是 G1 和 CMS 共同的關注點，但 G1 除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度為 M 毫秒的時間片段內。
G1 收集器的運作大致分為以下幾個步驟：
- 初始標記
- 併發標記
- 最終標記
- 篩選回收
G1 收集器在後臺維護了一個優先列表，每次根據允許的收集時間，優先選擇回收價值最大的 Region(這也就是它的名字 Garbage-First 的由來)。這種使用 Region 劃分記憶體空間以及有優先順序的區域回收方式，保證了 GF 收集器在有限時間內可以儘可能高的收集效率（把記憶體化整為零）。
參考
- 《深入理解 Java 虛擬機器：JVM 高階特性與最佳實踐（第二版》
- https://my.oschina.net/hosee/blog/644618
- https://docs.oracle.com/javase/specs/jvms/se8/html/index.html