![](http://img.blog.itpub.net/blog/2020/03/13/51cc57789cf574f0.png?x-oss-process=style/bb)

Java堆中存放著大量的Java物件例項，在垃圾收集器回收記憶體前，第一件事情就是確定哪些物件是“活著的”，哪些是可以回收的。

Java中Stop-The-World機制簡稱STW，是在執行垃圾收集演算法時，Java應用程式的其他所有執行緒都被掛起（除了垃圾收集幫助器之外）。Java中一種全域性暫停現象，全域性停頓，所有Java程式碼停止，native程式碼可以執行，但不能與JVM互動；這些現象多半是由於gc引起。

# 一. 判斷物件是否存活的演算法

**1. 引用計數演算法（基本棄用）**

引用計數演算法是判斷物件是否存活的基本演算法：給每個物件新增一個引用計數器，沒當一個地方引用它的時候，計數器值加1；當引用失效後，計數器值減1。但是這種方法有一個致命的缺陷，當兩個物件相互引用時會導致這兩個都無法被回收。

**2. 根搜尋演算法（目前使用中）**

在主流的商用語言中（Java、C#...）都是使用根搜尋演算法來判斷物件是否存活。對於程式來說，根物件總是可以訪問的。從這些根物件開始，任何可以被觸及的物件都被認為是"活著的"的物件。無法觸及的物件被認為是垃圾，需要被回收。

Java虛擬機器的根物件集合根據實現不同而不同，但是總會包含以下幾個方面：

- 棧（棧幀中的本地變數表）中引用的物件。
- 方法區中的類靜態屬性引用的變數。
- 方法區中的常量引用的變數。
- 本地方法JNI的引用物件。

區分活動物件和垃圾的兩個基本方法是引用計數和根搜尋。 引用計數是透過為堆中每個物件儲存一個計數來區分活動物件和垃圾。根搜尋演算法實際上是追蹤從根結點開始的引用圖。

在主流的商用程式語言（如我們的Java）的主流實現中，都是透過可達性分析演算法來判定物件是否存活的。

# 二. 垃圾收集演算法

**1. 標記-清除演算法**

分標記和清除兩個階段：首先標記處所需要回收的物件，在標記完成後統一回收所有被標記的物件。

它有兩點不足：一個效率問題，標記和清除過程都效率不高；一個是空間問題，標記清除之後會產生大量不連續的記憶體碎片（類似於我們電腦的磁碟碎片），空間碎片太多導致需要分配大物件時無法找到足夠的連續記憶體而不得不提前觸發另一次垃圾回收動作。

**2. 複製演算法**

為了解決效率問題，出現了“複製”演算法，他將可用記憶體按容量劃分為大小相等的兩塊，每次只需要使用其中一塊。當一塊記憶體用完了，將還存活的物件複製到另一塊上面，然後再把剛剛用完的記憶體空間一次清理掉。這樣就解決了記憶體碎片問題，但是代價就是可以用內容就縮小為原來的一半。

**3. 標記-整理演算法**

複製演算法在物件存活率較高時就會進行頻繁的複製操作，效率將降低。因此又有了標記-整理演算法，標記過程同標記-清除演算法，但是在後續步驟不是直接對物件進行清理，而是讓所有存活的物件都向一側移動，然後直接清理掉端邊界以外的記憶體。

**4. 分代收集法**

當前商業虛擬機器的GC都是採用分代收集演算法

為了增大垃圾收集的效率，所以JVM將堆進行分代，分為不同的部分，一般有三部分，新生代，老年代和永久代（在新的版本中已經將永久代廢棄，引入了元空間的概念，永久代使用的是JVM記憶體而元空間直接使用實體記憶體）：

- **新生代（對應minor GC）**：所有新new出來的物件都會最先出現在新生代中，當新生代這部分記憶體滿了之後，就會發起一次垃圾收集事件，這種發生在新生代的垃圾收集稱為Minor collections。這種收集通常比較快，因為新生代的大部分物件都是需要回收的，那些暫時無法回收的就會被移動到老年代。
- **老年代（對應Full GC）**：老年代用來儲存那些存活時間較長的物件。一般來說，我們會給新生代的物件限定一個存活的時間，當達到這個時間還沒有被收集的時候就會被移動到老年代中。
- **永久代**：用於存放靜態檔案，如Java類、方法等。持久代對垃圾回收沒有顯著影響，但是有些應用可能動態生成或者呼叫一些class，例如Hibernate 等，在這種時候需要設定一個比較大的持久代空間來存放這些執行過程中新增的類。

**程式中主動呼叫System.gc()強制執行的GC為Full GC**。

大概流程：

記憶體分割槽：

年輕代(Young Generation)（Eden,Survivor-s0,Survivor-s1，大小比例預設為8:1:1）

年老代(Old Generation)

永久代(Permanent Generation)。（包含應用的類/方法資訊, 以及JRE庫的類和方法資訊.和垃圾回收基本無關）

新生代中的物件“朝生夕死”，每次GC時都會有大量物件死去，少量存活，使用複製演算法。新生代又分為Eden區和Survivor區（Survivor from、Survivor to），大小比例預設為8:1:1。

老年代中的物件因為物件存活率高、沒有額外空間進行分配擔保，就使用標記-清除或標記-整理演算法。

新產生的物件優先進去Eden區，當Eden區滿了之後再使用Survivor from，當Survivor from 也滿了之後就進行Minor GC（新生代GC），將Eden和Survivor from中存活的物件copy進入Survivor to，然後清空Eden和Survivor from，這個時候原來的Survivor from成了新的Survivor to，原來的Survivor to成了新的Survivor from。複製的時候，如果Survivor to 無法容納全部存活的物件，則根據老年代的分配擔保（類似於銀行的貸款擔保）將物件copy進去老年代，如果老年代也無法容納，則進行Full GC（老年代GC）。

- 大物件直接進入老年代：JVM中有個引數配置-XX:PretenureSizeThreshold，令大於這個設定值的物件直接進入老年代，目的是為了避免在Eden和Survivor區之間發生大量的記憶體複製。
- 長期存活的物件進入老年代：JVM給每個物件定義一個物件年齡計數器，如果物件在Eden出生並經過第一次Minor GC後仍然存活，並且能被Survivor容納，將被移入Survivor並且年齡設定為1。每熬過一次Minor GC，年齡就加1，當他的年齡到一定程度（預設為15歲，可以透過XX:MaxTenuringThreshold來設定），就會移入老年代。
- 但是JVM並不是永遠要求年齡必須達到最大年齡才會晉升老年代，如果Survivor 空間中相同年齡（如年齡為x）所有物件大小的總和大於Survivor的一半，年齡大於等於x的所有物件直接進入老年代，無需等到最大年齡要求。

# 三. 垃圾收集器

垃圾回收演算法是方法論，垃圾回收器是實現。

- **Serial收集器**：序列收集器是最古老，最穩定以及效率高的收集器，可能會產生較長的停頓，只使用一個執行緒去回收。（STW）它是虛擬機器執行在client模式下的預設新生代收集器：簡單而高效（與其他收集器的單個執行緒相比，因為沒有執行緒切換的開銷等）。
- **ParNew收集器**：ParNew收集器其實就是Serial收集器的多執行緒版本。（STW）是許多執行在Server模式下的JVM中首選的新生代收集器，其中一個很重還要的原因就是除了Serial之外，只有他能和老年代的CMS收集器配合工作。
- **Parallel Scavenge收集器**：Parallel Scavenge收集器類似ParNew收集器，Parallel收集器更關注系統的吞吐量（就是CPU執行使用者程式碼的時間與CPU總消耗時間的比值，即 吞吐量=執行使用者程式碼的時間/[執行使用者程式碼的時間+垃圾收集時間]）。
- **CMS收集器**：CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。，停頓時間短，使用者體驗就好。

基於“標記清除”演算法，併發收集、低停頓，運作過程複雜，分4步：

- 初始標記：僅僅標記GC Roots能直接關聯到的物件，速度快，但是需要“Stop The World”
- 併發標記：就是進行追蹤引用鏈的過程，可以和使用者執行緒併發執行。
- 重新標記：修正併發標記階段因使用者執行緒繼續執行而導致標記發生變化的那部分物件的標記記錄，比初始標記時間長但遠比並發標記時間短，需要“Stop The World”
- 併發清除：清除標記為可以回收物件，可以和使用者執行緒併發執行

由於整個過程耗時最長的併發標記和併發清除都可以和使用者執行緒一起工作，所以總體上來看，CMS收集器的記憶體回收過程和使用者執行緒是併發執行的。

CSM收集器有3個缺點：

1)對CPU資源非常敏感

