java垃圾回收的必要性

程式的運作必然需要申請記憶體資源，無效的對象資源如果不及時處理就會一直占有記憶體資源，最終将導緻記憶體溢

出，是以對記憶體資源的管理是非常重要了。

在C/C++語言中，沒有自動垃圾回收機制，是通過new關鍵字申請記憶體資源，通過delete關鍵字釋放記憶體資源。

如果，程式員在某些位置沒有寫delete進行釋放，那麼申請的對象将一直占用記憶體資源，最終可能會導緻記憶體溢

出。

為了讓程式員更專注于代碼的實作，而不用過多的考慮記憶體釋放的問題，是以，在Java語言中，有了自動的垃圾回收機制，也就是我們熟悉的GC。

有了垃圾回收機制後，程式員隻需要關心記憶體的申請即可，記憶體的釋放由系統自動識别完成。

換句話說，自動的垃圾回收的算法就會變得非常重要了，如果因為算法的不合理，導緻記憶體資源一直沒有釋放，同樣也可能會導緻記憶體溢出的。

當然，除了Java語言，C#、Python等語言也都有自動的垃圾回收機制。

常見的垃圾回收算法

自動化的管理記憶體資源，垃圾回收機制必須要有一套算法來進行計算，哪些是有效的對象，哪些是無效的對象，對

于無效的對象就要進行回收處理。

常見的垃圾回收算法有：引用計數法、标記清除法、标記壓縮法、複制算法、分代算法等。

引用計數法：

原理:

假設有一個對象A，任何一個對象對A的引用，那麼對象A的引用計數器+1，當引用失敗時，對象A的引用計數器就-1，如果對象A的計數器的值為0，就說明對象A沒有引用了，可以被回收。

優點：

實時性較高，無需等到記憶體不夠的時候，才開始回收，運作時根據對象的計數器是否為0，就可以直接回收。
在垃圾回收過程中，應用無需挂起。如果申請記憶體時，記憶體不足，則立刻報outofmember 錯誤。
區域性，更新對象的計數器時，隻是影響到該對象，不會掃描全部對象。

缺點：

每次對象被引用時，都需要去更新計數器，有一點時間開銷。
浪費CPU資源，即使記憶體夠用，仍然在運作時進行計數器的統計。
無法解決循環引用問題。（最大的缺點）

循環引用

class TestA{
 public TestB b;
}
class TestB{
 public TestA a;
}
public class Main{
  public static void main(String[] args){
    A a = new A();
    B b = new B();
    a.b=b;
    b.a=a;
    a = null;
    b = null;
 }
}

雖然a和b都為null，但是由于a和b存在循環引用，這樣a和b永遠都不會被回收。

标記清除算法

原理：

标記清除算法，是将垃圾回收分為2個階段，分别是标記和清除。

标記：從根節點開始标記引用的對象。
清除：未被标記引用的對象就是垃圾對象，可以被清理。

GC垃圾回收機制java垃圾回收的必要性常見的垃圾回收算法垃圾收集器以及記憶體配置設定

這張圖代表的是程式運作期間所有對象的狀态，它們的标志位全部是0（也就是未标記，以下預設0就是未标記，1為已标記），假設這會兒有效記憶體空間耗盡了，JVM将會停止應用程式的運作并開啟GC線程，然後開始進行标記工作，按照根搜尋算法，标記完以後，對象的狀态如下圖。

可以看到，按照根搜尋算法，所有從root對象可達的對象就被标記為了存活的對象，此時已經完成了第一階段标記。接下來，就要執行第二階段清除了，那麼清除完以後，剩下的對象以及對象的狀态如下圖所示。

可以看到，沒有被标記的對象将會回收清除掉，而被标記的對象将會留下，并且會将标記位重新歸0。接下來就不用說了，喚醒停止的程式線程，讓程式繼續運作即可。

優點：标記清除算法解決了引用計數算法中的循環引用的問題，沒有從root節點引用的對象都會被回收。
效率較低，标記和清除兩個動作都需要周遊所有的對象，并且在GC時，需要停止應用程式，對于互動性要求比較高的應用而言這個體驗是非常差的。

通過标記清除算法清理出來的記憶體，碎片化較為嚴重，因為被回收的對象可能存在于記憶體的各個角落，是以

清理出來的記憶體是不連貫的。

标記壓縮算法

标記壓縮算法是在标記清除算法的基礎之上，做了優化改進的算法。和标記清除算法一樣，也是從根節點開始，對對象的引用進行标記，在清理階段，并不是簡單的清理未标記的對象，而是将存活的對象壓縮到記憶體的一端，然後清理邊界以外的垃圾，進而解決了碎片化的問題。

