原文链接：https://www.infoq.com/news/2017/03/java-epsilon-gc
InfoQ中文翻译：http://www.infoq.com/cn/news/2017/03/java-epsilon-gc?utm_source=infoq_en&utm_medium=link_on_en_item&utm_campaign=item_in_other_langs
在RedHat负责OpenJDK开发和性能优化的Aleksey Shipilëv不久前发表了一份新的JEP草案，草案中计划将推出新一代不会真正回收内存的垃圾回收器（GC）。此次的回收器计划主要目的包括两个方面，给JVM的实现者和研究者在GC方面更多的帮助，以及大幅减少应用运行时产生的“内存垃圾”。虽然后者只是计划中的一小部分，但是显然他更受公众的关注。如果JEP继续照计划发展，新的GC将和现有的共存，并且只有在指定使用新版GC后才会生效。
垃圾回收器和Java性能是一个复杂且庞大的话题，因此InfoQ特地请来了两位Java Champions中的性能专家Martijn Verburg 和 Kirk Pepperdine，来为我们作出更加客观准确的分析讲解。同时我们也会采访Remko Popma——实现Log4j 的garbage-free功能的领导者，向他了解相关功能的实现细节。Verburg 和 Popma都认为无操作GC（或者称之为Epsilon GC）的主要受益者是GC开发者和性能研究人员。Epsilon
GC可以作为一个可控的选项，来测量比较和其他垃圾回收器的性能差别。举个简单的例子，我们可以让应用程序运行在无操作GC上来较少GC的性能开销（在排除其他内存申请和突发情况的前提下）。如果同样的应用程序在除了GC算法以外都相同的工作环境上运行，性能上的差异就能直接反映出GC算法对这个应用的影响。这将让GC开发者和性能研究人员通过更纯粹的方式理解GC的行为。
“我认为这是对精确测量JVM个部分性能跨出的一大步（比如已有的JIT C1/C2 编译器，可能会被转移到Graal 等）。这将让JVM存活得更久。”Martijn Verburg说。
在另一方面，Epslion GC可以让性能要求严格的应用从中收益。存在某些类似前文提到的Log4j这样的应用或者库，它们通过一些方式使得运行中不会产生需要回收的内存，因此也不需要垃圾回收器。对于这种应用程序，去掉垃圾回收机制可以提升他们的性能。然而正如Popma强调的，如果要构建一个可以使用Epsilon GC的库，那将会“花费大量的工程力量来确保应用程序的内存使用得当不会溢出”。即便如此，也必须完成一场风险评估来确定，选择无操作GC的收益是否和实现无内存垃圾的难度向匹配。
然而我们很难预估怎样的应用程序可以被改写成不会生产内存垃圾的状态。虽然这个话题复杂到难以在这样一篇文章的篇幅内讲解清楚，但是下面列出的几个想法会帮助你更好的思考这个问题：
- JVM中通过两种机制来管理内存：堆和栈，这也是为什么会有两种不同的内存泄漏错误（OutOfMemoryError和StackOverflowError）。在栈上的内存只对当前线程可见，并且只存在于当前执行的方法之中。因此，当前的线程结束当前的方法时，内存会自动释放并不需要调用GC。而在堆中的可以被整个应用访问，这意味着需要有一个独立的内存垃圾回收器来判断是否有内存已经没有被引用并且将它回收。
- 基本类型的内存都会分配在栈上，因此并不会造成GC方面的压力。如果在写程序时大部分使用的都是基本类型，那么将只有少数对象需要垃圾回收器来对它们进行管理。
- 不产生内存垃圾和不产生对象是两个概念；对象可以继续被创建，但是并不需要垃圾回收器来对他们进行监控管理：
- 应用程序或者库可以在一开始就创建一些对象，并且一直重用他们。这种方式需要开发者对应用程序使用内存的每一步都了如指掌。
- 有时编译器会识别出那些只在方法内部调用的对象（参见 escape analysis）。当确定某个对象不会出现在方法外部被引用时，它将会通过栈而不是堆的方式来给它分配内存，因此会自动在当前方法运行结束后销毁。
尽管这些方法都可行，Pepperdine 却指出它们共有的问题：上述方法会让代码写起来非常不自然，且失去Java提供种种便利。同时，Verburg也认为Java的内存管理机制就是它在业界如此受欢迎的主要原因。另外有一点我们必须知道，垃圾回收器虽然名字如此，但它不只负责回收内存垃圾，内存申请也是它的任务之一，对于Epsilon GC也不例外。据此，Pepperdine认为在没有任何GC操作发生的情况下，Epsilon GC和普通的垃圾回收算法并没有性能上的区别，至少理论上如此。
尽管考虑到各种注意事项，Pepperdine和Verburg仍然确定Epsilon GC会对一小部分人非常游泳，虽然Kirk表示这一小部分读者甚至对无操作GC的实际用途保持怀疑。绝大部分的应用程序需要在某些时刻回收内存，因此需要存在一个有实际功能的垃圾回收器。
"合理的GC暂停时间对大部分应用程序来说并不是什么问题，所以我们为什么要放弃Java提供的种种便利来换取一个不确定的性能优势呢？“Kirk Pepperdine说到。
Pepperdine同样也提醒我们，所有新增的功能都将加大OpenJDK的维护开销，因此OpenJDK的开发者需要在添加新功能时有对应的大局观。Oracle 已经通过减少现存的垃圾回收器来减小维护成本，因此添加新的GC只会让少部分用户收益，并不一定是一种合理的资源投入。Shipilëv 似乎在起草JEP草案时就已经考虑到这一点，并初步分析认为在这次新GC加入带来的开销将会尽可能的低。草案中相关数据已经给出。事实上Pepperdine和Verburg都认为，考虑到Shipilëv's丰富的经验，应该对这次由他领导的倡议保持乐观。
另一方面，Pepperdine强调说虽然OpenJDK是JVM的参考实现，但它并没有对垃圾回收器提出相应的标准。这意味着服务提供商完全可以自行实现和标准Java兼容的GC算法。这会导致分化出两个不同意见的阵营：一方认为实现在市场上稳定运行的算法应该集成在商用版本的JVM中，另一方则会认为这是OpenJDK上一个不错的更新。
Remko还建议当性能变得至关重要时，应该考虑使用商业版JVM，因为在购买许可证上的开销会比自行研发并GC算法花费的工程力量要小很多。Popma 和 Verburg还提到了另外一个正在开发中的 Shenandoah GC，这项技术将专注于在超短时间来回收超大内存的特性。另外，专家们都认为如果需要对应用程序的性能有所要求，仔细挑选一个合适的GC算法很可能会比不使用GC要好很多。
这个提案仍然十分“年轻”，在成为正式的JEP之前还需要继续被审查和完善。如果一切顺利，Epsilon GC最终将会加入某个Java版本。虽然目前我们只能推测最终会添加到什么版本JVM中，Martijn认为有理由期待Epsilon GC将会加入到Java 10或者11。如果要说有什么好处的话，Epsilon GC至少能够帮助理解GC的接口，有助于成就一个更加模块化的JVM。
