Terracotta的BigMemory力图消除针对Java缓存的垃圾回收

Terracotta在解决Java应用的垃圾回收引起的暂停问题方面做出了最新的尝试。GC暂停问题在严重依赖缓存的应用中表现的比较突出。许多垃圾回收器将新、旧对象分代隔离，并发处理较年轻的对象，但是在处理老对象时却不得不采取全局暂停操作（stop-the-world）。通过将长期存在的对象放入内存，缓存在处理这些对象时会激化全局暂停的问题。Terracotta的解决方案名为BigMemory™ for Enterprise Ehcache，特意采用了独有的内存管理系统。

“如今，开发人员使用消耗时间的技术来处理大数据集合——例如，使用大量的VM（分配小堆）”，Terracotta的CTO Ari Zilka说：

BigMemory for Enterprise Ehcache使GC调优的神秘色彩一去不复返。企业可以充分利用现代服务器的能力实现因内存数据带来的性能提高，同时把数据中心的服务器合并。

BigMemory被视为Azul的Zing的竞争者，Zing为基于Intel和AMD的服务器提供无暂停的垃圾回收。但是，这两种产品采取了不同的方法。Azul的解决方案使用软件技术提供了一种垃圾回收算法，能够与应用并发运行，因此，需要Azul的Java虚拟机。BigMemory则是通过管理在堆外存放在缓存中的数据来减少垃圾回收的压力，类似于采用C语言编写的应用。因此，目前没有使用缓存代码的应用需要改变代码，但是对于已经使用缓存（如Hibernate Cache）的应用来说，JVM不需要变化。

InfoQ采访了Terracotta的首席执行官Amit Pandey。Pandey表示，虽然Terracotta的Ehcache支持单节点和多节点，但是Terracotta的用户中80-85%都在使用单节点缓存。这些用户可能还没有准备好采用完全分布式的架构，但是他们在扩展性和性能方面存在一些问题。对于这些客户，BigMemory提供了一种办法：

“当他们尝试扩展已经放入内存或者堆里的数据集大小时，就会遇到垃圾回收问题和性能问题。因此，他们只能发挥很小的潜力。”

Pandey告诉我们，最初Terracotta是解决自己的Java服务器的垃圾回收问题，今年早些时候才决定开发自己的内存管理器，采用Java编写。做完之后，他们决定将其集成到Ehcache产品中并投放市场。Pandey表示，大部分客户在堆达到4GB左右的时候就会面临困境。

在Java世界，我们的产品提供了将大量数据放入Encache的能力。我们已经测试了超过100GB数据，性能表现平稳，包括响应时间、SLA、最大垃圾回收暂停时间，这是因为我们基本上不做GC暂停。因此，如果你的应用在1GB的堆里GC时间为1秒，那么引入Ehcache，将数据脱离堆，仍然在内存中，你可以达到100GB而且GC时间几乎保持不变。

下图（感谢Terracotta提供）是针对真实应用抽象和模块化得出的数据。

我们还谈到了内存管理器的工作原理，Pandey说：

...... 我们没有做垃圾回收。我们的内存管理方式和其他语言非常类似。现在，我们把数据都存放在线性数据结构中。因此，不会存在分代问题等等，我们的应用负责处理这些问题。你在堆上有些数据并按照正常的方式处理，但是你也可以把堆设的很小，然后把所有其他数据都放到我们的数据结构中，我们来处理。我们引入了一些非常精妙的算法，能够处理碎片等，因为我们是在离线模式下操作，所以不会降低应用运行速度。

虽然BigMemory的目标市场是那些不想构建完全分布式架构的人，但是该产品在分布式缓存中同样有效。

该产品目前处在beta阶段，预计十月份发布GA版。具体价格将在这之前公布。

查看英文原文：Terracotta's BigMemory Aiming to Eliminate Garbage Collection for Java Caches