優缺點：

優缺點同标記清除算法，解決了标記清除算法的碎片化的問題，同時，标記壓縮算法多了一步，對象移動記憶體位置的步驟，其效率也有有一定的影響。

複制算法

複制算法的核心就是，将原有的記憶體空間一分為二，每次隻用其中的一塊，在垃圾回收時，将正在使用的對象複制到另一個記憶體空間中，然後将該記憶體空間清空，交換兩個記憶體的角色，完成垃圾的回收。

如果記憶體中的垃圾對象較多，需要複制的對象就較少，這種情況下适合使用該方式并且效率比較高，反之，則不适合。

JVM中年輕代的記憶體空間（young-gc|年輕代使用的複制算法）

在GC開始的時候，對象隻會存在于Eden區和名為“From”的Survivor區，Survivor區“To”是空的。
緊接着進行GC，Eden區中所有存活的對象都會被複制到“To”，而在“From”區中，仍存活的對象會根據他們的年齡值來決定去向。年齡達到一定值(年齡門檻值，可以通過-XX:MaxTenuringThreshold來設定)的對象會被移動到年老代中，沒有達到門檻值的對象會被複制到“To”區域。
經過這次GC後，Eden區和From區已經被清空。這個時候，“From”和“To”會交換他們的角色，也就是新

的“To”就是上次GC前的“From”，新的“From”就是上次GC前的“To”。不管怎樣，都會保證名為To的Survivor區域是空的。

GC會一直重複這樣的過程，直到“To”區被填滿，“To”區被填滿之後，會将所有對象移動到年老代中。

在垃圾對象多的情況下，效率較高（使用在young區比較合适，因為new的對象比較多，然後就會大量的回收）
清理後，記憶體無碎片
在垃圾對象少的情況下，不适用，如：老年代記憶體
配置設定的2塊記憶體空間，在同一個時刻，隻能使用一半，記憶體使用率較低

分代算法

前面介紹了多種回收算法，每一種算法都有自己的優點也有缺點，誰都不能替代誰，是以根據垃圾回收對象的特點進行選擇，才是明智的選擇。

分代算法其實就是這樣的，根據回收對象的特點進行選擇，在jvm中，年輕代适合使用複制算法，老年代适合使用标記清除或标記壓縮算法。

垃圾收集器以及記憶體配置設定

串行垃圾收集器

串行垃圾收集器，是指使用單線程進行垃圾回收，垃圾回收時，隻有一個線程在工作，并且java應用中的所有線程都要暫停，等待垃圾回收的完成。這種現象稱之為STW（Stop-The-World）。

對于互動性較強的應用而言，這種垃圾收集器是不能夠接受的。

一般在Javaweb應用中是不會采用該收集器的。

測試GC：

編寫代碼

public class TestGC {
  public static void main(String[] args) throws Exception {
    List<Object> list = new ArrayList<Object>();
    while (true){
      int sleep = new Random().nextInt(100);
      if(System.currentTimeMillis() % 2 ==0){
        list.clear();
     }else{
        for (int i = 0; i < 10000; i++) {
          Properties properties = new Properties();
          properties.put("key_"+i, "value_" + System.currentTimeMillis() +
i);
          list.add(properties);
       }
     }
     // System.out.println("list大小為：" + list.size());
      Thread.sleep(sleep);
   }
 }
}

設定垃圾回收為串行收集器
在程式運作參數中添加2個參數，如下：

-XX:+UseSerialGC 指定年輕代和老年代都使用串行垃圾收集器

-XX:+PrintGCDetails 列印垃圾回收的詳細資訊

# 為了測試GC，将堆的初始和最大記憶體都設定為16M
-XX:+UseSerialGC -XX:+PrintGCDetails -Xms16m -Xmx16m

啟動程式，可以看到下面資訊：

