Sun的Garbage First垃圾收集器：消除低时延与高吞吐量之间的取舍

Sun公司的Garbage First 垃圾收集器（下文将使用它的简称G1）是一款低时延的垃圾收集器，计划用来取代 Hotspot JVM 中的CMS。它是一种服务器风格的垃圾收集器，主要针对多处理器大内存的机器。CMS与G1有两大区别。第一，G1是一款压缩型的收集器。压缩，也就是把活动的对象从原先的存储地址移到堆的一端，那么堆的另外一端就会有整块的空闲内存，这对于长时间运行的应用系统来说非常重要，因为时间一长，这些系统不可避免都会产生内存碎片。G1通过有效的压缩完全避免了对细微空闲内存空间的分配，这不仅大大简化了收集器，而且还消除了潜在的碎片问题。除压缩以外，G1的垃圾收集停顿也比CMS容易估计，它允许用户自定义所希望的停顿参数。这种确定性也让G1具有某种实时级别的垃圾收集特征，但这还不是“硬实时”，因为底层操作系统的某些调度因素无法保证上述的停顿机制。尽管如此，与Java实时产品相比，G1对开发人员来说相对更容易使用，因为已有的程序不需要修改代码就能利用G1改善自身性能。G1采用了很多有意思的技术，它根据全局的标志信息和其度量，按各个区域的GC效率给区域排列垃圾收集的优先级。InfoQ之前有一篇文章探讨了更多的技术细节。

在最近的播客上，James Gosling强调了G1对于某些特定类型的大规模Java应用（比如财务交易）的重要性，这类应用通常具有大量活动的堆数据和相当数目的线程级别的并行计算，而且往往都运行在高端多核处理器上。

“……这类Java应用都有一个不为人知的秘密，就是它们其实并不‘真正’使用数据库。它们使用大量的RAM而不是数据库，而且极其依赖垃圾收集器，因为访问硬盘对它们而言无法接受。当每秒需要处理成千上万个事务的时候，你只能把所有东西都放在RAM，使用散列表，并利用尽可能多的核来处理事务，而且事务的延时通常是很严重的问题。”

Gosling 接着谈到了吞吐量和确定性之间的取舍。垃圾收集器通常两者只能顾其一。在吞吐量方面优化的垃圾收集器非常适合处理运行时间长的批处理任务，垃圾收集器此时更关心的是如何尽可能快地完成整个批处理任务，而不是考虑停顿问题。相反地，如果是像网络应用这样的交互式系统，低时延的垃圾收集器则通常是最好的选择。Gosling 指出JVM的其它部分也存在这样的取舍，但整体来说JVM优化的方向是吞吐量。事实上：

“所有的再调整算法都会有这样的取舍。比如说散列表，大部分人都认为散列表的插入和删除操作所花的时间是固定的，但事实上不是。只有当插入操作不会引起对哈希值的重新计算时，这个时间才是固定的，否则单次插入会花费更长的时间。”

用户可以显式指定在Y毫秒的时间段里面垃圾收集的开销时间不能超过X毫秒，这样，G1会尝试为应用系统的垃圾收集保持必要的短停顿和低频率，但不会低到引起不必要的吞吐量下降和内存使用率上升。吞吐量/低时延之间的取舍，会给垃圾收集器带来非常明显的影响，G1应该给Java企业开发人员提供显著的益处。G1包含在Java 6 update 14的发布中，Sun公司的 Hotspot 团队也非常期望能收到早期试用者的反馈和bug报告。

查看英文原文：Sun's Garbage First Collector Largely Eliminates Low Latency/High Throughput Tradeoff