Java11新特性 - Epsilon GC和ZGC

Java11中新增了兩個GC，Epsilon GC和ZGC。

Epsilon垃圾收集器

A NoOp Garbage Collector
沒有操做的垃圾收集器

JDK上對這個特性的描述是：開發一個處理內存分配但不實現任何實際內存回收機制的GC， 一旦可用堆內存用完，JVM就會退出。
若是有System.gc()調用，實際上什麼也不會發生(這種場景下和-XX:+DisableExplicitGC效果同樣)， 由於沒有內存回收，這個實現可能會警告用戶嘗試強制GC是徒勞。

用法

-XX:+UnlockExperimentalVMOptions
-XX:+UseEpsilonGC

測試默認GC

咱們寫一段代碼，不斷的產生垃圾：

public class EpsilonTest {
    public static void main(String[] args) {
        boolean flag = true;
        List<Garbage> garbageList = new ArrayList<>();
        int count = 0;
        while (flag) {
            garbageList.add(new Garbage());
            if (count ++ == 500) {
                garbageList.clear();
            }
        }
    }
}

class Garbage {
    private double d1 = 1;
    private double d2 = 2;

    /**
     * 在GC清除對象時會調用一次
     */
    @Override
    protected void finalize() throws Throwable {
        System.out.println(this + " collecting");
    }
}

直接運行，使用的默認的垃圾回收器：

java11.Garbage@37c7d031 collecting
java11.Garbage@71a19bf9 collecting
java11.Garbage@3b2df791 collecting
java11.Garbage@61441b29 collecting
java11.Garbage@680b1968 collecting
java11.Garbage@158829c3 collecting
java11.Garbage@414dc59c collecting
java11.Garbage@1103cf collecting
......

從運行打印的結果能夠看出：有對象被回收了，觸發了GC【默認用的是G1】
由於我只限定回收了500個，500個以後的對象會不斷加到內存中，內存就會不夠用：

Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
    at java11.EpsilonTest.main(EpsilonTest.java:16)

測試Epsilon GC

若是我使用的是Epsilon GC，會是什麼樣的結果呢？

使用方法

啓動時添加VM參數：

運行結果

運行代碼，發現控制檯沒有任何的輸出，即EpsilonGC不會作任何的回收，而且程序很快就由於堆空間不足而退出。

Terminating due to java.lang.OutOfMemoryError: Java heap space

使用這個選項的緣由

提供徹底被動的GC實現, 具備有限的分配限制和儘量低的延遲開銷,但代價是內存佔用和內存吞吐量.
衆所周知, java實現可普遍選擇高度可配置的GC實現. 各類可用的收集器最終知足不一樣的需求, 即便它們的可配置性使它們的功能相交. 有時更容易維護單獨的實現, 而不是在現有GC實現上堆積另外一個配置選項.

主要用途

• 性能測試(它能夠幫助過濾掉GC引發的性能假象)
• 內存壓力測試(例如,知道測試用例 應該分配不超過1GB的內存, 咱們可使用-Xmx1g –XX:+UseEpsilonGC, 若是程序有問題, 則程序會崩潰)
• 很是短的JOB任務(對象這種任務, 接受GC清理堆那都是浪費空間)
• VM接口測試
• Last-drop 延遲&吞吐改進

ZGC

ZGC, A Scalable Low-Latency Garbage Collector(Experimental)
ZGC是一款可伸縮、低延遲的GC

概述

ZGC，應該是JDK11最爲矚目的特性。可是後面帶了Experimental，說明這還不建議用到生產環境。

• GC暫停時間不會超過10ms
• 既能處理幾百兆的小堆, 也能處理幾個T的大堆(OMG)
• 和G1相比, 應用吞吐能力不會降低超過15%
• 爲將來的GC功能和利用colord指針以及Load barriers優化奠基基礎
• 初始只支持64位系統

ZGC的設計目標是：支持TB級內存容量，暫停時間低（<10ms），對整個程序吞吐量的影響小於15%。 未來還能夠擴展實現機制，以支持很多使人興奮的功能，例如多層堆（即熱對象置於DRAM和冷對象置於NVMe閃存），或壓縮堆。

在使用G1的時候，在回收垃圾的時候，必需要保證應用程序當中全部的線程停下來，不在內存中製造混亂，而後GC纔會開始工做，會形成停頓。這一個過程，有一個專屬名詞來解釋：STW（stop the world）。
ZGC的目標就是縮短STW的時間：ZGC是一個併發，基於region， 壓縮型的垃圾收集器，只有root掃描階段會STW， 所以GC停頓時間不會隨着堆的增加和存活對象的增加而變長。

用法

-XX:+UnlockExperimentalVMOptions
-XX:+UseZGC

ps：ZGC暫時不能在windows系統中使用，不知道最新的版本有沒有支持，我手邊沒有windows機器，未作測試。