[GC (Allocation Failure) [DefNew: 4416K->512K(4928K), 0.0046102 secs] 4416K-
>1973K(15872K), 0.0046533 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
[Full GC (Allocation Failure) [Tenured: 10944K->3107K(10944K), 0.0085637 secs] 15871K-
>3107K(15872K), [Metaspace: 3496K->3496K(1056768K)], 0.0085974 secs] [Times: user=0.02
sys=0.00, real=0.01 secs]

GC日志資訊解讀：
年輕代的記憶體GC前後的大小：
- DefNew：表示使用的是串行垃圾收集器。
  - 4416K->512K(4928K) ：表示，年輕代GC前，占有4416K記憶體，GC後，占有512K記憶體，總大小4928K
  - 0.0046102 secs：表示，GC所用的時間，機關為毫秒。
  - 4416K->1973K(15872K)：表示，GC前，堆記憶體占有4416K，GC後，占有1973K，總大小為15872K
  - Full GC：表示，記憶體空間全部進行GC

并行垃圾收集器

并行垃圾收集器在串行垃圾收集器的基礎之上做了改進，将單線程改為了多線程進行垃圾回收，這樣可以縮短垃圾回收的時間。（這裡是指，并行能力較強的機器）

當然了，并行垃圾收集器在收集的過程中也會暫停應用程式，這個和串行垃圾回收器是一樣的，隻是并行執行，速度更快些，暫停的時間更短一些。

ParNew垃圾收集器（工作在年輕代上面）

ParNew垃圾收集器是工作在年輕代上的，隻是将串行的垃圾收集器改為了并行。

通過-XX:+UseParNewGC參數設定年輕代使用ParNew回收器，老年代使用的依然是串行收集器。

ParallelGC垃圾收集器（工作在年輕代或者是老年代上面）

ParallelGC收集器工作機制和ParNewGC收集器一樣，隻是在此基礎之上，新增了兩個和系統吞吐量相關的參數，

使得其使用起來更加的靈活和高效。

相關參數如下：

-XX:+UseParallelGC

年輕代使用ParallelGC垃圾回收器，老年代使用串行回收器。

-XX:+UseParallelOldGC

年輕代使用ParallelGC垃圾回收器，老年代使用ParallelOldGC垃圾回收器。

-XX:MaxGCPauseMillis

設定最大的垃圾收集時的停頓時間，機關為毫秒

需要注意的時，ParallelGC為了達到設定的停頓時間，可能會調整堆大小或其他的參數，如果堆的大小

設定的較小，就會導緻GC工作變得很頻繁，反而可能會影響到性能。

該參數使用需謹慎。

-XX:GCTimeRatio

設定垃圾回收時間占程式運作時間的百分比，公式為1/(1+n)。

它的值為0~100之間的數字，預設值為99，也就是垃圾回收時間不能超過1%

-XX:UseAdaptiveSizePolicy

自适應GC模式，垃圾回收器将自動調整年輕代、老年代等參數，達到吞吐量、堆大小、停頓時間之間的

平衡。

一般用于，手動調整參數比較困難的場景，讓收集器自動進行調整。

CMS垃圾收集器

CMS全稱 Concurrent Mark Sweep，是一款并發的、使用标記-清除算法的垃圾回收器，該回收器是針對老年代垃圾回收的，通過參數-XX:+UseConcMarkSweepGC進行設定。

初始化标記(CMS-initial-mark) ,标記root，會導緻stw；
并發标記(CMS-concurrent-mark)，與使用者線程同時運作；
預清理（CMS-concurrent-preclean），與使用者線程同時運作；
重新标記(CMS-remark) ，會導緻stw；
并發清除(CMS-concurrent-sweep)，與使用者線程同時運作；
調整堆大小，設定CMS在清理之後進行記憶體壓縮，目的是清理記憶體中的碎片；
并發重置狀态等待下次CMS的觸發(CMS-concurrent-reset)，與使用者線程同時運作；

G1垃圾收集器（重點）

G1垃圾收集器是在jdk1.7中正式使用的全新的垃圾收集器，oracle官方計劃在jdk9中将G1變成預設的垃圾收集器，以替代CMS。

G1的設計原則就是簡化JVM性能調優，開發人員隻需要簡單的三步即可完成調優：

第一步，開啟G1垃圾收集器
第二步，設定堆的最大記憶體
第三步，設定最大的停頓時間

G1中提供了三種模式垃圾回收模式，Young GC、Mixed GC 和 Full GC，在不同的條件下被觸發。

原理

G1垃圾收集器相對比其他收集器而言，最大的差別在于它取消了年輕代、老年代的實體劃分，取而代之的是将堆劃分為若幹個區域（Region），這些區域中包含了有邏輯上的年輕代、老年代區域。

這樣做的好處就是，我們再也不用單獨的空間對每個代進行設定了，不用擔心每個代記憶體是否足夠。

在G1劃分的區域中，年輕代的垃圾收集依然采用暫停所有應用線程的方式，将存活對象拷貝到老年代或者Survivor空間，G1收集器通過将對象從一個區域複制（将區域覆寫）到另外一個區域，完成了清理工作。

這就意味着，在正常的處理過程中，G1完成了堆的壓縮（至少是部分堆的壓縮），這樣也就不會有cms記憶體碎片問題的存在了。

在G1中，有一種特殊的區域，叫Humongous區域。

如果一個對象占用的空間超過了分區容量50%以上，G1收集器就認為這是一個巨型對象。

這些巨型對象，預設直接會被配置設定在老年代，但是如果它是一個短期存在的巨型對象，就會對垃圾收集器造

成負面影響。

為了解決這個問題，G1劃分了一個Humongous區，它用來專門存放巨型對象。如果一個H區裝不下一個巨型

對象，那麼G1會尋找連續的H分區來存儲。為了能找到連續的H區，有時候不得不啟動Full GC。

Young GC

Young GC主要是對Eden區進行GC，它在Eden空間耗盡時會被觸發。

Eden空間的資料移動到Survivor空間中，如果Survivor空間不夠，Eden空間的部分資料會直接晉升到年老代

空間。

Survivor區的資料移動到新的Survivor區中，也有部分資料晉升到老年代空間中。
最終Eden空間的資料為空，GC停止工作，應用線程繼續執行。

Remembered Set（已記憶集合）

在GC年輕代的對象時，我們如何找到年輕代中對象的根對象呢？

根對象可能是在年輕代中，也可以在老年代中，那麼老年代中的所有對象都是根麼？

如果全量掃描老年代，那麼這樣掃描下來會耗費大量的時間。

于是，G1引進了RSet的概念。它的全稱是Remembered Set，其作用是跟蹤指向某個堆内的對象引用。

每個Region初始化時，會初始化一個RSet，該集合用來記錄并跟蹤其它Region指向該Region中對象的引用，每個Region預設按照512Kb劃分成多個Card，是以RSet需要記錄的東西應該是 xx Region的 xx Card。

Mixed GC

當越來越多的對象晉升到老年代old region時，為了避免堆記憶體被耗盡，虛拟機會觸發一個混合的垃圾收集器，即Mixed GC，該算法并不是一個Old GC，除了回收整個Young Region，還會回收一部分的Old Region，這裡需要注意：是一部分老年代，而不是全部老年代，可以選擇哪些old region進行收集，進而可以對垃圾回收的耗時時間進行控制。也要注意的是Mixed GC 并不是 Full GC。

MixedGC什麼時候觸發？由參數 -XX:InitiatingHeapOccupancyPercent=n 決定。預設：45%，該參數的意思是：

當老年代大小占整個堆大小百分比達到該閥值時觸發。

它的GC步驟分2步：

全局并發标記（global concurrent marking）
拷貝存活對象（evacuation）

全局并發标記

全局并發标記，執行過程分為五個步驟：

初始标記（initial mark，STW）

标記從根節點直接可達的對象，這個階段會執行一次年輕代GC，會産生全局停頓。

根區域掃描（root region scan）

G1 GC 在初始标記的存活區掃描對老年代的引用，并标記被引用的對象。

該階段與應用程式（非 STW）同時運作，并且隻有完成該階段後，才能開始下一次 STW 年輕代垃圾回

收。

并發标記（Concurrent Marking）

G1 GC 在整個堆中查找可通路的（存活的）對象。該階段與應用程式同時運作，可以被 STW 年輕代垃

圾回收中斷。

重新标記（Remark，STW）

該階段是 STW 回收，因為程式在運作，針對上一次的标記進行修正。

清除垃圾（Cleanup，STW）

清點和重置标記狀态，該階段會STW，這個階段并不會實際上去做垃圾的收集，等待evacuation階段來

回收。

拷貝存活對象

Evacuation階段是全暫停的。該階段把一部分Region裡的活對象拷貝到另一部分Region中，進而實作垃圾的回收清理。

G1收集器相關參數

-XX:+UseG1GC

使用 G1 垃圾收集器

設定期望達到的最大GC停頓時間名額（JVM會盡力實作，但不保證達到），預設值是 200 毫秒。

-XX:G1HeapRegionSize=n

設定的 G1 區域的大小。值是 2 的幂，範圍是 1 MB 到 32 MB 之間。目标是根據最小的 Java 堆大小劃

分出約 2048 個區域。預設是堆記憶體的1/2000。

-XX:ParallelGCThreads=n

設定 STW 工作線程數的值。将 n 的值設定為邏輯處理器的數量。n 的值與邏輯處理器的數量相同，最多

為 8。

-XX:ConcGCThreads=n

設定并行标記的線程數。将 n 設定為并行垃圾回收線程數 (ParallelGCThreads) 的 1/4 左右。

-XX:InitiatingHeapOccupancyPercent=n

設定觸發标記周期的 Java 堆占用率門檻值。預設占用率是整個 Java 堆的 45%。

測試結果及說明：

-XX:+UseG1GC -XX:MaxGCPauseMillis=100 -XX:+PrintGCDetails -Xmx256m
#日志
[GC pause (G1 Evacuation Pause) (young), 0.0044882 secs]
 [Parallel Time: 3.7 ms, GC Workers: 3]
  [GC Worker Start (ms): Min: 14763.7, Avg: 14763.8, Max: 14763.8, Diff: 0.1]
   #掃描根節點
  [Ext Root Scanning (ms): Min: 0.2, Avg: 0.3, Max: 0.3, Diff: 0.1, Sum: 0.8]
   #更新RS區域所消耗的時間
  [Update RS (ms): Min: 1.8, Avg: 1.9, Max: 1.9, Diff: 0.2, Sum: 5.6]
    [Processed Buffers: Min: 1, Avg: 1.7, Max: 3, Diff: 2, Sum: 5]
  [Scan RS (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
  [Code Root Scanning (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
   #對象拷貝
  [Object Copy (ms): Min: 1.1, Avg: 1.2, Max: 1.3, Diff: 0.2, Sum: 3.6]
  [Termination (ms): Min: 0.0, Avg: 0.1, Max: 0.2, Diff: 0.2, Sum: 0.2]
    [Termination Attempts: Min: 1, Avg: 1.0, Max: 1, Diff: 0, Sum: 3]
  [GC Worker Other (ms): Min: 0.0, Avg: 0.0, Max: 0.0, Diff: 0.0, Sum: 0.0]
  [GC Worker Total (ms): Min: 3.4, Avg: 3.4, Max: 3.5, Diff: 0.1, Sum: 10.3]
  [GC Worker End (ms): Min: 14767.2, Avg: 14767.2, Max: 14767.3, Diff: 0.1]
 [Code Root Fixup: 0.0 ms]
 [Code Root Purge: 0.0 ms]
 [Clear CT: 0.0 ms] #清空CardTable
 [Other: 0.7 ms]
  [Choose CSet: 0.0 ms] #選取CSet
  [Ref Proc: 0.5 ms] #弱引用、軟引用的處理耗時
  [Ref Enq: 0.0 ms] #弱引用、軟引用的入隊耗時
  [Redirty Cards: 0.0 ms]
  [Humongous Register: 0.0 ms] #大對象區域注冊耗時
  [Humongous Reclaim: 0.0 ms] #大對象區域回收耗時
  [Free CSet: 0.0 ms]
 [Eden: 7168.0K(7168.0K)->0.0B(13.0M) Survivors: 2048.0K->2048.0K Heap:
55.5M(192.0M)->48.5M(192.0M)] #年輕代的大小統計
[Times: user=0.00 sys=0.00, real=0.00 secs]

對于G1垃圾收集器優化建議

年輕代大小

避免使用 -Xmn 選項或 -XX:NewRatio 等其他相關選項顯式設定年輕代大小。

固定年輕代的大小會覆寫暫停時間目标。

暫停時間目标不要太過嚴苛

G1 GC 的吞吐量目标是 90% 的應用程式時間和 10%的垃圾回收時間。

評估 G1 GC 的吞吐量時，暫停時間目标不要太嚴苛。目标太過嚴苛表示您願意承受更多的垃圾回收開

銷，而這會直接影響到吞吐量。

可視化GC日志分析工具

GC日志輸出參數

-XX:+PrintGC 輸出GC日志
-XX:+PrintGCDetails 輸出GC的詳細日志
-XX:+PrintGCTimeStamps 輸出GC的時間戳（以基準時間的形式）
-XX:+PrintGCDateStamps 輸出GC的時間戳（以日期的形式，如 2013-05-04T21:53:59.234+0800）
-XX:+PrintHeapAtGC 在進行GC的前後列印出堆的資訊
-Xloggc:../logs/gc.log 日志檔案的輸出路徑

運作後就可以在F盤下生成gc.log檔案。

GC Easy 可視化工具

網址：

http://gceasy.io/

GC垃圾回收機制java垃圾回收的必要性常見的垃圾回收算法垃圾收集器以及記憶體配置設定