GC（Garbage Collection 垃圾回收）的概念隨著 java 的流行而被人們所熟知。 實際 GC 最早起源于20世紀60年代的 LISP 語言，是一種自動的內存管理機制。 GC 要解決的問題有 3 個：
1. 回收什么？（what）
2. 何時回收？（when）
3. 如何回收？（how）
回收什么？
清理的是垃圾，回收的是內存空間。
既然 GC 是 java 的自動內存管理機制，那么先看下 java 虛擬機將所管理的內存劃分為不同的區域，如圖1。
如圖1所示，java 虛擬機管理的內存區域分為如下幾個部分：
1. 堆（Heap）
2. 方法區（Method Area）
3. 虛擬機棧（VM Stack）
4. 本地方法棧（Native Method Stack）
5. 程序計數器（Program Counter Register）
其中堆和方法區屬于所有線程共享，而其他區域屬于線程隔離的區域。
下面我們以 java HotSpot 虛擬機為例分別說說每個區域的作用和構成：
堆（Heap）
堆用于存儲對象實例，從內存回收的角度看，由于收集器基本都采用了分代收集算法，所以堆可以進一步細分為：
- Eden 區
- Survivor 0 區 （From）
- Survivor 1 區 （To）
- Old/Tenured 區
其中 Eden、S0、S1 組成了新生代（Young/New Generation），Old/Tenured 為老年代。
方法區（Method Area）
方法區存儲虛擬機加載的類信息、常量、編譯代碼等數據。 HotSpot 虛擬機使用永久代（Permanent Generation）來實現方法區。
虛擬機棧（VM Stack）
虛擬機棧描述的是 java 方法執行的內存模型，每個方法在執行時創建一個棧幀（Stack Frame）。 棧幀中存儲內容主要包含：
- 局部變量表
- 操作數棧
- 動態鏈接
- 方法返回地址
每個方法的執行過程就對應著一個棧幀在虛擬機棧中入棧到出棧的過程。
本地方法棧（Native Method Stack）
本地方法棧與虛擬機棧類似，只不過服務于虛擬機執行 Native 方法時。 HotSpot 虛擬機的實現把虛擬機棧和本地方法棧合二為一。
程序計數器（Program Counter Register）
可以看作是線程執行的字節碼的行號指示器，在虛擬機的概念模型中便于實現分支、循環、跳轉、異常處理和線程切換恢復等基礎功能。 每個線程都有一個獨立的程序計數器。
GC 管理的內存區域主要是堆（Heap），而堆中存放的是對象實例，因此 GC 回收的就是“死亡”（不可能再被使用）的對象占用的內存空間。
何時回收？
既然說到“死亡”的對象，那不得不說下對象的生命周期。
虛擬機通過 new 指令創建了對象，大多數對象創建時在 Eden 區分配內存空間，而一些大對象若 Eden 區不能滿足其空間需求時會直接在 Old/Tenured 區分配。
對象的死亡判定，主流的 GC 實現都是通過可達性分析，形象點來說就是在基于引用建立的對象圖中形成了孤島的對象就是死亡的（可回收的）。
GC 分類
- Minor GC
- Major GC
- Full GC
Minor GC 是針對新生代的回收，當 Eden 區空間滿了時將觸發 Minor GC。
Major GC 是針對老年代的回收，當 Minor GC 發生時會拷貝對象到老年代，這個過程稱為對象晉升（promotion）或老年化（tenuring）。
為了避免對象晉升時老年代空間不足，收集器總是嘗試預測剩余的空間是否足夠以避免對象晉升失敗，當晉升失敗時就會發生 Full GC。
Full GC 是針對整個堆的操作，是非常昂貴的操作。除了在對象晉升失敗時發生 Full GC，當堆自動調整大小時（Heap-Resizing）也會發生，不過可以通過設置 -Xms和-Xmx為相同的值來避免 Heap-Resizing。
如何回收？
Minor GC 將新生代中存活的對象拷貝到 Survivor 區和 Tenured 區。
Major GC 針對老年代區域進行死亡對象標記、清除和內存整理。
Full GC 則包括了所有存活對象的晉升以及老年代的內存回收及整理。
前面泛泛而談了3種垃圾收集方式的過程，而具體則是由垃圾收集器來實現。
截至 JDK 1.7 HotSpot 虛擬機提供的垃圾收集器如圖2所示，一共有 7 種不同作用的收集器。
圖中連線表明它們可以搭配使用。
Serial Collector
如其名，串行的單線程收集器，是目前虛擬機運行在 client 模式下的默認新生代收集器。
ParNew Collector
相當于 Serial 的多線程版本。
Parallel Scavenge Collector
與 ParNew 很像，但它的關注點在達到一個可控制的吞吐量（Throughput），這里吞吐量的定義是 CPU 用于運行用戶代碼的時間與 CPU總消耗時間的比值。
因此 Parallel Scavenge 收集器也經常稱為吞吐優先收集器，它還有個特點是自適應調節策略。 虛擬機會根據當前系統的運行情況收集監控信息，動態調整 Eden與Survivor區比例、晉升老年代對象年齡等參數，以提供最合適的停頓時間或最大的吞吐量。
Serial Old Collector
相當于 Serial 收集器的老年代版本。
Parallel Old Collector
相當于 Parallel Scavenge 收集器的老年代版本。
Concurrent Mark Sweep (CMS) Collector
前述的收集器在執行時都會停止所有的用戶線程執行（Stop-The-World）
CMS 收集器的關注點則是盡可能地縮短垃圾收集時用戶線程的停頓時間，讓垃圾收集和用戶線程并行執行，從而減少應用停頓時間，提升用戶體驗。
當然在獲得低停頓的好處時是付出了吞吐量的代價，通常與 Parallel 系收集器相比吞吐率下降 10%-40%。
CMS 收集器的處理整個過程有如下步驟:
1. 初始標記：找到 GC Roots。
2. 并發標記：標記所有從 GC Roots 可達的對象。
3. 并發預清理：檢查對象引用更新和在并發標記階段晉升到老年代的對象并進行標記。
4. 重新標記：標記預清理階段更新的對象引用。
5. 并發清理：回收死亡對象的內存。
6. 并發重置：重置數據結構為下次運行作準備。
其執行示意如圖3所示
其中步驟1（初始標記）和步驟4（ 重新標記）仍然需要 Stop The World，只是相對來說時間較短。
低停頓是 CMS 收集器是的優點，但它也并不完美，它有 3 個明顯缺點：
1. 由于和用戶線程并發執行，所以存在 CPU 爭搶的問題。
2. 無法回收浮動垃圾。
3. CMS 僅進行了標記、清除而未進行整理，容易產生大量內存空間碎片。
CMS 默認啟動的回收線程是 (CPU數量 + 3) / 4，也就是 CPU 在 4 個以上時并發回收線程使用的 CPU 資源不少于 25%。 在并發清理時新產生的垃圾稱為浮動垃圾（Floating Garbage），本次無法收集，當浮動垃圾過多導致預留的內存無法滿足程序需要時觸發， 就可能出現 Concurrent Mode Failure 導致啟用 Serial Old 收集器作為后備進行 Full GC。
Garbage First (G1) Collector
一種新的收集器，在 jdk7u4 開始正式支持，它有如下特點：
1. 多分區的堆組織方式
G1 也是分代收集器，但其組織堆的方式與其他收集器完全不同。它根據不同的用途將堆分為大量（~2000）固定大小的區域（region）。 相同用途的堆也并不連續，G1 依然保留了新生代和老年代的概念，但新生代和老年代不再是物理上隔離的了，它們都是一部分 region 的集合，如圖4所示。
如果一個對象大小超過了普通區域大小的50%，那么它會被分配到一個大區域（humongous）里面。
2. 優先的收集方式
G1 的收集方式追求低停頓，并且建立可預測的停頓時間模型（在 M 毫秒的時間片段內，GC 的時間不得超過 N 毫秒，N < M）。 G1 通過有計劃的避免在整個堆中進行全區域掃描進行垃圾收集，它通過跟蹤各個 region 中垃圾的價值大小（回收獲得的空間及回收所花費的時間的經驗值）， 在后臺維護一個優先級列表，每次根據允許的收集時間，優先回收價值最大的 region，這也正式 Garbage-First 名稱的由來。 而對 region 的收集采用的是 Stop-The-World 的方式，增量的將存活的對象復制到一個空 region 里面，這種方式不會產生內存碎片問題。
最后我們引用《Java Garbage Collection Distilled》 一文中的關于 GC 的折衷權衡點來總結下。
俗話說：“從來沒有不勞而獲，當我們得到某些事物的時候，通常不得不放棄另外一些事物”。
當談論垃圾收集的時候，我們主要考慮三個收集器的指標：
1. 吞吐量：花費在 GC 上的時間占整個應用程序工作的比例。
2. 延遲：因為垃圾回收，而引起的響應暫停的時間。
3. 內存：我系統使用內存來存儲狀態，在管理的時候它們常常需要復制和移動。
上述三個指標，吞吐量越大越好，延遲越低越好，內存復制和移動產生的碎片越少越好。 但可惜這三個目標很難同時滿足，很多時候我們都是根據應用類型在其中做出權衡取舍。
：視頻截圖)
