01、背景介紹

今天通過這篇文章，結合之前的知識，我們一起來了解一下 JVM 中的垃圾收集器。

02、垃圾收集器

如果說收集算法是內存回收的方法論，那么垃圾收集器就是內存回收的具體實現。

不同的虛擬機所提供的垃圾收集器可能會有很大差異，以 HotSpot 虛擬機為例，所包含的垃圾收集器可以用如下圖來概括。

圖片

上圖中的連線表示，不同分代的收集器可以搭配使用。

• 新生代收集器：Serial、ParNew、Parallel Scavenge
• 老年代收集器：Serial Old、CMS、Parallel Old
• 通用收集器：G1

在虛擬機中，沒有所謂的萬能收集器，只有根據具體的業務場景，選擇最合適的收集器。這也是為什么 HotSpot 實現了這么多收集器的原因。

下面我們一起來看看相關的具體實現。

2.1、Serial 和 Serial Old收集器

Serial 系列的垃圾收集器是 JVM 的第一款收集器，它的設計思路很簡單，在新生代，使用單線程采用復制算法進行收集對象；在老年代，使用單線程采用標記整理算法進行收集對象；垃圾收集的過程中會暫停用戶線程，直到垃圾收集完畢。

因為當時的硬件環境配置都不高，內存都是幾十兆，CPU 也都是單核的，不像現在這樣處處都是高并發的應用場景。限于當時的硬件資源和應用場景，這個收集器優勢很突出，簡單高效、消耗資源也很少。

唯一的不足在于，在用戶不可見的情況下要把用戶正常工作的線程全部停掉，這對很多應用比較難以接受。不過實際上到目前為止，Serial 收集器依然是虛擬機在 Client 模式下運行的默認新生代收集器，因為它簡單而高效。客戶端應用模型下，分配給虛擬機管理的內存一般來說不會很大，收集幾十兆甚至一兩百兆的新生代對象，停頓時間平均在幾十毫秒，只要不是頻繁收集，完全可以接受。

整個流程，可以用如下圖來概括。

圖片

總結下來，收集器特點如下：

• 收集區域：Serial（新生代），Serial Old（老年代）
• 收集算法：Serial（復制算法），Serial Old（標記整理算法）
• 收集方式：單線程
• 優勢：簡單高效，內存資源占用少，單核 CPU 環境最佳選項
• 劣勢：整個搜集過程需要停頓用戶線程，多核 CPU、大內存的環境，資源優勢無法發揮起來

2.2、ParNew收集器

ParNew 收集器，可以看成是 Serial 收集器的多線程版本。除了使用多線程進行垃圾收集外，其余行為和 Serial 收集器完全一樣，包括使用的也是復制算法，垃圾收集時暫停用戶線程。在多核 CPU 資源環境下，可以顯著提升整個垃圾收集的性能，也是虛擬機在 Server 模式下運行的首選新生代收集器。

能讓 ParNew 出名的一個核心因素是，它是除了 Serial 收集器外，目前唯一一個能與 CMS 收集器配合一起使用的新生代收集器，因為 CMS 優秀所以 ParNew 也出名了，有點類似碰上了大款的感覺，其中 CMS 收集器是一款幾乎可以認為有劃時代意義的垃圾收集器，下文我們再講。

其次，ParNew 收集器在單個 CPU 的環境中絕對不會有比 Serial 收集器更好的效果，甚至由于線程交互的開銷，該收集器在兩個 CPU 的環境中都不能百分之百保證可以超越 Serial 收集器。當然，隨著可用 CPU 數量的增加，它對于垃圾收集的效率提升還是很有幫助的。

整個流程，可以用如下圖來概括。

圖片

總結下來，收集器特點如下：

• 收集區域：新生代
• 收集算法：復制算法
• 收集方式：多線程
• 優勢：多線程收集，多核 CPU 環境下效率要比 serial 高，新生代中，除了 Serial 收集器外目前唯一一個能與 CMS 配合的收集器
• 劣勢：整個搜集過程需要停頓用戶線程

3.3、Parallel Scavenge 和 Parallel Old收集器

Parallel Scavenge 和 ParNew 收集器很類似，也是一款使用多線程采用復制算法的新生代收集器；Parallel Old 收集器是一款使用多線程采用標記整理算法的老年代收集器；垃圾收集過程中也會暫停用戶線程，直到整個垃圾收集過程結束。

不同的是，Parallel 收集器更關注系統的吞吐量，也被稱為“吞吐量優先收集器”。

