JVM 垃圾收集器

JVM學習目錄
1.JVM 概念簡介
 2.JVM 運行時內存
 3.JVM算法簡介
 4.JVM 垃圾收集器
 5.JVM 調優實戰

一、Serial收集器

Serial收集器是最基本、發展歷史最悠久的收集器，曾經（在JDK 1.3.1之前）是虛擬機新生代收集的唯一選擇。大家看名字就會知道，這個收集器是一個單線程的收集器，但它的“單線程”的意義並不僅僅說明它只會使用一個CPU或一條收集線程去完成垃圾收集工作，更重要的是在它進行垃圾收集時，必須暫停其他所有的工作線程，直到它收集結束。“Stop The World”這個名字也許聽起來很酷，但這項工作實際上是由虛擬機在後臺自動發起和自動完成的，在用戶不可見的情況下把用戶正常工作的線程全部停掉，這對很多應用來說都是難以接受的。讀者不妨試想一下，要是你的計算機每運行一個小時就會暫停響應5分鐘，你會有什麼樣的心情？下圖示意了Serial/Serial Old收集器的運行過程。

二、ParNew收集器

ParNew收集器其實就是Serial收集器的多線程版本，除了使用多條線程進行垃圾收集之外，其餘行爲包括Serial收集器可用的所有控制參數（例如：-XX：SurvivorRatio、-XX： PretenureSizeThreshold、-XX：HandlePromotionFailure等）、收集算法、Stop The World、對象分配規則、回收策略等都與Serial收集器完全一樣，在實現上，這兩種收集器也共用了相當多的代碼。ParNew收集器的工作過程如圖所示。

三、Parallel Scavenge收集器

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

四、Serial Old收集器

Serial Old是Serial收集器的老年代版本，它同樣是一個單線程收集器，使用“標記-整理”算法。這個收集器的主要意義也是在於給Client模式下的虛擬機使用。如果在Server模式下，那麼它主要還有兩大用途：一種用途是在JDK 1.5以及之前的版本中與Parallel Scavenge 收集器搭配使用[1]，另一種用途就是作爲CMS收集器的後備預案，在併發收集發生Concurrent Mode Failure時使用。這兩點都將在後面的內容中詳細講解。Serial Old收集器的工作過程如圖3-8所示。

五、Parallel Old收集器

Parallel Old是Parallel Scavenge收集器的老年代版本，使用多線程和“標記-整理”算法。這個收集器是在JDK 1.6中才開始提供的，在此之前，新生代的Parallel Scavenge收集器一直處於比較尷尬的狀態。原因是，如果新生代選擇了Parallel Scavenge收集器，老年代除了 Serial Old（PS MarkSweep）收集器外別無選擇（還記得上面說過Parallel Scavenge收集器無法與CMS收集器配合工作嗎？）。由於老年代Serial Old收集器在服務端應用性能上的“拖累”，使用了Parallel Scavenge收集器也未必能在整體應用上獲得吞吐量最大化的效果，由於單線程的老年代收集中無法充分利用服務器多CPU的處理能力，在老年代很大而且硬件比較高級的環境中，這種組合的吞吐量甚至還不一定有ParNew加CMS的組合“給力”。

直到Parallel Old收集器出現後，“吞吐量優先”收集器終於有了比較名副其實的應用組合，在注重吞吐量以及CPU資源敏感的場合，都可以優先考慮Parallel Scavenge加Parallel Old 收集器。Parallel Old收集器的工作過程如圖所示。

六、CMS收集器

CMS（Concurrent Mark Sweep）收集器是一種以獲取最短回收停頓時間爲目標的收集器。目前很大一部分的Java應用集中在互聯網站或者B/S系統的服務端上，這類應用尤其重視服務的響應速度，希望系統停頓時間最短，以給用戶帶來較好的體驗。CMS收集器就非常符合這類應用的需求。

從名字（包含“Mark Sweep”）上就可以看出，CMS收集器是基於“標記—清除”算法實現的，它的運作過程相對於前面幾種收集器來說更復雜一些，整個過程分爲4個步驟，包括：

初始標記（CMS initial mark）
併發標記（CMS concurrent mark）
重新標記（CMS remark）
併發清除（CMS concurrent sweep）
由於整個過程中耗時最長的併發標記和併發清除過程收集器線程都可以與用戶線程一起工作，所以，從總體上來說，CMS收集器的內存回收過程是與用戶線程一起併發執行的。通過下圖可以比較清楚地看到CMS收集器的運作步驟中併發和需要停頓的時間。

七、G1收集器

G1（Garbage-First）收集器是當今收集器技術發展的最前沿成果之一，早在JDK 1.7剛剛確立項目目標，Sun公司給出的JDK 1.7 RoadMap裏面，它就被視爲JDK 1.7中HotSpot虛擬機的一個重要進化特徵。從JDK 6u14中開始就有Early Access版本的G1收集器供開發人員實驗、試用，由此開始G1收集器的“Experimental”狀態持續了數年時間，直至JDK 7u4，Sun公司才認爲它達到足夠成熟的商用程度，移除了“Experimental”的標識。

G1是一款面向服務端應用的垃圾收集器。HotSpot開發團隊賦予它的使命是（在比較長期的）未來可以替換掉JDK 1.5中發佈的CMS收集器。與其他GC收集器相比，G1具備如下特點。