为了达到所需的吞吐量，越来越多的采用 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
注册/登录 InfoQ 发表评论