一、物件引用

JDK1.2之前，Java中的引用定義很很純粹：如果reference型別的資料中儲存的數值代表的是另外一塊記憶體的起始地址，就稱這塊記憶體代表著一個引用。但在JDK1.2之後，Java對引用的概念進行了擴充，將其分為強引用（Strong Reference）、軟引用（Soft Reference）、弱引用（Weak Reference）、虛引用（Phantom Reference）四種，引用強度依次減弱。
（1）強引用：如“Object obj = new Object（）”，這類引用是Java程式中最普遍的。只要強引用還存在，垃圾收集器就永遠不會回收掉被引用的物件。
（2）軟引用：它用來描述一些可能還有用，但並非必須的物件。在系統記憶體不夠用時，這類引用關聯的物件將被垃圾收集器回收。JDK1.2之後提供了SoftReference類來實現軟引用。
（3）弱引用：它也是用來描述非需物件的，但它的強度比軟引用更弱些，被弱引用關聯的物件只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時，無論當前記憶體是否足夠，都會回收掉只被弱引用關聯的物件。在JDK1.2之後，提供了WeakReference類來實現弱引用。
（4）虛引用：最弱的一種引用關係，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個物件例項。為一個物件設定虛引用關聯的唯一目的是希望能在這個物件被收集器回收時收到一個系統通知。JDK1.2之後提供了PhantomReference類來實現虛引用。

二、垃圾物件的判定

Java堆中存放著幾乎所有的物件例項，垃圾收集器對堆中的物件進行回收前，要先確定這些物件是否還有用，判定物件是否為垃圾物件有如下演算法：
（1）引用計數演算法
給物件新增一個引用計數器，每當有一個地方引用它時，計數器值就加1，當引用失效時，計數器值就減1，任何時刻計數器都為0的物件就是不可能再被使用的。
引用計數演算法的實現簡單，判定效率也很高，在大部分情況下它都是一個不錯的選擇，當Java語言並沒有選擇這種演算法來進行垃圾回收，主要原因是它很難解決物件之間的相互迴圈引用問題。
（2）可達性分析演算法
Java和C#中都是採用可達性分析演算法來判定物件是否存活的。這種演算法的基本思路是通過一系列名為“GC Roots”的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑稱為引用鏈，當一個物件到GC Roots沒有任何引用鏈相連時，就證明此物件是不可用的。如圖所示，object5、object6和object7雖然互相有關聯，但它們到GC Roots是不可達的，所以會被判定為可回收的物件。

在Java語言裡，可作為GC Roots的物件包括下面幾種：
1.虛擬機器棧（棧幀中的本地變量表）中引用的物件。
2.方法區中的類靜態屬性引用的物件。
3.方法區中的常量引用的物件。
4.本地方法棧中JNI（Native方法）的引用物件。

實際上，在可達性分析演算法中，要真正宣告一個物件死亡，至少要經歷兩次標記過程：如果物件在進行根搜尋後發現沒有與GC Roots相連線的引用鏈，那它會被第一次標記並且進行一次篩選，篩選的條件是此物件是否有必要執行finalize（）方法。當物件沒有覆蓋finalize（）方法，或finalize（）方法已經被虛擬機器呼叫過，虛擬機器將這兩種情況都視為沒有必要執行。如果該物件被判定為有必要執行finalize（）方法，那麼這個物件將會被放置在一個名為F-Queue佇列中，並在稍後由一條由虛擬機器自動建立的、低優先順序的Finalizer執行緒去執行finalize（）方法。finalize（）方法是物件逃脫死亡命運的最後一次機會（因為一個物件的finalize（）方法最多隻會被系統自動呼叫一次），稍後GC將對F-Queue中的物件進行第二次小規模的標記，如果要在finalize（）方法中成功拯救自己，只要在finalize（）方法中讓該物件重引用鏈上的任何一個物件建立關聯即可。而如果物件這時還沒有關聯到任何鏈上的引用，那它就會被回收掉。

三、垃圾收集演算法

判定除了垃圾物件之後，便可以進行垃圾回收了。下面介紹一些垃圾收集演算法
（1）標記清除演算法
標記—清除演算法是最基礎的收集演算法，它分為“標記”和“清除”兩個階段：首先標記出所需回收的物件，在標記完成後統一回收掉所有被標記的物件，它的標記過程其實就是前面的根搜尋演算法中判定垃圾物件的標記過程。標記—清除演算法的執行情況如下圖所示：