所謂吞吐量的意思就是 CPU 用于運行用戶代碼時間與 CPU 總消耗時間的比值，即吞吐量=運行用戶代碼時間/（運行用戶代碼時間+垃圾收集時間），比如虛擬機總運行 100 分鐘，垃圾收集 1 分鐘，那吞吐量就是 99%。高吞吐量可以高效率的利用 CPU 資源，盡快完成程序的運算任務，主要適合在后臺運算而不需要太多交互的任務。

自適應調節策略也是 Parallel Scavenge 與 ParNew 的一個重要區別，用戶可以通過參數來打開自適應調節策略，比如-XX:+UseAdaptiveSizePolicy參數，打開之后就不需要手動指定新生代大小、Eden 區和 Survivor 參數等細節參數了，虛擬機會根據當前系統的運行情況收集性能監控信息，動態調整這些參數以提供最合適的停頓時間或最大的吞吐量。如果對于垃圾收集器運作原理不太了解，優化比較困難的情況下，使用 Parallel 收集器配合自適應調節策略，把內存管理的調優任務交給虛擬機去完成也是一個不錯的選擇。

另外，Parallel 收集器是虛擬機在 Server 模式下運行的默認垃圾收集器。

整個執行流程，跟 ParNew 收集器類似。

總結下來，收集器特點如下：

• 收集區域：Parallel Scavenge（新生代），Parallel Old（老年代）
• 收集算法：Parallel Scavenge（復制算法），Parallel Old（標記整理算法）
• 收集方式：多線程
• 優勢：多線程收集，多核 CPU 環境下效率要比 serial 高
• 劣勢：整個搜集過程需要停頓用戶線程

2.4、CMS收集器

CMS 收集器是一種以獲取最短回收停頓時間為目標的老年代收集器。

與前面幾個收集器不同，它采用了一種全新的策略可以在垃圾回收過程中的某些階段用戶線程和垃圾回收線程一起工作，從而避免了因為長時間的垃圾回收而使用戶線程一直處于等待之中。

目前很大一部分 Java 應用集中在互聯網站或者 B/S 系統的服務端上，這類應用尤其注重服務的響應速度，希望系統停頓時間最短，比如在一個長度為 M 毫秒的時間片段內，消耗在垃圾收集上的時間不得超過多少毫秒，以期給用戶帶來較好的體驗，其中 CMS 收集器就非常符合這類應用的需求。

CMS 的英文全程是：Concurrent Mark-Sweep Collector，從名字上就能看出 CMS 收集器是基于“標記-清除”算法實現的，它的運作過程相對于前面幾種收集器來說要更復雜一些，整個過程分為如下 4 個步驟：

• 初始標記
• 并發標記
• 重新標記
• 并發清除

CMS 會根據每個階段不同的特性來決定是否停頓用戶線程。整個流程，可以用如下圖來概括。（圖片來自于勤勞的小手 - 垃圾收集器文章）

圖片

2.4.1、階段一：初始標記

初始標記階段的工作主要是標記一下 GC Roots 能直接關聯到的對象，這個過程會短暫的停頓用戶線程，因為并不會對整個 GC Roots 的引用進行遍歷，因此速度很快。

2.4.2、階段二：并發標記

并發標記階段的工作主要是把階段一標記好的 GC Roots 對象進行深度的遍歷，找到所有與 GC Roots 關聯的對象并進行標記，這個過程會采用多線程的方式進行遍歷標記，因為非常耗時，CMS 考慮到為了盡量不停頓用戶線程，因此這個階段不會暫停用戶線程，也就是說，此時 JVM 會分配一些資源給用戶線程執行任務，通過這樣的方式減少用戶線程的停頓時間。

2.4.3、階段三：重新標記

重新標記階段的工作主要是修補階段二用戶線程運行期間產生新的垃圾對象，進行重新標記，同樣也是采用多線程方式進行，此階段數量不會很多，會短暫的停頓用戶線程，速度也很快。

2.4.4、階段四：并發清除

并發清除階段的工作主要是對那些被標記為可回收的對象進行清理，在一般情況下，并發清除階段是使用的是“標記-清除”算法，因為這個過程不會牽扯到對象的地址變更，所以 CMS 在并發清除階段是不需要停止用戶線程的，對象回收效率非常高。

與此同時，正因為并發清除階段用戶線程也可以同時運行，所以在用戶線程運行的過程中自然也會產生新的垃圾對象，這也就是導致 CMS 收集器會產生“浮動垃圾”的原因，此時也會產生很多的空間碎片，當空間碎片到達了一定程度時，此時 CMS 就會使用“標記-整理”算法來解決空間碎片的問題。

