Java的垃圾回收器有哪些

這篇文章主要講解了“Java的垃圾回收器有哪些”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“Java的垃圾回收器有哪些”吧！

我們先回顧一下主流Java的垃圾回收器(HotSpot JVM)。本文是針對堆的垃圾回收展開討論的。 堆被分解為較小的三個部分。具體分為：新生代、老年代、持久代。

1. 絕大部分新生成的對象都放在Eden區，當Eden區將滿，JVM會因申請不到內存，而觸發Young GC ,進行Eden區+有對象的Survivor區(設為S0區)垃圾回收，把存活的對象用復制算法拷貝到一個空的Survivor(S1)中，此時Eden區被清空，另外一個Survivor S0也為空。下次觸發Young GC回收Eden+S0，將存活對象拷貝到S1中。新生代垃圾回收簡單、粗暴、高效。

2. 若發現Survivor區滿了，則將這些對象拷貝到old區或者Survivor沒滿但某些對象足夠Old,也拷貝到Old區(每次Young GC都會使Survivor區存活對象值+1，直到閾值)。 Old區也會進行垃圾收集(Young GC),發生一次 Major GC 至少伴隨一次Young GC，一般比Young GC慢十倍以上。

3. JVM在Old區申請不到內存，會進行Full GC。Old區使用一般采用Concurrent-Mark–Sweep策略回收內存。 總結：Java垃圾回收器是一種“自適應的、分代的、停止—復制、標記-清掃”式的垃圾回收器 缺點：

4. GC過程中會出現STW(Stop-The-World)，若Old區對象太多，STW耗費大量時間。

5. CMS收集器對CPU資源很敏感。

6. CMS收集器無法處理浮動垃圾，可能出現“Concurrent Mode Failure”失敗而導致另一次Full GC的產生。

7. CMS導致內存碎片問題

#比較

1. Serial收集器
   Serial收集器是JAVA虛擬機中最基本、歷史最悠久的收集器，在JDK 1.3.1之前是JAVA虛擬機新生代收集的唯一選擇。Serial收集器是一個單線程的收集器，但它的“單線程”的意義并不僅僅是說明它只會使用一個CPU或一條收集線程去完成垃圾收集工作，更重要的是在它進行垃圾收集時，必須暫停其他所有的工作線程，直到它收集結束。 Serial收集器到JDK1.7為止，它依然是JAVA虛擬機運行在Client模式下的默認新生代收集器。它也有著優于其他收集器的地方：簡單而高效（與其他收集器的單線程比），對于限定單個CPU的環境來說，Serial收集器由于沒有線程交互的開銷，專心做垃圾收集自然可以獲得最高的單線程收集效率。在用戶的桌面應用場景中，分配給虛擬機管理的內存一般來說不會很大，收集幾十兆甚至一兩百兆的新生代（僅僅是新生代使用的內存，桌面應用基本上不會再大了），停頓時間完全可以控制在幾十毫秒最多一百多毫秒以內，只要不是頻繁發生，這點停頓是可以接受的。所以，Serial收集器對于運行在Client模式下的虛擬機來說是一個很好的選擇。
   PS：開啟Serial收集器的方式 -XX:+UseSerialGC 如：Xms30m -Xmx30m -Xmn10m -XX:+UseSerialGC -XX:+PrintGCDetails -XX:+UseSerialGC的是Serial收集器，Xms30m -Xmx30m 指定了JAVA虛擬機的固定大小為30M，-Xmn10m 指JAVA新生代的空間為10M。

2. Parallel（并行）收集器
   這是 JVM 的缺省收集器。就像它的名字，其最大的優點是使用多個線程來通過掃描并壓縮堆。串行收集器在GC時會停止其他所有工作線程（stop-the-world），CPU利用率是最高的，所以適用于要求高吞吐量（throughput）的應用，但停頓時間（pause time）會比較長，所以對web應用來說就不適合，因為這意味著用戶等待時間會加長。而并行收集器可以理解是多線程串行收集，在串行收集基礎上采用多線程方式進行GC，很好的彌補了串行收集的不足，可以大幅縮短停頓時間（如下圖表示的停頓時長高度，并發比并行要短），因此對于空間不大的區域（如young generation），采用并行收集器停頓時間很短，回收效率高，適合高頻率執行。 圖1.Serial收集器與Parallel/ Throughput（并行）收集器的比較

