本文轉自：https://www.cnblogs.com/snailclimb/p/9086341.html

本系列文章將整理到我在GitHub上的《Java面試指南》倉庫，更多精彩內容請到我的倉庫裡檢視
> https://github.com/h2pl/Java-Tutorial

喜歡的話麻煩點下Star哈

文章將同步到我的個人部落格：
> www.how2playlife.com

本文是微信公眾號【Java技術江湖】的《深入理解JVM虛擬機器》其中一篇，本文部分內容來源於網路，為了把本文主題講得清晰透徹，也整合了很多我認為不錯的技術部落格內容，引用其中了一些比較好的部落格文章，如有侵權，請聯絡作者。

該系列博文會告訴你如何從入門到進階，一步步地學習JVM基礎知識，並上手進行JVM調優實戰，JVM是每一個Java工程師必須要學習和理解的知識點，你必須要掌握其實現原理，才能更完整地瞭解整個Java技術體系，形成自己的知識框架。

為了更好地總結和檢驗你的學習成果，本系列文章也會提供每個知識點對應的面試題以及參考答案。

如果對本系列文章有什麼建議，或者是有什麼疑問的話，也可以關注公眾號【Java技術江湖】聯絡作者，歡迎你參與本系列博文的創作和修訂。

**本節常見面試題（推薦帶著問題閱讀，問題答案在文中都有提到）：**

如何判斷物件是否死亡（兩種方法）。

簡單的介紹一下強引用、軟引用、弱引用、虛引用（虛引用與軟引用和弱引用的區別、使用軟引用能帶來的好處）。

垃圾收集有哪些演算法，各自的特點？

HotSpot為什麼要分為新生代和老年代？

常見的垃圾回收器有那些？

介紹一下CMS,G1收集器。

Minor Gc和Full GC 有什麼不同呢？

## 1 概述

首先所需要考慮：
- 那些垃圾需要回收？
- 什麼時候回收？
- 如何回收？

當需要排查各種 記憶體溢位問題、當垃圾收集稱為系統達到更高併發的瓶頸時，我們就需要對這些“自動化”的技術實施必要的監控和調節。

## 2 物件已經死亡？

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

### 2.1引用計數法

給物件中新增一個引用計數器，每當有一個地方引用它，計數器就加1；當引用失效，計數器就減1；任何時候計數器為0的物件就是不可能再被使用的。

這個方法實現簡單，效率高，但是目前主流的虛擬機器中並沒有選擇這個演算法來管理記憶體，其最主要的原因是它很難解決物件之間相互迴圈引用的問題。

### 2.2可達性分析演算法

