Java开发网 - G1垃圾收集器：消除低时延与高吞吐量之间的取舍

Topic: G1垃圾收集器：消除低时延与高吞吐量之间的取舍

1.G1垃圾收集器：消除低时延与高吞吐量之间的取舍

Posted by: 阿熊
Posted on: 2009-06-04 11:18

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

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

“……这类Java应用都有一个不为人知的秘密，就是它们其实并不‘真正’使用数据库。它们使用大量的RAM而不是数据库，而且极其依赖垃圾收集器，因为访问硬盘对它们而言无法接受。当每秒需要处理成千上万个事务的时候，你只能把所有东西都放在RAM，使用散列表，并利用尽可能多的核来处理事务，而且事务的延时通常是很严重的问题。”
Gosling 接着谈到了吞吐量和确定性之间的取舍。垃圾收集器通常两者只能顾其一。在吞吐量方面优化的垃圾收集器非常适合处理运行时间长的批处理任务，垃圾收集器此时更关心的是如何尽可能快地完成整个批处理任务，而不是考虑停顿问题。相反地，如果是像网络应用这样的交互式系统，低时延的垃圾收集器则通常是最好的选择。Gosling 指出JVM的其它部分也存在这样的取舍，但整体来说JVM优化的方向是吞吐量。事实上：

“所有的再调整算法都会有这样的取舍。比如说散列表，大部分人都认为散列表的插入和删除操作所花的时间是固定的，但事实上不是。只有当插入操作不会引起对哈希值的重新计算时，这个时间才是固定的，否则单次插入会花费更长的时间。”
用户可以显式指定在Y毫秒的时间段里面垃圾收集的开销时间不能超过X毫秒，这样，G1会尝试为应用系统的垃圾收集保持必要的短停顿和低频率，但不会低到引起不必要的吞吐量下降和内存使用率上升。吞吐量/低时延之间的取舍，会给垃圾收集器带来非常明显的影响，G1应该给Java企业开发人员提供显著的益处。G1包含在Java 6 update 14的发布中，Sun公司的 Hotspot 团队也非常期望能收到早期试用者的反馈和bug报告。

来源：http://www.infoq.com/cn/news/2009/04/g1

2.G1技术细节 [Re: 阿熊]

Copy to clipboard

Posted by: 阿熊
Posted on: 2009-06-04 11:25

Sun的HotSpot垃圾收集器可分为两类：新生区（young generation）与老年区（tenured generation）。大部分的内存分配在新生区中进行，相对于垃圾收集的间隔时间来说，它经过了优化并且生命周期很短。经过几次垃圾收集后仍然存活于新生区中的对象将被迁移到老年区中，这部分区域通常更大并且垃圾收集不那么频繁。新生区收集器分为连续式（Serial）、同新式（ParNew）及并行扫描式（Parallel Scavenge）三种。所有这三种都是拷贝收集器。连续式使用了一个单独的GC线程，而同新式与并行扫描式都使用了多线程。老年区收集器都使用了标记扫描压缩（mark-sweep-compact）算法。同样老年区收集器也分为三种：Serial Old（另一个单独的GC线程）、Parallel Old（使用多个GC线程）及CMS（一个多并发低暂停的收集器）。Garbage First的目标在于替换掉CMS并且采取了某些不同的方式——跨越了新生区和老年区的边界。

G1的工作方式

“堆被切分成固定大小的区域，同时两个区域之间的分隔基本上是合理的。因此我们可以认为一些区域是新的，另一些是老的。在G1中所有的空间回收都是通过拷贝完成的。G1选择一组区域，从那些区域中摘出存活的对象，然后将其拷贝到另一组区域中。这就是G1中空间回收的方式，而不是CMS中所采取的那种方式（拷贝与适当的重分配的组合方式）。”

新的收集器的三个主要目标：

“首要目标是随始终一致的低停顿率。本质上，由于G1在处理同时做压缩，它将对象从堆的一个地方拷贝到另一个地方。这样，由于压缩的原因，它不会遇到CMS可能会遇到的碎片问题。总会有连续空闲的空间供分配，这就使得G1拥有始终一致的停顿率。
第二个目标是尽量避免完全的GC。在G1对全局进行标记并决定堆上对象的活跃度后，它立刻就知道堆上的哪些区域几乎是空闲的。它将首先处理那些区域，腾出大量空间。通过这种方式，垃圾收集器将获得更多空间并减少完全GC的可能性。这也是为什么该垃圾收集器叫做Garbage-First的原因。
最后一个目标是良好的吞吐量。对于我们很多客户来说，吞吐量意味着一切。我们期望G1拥有良好的吞吐量以满足我们客户的需求。”

附件PDF文档更加详尽地论述了Garbage-First并深入分析了如何实现这些目标，尤其是实时目标。大多数实时收集器工作在单个对象层次上，而 Garbage First则在区域层次上进行收集。如果任何区域不再包含存活的对象时，它就会被立刻回收。用户可以为停顿率指定一个目标，G1会基于之前的收集对此时可回收的区域数量作出估计。该收集器对区域回收的代价有一个合理且精确的模型，所以“该收集器可以在给定的停顿时间内（高概率）选择一组可被回收的区域。” 换句话说，Garbage-First并不是一个纯粹的实时收集器——它以高概率但不绝对地满足软实时目标。作为交换，Garbage-First应该具备更高的吞吐量以作为软实时的补偿，但是其仍会适度遵循实时的限制。这对于经常产生大量存活堆数据和线程级别数据的大规模服务器端应用来说是非常棒的。 Garbage-First还提供了一些出色的控制，使得用户可以在垃圾收集的执行周期中指定一小部分时间——例如，在下一个120秒中最多花20秒的时间在垃圾收集上。

04-g1-paper-ismm.pdf (162.3k)

3.Re:G1垃圾收集器：消除低时延与高吞吐量之间的取舍 [Re: 阿熊]	Copy to clipboard
Posted by: abefirst Posted on: 2009-06-28 11:23 这么多看的头大，lz可以简单点介绍啊，谢谢

4.Re:G1垃圾收集器：消除低时延与高吞吐量之间的取舍 [Re: 阿熊]	Copy to clipboard
Posted by: mw3943 Posted on: 2009-07-04 13:07 楼主在弄的精简点啊