JDK11 | 第六篇 : Epsilon 垃圾收集器

文章首发于公众号《程序员果果》

地址 : https://mp.weixin.qq.com/s/RhGXJImhp7Xm-wDrpPomkQ

1、简介

Epsilon（A No-Op Garbage Collector）垃圾回收器控制内存分配，可是不执行任何垃圾回收工做。一旦java的堆被耗尽，jvm就直接关闭。设计的目的是提供一个彻底消极的GC实现，分配有限的内存分配，最大限度下降消费内存占用量和内存吞吐时的延迟时间。一个好的实现是隔离代码变化，不影响其余GC，最小限度的改变其余的JVM代码。

2、使用场景

• Performance testing,什么都不执行的GC很是适合用于差别性分析。no-op GC能够用于过滤掉GC诱发的新能损耗，好比GC线程的调度，GC屏障的消耗，GC周期的不合适触发，内存位置变化等。此外有些延迟者不是因为GC引发的，好比scheduling hiccups, compiler transition hiccups，因此去除GC引起的延迟有助于统计这些延迟。
• Memory pressure testing, 在测试java代码时，肯定分配内存的阈值有助于设置内存压力常量值。这时no-op就颇有用，它能够简单地接受一个分配的内存分配上限，当内存超限时就失败。例如：测试须要分配小于1G的内存，就使用-Xmx1g参数来配置no-op GC，而后当内存耗尽的时候就直接crash。
• VM interface testing, 以VM开发视角，有一个简单的GC实现，有助于理解VM-GC的最小接口实现。它也用于证实VM-GC接口的健全性。
• Extremely short lived jobs, 一个短声明周期的工做可能会依赖快速退出来释放资源，这个时候接收GC周期来清理heap实际上是在浪费时间，由于heap会在退出时清理。而且GC周期可能会占用一会时间，由于它依赖heap上的数据量。
• Last-drop latency improvements, 对那些极端延迟敏感的应用，开发者十分清楚内存占用，或者是几乎没有垃圾回收的应用，此时耗时较长的GC周期将会是一件坏事。
• Last-drop throughput improvements, 即使对那些无需内存分配的工做，选择一个GC意味着选择了一系列的GC屏障，全部的OpenJDK GC都是分代的，因此他们至少会有一个写屏障。避免这些屏障能够带来一点点的吞吐量提高。

3、案例

使用G1垃圾收集器

代码：

public class TestEpsilon {

    public static void main(String[] args) {
        System.out.println("程序开始");
        boolean flag = true;
        List<Garbage> list = new ArrayList<>();
        long count = 0;
        while (flag) {
            list.add(new Garbage(list.size() + 1));
            if (list.size() == 1000000 && count == 0) {
                list.clear();
                count++;
            }
        }
        System.out.println("程序结束");
    }
}

class Garbage {

    private int number;

    public Garbage(int number) {
        this.number = number;
    }

    /**
     * GC在清除对象时，会调用finalize()方法
     */
    @Override
    public void finalize() {
        System.out.println(this + " : " + number + " is dying");
    }

    public int getNumber() {
        return number;
    }

    public void setNumber(int number) {
        this.number = number;
    }

}

启动参数：

-Xms100m -Xmx100m

运行程序后，结果以下：

程序开始
...
com.gf.demo8.Garbage@15ddf76b : 305097 is dying
com.gf.demo8.Garbage@35e52705 : 305224 is dying
com.gf.demo8.Garbage@32c14bc1 : 305362 is dying
com.gf.demo8.Garbage@7521660a : 305705 is dying
com.gf.demo8.Garbage@f3da16a : 305948 is dying
com.gf.demo8.Garbage@13fc7287 : 306089 is dying
    at java.base/java.lang.ref.Finalizer.register(Finalizer.java:66)
    at java.base/java.lang.Object.<init>(Object.java:50)
    at com.gf.demo8.Garbage.<init>(TestEpsilon.java:28)
    at com.gf.demo8.TestEpsilon.main(TestEpsilon.java:14)
...

会发现G1一直回收对象，直到内存不够用。

使用Epsilon垃圾收集器

启动参数：

UnlockExperimentalVMOptions：解锁隐藏的虚拟机参数。

-XX:+UnlockExperimentalVMOptions -XX:+UseEpsilonGC -Xms100m -Xmx100m

运行程序后，结果以下：

程序开始
Terminating due to java.lang.OutOfMemoryError: Java heap space

会发现很快就内存溢出了，由于Epsilon不会去回收对象。

关注我

欢迎扫码或微信搜索公众号《程序员果果》关注我，更多精彩内容不能错过 ~~

（转载本站文章请注明做者和出处 程序员果果的博客）