为了达到所需的吞吐量，越来越多的采用 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
评论