Java 11 : Epsilon 简介（上）

Epsilon ：

Release 11 ，HotSpot虚拟机提供的GC. 

特点：

一个处理内存分配但不实现任何实际内存回收机制的GC，一旦可用的Java堆耗尽，JVM将关闭。

目标：

““Provide a completely passive GC implementation with a bounded allocation limit and the lowest latency overhead possible, at the expense of memory footprint and memory throughput. A successful implementation is an isolated code change, does not touch other GCs, and makes minimal changes in the rest of JVM.” ------《JEP 318: Epsilon: A No-Op Garbage Collector (Experimental)》

被动的GC,即不进行对象的回收，进行内存分配以及尽可能低的延迟,以内存占用和内存吞吐量为代价。 不影响其他GC，不会触及其他GC，并且在JVM的其余部分中进行最小的更改。

为什么使用NO-OP GC？

无操作垃圾收集器对于测量和管理应用程序性能很有用。 活动垃圾收集器是在应用程序旁边的JVM内部运行的复杂程序。 它们会产生开销，从而导致延迟并降低吞吐量。 Epsilon消除了GC对性能的影响。 没有GC循环或读或写障碍。 使用Epsilon GC时，您的代码将独立运行。 您可以使用它来查看垃圾收集如何影响应用程序的性能以及内存阈值是什么，因为它会告诉您何时用完。 如果您认为只需要4 GB的内存，请使用-Xmx4g运行它，看看你是否正确。 如果你错了，请用XX重新运行它：启用HeapDumpOnOutOfMemoryError并查看堆转储以查看你错在哪里

如果您需要从应用程序中挤出所有性能，Epsilon可能是GC的最佳选择。 但是您需要完全了解代码如何使用内存。 如果它几乎没有产生垃圾，或者你确切知道它运行的时间段内使用了多少内存，那么Epsilon是一个可行的选择。

具体描述

Epsilon GC通过在单个连续的已分配内存块中实现线性分配来工作。这允许GC中的普通无锁TLAB（线程局部分配缓冲区）发布代码，然后可以重用现有VM代码处理的无锁内TLAB分配。发布TLAB还有助于保持由实际分配的进程限制的进程占用驻留内存。

Epsilon使用的屏障集(barrier set )是完全空的/无操作，因为GC不执行任何GC循环，因此不关心对象图，对象标记，对象复制等。由于Epsilon运行时接口的唯一重要部分是发布TLAB，因此其延迟在很大程度上取决于发布的TLAB大小。对于任意大的TLAB和任意大的堆，延迟开销可以通过任意低的正值来描述.

一旦Java堆耗尽，就无法进行分配，也无法进行内存回收，因此我们必须失败。这时有几种选择

1.使用描述性消息抛出OutOfMemoryError。

2.执行堆转储（像往常一样启用-XX：+ HeapDumpOnOutOfMemoryError）

3.执行外部操作（通过通常的-XX：OnOutOfMemoryError = ...），例如，启动调试器或通知外部监视系统有关失败的信息。

参考：https://dzone.com/java-jdk-development-tutorials-tools-news。

参考：https://openjdk.java.net/jeps/318。