這個演算法的基本思想就是透過一系列的稱為 **“GC Roots”** 的物件作為起點，從這些節點開始向下搜尋，節點所走過的路徑稱為引用鏈，當一個物件到GC Roots沒有任何引用鏈相連的話，則證明此物件是不可用的。
![可達性分析演算法](https://user-gold-cdn.xitu.io/2018/4/28/1630be33dd8c8e32?w=807&h=485&f=png&s=223006)

### 2.3 再談引用

JDK1.2以後，Java對引用的感念進行了擴充，將引用分為強引用、軟引用、弱引用、虛引用四種（引用強度逐漸減弱）

**1．強引用**

以前我們使用的大部分引用實際上都是強引用，這是使用最普遍的引用。如果一個物件具有強引用，那就類似於**必不可少的生活用品**，垃圾回收器絕不會回收它。當記憶體空 間不足，Java虛擬機器寧願丟擲OutOfMemoryError錯誤，使程式異常終止，也不會靠隨意回收具有強引用的物件來解決記憶體不足問題。

**2．軟引用（SoftReference）**

如果一個物件只具有軟引用，那就類似於**可有可物的生活用品**。如果記憶體空間足夠，垃圾回收器就不會回收它，如果記憶體空間不足了，就會回收這些物件的記憶體。只要垃圾回收器沒有回收它，該物件就可以被程式使用。軟引用可用來實現記憶體敏感的快取記憶體。

軟引用可以和一個引用佇列（ReferenceQueue）聯合使用，如果軟引用所引用的物件被垃圾回收，JAVA虛擬機器就會把這個軟引用加入到與之關聯的引用佇列中。

**3．弱引用（WeakReference）**

如果一個物件只具有弱引用，那就類似於**可有可物的生活用品**。弱引用與軟引用的區別在於：只具有弱引用的物件擁有更短暫的生命週期。在垃圾回收器執行緒掃描它 所管轄的記憶體區域的過程中，一旦發現了只具有弱引用的物件，不管當前記憶體空間足夠與否，都會回收它的記憶體。不過，由於垃圾回收器是一個優先順序很低的執行緒， 因此不一定會很快發現那些只具有弱引用的物件。

弱引用可以和一個引用佇列（ReferenceQueue）聯合使用，如果弱引用所引用的物件被垃圾回收，Java虛擬機器就會把這個弱引用加入到與之關聯的引用佇列中。

**4．虛引用（PhantomReference）**

“虛引用”顧名思義，就是形同虛設，與其他幾種引用都不同，虛引用並不會決定物件的生命週期。如果一個物件僅持有虛引用，那麼它就和沒有任何引用一樣，在任何時候都可能被垃圾回收。

**虛引用主要用來跟蹤物件被垃圾回收的活動**。

**虛引用與軟引用和弱引用的一個區別在於：** 虛引用必須和引用佇列（ReferenceQueue）聯合使用。當垃 圾回收器準備回收一個物件時，如果發現它還有虛引用，就會在回收物件的記憶體之前，把這個虛引用加入到與之關聯的引用佇列中。程式可以透過判斷引用佇列中是 否已經加入了虛引用，來了解被引用的物件是否將要被垃圾回收。程式如果發現某個虛引用已經被加入到引用佇列，那麼就可以在所引用的物件的記憶體被回收之前採取必要的行動。

特別注意，在程式設計中一般很少使用弱引用與虛引用，使用軟引用的情況較多，這是因為**軟引用可以加速JVM對垃圾記憶體的回收速度，可以維護系統的執行安全，防止記憶體溢位（OutOfMemory）等問題的產生**。

### 2.4 生存還是死亡

即使在可達性分析法中不可達的物件，也並非是“非死不可”的，這時候它們暫時處於“緩刑階段”，要真正宣告一個物件死亡，至少要經歷兩次標記過程；可達性分析法中不可達的物件被第一次標記並且進行一次篩選，篩選的條件是此物件是否有必要執行finalize方法。當物件沒有覆蓋finalize方法，或finalize方法已經被虛擬機器呼叫過時，虛擬機器將這兩種情況視為沒有必要執行。被判定為需要執行的物件將會被放在一個佇列中進行第二次標記，除非這個物件與引用鏈上的任何一個物件建立關聯，否則就會被真的回收。

### 2.5 回收方法區

方法區（或Hotspot虛擬中的永久代）的垃圾收集主要回收兩部分內容：**廢棄常量和無用的類。**

判定一個常量是否是“廢棄常量”比較簡單，而要判定一個類是否是“無用的類”的條件則相對苛刻許多。類需要同時滿足下面3個條件才能算是 **“無用的類”** ：
- 該類所有的例項都已經被回收，也就是Java堆中不存在該類的任何例項。
- 載入該類的ClassLoader已經被回收。
- 該類對應的java.lang.Class物件沒有在任何地方被引用，無法在任何地方透過反射訪問該類的方法。

## 3 垃圾收集演算法

### 3.1 標記-清除演算法

演算法分為“標記”和“清除”階段：首先標記出所有需要回收的物件，在標記完成後統一回收所有被標記的物件。它是最基礎的收集演算法，會帶來兩個明顯的問題；1：效率問題和2：空間問題（標記清除後會產生大量不連續的碎片）
![標記-清除演算法](https://user-gold-cdn.xitu.io/2018/4/28/1630bedcd37144b0?w=809&h=438&f=png&s=143686)

### 3.2 複製演算法

為了解決效率問題，“複製”收集演算法出現了。它可以將記憶體分為大小相同的兩塊，每次使用其中的一塊。當這一塊的記憶體使用完後，就將還存活的物件複製到另一塊去，然後再把使用的空間一次清理掉。這樣就使每次的記憶體回收都是對記憶體區間的一半進行回收。

![複製演算法](https://user-gold-cdn.xitu.io/2018/4/28/1630bee78552641e?w=829&h=420&f=png&s=188338)

### 3.3 標記-整理演算法

根據老年代的特點特出的一種標記演算法，標記過程仍然與“標記-清除”演算法一樣，但後續步驟不是直接對可回收物件回收，而是讓所有存活的物件向一段移動，然後直接清理掉端邊界以外的記憶體。

![標記-整理演算法](https://user-gold-cdn.xitu.io/2018/4/28/1630bef38f362a98?w=816&h=459&f=png&s=147162)

### 3.4分代收集演算法

當前虛擬機器的垃圾手機都採用分代收集演算法，這種演算法沒有什麼新的思想，只是根據物件存活週期的不同將記憶體分為幾塊。一般將java堆分為新生代和老年代，這樣我們就可以根據各個年代的特點選擇合適的垃圾收集演算法。

比如在新生代中，每次收集都會有大量物件死去，所以可以選擇複製演算法，只需要付出少量物件的複製成本就可以完成每次垃圾收集。而老年代的物件存活機率是比較高的所以我們可以選擇“標記-清理”或“標記-整理”演算法進行垃圾收集。

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

根據上面的對分代收集演算法的介紹回答。

## 4 垃圾收集器

**如果說收集演算法是記憶體回收的方法論，那麼垃圾收集器就是記憶體回收的具體實現。**
雖然我們對各個收集器進行比較，但並非了挑選出一個最好的收集器。因為知道現在位置還沒有最好的垃圾收集器出現，更加沒有萬能的垃圾收集器，**我們能做的就是根據具體應用場景選擇適合自己的垃圾收集器**。試想一下：如果有一種四海之內、任何場景下都適用的完美收集器存在，那麼我們的HotSpot虛擬機器就不會實現那麼多不同的垃圾收集器了。

### 4.1 Serial收集器

Serial（序列）收集器收集器是最基本、歷史最悠久的垃圾收集器了。大家看名字就知道這個收集器是一個單執行緒收集器了。它的 **“單執行緒”** 的意義不僅僅意味著它只會使用一條垃圾收集執行緒去完成垃圾收集工作，更重要的是它在進行垃圾收集工作的時候必須暫停其他所有的工作執行緒（ **“Stop The World”** 瞭解一下），直到它收集結束。
![Serial收集器](https://user-gold-cdn.xitu.io/2018/4/28/1630c032627e6728?w=767&h=177&f=png&s=80000)

虛擬機器的設計者們當然知道Stop The World帶來的不良使用者體驗，所以在後續的垃圾收集器設計中停頓時間在不斷縮短（仍然還有停頓，尋找最優秀的垃圾收集器的過程仍然在繼續）。

但是Serial收集器有沒有優於其他垃圾收集器的地方呢？當然有，它**簡單而高效（與其他收集器的單執行緒相比）**。Serial收集器由於沒有執行緒互動的開銷，自然可以獲得很高的單執行緒收集效率。Serial收集器對於執行在Client模式下的虛擬機器來說是個不錯的選擇。

### 4.2 ParNew收集器

**ParNew收集器其實就是Serial收集器的多執行緒版本，除了使用多執行緒進行垃圾收集外，其餘行為（控制引數、收集演算法、回收策略等等）和Serial收集器完全一樣。**

![ParNew收集器](https://user-gold-cdn.xitu.io/2018/4/28/1630c07412c5e73a?w=785&h=187&f=png&s=87246)
它是許多執行在Server模式下的虛擬機器的首要選擇，除了Serial收集器外，只有它能與CMS收集器（真正意義上的併發收集器，後面會介紹到）配合工作。

**並行和併發概念補充：**

*   **並行（Parallel）** ：指多條垃圾收集執行緒並行工作，但此時使用者執行緒仍然處於等待狀態。

*   **併發（Concurrent）**：指使用者執行緒與垃圾收集執行緒同時執行（但不一定是並行，可能會交替執行），使用者程式在繼續執行，而垃圾收集器執行在另一個CPU上。

### 4.3 Parallel Scavenge收集器

Parallel Scavenge收集器是一個新生代收集器，它也是使用複製演算法的收集器，又是並行的的多執行緒收集器。。。那麼它有什麼特別之處呢？

**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）收集器是一種以獲取最短回收停頓時間為目標的收集器。它而非常符合在注重使用者體驗的應用上使用。**

從名字中的**Mark Sweep**這兩個詞可以看出，CMS收集器是一種 **“標記-清除”演算法**實現的，它的運作過程相比於前面幾種垃圾收集器來說更加複雜一些。整個過程分為四個步驟：

*   **初始標記：** 暫停所有的其他執行緒，並記錄下直接與root相連的物件，速度很快 ；
*   **併發標記：** 同時開啟GC和使用者執行緒，用一個閉包結構去記錄可達物件。但在這個階段結束，這個閉包結構並不能保證包含當前所有的可達物件。因為使用者執行緒可能會不斷的更新引用域，所以GC執行緒無法保證可達性分析的實時性。所以這個演算法裡會跟蹤記錄這些發生引用更新的地方。
*   **重新標記：** 重新標記階段就是為了修正併發標記期間因為使用者程式繼續執行而導致標記產生變動的那一部分物件的標記記錄，這個階段的停頓時間一般會比初始標記階段的時間稍長，遠遠比並發標記階段時間短
*   **併發清除：** 開啟使用者執行緒，同時GC執行緒開始對為標記的區域做清掃。

![CMS收集器](https://user-gold-cdn.xitu.io/2018/4/28/1630c17fcd5f9497?w=816&h=210&f=png&s=91490)

從它的名字就可以看出它是一款優秀的垃圾收集器，主要優點：**併發收集、低停頓**。但是它有下面三個明顯的缺點：
- **對CPU資源敏感；**
- **無法處理浮動垃圾；**
- **它使用的回收演算法-“標記-清除”演算法會導致收集結束時會有大量空間碎片產生。**

### 4.7 G1收集器

上一代的垃圾收集器(序列serial, 並行parallel, 以及CMS)都把堆記憶體劃分為固定大小的三個部分: 年輕代(young generation), 年老代(old generation), 以及持久代(permanent generation).

![年輕代(young generation), 年老代(old generation), 以及持久代(permanent generation)](https://user-gold-cdn.xitu.io/2018/4/28/1630c1b1b3b95713?w=960&h=513&f=png&s=24990)

**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和ＣＭＳ共同的關注點，但Ｇ１除了追求低停頓外，還能建立可預測的停頓時間模型，能讓使用者明確指定在一個長度為M毫秒的時間片段內。

**G1收集器在後臺維護了一個優先列表，每次根據允許的收集時間，優先選擇回收價值最大的Region(這也就是它的名字Garbage-First的由來)**。這種使用Region劃分記憶體空間以及有優先順序的區域回收方式，保證了GF收集器在有限時間內可以儘可能高的收集效率（把記憶體化整為零）。

G1收集器的運作大致分為以下幾個步驟：
- **初始標記**
- **併發標記**
- **最終標記**
- **篩選回收**

上面幾個步驟的運作過程和CMS有很多相似之處。初始標記階段僅僅只是標記一下GC Roots能直接關聯到的物件，並且修改TAMS的值，讓下一個階段使用者程式併發執行時，能在正確可用的Region中建立新物件，這一階段需要停頓執行緒，但是耗時很短，併發標記階段是從GC Root開始對堆中物件進行可達性分析，找出存活的物件，這階段時耗時較長，但可與使用者程式併發執行。而最終標記階段則是為了修正在併發標記期間因使用者程式繼續運作而導致標記產生變動的那一部分標記記錄，虛擬機器將這段時間物件變化記錄線上程Remenbered Set Logs裡面，最終標記階段需要把Remembered Set Logs的資料合併到Remembered Set Logs裡面，最終標記階段需要把Remembered Set Logs的資料合併到Remembered Set中，這一階段需要停頓執行緒，但是可並行執行。最後在篩選回收階段首先對各個Region的回收價值和成本進行排序，根據使用者所期望的GC停頓時間來制定回收計劃。

![G1收集器](https://user-gold-cdn.xitu.io/2018/4/28/1630c1e0bb4557d8?w=814&h=206&f=png&s=98459)

## 5 記憶體分配與回收策略

### 5.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倍以上。

### 5.2 大物件直接進入老年代

大物件就是需要大量連續記憶體空間的物件（比如：字串、陣列）。

### 5.3長期存活的物件將進入老年代

既然虛擬機器採用了分代收集的思想來管理記憶體，那麼記憶體回收時就必須能識別那些物件應放在新生代，那些物件應放在老年代中。為了做到這一點，虛擬機器給每個物件一個物件年齡（Age）計數器。

### 5.4 動態物件年齡判定

為了更好的適應不同程式的記憶體情況，虛擬機器不是永遠要求物件年齡必須達到了某個值才能進入老年代，如果Survivor 空間中相同年齡所有物件大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的物件就可以直接進入老年代，無需達到要求的年齡。

## 總結：

本節介紹了垃圾收集演算法，幾款JDK1.7中提供的垃圾收集器特點以及運作原理。
記憶體回收與垃圾收集器在很多時候都是影響系統效能、併發能力的主要因素之一，虛擬機器之所以提供多種不同的收集器以及大量調節引數，是因為只有根據實際應用的需求、實現方式選擇最優的收集方式才能獲取最高的效能。沒有固定收集器、引數組合、也沒有最優的調優方法，那麼必須瞭解每一個具體收集器的行為、優勢和劣勢、調節引數。

深入理解JVM虛擬機器3：垃圾回收器詳解

相關文章