在堆增大的同时确保垃圾回收停顿时间短暂——专访Cliff Click博士

为了达到所需的吞吐量，越来越多的采用Java编写的企业级应用把大部分处理过程从数据库转移到内存中。这类应用的特点是存在大量活跃堆数据和线程级别的并发，并且往往运行在高端多核处理器上。这种特点意味着堆大小和垃圾回收停顿时间之间的强相关性成为Java应用伸缩性的主要限制之一，专家进行了大量的研究以努力改进这种情况。

例如预计今年推出的Java 7中，即将包含一个新的垃圾回收器— Garbage-First—目的是确保持续的短停顿时间，尽量消除低延迟/高吞吐量之间的折衷。与这种纯软件方法相反 Azul Systems硬件基于自定制的54核处理器构建，专为运行高标准Java应用程序设计，支持内置于处理器的写操作和读操作屏障。InfoQ最近采访了HotSpot Server编译器的前架构师和首席程序员、现任Azul Systems公司首席JVM架构师的Cliff Click博士，讨论了Azul的解决方案。第一个问题是Azul硬件适用的领域：

任何需要可靠的低停顿时间（业务关键应用）或者超大堆的领域。类似金融建模的超大堆应用可能需要300G大小的堆存储金融数据，然后通过数百个处理器并行操作。我们针对Java DB缓存也做得很好，在缓存中提供10到100G的数据。

低停顿时间应用通常意味着你希望及时地将网页回馈给客户。几秒钟的延迟通常会让客户认为“网站关闭了”并转向他处或者提出投诉。一些大牌公司在Azul设备上部署Web展现应用，因为我们能够提供高负载下的出色（平稳）响应时间。一些典型的用途如客户的门户网站、大缓存（针对性能和扩展性）和内部业务应用的Web版（如库存管理、“请假系统”等等）。

InfoQ: 按照我的理解，Azul硬件的关键优势之一是它直接支持写操作和读操作屏障以获得低GC停顿。是这样吗？

是啊！特别是，拥有读操作屏障允许你切换到较简单的GC算法—更易于并发、扩展和强壮。我们在多年前已经改变了算法，我们的垃圾回收机制能够处理超越竞争对手数量级大小的堆（和分配频率）。

InfoQ: 显然采用软件也能够做到。哪些情况下值得使用硬件？

学术文献已经对该领域做了很多探讨，已知的问题是单线程性能下降大约10%到20%。IBM的Metronome硬实时垃圾回收器采用Brooks风格的读操作屏障，并极力把延迟时间降低到正常回收器的30%...但是，一些消耗在于硬实时和不仅仅是读操作屏障。IBM的确卖出了Metronome回收器（我相信大部分是军事领域）。

InfoQ: Azul的GC停顿与Oracle的Garbage-First垃圾回收器或者使用Java实时产品相比如何？

我觉得G1将很有意思...如果有的话。我们的垃圾回收器到目前为止已经在生产环境中稳定运行了4年。我认为现在与G1比较为时过早。

实时Java产品往往存在一些问题导致它们不适合大型企业应用——通常是GC局限于4G堆大小或者单垃圾回收器（有时是单mutator线程）。RTSJ规范要求程序重写以使用有限的内存。

InfoQ:对于GC来说，并发存在哪些局限？是否存在某部分GC算法在非并发情况下效率也很高？

人们总是把堆搞得难以并发收集，但实际上大多数大型堆有足够的并发性。其他GC问题也可以逐个解决，我们多年来一直在进行这项工作，并有了极具扩展性和并发性的GC。我们能够（有时候）有效地并发运行超过100个GC线程。

InfoQ:是否计划开源Azul虚拟机（或者重新为OpenJDK项目工作）？

我们一直在考虑开源部分成果，因为这很有意义。例如，我们的CheckedCollections和LockedCollections捕捉（或者纠正）常见的编程错误，如标准的非锁定Collections类被多个线程使用同时一个线程正在写入。

Azul虚拟机的更多信息可以查看这里或者Click博士的博客。

查看英文原文：Keeping Garbage Collection Pauses Short with Growing Heap Sizes: Q&A With Dr. Cliff Click