物件已死嗎

在堆裡面存放著java世界幾乎所有的物件例項，垃圾收集器在對堆進行回收前，第一件事情就是要確定這些物件哪些還“存活”，哪些已經“死去”

引用計數演算法

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

java虛擬機器中沒有選用引用計數演算法是來管理記憶體，其中最主要的原因是它很難解決物件之間互相迴圈引用的問題

可達性分析演算法

JVM通過可達性分析演算法來判定物件是否存活。這個演算法的基本思路是：
通過一系列的稱為“GC Roots”的物件作為起始點，從這些節點開始向下搜尋，搜尋走過的路徑稱為引用鏈，當一個物件到GC Roots沒有任何引用鏈相連（用圖論來說，就是從GC Roots到這個物件不可達）時，則證明此物件是不可達的。如下圖所示，object5,6,7不可達：

在java語言中，可作為GC Roots的物件包含下面幾種：
- 虛擬機器棧（棧幀中的本地變量表）中引用的物件
- 方法區中類靜態屬性引用的物件
- 方法區中常量引用的物件
- 本地方法棧中JNI（即一般說的Native方法）引用的物件

再談引用

引用可分為四類：強引用（Strong Reference），軟引用（Soft Reference），弱引用（Weak Reference），虛引用（Phantom Reference），這四種引用強度依次減弱

強引用

強引用就是指在程式程式碼中普遍存在的，類似“Object obj = new Onject()”這類的引用，只要引用還存在，垃圾收集器永遠不會回收掉被引用的物件。

軟引用

軟引用是用來描述一些還有用但並非必需的物件。對於軟引用關聯著的物件，在系統將要發生記憶體溢位異常之前，將會把這些物件列進回收範圍之中進行第二次回收。如果這次回收還沒有足夠的記憶體，才會丟擲記憶體溢位異常

弱引用

弱引用也是用來描述非必需物件的，被弱引用關聯著的物件只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時，無論當前記憶體是否足夠，都會回收掉只被弱引用關聯的物件

虛引用

虛引用也稱為幽靈引用或者幻影引用，一個物件是否有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個物件例項。為一個物件設定虛引用關聯的唯一目的就是能在在這個物件被收集器回收時收到一個系統通知。

生存還是死亡

即使在可達性分析演算法中不可達的物件，也並非是“非死不可”的，這時候它們暫時處於“緩刑”階段，要真正宣告一個物件死亡，至少要經歷兩次標記過程：如果物件在進行可達性分析後發現沒有與GC Roots相連線的引用鏈，那它將會被第一次標記並且進行一次篩選，篩選的條件是此物件是否有必要執行finalize（）方法。當物件沒有覆蓋finalize（）方法，或者finalize（）方法已經被虛擬機器呼叫過，虛擬機器將這兩種情況都視為“沒有必要執行”。

如果這個物件被判定為有必要執行finalize（）方法，那麼這個物件將會放置在一個叫做F-Queue的佇列之中，並在稍後由一個由虛擬機器自動建立的、低優先順序的Finalizer執行緒去執行它。這裡所謂的“執行”是指虛擬機器會觸發這個方法，但並不承諾會等待它執行結束。finalize（）方法是物件逃脫死亡命運的最後一次機會，稍後GC將對F-Queue中的物件進行第二次小規模的標記，如果物件要在finalize（）中成功拯救自己——只要重新與引用鏈上的任何一個物件建立關聯即可，譬如把自己（this關鍵字）賦值給某個類變數或者物件的成員變數，那在第二次標記時它將被移除出“即將回收”的集合；如果物件這時候還沒有逃脫，那基本上它就真的被回收了。

(不鼓勵大家使用這種finalize方法來拯救物件，它的執行代價高昂，不確定性大，無法保證各個物件的呼叫順序。)

回收方法區（HotSpot的永久代）

永久代的垃圾收集主要回收兩部分內容：
- 廢棄常量
回收廢棄常量與回收java堆中的物件非常相似。
- 無用的類
判定一個類是“無用的類“”需同時滿足以下三個條件：
1. 該類所有的例項都已經被回收，也就是java堆中不存在該類的任何例項
2. 載入該類的ClassLoader已經被回收
3. 該類對應的java.lang.Class物件沒有任何地方被引用，無法再任何地方通過反射訪問該類的方法
（虛擬機器可以對滿足上述3個條件的無用類進行回收，這裡說的僅僅是“可以”，而並不是和物件一樣，不使用了就必然會回收。是否對類進行回收，HotSpot虛擬機器提供了-Xnoclassgc引數進行控制）

