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
评论