在上文的垃圾回收算法中我們有說到，“標記-整理”算法會將對象的位置進行挪動并更新對象的引用的指向地址，在這個過程中，如果用戶線程同時運行的話會產生并發問題，因此當 CMS 進行碎片整理的時候必須得停止用戶線程。所以，在某些情況下，并發清除階段 CMS 也會停頓用戶線程。

CMS 收集器作為一個全新思路的垃圾收集器，雖然很優秀，但一直沒有被 Hospot 虛擬機納入為默認的垃圾收集器。時至今日，JDK1.8 使用的默認收集器都還是 Parallel scavenge 和 Parallel old 收集器，主要原因在于 CMS 存在一些比較頭疼的問題，比如浮動垃圾、空間碎片整理時會造成系統卡頓、在并發清除階段可能會出現系統長時間的假死。

2.4.5、小結

總結下來，收集器特點如下：

• 收集區域：老年代
• 收集算法：標記清除算法 + 標記整理算法
• 收集方式：多線程
• 優勢：多線程收集過程中可以做到不停止用戶線程，以獲取最短回收停頓時間
• 劣勢：會產生浮動垃圾、空間碎片整理時會造成系統卡頓、并發清除階段可能會出現系統假死等問題

2.5、G1收集器

G1（Garbage-First）收集器是當今收集器技術發展的最前沿成果之一，從 JDK 7 Update 4 后開始進入商用。

在 G1 收集器出現之前，不管是 Serial 系列，Parallel 系列，還是 CMS 收集器，它們都是基于把內存進行物理分區的形式將 JVM 內存分成新生代、老年代、永久代或 MetaSpace，這種分區模式下進行垃圾收集時必須對某個區域進行整體性的收集，比如整個新生代、整個老年代收集或者整個堆，當內存空間不大的時候，比如幾個 G，通過參數優化能取得不錯的收集性能。但是，隨著硬件資源的發展，JVM 可用內存從幾十 G 到幾百 G 甚至上 T 時，這種采用傳統模式下的物理分區進行收集時，每次掃描內存的區域自然就變大了，進行垃圾清理的時間自然就變得更長了，此時傳統的收集器即時再怎么優化，也難以取得令人滿意的收集效果，因此需要一款全新的垃圾收集器。

G1 收集器就是在這樣的環境下誕生的，它摒棄了原來的物理分區，把整個 Java 堆分成若干個大小相等的獨立區域（Region），雖然還保留有新生代和老年代的概念，但新生代和老年代不再是物理隔離，它們都是一部分 Region 的集合。從結構上看，G1 收集器不要求整個新生代或者老年代都是連續的，也不再堅持固定大小和固定數量，它會跟蹤各個 Region 里面的垃圾堆積的價值大小，在后臺維護一個優先列表，每次根據允許的收集時間，優先回收價值最大的 Region。這種通過 Region 劃分內存空間以及有優先級的區域回收方式，保證了 G1 收集器在有限的時間內可以獲取盡可能高的收集效率。

G1 收集器內存劃分，可以用如下圖來概括。（圖片來自于勤勞的小手 - 垃圾收集器文章）

圖片

在 G1 收集器里面維護了一個 Collect Set 集合，這個集合里面記錄了待回收的 Region 區域信息，同時也包括了每個 Region 區域可回收的大小空間。通過 Collect Set 里面的信息，G1 在進行垃圾收集時，可以根據用戶設定的可接受停頓時間來進行分析，在設定的時間范圍內優先收集垃圾最多的 Region 區域，以實現高吞吐、低停頓的收集效果。

在工作流程上，G1 收集器也吸收了 CMS 很多優秀的收集思路，整個垃圾收集過程，可以分為如下 4 個步驟：

• 初始標記
• 并發標記
• 重新標記
• 篩選回收

G1 收集器的垃圾回收流程和 CMS 邏輯大致相同，主要的區別在最后一個階段，G1 不會直接進行清除，而是會根據設置的停頓時間進行智能的篩選和局部的回收，采用“標記復制”算法來實現。

整個流程，可以用如下圖來概括。

圖片

2.5.1、階段一：初始標記

此階段的工作內容與上文介紹的 CMS 收集器一樣，會先把所有 GC Roots 直接引用的對象進行標記，同時會短暫的停止用戶線程，因為不會對整個 GC Roots 的引用進行遍歷，因此速度比較快。

2.5.2、階段二：并發標記