垃圾收集演算法

標記-清除演算法

最基礎的收集演算法是“標記-清除”（Mark-Sweep）演算法，演算法分為“標記”和“清除”兩個階段：首先標記出所有需要回收的物件，在標記完成後統一回收所有被標記的物件，它的標記過程其實在前面講述物件標記判定時已經介紹過了。
主要不足有兩個：一個是效率問題，標記和清除兩個過程的效率都不高；另一個是空間問題，標記清除之後會產生大量不連續的記憶體碎片，空間碎片太多可能會導致以後在程式執行過程中需要分配較大物件時，無法找到足夠的連續記憶體而不得不提前觸發另一次垃圾收集動作。標記—清除演算法的執行過程如圖所示：

複製演算法

將可用記憶體按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的記憶體用完了，就將還存活著的物件複製到另外一塊上面，然後再把已使用過的記憶體空間一次清理掉。這樣使得每次都是對整個半區進行記憶體回收，記憶體分配時也就不用考慮記憶體碎片等複雜情況，只要移動堆頂指標，按順序分配記憶體即可，實現簡單，執行高效。只是這種演算法的代價是將記憶體縮小為了原來的一半，未免太高了一點。複製演算法的執行過程如圖所示：

現在的商業虛擬機器都採用這種收集演算法來回收新生代：
將記憶體分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中一塊Survivor。當回收時，將Eden和Survivor中還存活著的物件一次性地複製到另外一塊Survivor空間上，最後清理掉Eden和剛才用過的Survivor空間。HotSpot虛擬機器預設Eden和Survivor的大小比例是8:1，也就是每次新生代中可用記憶體空間為整個新生代容量的90%（80%+10%），只有10%的記憶體會被“浪費”。當然，98%的物件可回收只是一般場景下的資料，我們沒有辦法保證每次回收都只有不多於10%的物件存活，當Survivor空間不夠用時，需要依賴其他記憶體（這裡指老年代）進行分配擔保

記憶體的分配擔保：
如果另外一塊Survivor空間沒有足夠空間存放上一次新生代收集下來的存活物件時，
這些物件將直接通過分配擔保機制進入老年代。

標記-整理演算法

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

分代收集演算法

當前商業虛擬機器的垃圾收集都採用“分代收集”演算法：
根據物件存活週期的不同將記憶體劃分為幾塊。一般是把Java堆分為新生代和老年代，這樣就可以根據各個年代的特點採用最適當的收集演算法。在新生代中，每次垃圾收集時都發現有大批物件死去，只有少量存活，那就選用複製演算法，只需要付出少量存活物件的複製成本就可以完成收集。而老年代中因為物件存活率高、沒有額外空間對它進行分配擔保，就必須使用“標記—清理”或者“標記—整理”演算法來進行回收。

HotSpot的演算法實現

列舉根節點

由於在GC Roots節點（GC Roots的節點主要在全域性性的引用（例如常量或類靜態屬性）與執行上下文（例如棧幀中的本地變量表）中）找引用鏈操作時，若要逐個檢查這裡面的引用，那麼必然會消耗很多時間。因此在HotSpot的實現中，是使用一組稱為OopMap的資料結構來達到這個目的的，在類載入完成的時候，HotSpot就把物件內什麼偏移量上是什麼型別的資料計算出來，在JIT編譯過程中，也會在特定的位置記錄下棧和暫存器中哪些位置是引用。

當GC在掃描時就可以直接得知這些資訊，同時GC進行時必須停頓所有Java執行執行緒（Sun將這件事情稱為“Stop The World”），才不會出現列舉根節點過程中物件引用關係還在不斷變化的情況

安全點

HotSpot沒有為每條指令都生成OopMap，只有程式執行到安全點（Safepoint）時才能暫停開始GC。

安全點的選定基本上是以程式“是否具有讓程式長時間執行的特徵”為標準進行選定的。“長時間執行”的最明顯特徵就是指令序列複用，例如方法呼叫、迴圈跳轉、異常跳轉等，所以具有這些功能的指令才會產生Safepoint。