併發收集雖然不會暫停使用者執行緒，但因為佔用一部分CPU資源，還是會導致應用程式變慢，總吞吐量降低。

CMS的預設收集執行緒數量是=(CPU數量+3)/4；當CPU數量多於4個，收集執行緒佔用的CPU資源多於25%，對使用者程式影響可能較大；不足4個時，影響更大，可能無法接受。

2)無法處理浮動垃圾（在併發清除時，使用者執行緒新產生的垃圾叫浮動垃圾）,可能出現"Concurrent Mode Failure"失敗。

併發清除時需要預留一定的記憶體空間，不能像其他收集器在老年代幾乎填滿再進行收集；如果CMS預留記憶體空間無法滿足程式需要，就會出現一次"Concurrent Mode Failure"失敗；這時JVM啟用後備預案：臨時啟用Serail Old收集器，而導致另一次Full GC的產生；

3)產生大量記憶體碎片：CMS基於"標記-清除"演算法，清除後不進行壓縮操作產生大量不連續的記憶體碎片，這樣會導致分配大記憶體物件時，無法找到足夠的連續記憶體，從而需要提前觸發另一次Full GC動作。

- **Serial Old收集器**：Serial 收集器的老年代版本，單執行緒，“標記整理”演算法，主要是給Client模式下的虛擬機器使用。可以作為CMS的後背方案，在CMS發生Concurrent Mode Failure是使用

- **Parallel Old 收集器**：Parallel Scavenge的老年代版本，多執行緒，“標記整理”演算法，JDK 1.6才出現。在此之前Parallel Scavenge只能同Serial Old搭配使用，由於Serial Old的效能較差導致Parallel Scavenge的優勢發揮不出來，Parallel Old收集器的出現，使“吞吐量優先”收集器終於有了名副其實的組合。在吞吐量和CPU敏感的場合，都可以使用Parallel Scavenge/Parallel Old組合。

- **G1收集器**：G1 (Garbage-First)是一款面向伺服器的垃圾收集器,主要針對配備多顆處理器及大容量記憶體的機器. 以極高機率滿足GC停頓時間要求的同時,還具備高吞吐量效能特徵。G1是面向服務端應用的垃圾收集器。它的使命是未來可以替換掉CMS收集器。

Java常見知識點彙總（⑰）——垃圾回收機制（garbage collection-GC）

相關文章