1 概述
說起垃圾收集（ Garbage Collection , GC ) ，大部分人都把這項技術當做 Java 語言的伴生產物。事實上， GC 的歷史遠遠比 Java 久遠，1960 年誕生於 MIT 的 Lisp 是第一門真正使用記憶體動態分配和垃圾收集技術的語言。當 Lisp 還在胚胎時期時，人們就在思考 GC 需要完成的三件事情：
- 哪些記憶體需要回收？
- 什麼時候回收？
- 如何回收？
經過半個世紀的發展，記憶體的動態分配與記憶體回收技術已經相當成熟，一切看起來都進入了“自動化”時代，那為什麼我們還要去了解 GC 和記憶體分配呢？答案很簡單：當需要排查各種記憶體溢位、記憶體洩漏問題時，當垃圾收整合為系統達到更高併發量的瓶頸時，我們就需要對這些“自動化”的技術實施必要的監控和調節。
2 物件已死？
堆中幾乎存放著 Java 世界中所有的物件例項，垃圾收集器在對堆進行回收前，第一件事情就是要確定這些物件有哪些還“存活”著，哪些已經“死去”（即不可能再被任何途徑使用的物件）。
2.1 引用計數演算法
引用計數演算法的基本思路是：給物件中新增一個引用計數器，每當有一個地方引用它時，計數器值就加 l ；當引用失效時，計數器值就減 1 ；任何時刻計數器都為 0 的物件就是不可能再被使用的。
客觀地說，引用計數演算法（ Reference Counting ）的實現簡單，判定效率也很高，在大部分情況下它都是一個不錯的演算法，也有一些比較著名的應用案例，例如微軟的 COM ( Component object Model ）技術、使用 Actionscript3 的 FlashPlayer 、 Python 語言以及在遊戲指令碼領域中被廣泛應用的 Squirrel 中都使用了引用計數演算法進行記憶體管理。但是， Java 語言中沒有選用引用計數演算法來管理記憶體，其中最主要的原因是它很難解決物件之間的相互迴圈引用的問題。
2.2 根搜尋演算法
在主流的商用程式語言中（ Java 和 C # ，甚至包括前面提到的古老的 Lisp ) ，都是使用根搜尋演算法（ GC Roots Tracing ）判定物件是否存活的。這個演算法的基本思路就是通過一系列的名為“ GC Roots ”的物件作為起始點，從這些節點開始向下搜尋，搜尋所走過的路徑稱為引用鏈（ Reference Chain ) ，當一個物件到 GC Roots 沒有任何引用鏈相連（用圖論的話來說就是從 GC Roots 到這個物件不可達）時，則證明此物件是不可用的．如下圖所示，物件 objects5 、object6 、object7 雖然互相有關聯，但是它們到 GC Roots 是不可達的，所以它們將會被判定為是可回收的物件。
在 Java 語言裡，可作為 GC Roots 的物件包括下面幾種：
- 虛擬機器棧（棧幀中的本地變數表）中的引用的物件。
- 方法區中的類靜態屬性引用的物件。
- 方法區中的常量引用的物件。
- 本地方法棧中JNI（即一般說的 Native 方法）的引用的物件。
2.3 再談引用
在JDK1.2之後，Java對引用的概念進行了擴充，將引用分為強引用(Strong Reference)、軟引用(Soft Reference)、弱引用(Weak Reference)、虛引用(Phantom Reference)四種，這四種引用強度依次逐漸減弱。
強引用就是指在程式程式碼之中普遍存在的，類似"Object obj = new Object()"這類的引用，只要強引用還存在，垃圾收集器永遠不會回收掉被引用的物件。
軟引用用來描述一些還有用，但並非必需的物件。對於軟引用關聯著的物件，在系統將要發生記憶體溢位異常之前，將會把這些物件列進回收範圍之中並進行第二次回收。如果這次回收還是沒有足夠的記憶體，才會丟擲記憶體溢位異常。在 JDK 1 . 2 之後，提供了SoftReference 類來實現軟引用。
弱引用也是用來描述非必需物件的，但是它的強度比軟引用更弱一些，被弱引用關聯的物件只能生存到下一次垃圾收集發生之前。當垃圾收集器工作時，無論當前記憶體是否足夠，都會回收掉只被弱引用關聯的物件。在 JDK 1 . 2 之後，提供了WeakReference 類來實現弱引用。
虛引用也稱為幽靈引用或者幻影引用，它是最弱的一種引用關係。一個物件是否有虛引用的存在，完全不會對其生存時間構成影響，也無法通過虛引用來取得一個物件例項。為一個物件設定虛引用關聯的唯一目的就是希望能在這個物件被收集器回收時收到一個系統通知。在 JDK 1 . 2 之後，提供了 PhantomReference 類來實現虛引用。
2.4生存還是死亡
在根搜尋演算法中不可達的物件，也並非是"非死不可"的，這時候它們暫時處於"緩刑"階段，要真正宣告一個物件死亡，至少要經歷兩次標記過程：如果物件在進行根搜尋後發現沒有與GC Roots相連線的引用鏈，那它將會被第一次標記並且進行一次篩選。篩選條件是此物件是否有必要執行finalize方法(物件未覆蓋finalize方法或finalize方法已被呼叫，都視為沒有必要執行)。
如果這個物件被判定為有必要執行finalize方法，那麼這個物件將會被放置在一個名為F-Queue的佇列中，並在稍後由一條由虛擬機器自動建立的、低優先順序Finalizer執行緒去執行。finalize方法是物件逃脫死亡命運最後一次機會，稍後GC將對F-Queue中的物件進行第二次小規模的標記，如果物件要在finalize中成功拯救自己--只要重新與引用鏈上的任何一個物件建立關聯即可，譬如把自己(this關鍵字)賦值給某個類變數或物件的成員變數，那在第二次標記時它將被移除出"即將回收"的集合；如何物件這時候還沒有逃脫，那它就真的離死不遠了。
2.5 回收方法區
永久代的垃圾收集主要回收兩部分內容:廢棄常量和無用的類。
廢棄常量
回收廢棄常量與回收Java堆中的物件非常類似。
無用的類
類需要同時滿足下面3個條件才能算是"無用的類"：
- 該類所有的例項都已經被回收，也就是Java堆中不存在該類的任何例項；
- 載入該類的ClassLoader已經被回收；
- 該類對應的java.lang.Class物件沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法。
虛擬機器可以對滿足上述3個條件的無用類進行回收，僅僅是可以，而不是必然就會回收。在大量使用反射、動態代理、CGLib等bytecode場景，以及動態生成JSP和OSGi這類頻繁自定義ClassLoader的場景都需要虛擬機器具備類解除安裝的功能，以保證永久代不會溢位。
3 垃圾收集演算法
3.1 標記-清除演算法
最基礎的收集演算法，首先標記出所有需要回收的物件，在標記完成後統一回收掉所有被標記的物件，
- 效率問題，標記和清除過程的效率都不高；
- 空間問題，標記清除之後會產生大量不連續的記憶體碎片，可能會導致在需要分配較大物件時無法找到足夠的連續記憶體而不得不提前觸發另一次垃圾收集動作。
3.2 複製演算法
它將可用記憶體按容量劃分為大小相等的兩塊，每次只使用其中的一塊。當這一塊的記憶體用完了，就將還存活著的物件複製到另外一塊上面，然後再把已使用過的記憶體空間一次清理掉。
- 不用考慮記憶體碎片等複雜情況，實現簡單執行高效；
- 代價是將記憶體縮小為原來的一半。
現在的商業虛擬機器都採用這種收集演算法來回收新生代，將記憶體分為一塊較大的Eden空間和兩塊較小的Survivor空間，每次使用Eden和其中的一塊Survivor。當回收時，將Eden和Survivor中還存活著的物件一次性地拷貝到另外一塊Survivor空間上，最後清理掉Eden和剛才用過的Survivor的空間。HotSpot虛擬機器預設Eden和Survivor的大小比例是8:1，也就是每次新生代中可用記憶體空間為整個新生代容量的90%，只有10%的記憶體會被浪費。當Survivor空間不夠用時，需要依賴其他記憶體(老年代)進行分配擔保，即如果另一塊Survivor空間沒有足夠的空間存放上一次新生代收集下來的存活物件，這些物件將直接通過分配擔保機制進入老年代。
3.3 標記-整理演算法
標記過程任然與"標記-清除"演算法一樣，但後續步驟不是直接對可回收物件進行清理，而是讓所有存活的物件都向一端移動，然後直接清理掉端邊界以外的記憶體。老年代一般使用該演算法。
3.4 分代收集演算法
當前商業虛擬機器的垃圾收集都採用"分代收集"(Generational Collection)演算法，根據物件的存活週期的不同將記憶體劃分為幾塊。一般是把Java堆分為新生代和老年代，這樣就可以根據各個年代的特點採用最適當的收集演算法。在新生代中，選用複製演算法；而老年代使用"標記-清理"或"標記-整理"演算法。
4 垃圾收集器
本文討論的收集器基於SunHotSpot虛擬機器1.6版Update22,這個虛擬機器包含的所有收集器如下圖所示。圖中展示了7種作用於不同分代的收集器，如果兩個收集器之間存在連線，就說明它們可以搭配使用。
4.1 Serial收集器
一個單執行緒收集器，不僅僅說明它只會使用一個CPU或一條收集執行緒去完成垃圾收集工作，更重要的是它在進行垃圾收集時，必須暫停其他所有的工作執行緒(Stop The World),直到它收集結束。
虛擬機器執行在Client模式下的預設新生代收集器。它也有著優於其它收集器的地方:簡單而高效(與其它收集器的單執行緒比)。在使用者的桌面應用場景中，分配給虛擬機器管理的記憶體一般來說不會很大，收集幾十兆甚至一兩百兆的新生代(僅僅是新生代使用的記憶體，桌面應用基本不會再大了)，停頓時間完全可以控制在幾十毫秒最多一百毫秒以內，只要不是頻繁發生是可以接受的。
4.2 ParNew收集器
- Serial收集器的多執行緒版本，並行，新生代，採用複製演算法；
- Server模式下虛擬機器中首選的新生代收集器；
4.3 Parallel Scavenge收集器
- 新生代收集器，並行，採用複製演算法；
- 目標是達到一個可控制的吞吐量(Throughput)，所謂吞吐量就是CPU用於執行使用者程式碼的時間與CPU總消耗時間的比值；
- 高吞吐量可以最高效率利用CPU時間，適合在後臺運算而不需要太多互動的任務，-XX:MaxGCPauseMillis(控制最大垃圾收集停頓時間)，-XX:GCTimeRatio(直接設定吞吐量大小)。
4.4 Serial Old收集器
- Serial收集器的老年代版本，單執行緒收集，使用"標記-整理"演算法；
- client模式下的虛擬機器使用；
- 作為CMS收集器的後備預案，在併發收集發生Concurrent Mode Failure的時候使用。
4.5 Parallel Old收集器
- Parallel Scavenge收集器的老年代版本，使用多執行緒和"標記-整理演算法"
4.6 CMS收集器
以獲取最短回收停頓時間為目標的收集器，基於"標記-清除"演算法，整個過程分為4個步驟:
- 初始標記(CMS initial mark)
- 併發標記(CMS concurrent mark)
- 重新標記(CMS remark)
- 併發清除(CMS concurrent sweep)
其中初始標記、重新標記兩個步驟任然需要"Stop The World"。初始標記僅僅只是標記一下GC Roots能直接關聯到的物件，速度很快，併發標記階段就是進行GC Roots Tracing的過程，而重新標記階段則是為了修正併發標記期間，因使用者程式繼續運作而導致標記產生變動的那一部分物件的標記記錄。
優點：併發收集、低停頓
缺點:
- 對CPU資源非常敏感
- 無法處理浮動垃圾(Floating Garbage)
- 會產生垃圾碎片
4.7 G1收集器
基於"標記-整理"演算法，可以非常精確地控制停頓，即能讓使用者明確指定在一個長度為M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒。G1收集器可以實現在基本不犧牲吞吐量的前提下完成低停頓的記憶體回收，這是由於它能夠極力地避免全區域的垃圾收集，G1將整個Java堆(包括新生代、老年代)劃分為多個大小固定的獨立區域(Region)，並且跟蹤這些區域裡面的垃圾堆積程度，在後臺維護一個優先列表，每次根據允許的收集時間，優先回收垃圾最多的區域(Garbage First)。區域劃分及有優先順序的區域回收，保證了G1收集器在有限的時間內可以獲得最高的收集效率。
5 記憶體分配與回收策略
5.1 物件優先在Eden分配
大多數情況下，物件在新生代Eden區分配。當Eden區沒有足夠的空間進行分配時，虛擬機器將發起一次Minor GC。
5.2 大物件直接進入老年代
所謂大物件就是指，需要大量連續記憶體空間的Java物件，最典型的大物件就是那種很長的字串及陣列。虛擬機器提供了一個-XX:PretenureSizeThreshold引數，令大於這個設定值的物件直接在老年代中分配。這樣做的目的是避免在Eden區及兩個Survivor區之間發生大量的記憶體拷貝。
注意:PretenureSizeThreshold引數只對Serial和ParNew兩款收集器有效。
5.3 長期存活的物件將進入老年代
虛擬機器給每個物件定義了一個物件年齡(Age)計數器。如果物件在Eden出生並經過第一次Minor GC後任然存活，並且能被Survivor容納的話，將被移動到Survivor空間，並將物件年齡設為1。物件在Survivor區中每熬過一次Minor GC，年齡就增加1歲，當年齡增加到一定程度(預設15歲)，就會被晉升到老年代中，可通過引數-XX:MaxTenuringThreshold來設定。
5.4 動態物件年齡判定
為了能更好地適應不同程式的記憶體狀況，虛擬機器並不總是要求物件的年齡必須達到MaxTenuringThreshold才能晉升到老年代，如果在Survivor空間中相同年齡所有物件大小的總和大於Survivor空間的一半，年齡大於或等於該年齡的物件就可以直接進入老年代，無需等到MaxTenuringThreshold中要求的年齡。
5.5 空間分配擔保
前面提到過，新生代使用複製收集演算法，但為了記憶體利用率，只使用其中一個Survivor空間來作為輪換備份，因此當出現大量物件在Minor GC後仍然存活的情況時(最極端就是記憶體回收後新生代中所有物件都存活)，就需要老年代進行分配擔保，讓Survivor無法容納的物件直接進入老年代。老年代要進行這樣的擔保，前提是老年代本身還有容納這些物件的剩餘空間，一共有多少物件會活下來，在實際完成記憶體回收之前是無法明確知道的，所以只好取之前每一次回收晉升到老年代物件容量的平均大小值作為經驗值，與老年代的剩餘空間進行比較，決定是否進行Full GC來讓老年代騰出更多空間。