對於Sefepoint，在GC發生時讓所有執行緒（這裡不包括執行JNI呼叫的執行緒）都“跑”到最近的安全點上再停頓下來。這裡有兩種方案可供選擇：搶先式中斷和主動式中斷
- 搶先式中斷
搶先式中斷不需要執行緒的執行程式碼主動去配合，在GC發生時，首先把所有執行緒全部中斷，如果發現有執行緒中斷的地方不在安全點上，就恢復執行緒，讓它“跑”到安全點上。現在幾乎沒有虛擬機器實現採用搶先式中斷來暫停執行緒從而響應GC事件。
- 主動式中斷
主動式中斷的思想是當GC需要中斷執行緒的時候，不直接對執行緒操作，僅僅簡單地設定一個標誌，各個執行緒執行時主動去輪詢這個標誌，發現中斷標誌為真時就自己中斷掛起。輪詢標誌的地方和安全點是重合的，另外再加上建立物件需要分配記憶體的地方。

安全區域

Safepoint機制保證了程式執行時，在不太長的時間內就會遇到可進入GC的Safepoint。但是，程式“不執行”的時候呢？典型的例子就是執行緒處於Sleep狀態或者Blocked狀態，這時候執行緒無法響應JVM的中斷請求，“走”到安全的地方去中斷掛起。對於這種情況，就需要安全區域（Safe Region）來解決。

安全區域是指在一段程式碼片段之中，引用關係不會發生變化。在這個區域中的任意地方開始GC都是安全的。

線上程執行到Safe Region中的程式碼時，首先標識自己已經進入了Safe Region，那樣，當在這段時間裡JVM要發起GC時，就不用管標識自己為Safe Region狀態的執行緒了。線上程要離開Safe Region時，它要檢查系統是否已經完成了根節點列舉（或者是整個GC過程），如果完成了，那執行緒就繼續執行，否則它就必須等待直到收到可以安全離開Safe Region的訊號為止。

垃圾收集器

虛擬機器包含的所有收集器如圖所示：

（如果兩個收集器之間存在連線，就說明它們可以搭配使用。虛擬機器所處的區域，則表示它是屬於新生代收集器還是老年代收集器）

先解釋兩個名詞：併發和並行
- 並行（Parallel）：指多條垃圾收集執行緒並行工作，但此時使用者執行緒仍然處於等待狀態。
- 併發（Concurrent）：指使用者執行緒與垃圾收集執行緒同時執行（但不一定是並行的，可能會交替執行），使用者程式在繼續執行，而垃圾收集程式運行於另一個CPU上。

Serial收集器

在進行垃圾收集時，必須暫停其他所有的工作執行緒，只是用一個CPU或一條收集執行緒去完成拉垃圾收集工作。如下圖所示：

優點：
簡單而高效（與其他收集器的單執行緒比），對於限定單個CPU的環境來說，Serial收集器由於沒有執行緒互動的開銷，專心做垃圾收集自然可以獲得最高的單執行緒收集效率。

ParNew收集器

ParNew收集器其實就是Serial收集器的多執行緒版本，除了使用多條執行緒進行垃圾收集之外，其餘行為都與Serial收集器完全一樣。ParNew收集器的工作過程如圖所示：

優點：
它預設開啟的收集執行緒數與CPU的數量相同，在CPU非常多的環境下，效率能得到提升。

Parallel Scavenge收集器

Parallel Scavenge收集器是一個新生代收集器，它也是使用複製演算法的收集器，又是並行的多執行緒收集器。Parallel Scavenge收集器無法與CMS收集器配合工作

優點：
CMS等收集器的關注點是儘可能地縮短垃圾收集時使用者執行緒的停頓時間，而Parallel Scavenge收集器的目標則是達到一個可控制的吞吐量。所謂吞吐量就是CPU用於執行使用者程式碼的時間與CPU總消耗時間的比值，即吞吐量=執行使用者程式碼時間/（執行使用者程式碼時間+垃圾收集時間），虛擬機器總共運行了100分鐘，其中垃圾收集花掉1分鐘，那吞吐量就是99%。

停頓時間越短就越適合需要與使用者互動的程式，良好的響應速度能提升使用者體驗，而高吞吐量則可以高效率地利用CPU時間，儘快完成程式的運算任務，主要適合在後臺運算而不需要太多互動的任務

Serial Old收集器

Serial Old是Serial收集器的老年代版本，它同樣是一個單執行緒收集器，使用“標記-整理”演算法。這個收集器的主要意義也是在於給Client模式下的虛擬機器使用。

Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多執行緒和“標記-整理”演算法。