此階段的工作內容與上文介紹的 CMS 收集器也一樣，找到所有與 GC Roots 關聯的對象并進行深度遍歷標記，會采用多線程的方式進行遍歷標記，因為比較耗時，為了盡量不停頓用戶線程，這個階段 GC 線程會和用戶線程同時運行，通過這樣的方式減少用戶線程的停頓時間。

2.5.3、階段三：重新標記

此階段的工作內容與上文介紹的 CMS 收集器也是一樣，針對階段二用戶線程運行的過程中產生新的垃圾，采用多線程方式進行重新標記，為了避免這個過程再次產生新的垃圾對象，會短暫的停止用戶線程，因為數量不會很多，因此速度比較快。

2.5.4、階段四：篩選回收

篩選回收階段的工作主要是把存活的對象復制到 Region 空閑區域，同時會根據 Collect Set 記錄的可回收 Region 信息進行篩選，計算 Region 回收成本，接著根據用戶設定的停頓時間值制定回收計劃，最后根據回收計劃篩選合適的 Region 區域進行垃圾回收。

從局部來看，G1 使用的是復制算法，將存活對象從一個 Region 區域復制到另一個 Region 空閑區域；但從整個堆來看，G1 使用的邏輯又相當于標記整理算法，每次垃圾收集時會把存活的對象整理到對應可用的 Region 區域，再把原來的 Region 區域標記為可回收區域并記錄到 Collect Set 中，因此 G1 的每一次回收都可以看作是一次標記整理過程，兩者都不會產生空間碎片問題。

2.5.5、小結

總結下來，收集器特點如下：

• 收集區域：整個堆內存
• 收集算法：復制算法
• 收集方式：多線程
• 優勢：停頓時間可控，吞吐量高，不會產生空間碎片，不需要額外的收集器搭配
• 劣勢：目前而言，相較于 CMS，G1 還不具備全方位、壓倒性優勢，G1 在收集過程中內存占用和執行負載都偏高；其次，在小內存應用上 CMS 的表現大概率會優于 G1，而 G1 在大內存應用上會比較有優勢，6G 以上的內存可以考慮使用 G1 收集器

2.6、常用的收集器組合

最后我們對以上介紹的垃圾收集器進行一次匯總，同時介紹一下服務器端常用的組合模式，內容如下。

03、方法區回收

以上介紹的都是對象的回收過程，在之前的 JVM 內存結構的文章中我們介紹到，Java 應用程序運行時，除了堆空間會存在垃圾數據以外，方法區同樣也存在。

雖然虛擬機規范中沒有明確要求方法區一定要實現垃圾回收，主要原因在于這個區域的垃圾回收效率非常低，但是 HotSpot 虛擬機對方法區也會進行回收的，主要回收的是廢棄常量和無用的類兩部分。

如何判斷一個常量是否為“廢棄常量”呢？其實很簡單，只要當前系統中沒有任何一處引用該常量，就會被判定為廢棄常量。

如何判斷一個類是否為“無用的類”呢？條件非常苛刻，需要同時滿足以下三點。

• 1.該類所有實例都已經被回收，也就是說 Java 堆中不存在該類的任何實例
• 2.該類對應的java.lang.Class對象沒有在任何地方被引用，無法在任何地方通過反射訪問該類的方法
• 3.加載該類的 ClassLoader 已經被回收，也就是說這個類的類加載器被卸載回收了

滿足以上三個條件則表示這個類再也無用了，HotSpot 虛擬機會對此類進行回收。例如在大量使用反射、動態代理、CGLib 等 ByteCode 框架，并自定義 ClassLoader 創建的類，為了保證方法區不會溢出，虛擬機會在適當的情況下對無用的類進行回收。

在 JDK1.7 及以前的版本中，用永久代來作為方法區的實現，當永久代的空間不足時會觸發 Full GC。

在 JDK1.8 及之后的版本中，用元空間來作為方法區的實現，元空間的內存空間默認使用的是操作系統的內存空間，它的垃圾回收不再由 Java 來控制，元空間的內存管理由元空間虛擬機來完成。

04、小結

本文主要圍繞對象的垃圾收集器，做了一次知識內容的整理和總結，如果有描述不當的地方，歡迎大家留言指出，不勝感激。

05、參考

1.https://zhuanlan.zhihu.com/p/267223891

2.https://www.cnblogs.com/xrq730/p/4836700.html

3.https://zhuanlan.zhihu.com/p/248709769

4.http://www.ityouknow.com/jvm/2017/09/28/jvm-overview.html