3. CMS收集器
   CMS（Concurrent Mark Sweep）收集器是基于“標記-清除”算法實現的，它使用多線程的算法去掃描堆（標記）并對發現的未使用的對象進行回收（清除）。整個過程分為6個步驟，包括： 初始標記（CMS initial mark）

   并發標記（CMS concurrent mark）

   并發預清理（CMS-concurrent-preclean）

   重新標記（CMS remark）

   并發清除（CMS concurrent sweep）

   并發重置（CMS-concurrent-reset）

   其中初始標記、重新標記這兩個步驟仍然需要“Stop The World”。
   初始標記僅僅只是標記一下GC Roots能直接關聯到的對象，速度很快
   并發標記階段就是進行GC Roots Tracing的過程
   重新標記階段則是為了修正并發標記期間，因用戶程序繼續運作而導致標記產生變動的那一部分對象的標記記錄，這個階段的停頓時間一般會比初始標記階段稍長一些，但遠比并發標記的時間短。其他動作都是并發的。

   需要注意的是，CMS收集器無法處理浮動垃圾（Floating Garbage），可能出現“Concurrent Mode Failure”失敗而導致另一次Full GC的產生。由于CMS并發清理階段用戶線程還在運行著，伴隨程序的運行自然還會有新的垃圾不斷產生，這一部分垃圾出現在標記過程之后，CMS無法在本次收集中處理掉它們，只好留待下一次GC時再將其清理掉。這一部分垃圾就稱為“浮動垃圾”。也是由于在垃圾收集階段用戶線程還需要運行，即還需要預留足夠的內存空間給用戶線程使用，因此CMS收集器不能像其他收集器那樣等到老年代幾乎完全被填滿了再進行收集，需要預留一部分空間提供并發收集時的程序運作使用。在默認設置下，CMS收集器在老年代使用了68%的空間后就會被激活，這是一個偏保守的設置，如果在應用中老年代增長不是太快，可以適當調高參數-XX:CMSInitiatingOccupancyFraction的值來提高觸發百分比，以便降低內存回收次數以獲取更好的性能。要是CMS運行期間預留的內存無法滿足程序需要，就會出現一次“Concurrent Mode Failure”失敗，這時候虛擬機將啟動后備預案：臨時啟用Serial Old收集器來重新進行老年代的垃圾收集，這樣停頓時間就很長了。所以說參數-XX:CMSInitiatingOccupancyFraction設置得太高將會很容易導致大量“Concurrent Mode Failure”失敗，性能反而降低。
   還有一個缺點，CMS是一款基于“標記-清除”算法實現的收集器，這意味著收集結束時會產生大量空間碎片。空間碎片過多時，將會給大對象分配帶來很大的麻煩，往往會出現老年代還有很大的空間剩余，但是無法找到足夠大的連續空間來分配當前對象，不得不提前觸發一次Full GC。為了解決這個問題，CMS收集器提供了一個-XX:+UseCMSCompactAtFullCollection開關參數，用于在“享受”完Full GC服務之后額外免費附送一個碎片整理過程，內存整理的過程是無法并發的。空間碎片問題沒有了，但停頓時間不得不變長了。虛擬機設計者們還提供了另外一個參數-XX: CMSFullGCsBeforeCompaction，這個參數用于設置在執行多少次不壓縮的Full GC后，跟著來一次帶壓縮的。
   該算法與并行收集器的另一個缺點是吞吐量的它使用更多的 CPU，為了使應用程序提供更好的體驗，通過使用多個線程來執行掃描和收集。這種情況長時間的運行會使應用程序停頓下來，可以使用提高空間來換取高效的運行。但是，這種算法的使用不是默認的。您必須指定 XX： + USeParNewGC來使用它。如果你可以提供更多的CPU資源的話以避免應用程序暫停，那么你可以使用CMS收集器。假設你的堆的大小小于 4 Gb你必須分配大于 4 GB的資源。

4. G1收集器
   G1垃圾收集器在JDK7 update 4之后對大于4G的堆有了更好的支持，G1是一個針對多處理器大容量內存的服務器端的垃圾收集器，其目標是在實現高吞吐量的同時，盡可能的滿足垃圾收集暫停時間的要求。G1在執行一些Java堆空間中的全區域操作（如：全局標記）時是和應用程序線程并發進行的，因此減少了Java堆空間的中斷比例。（譯者注：可簡單理解為減少了Stop-the-World的時間比例）。
   它與前面的CMS收集器相比有兩個顯著的改進：一是G1收集器是基于“標記-整理”算法實現的收集器，也就是說它不會產生空間碎片，這對于長時間運行的應用系統來說非常重要。二是它可以非常精確地控制停頓，既能讓使用者明確指定在一個長度為M毫秒的時間片段內，消耗在垃圾收集上的時間不得超過N毫秒，具備了一些實時Java（RTSJ）的垃圾收集器的特征。
   首先將Java堆空間劃分為一些大小相等的區域（region），每個區域都是虛擬機中的一段連續內存空間。G1通過執行并發的全局標記來確定整個Java堆空間中存活的對象。標記階段完成后，G1就知道哪些區域基本上是空閑的。在回收內存時優先回收這些區域，這樣通常都會回收相當數量的內存。這就是為什么它叫做Garbage-First的原因。顧名思義G1關注某些區域的回收和整理，這些區域中的對象很有可能被完全回收。而且G1使用了一個暫停時間預測模型使得暫停時間控制在用戶指定的暫停時間內，并根據用戶指定的暫停時間來選擇合適的區域回收內存。
   G1確定了可回收的區域后就是篩選回收（evacuation）階段了。在此階段將對象從一個或多個區域復制到單一區域，同時整理和釋放內存。該階段是在多個處理器上多個線程并行進行的，因此減少了暫停時間并提高了吞吐量。G1在每一次的垃圾收集過程中都不斷地減少碎片，并能夠將暫停時間控制在一定范圍內。這些已經是以前的垃圾收集器無法完成的了。比如：CMS收集器并不做內存整理。ParallelOld收集器只是對整個Java堆空間做整理，這樣導致相當長的暫停時間。

感謝各位的閱讀，以上就是“Java的垃圾回收器有哪些”的內容了，經過本文的學習后，相信大家對Java的垃圾回收器有哪些這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！