CMS收集器

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間為目標的收集器。CMS收集器是基於“標記—清除”演算法實現的整個過程分為4個步驟，包括：
1. 初始標記（CMS initial mark）
2. 併發標記（CMS concurrent mark）
3. 重新標記（CMS remark）
4. 併發清除（CMS concurrent sweep）

初始標記、重新標記這兩個步驟仍然需要“Stop The World”。初始標記僅僅只是標記一下GC Roots能直接關聯到的物件，速度很快，併發標記階段就是進行GC RootsTracing的過程，而重新標記階段則是為了修正併發標記期間因使用者程式繼續運作而導致標記產生變動的那一部分物件的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比並發標記的時間短。

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

優點：
併發收集、低停頓

缺點：
- CMS收集器對CPU資源非常敏感。在併發階段，會因為佔用了一部分執行緒而導致應用程式變慢，總吞吐量會降低。
- CMS收集器無法處理浮動垃圾。由於CMS併發清理階段使用者執行緒還在執行著，伴隨程式執行自然就還會有新的垃圾不斷產生，這一部分垃圾出現在標記過程之後，CMS無法在當次收集中處理掉它們，只好留待下一次GC時再清理掉。
- CMS是一款基於“標記—清除”演算法實現的收集器，意味著收集結束時會有大量空間碎片產生。

G1收集器

G1是一款面向服務端應用的垃圾收集器。

特點：
- 並行與併發：G1能充分利用多CPU、多核環境下的硬體優勢
- 分代收集：採用不同的方式去處理新建立的物件和已經存活了一段時間、熬過多次GC的舊物件以獲取更好的收集效果
- 空間整合：G1從整體來看是基於“標記—整理”演算法實現的收集器，從區域性（兩個Region之間）上來看是基於“複製”演算法實現的
- 可預測的停頓：能讓使用者明確指定在一個長度為M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒

G1收集器的運作大致可劃分為以下幾個步驟：
1. 初始標記（Initial Marking）
2. 併發標記（Concurrent Marking）
3. 最終標記（Final Marking）
4. 篩選回收（Live Data Counting and Evacuation）

步驟過程如下圖所示：

記憶體分配和回收策略

物件的記憶體分配，往大方向講，就是在堆上分配（但也可能經過JIT編譯後被拆散為標量型別並間接地棧上分配），物件主要分配在新生代的Eden區上，如果啟動了本地執行緒分配緩衝，將按執行緒優先在TLAB上分配。

分配策略：
1. 物件優先在Eden分配
大多數情況下，物件在新生代Eden區中分配。當Eden區沒有足夠空間進行分配時，虛擬機器將發起一次Minor GC。
2. 大物件直接進入老年代
所謂的大物件是指，需要大量連續記憶體空間的Java物件，最典型的大物件就是那種很長的字串以及陣列
3. 長期存活的物件將進入老年代
虛擬機器採用了分代收集的思想來管理記憶體。虛擬機器給每個物件定義了一個物件年齡（Age）計數器。如果物件在Eden出生並經過第一次Minor GC後仍然存活，並且能被Survivor容納的話，將被移動到Survivor空間中，並且物件年齡設為1。物件在Survivor區中每“熬過”一次Minor GC，年齡就增加1歲，當它的年齡增加到一定程度（預設為15歲），就將會被晉升到老年代中。
4. 動態物件年齡判定
如果在Survivor空間中相同年齡所有物件大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的物件就可以直接進入老年代
5. 空間分配擔保
在發生Minor GC之前，虛擬機器會先檢查老年代最大可用的連續空間是否大於新生代所有物件總空間，如果這個條件成立，那麼Minor GC可以確保是安全的。如果不成立，則虛擬機器會檢視HandlePromotionFailure設定值是否允許擔保失敗。如果允許，那麼會繼續檢查老年代最大可用的連續空間是否大於歷次晉升到老年代物件的平均大小，如果大於，將嘗試著進行一次Minor GC，儘管這次Minor GC是有風險的；如果小於，或者HandlePromotionFailure設定不允許冒險，那這時也要改為進行一次Full GC。
（上述風險的原因：新生代使用複製收集演算法，但為了記憶體利用率，只使用其中一個Survivor空間來作為輪換備份，因此當出現大量物件在MinorGC後仍然存活的情況（最極端的情況就是記憶體回收後新生代中所有物件都存活），就需要老年代進行分配擔保，把Survivor無法容納的物件直接進入老年代。）