一、物件存活標記

　　1. 引用計數演算法

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

　　引用計數演算法（Reference Counting）的實現簡單，判定效率也很高，在大部分情況下它都是一個不錯的演算法，也有一些比較著名的應用案例，例如微軟的COM（Component Object Model）技術、使用ActionScript 3的FlashPlayer、Python語言以及在遊戲指令碼領域中被廣泛應用的Squirrel中都使用了引用計數演算法進行記憶體管理。但是，在Java語言中沒有選用引用計數演算法來管理記憶體，其中最主要的原因就是它很難解決物件之間的相互迴圈引用的問題。

　　2. 根搜尋演算法

　　在主流的商用程式語言中（Java和C#，甚至包括Lisp）都是使用根搜尋演算法（GCRoots Tracing）判定物件是否存活的。這個演算法的基本思路是通過一系列的名為“GC Roots”的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑稱為引用鏈（Reference Chain），當一個物件GC Roots沒有任何引用鏈相連（用圖論的話來說就是從GC Roots到這個物件不可達）時，則證明此物件是不可用的。

　　在Java語言裡，可作為GC Roots的物件包括下面幾種：

• 虛擬機器棧（棧幀中的本地變量表）中的引用的物件。
• 方法區中的類靜態屬性引用的物件
• 方法區中的常量引用的物件
• 本地方法棧中JNI（即一般說的Native方法）的引用的物件

　　3. 物件標記過程

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

　　如果這個物件被判定為有必要執行finalize()方法，那麼這個物件將會被放置在一個名為F-Queue的佇列之中，並在稍後由一條虛擬機器自動建立的、低優先順序的Fianlizer執行緒去挪。這裡所謂的“執行”是指虛擬機器會觸發這個方法，但並不承諾會等待它執行結束。這樣做的原因是，如果一個物件在finalize()方法中執行緩慢，或者發生了死迴圈（更極端的情況），將很可能導致F-Queue佇列中的其他物件永久處於等待狀態，甚至導致整個記憶體回收系統崩潰。finalize()方法是物件逃脫死亡命運的最後一次機會，稍後GC將對F-Queue中的物件進行第二次小規模的標記，如果物件要在finalize()中成功拯救自己——只要重新與引用鏈上的任何一個物件建立關聯即可，譬如把自己（this關鍵字）賦值給某個類變數或物件的成員變數，那在第二次標記時它將被移除出“即將回收”的集合；如果物件這時候還沒有逃脫，那它就真的離死不遠了。

二、垃圾收集演算法解析

1. 標記-清除演算法

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

　　2. 複製演算法

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

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

　　3. 標記-整理演算法

　　複製收集演算法在物件存活率較高時就要執行較多的複製操作，效率將會變低。更關鍵的是，如果不想浪費50%的空間，就需要有額外的空間進行分配擔保，以應對被使用的記憶體中所有物件都100%存活的極端情況，所以在老年代一般不能直接選用這種演算法。

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

　　4. 分代收集演算法

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