「译文」Java 垃圾收集参考手册（八）：GC 算法总结

总结

通过本节内容的学习，你应该对 G1 垃圾收集器有了一定了解。当然，为了简洁，我们省略了很多实现细节， 例如如何处理巨无霸对象 (humongous objects)。 综合来看，G1 是 HotSpot 中最先进的 ** 准产品级 (production-ready)** 垃圾收集器。重要的是，HotSpot 工程师的主要精力都放在不断改进 G1 上面，在新的 java 版本中，将会带来新的功能和优化。

可以看到，G1 解决了 CMS 中的各种疑难问题，包括暂停时间的可预测性，并终结了堆内存的碎片化。对单业务延迟非常敏感的系统来说，如果 CPU 资源不受限制，那么 G1 可以说是 HotSpot 中最好的选择，特别是在最新版本的 Java 虚拟机中。当然，这种降低延迟的优化也不是没有代价的：由于额外的写屏障 (write barriers) 和更积极的守护线程，G1 的开销会更大。所以，如果系统属于吞吐量优先型的，又或者 CPU 持续占用 100%, 而又不在乎单次 GC 的暂停时间，那么 CMS 是更好的选择。

总之: G1 适合大内存，需要低延迟的场景。

选择正确的 GC 算法，唯一可行的方式就是去尝试，并找出不对劲的地方，在下一章我们将给出一般指导原则。

注意，G1 可能会成为 Java 9 的默认 GC: http://openjdk.java.net/jeps/248

Shenandoah 的性能

译注: Shenandoah: 谢南多厄河；情人渡，水手谣；–> 此款 GC 暂时没有标准的中文译名；翻译为大水手垃圾收集器？

我们列出了 HotSpot 中可用的所有 “准生产级” 算法。还有一种还在实验室中的算法，称为超低延迟垃圾收集器 (Ultra-Low-Pause-Time Garbage Collector). 它的设计目标是管理大型的多核服务器上，超大型的堆内存：管理 100GB 及以上的堆容量，GC 暂停时间小于 10ms。 当然，也是需要和吞吐量进行权衡的：没有 GC 暂停的时候，算法的实现对吞吐量的性能损失不能超过 10%

在新算法作为准产品级进行发布之前，我们不准备去讨论具体的实现细节，但它也构建在前面所提到的很多算法的基础上，例如并发标记和增量收集。但其中有很多东西是不同的。它不再将堆内存划分成多个代，而是只采用单个空间。没错，Shenandoah 并不是一款分代垃圾收集器。这也就不再需要 card tables 和 remembered sets. 它还使用转发指针 (forwarding pointers), 以及 Brooks 风格的读屏障 (Brooks style read barrier), 以允许对存活对象的并发复制，从而减少 GC 暂停的次数和时间。

关于 Shenandoah 的更多信息，请参考博客: https://rkennke.wordpress.com/, JEP 文档: http://openjdk.java.net/jeps/189, 或者 Google 搜索 「Shenandoah GC」。

原文链接: GC Algorithms: Implementations

翻译人员: 铁锚 http://blog.csdn.net/renfufei

翻译时间: 2016 年 02 月 06 日

系列文章

「译文」Java 垃圾收集参考手册