該演算法的缺點：
1.標記和清除過程的效率都不高。
2. 標記清除後會產生大量不連續的記憶體碎片，空間碎片太多可能會導致，當程式在以後的執行過程中需要分配較大物件時無法找到足夠的連續記憶體而不得不觸發另一次垃圾收集動作。

（2）複製演算法
複製演算法是針對標記—清除演算法的缺點，在其基礎上進行改進而得到的，它講課用記憶體按容量分為大小相等的兩塊，每次只使用其中的一塊，當這一塊的記憶體用完了，就將還存活著的物件複製到另外一塊記憶體上面，然後再把已使用過的記憶體空間一次清理掉。
複製演算法的執行情況如下圖所示：

複製演算法的優點：
1. 每次只對一塊記憶體進行回收，執行高效。
2.只需移動棧頂指標，按順序分配記憶體即可，實現簡單。
3. 記憶體回收時不用考慮記憶體碎片的出現。
複製演算法的缺點：
可一次性分配的最大記憶體縮小了一半。

（3）標記—整理演算法
複製演算法比較適合於新生代，在老年代中，物件存活率比較高，如果執行較多的複製操作，效率將會變低，所以老年代一般會選用其他演算法，如標記—整理演算法。該演算法標記的過程與標記—清除演算法中的標記過程一樣，但對標記後出的垃圾物件的處理情況有所不同，它不是直接對可回收物件進行清理，而是讓所有的物件都向一端移動，然後直接清理掉端邊界以外的記憶體。
標記—整理演算法的回收情況如下所示：

（4）分代收集演算法
當前商業虛擬機器的垃圾收集 都採用分代收集，它根據物件的存活週期的不同將記憶體劃分為幾塊，一般是把Java堆分為新生代和老年代。在新生代中，每次垃圾收集時都會發現有大量物件死去，只有少量存活，因此可選用複製演算法來完成收集，即Minor GC，而老年代中因為物件存活率高、沒有額外空間對它進行分配擔保，就必須使用標記—清除演算法或標記—整理演算法來進行回收，即Full GC。

四、垃圾收集器

基於JDK1.7Update 14之後的HotSpot虛擬機器包含的所有收集器如圖所示

圖中展示了7種作用於不同分代的收集器，如果二個收集器之間存在連線，表示它們可以搭配使用。

Java虛擬機器規範中對垃圾收集器應該如何實現並沒有任何規定，實際上到目前為止還沒有最好的收集器出現，更加沒有萬能的收集器，所以我們選擇的只是對具體應用最合適的收集器。
Serial 收集器
它是最基本，發展歷史最悠久的收集器，曾經是虛擬機器新生代收集的唯一選擇。特點就是，它是一個“單執行緒”的收集器，所謂“單執行緒”是指它不僅僅只會使用一個CPU或一條收集執行緒去完成垃圾收集工作，更重要的是，在它進行垃圾收集時，必須暫停其他所有的工作執行緒，直到它收集結束。這顯然是很讓人難以接受的，但是現代虛擬機器不斷優化，不斷縮減停頓時間，將停頓時間完全可以控制在幾十毫秒最多一百多毫秒以內，那麼只要不是頻繁發生，這點停頓完全可以接受。針對執行在Client模式下的虛擬機器來說，例如使用者的桌面應用場景，分配給虛擬機器管理的記憶體一般來說不會太大，收集幾十兆甚至一兩百兆的新生代，Serial收集器完全夠用。

parNew收集器
parNew是Serial的多執行緒版本，其核心就是就是運用多個執行緒進行垃圾收集。但是在單CPU的環境下絕對不會比Serial收集器有更好的效果，甚至由於存線上程互動的開銷，該收集器在通過超執行緒技術實現的兩個CPU的環境中都不可能百分之百地保證可以超越Serial收集器。但當可用CPU數量增多時，能夠更加高效的利用系統資源。
parNew收集器除了多執行緒收集之外，其他與Serial收集器相比並沒有太多創新之處，但它卻是許多執行在Server模式下的虛擬機器中首選的新生代收集器，其中一個原因就是，除了Serial收集器外，目前只有它能與CMS收集器配合工作。

