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机器，未作测试。