Parallel Scavenge收集器
Parallel Scavenge收集器特別之處在於，其他收集器的關注點都是儘可能地縮短垃圾收集時使用者執行緒的停頓時間，Parallel Scavenge收集器的目標則是達到一個控制的吞吐量。吞吐量=執行使用者程式碼時間/(執行使用者程式碼時間+垃圾收集時間)，假設虛擬機器執行100分鐘，垃圾收集花費1分鐘，那麼吞吐量就是99%。Parallel Scavenge收集器提供了很多可精確設定的細節引數，可以精確控制最大垃圾收集停頓時間還有吞吐量的大小，特別的，當自適應引數開啟後，就不需要手動去指定新生代的大小等細節引數，虛擬機器會根據當前系統的執行情況收集效能監控資訊，動態調整這些引數以提供最合適的停頓時間或或者最大的吞吐量，這種方式就是所謂的GC 自適應調節策略。

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

Parallel Old收集器
Parallel Old收集器是 Parallel Scavenge的老年代版本，使用多執行緒和“標記-整理”演算法。JDK 1.6 之後才開始提供了這個收集器。在注重吞吐量以及CPU資源敏感的場合，都可以優先考慮Parallel Scavenge加Parallel Old 收集器。

CMS收集器
CMS（Concurrent Mark Sweep）收集器是基於“標記-清除”演算法實現的，它使用多執行緒的演算法去掃描堆（標記）並對發現的未使用的物件進行回收（清除）。整個過程分為4個步驟：
1.初始標記
2.併發標記
3.重新標記
4.併發清除
其中初始標記、重新標記這兩個步驟仍然需要“Stop The World”。初始標記僅僅只是標記一下GC Roots能直接關聯到的物件，速度很快，併發標記階段就是進行GC Roots Tracing的過程，而重新標記階段則是為了修正併發標記期間，因使用者程式繼續運作而導致標記產生變動的那一部分物件的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比並發標記的時間短。

CMS收集器的缺點：
1.吞吐量低的它使用更多的 CPU，為了使應用程式提供更好的體驗，通過使用多個執行緒來執行掃描和收集。
2.無法處理浮動垃圾，可能出現“Concurrent Mode Failure”失敗而導致另一次Full GC的產生。由於CMS併發清理階段使用者執行緒還在執行著，伴隨程式的執行自然還會有新的垃圾不斷產生，這一部分垃圾出現在標記過程之後，CMS無法在本次收集中處理掉它們，只好留待下一次GC時再將其清理掉。這一部分垃圾就稱為“浮動垃圾”。
3.基於標記-清除演算法的它收集結束會產生大量碎片。

G1收集器
與其他收集器相比，G1收集器具備如下特點。
1.並行與併發
G1能充分利用多CPU、多核環境下的硬體優勢，使用多個CPU來縮短Stop-The-World停頓的時間，部分其他收集器原本需要停頓Java執行緒執行的GC動作，G1收集器仍然可以通過併發的方式讓Java程式繼續執行。
2.分代收集
與其他收集器一樣，分代概念在G1中依然得以保留。
3.空間整合
G1收集器是基於“標記-整理”演算法實現的收集器，也就是說它不會產生空間碎片，這對於長時間執行的應用系統來說非常重要。
4.可預測的停頓
它可以非常精確地控制停頓，既能讓使用者明確指定在一個長度為M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒，具備了一些實時Java（RTSJ）的垃圾收集器的特徵。

如果不計算維護Remembered Set的操作，G1收集器的運作大致分為4個步驟：
1.初始標記
2.併發標記
3.最終標記
4.篩選回收
初始標記僅僅只是標記一下GC Roots能直接關聯到的物件並修改TAMS(Next Top at Mark Start)的值。併發標記是從GC Root開始對堆中物件進行可達性分析。最終標記是為了修正在併發標記期間因使用者程式繼續運作而導致標記產生變動的那一部分標記記錄。最後在篩選回收階段對各個Region的回收價值和成本進行排序，根據使用者所期望的GC停頓時間來制定回收計劃。

【參考資料】
《深入理解JVM虛擬機器》周志明 著