JSR-107（JCache）正在制定当中，将成为 Java EE 7 的一部分

分布式缓存在提升性能和可伸缩性时举足轻重，但 Java 目前还没有任何完整、标准的缓存机制。JSR-107（JCache API）正在紧锣密鼓的制定当中，以后会成为 Java EE 7 的一部分。 JSR-107 这些年有些声名狼藉，因为它是一个很老的规范，但到现在还没有完成，不过随着对缓存的需求越来越多，JSR-107 最终是要问世的。

Greg Luck 是 JSR-107 规范的共同牵头人，长期参与领先的开源 Java 缓存实现 Ehcache 的开发和维护。InfoQ有幸对 Greg 进行了采访。

InfoQ：JCache 真的会成为 Java EE 7 的一部分么？

是的，Java EE 7（JSR-342）已经把 JCache（JSR-107）引入为候选者了。 JSR-342 规范的领导者已经对 JSR-107 展开了评测。JSR-107 规范有一个强制的功能集和两个可选功能：注解和 JTA。我们想让 Java EE 7 引入的正是这个完整版本。同时，我们还和 Java EE 7 规范的领导者 Linda DeMichiel，以及 Oracle 的 Java EE 7 团队进行着密切的协调合作。

InfoQ：缓存对 Java EE 和 Java 来说，似乎是一个重要却缺失的功能，你觉得 JCache 为什么会花这么长时间呢？

JSR-107 的规范号比较小，从这可以看出来，这个规范十年前就被想到了。它最初由 Oracle 开始做，但后来被搁置了好几年。过去三年里我一直参与其中，Terracotta 和 Oracle 在去年加强了对 JSR-107 的投入。

缓存向来都不是规划在架构里，而是企业应用在生产环境里出问题之后才添加到企业应用里的。有一个例外是 ORM，因为它本身的方法就需要一个缓存。

Greg 接着说，Java EE 7 是针对云的，规范领导者也看到了缓存的价值。可以推断一下：一旦开发人员开始用缓存解决性能问题，他们就能看到缓存的价值。然后，认为缓存很不错的开发人员在新项目和解决方案一开始就会引入缓存，而不是等到出现性能问题的时候才加以引入。

这已经让缓存成为架构里公认的一部分，而不仅仅是性能补丁。Greg 对 NoSQL 和 Ehcache 等缓存解决方案进行了对比，Ehcache 这些缓存解决方案在很多方面都试图解决同样的伸缩性问题，只是采用了不同的方式。 Ehcahe 和 Java 里的 memcached ，以及整个行业内的缓存，两者的应用都急剧增长。比如说，Memcached 是个容错的分布式缓存，从消费者的注意力份额（Mindshare）来讲，2007 年它还相对默默无闻，现在则超越了位列第一的商业分布式缓存Oracle Coherence（Coherence 自身也在增长），这表明缓存的市场有很大潜力。

Greg 就职的 Terracotta 已经开始在 Ehcache 里实现规范，其中包括 BigMemory 、Cache 资源预留等功能，同时会支持独立模式和分布式模式。 Ehcache 是众所周知的开源 Java 缓存，尤其被使用过 Hibernate 的用户所熟知。

和大多数 Java 缓存实现一样，Ehcache 有一个本地内存复制模式，这种模式和纯粹的分布式版本相比具有显著的性能优势。虽然Memcached 激发了大家对缓存解决方案的兴趣和需求，但更快、符合标准的实现也会有一席之地。有了标准API，供应商就可以有自己的实现，开源实现也能在性能、易用性、对弹性云的支持、可伸缩性等更多方面和供应商的产品展开竞争。

缓存现在似乎愈发成为企业和云解决方案的特定组件，因此很多供应商目前都正在实现或是打算实现JCache，包括 Terracotta 、 Oracle 、 JBoss 、 Caucho 、IBM、 Google App Engine 等。

针对 JSR-107 和几个月前才推出的 JSR-347（数据网格 JSR），大家似乎有一些争议。

InfoQ：如果 JSR-107 和 JSP-347 有重叠的内容怎么办？JSR-107 和 JSR-347 的范围是怎样划定的？

JSR-347 定义为 JSR-107 的超集，它对 JSR-107 有一个依赖，额外增加了数据网格功能。JSR-107 进行了精心设计，同时支持独立缓存和分布式缓存，与分布式缓存实现的拓扑结构没有关系。JSR-107 已接近尾声，我们希望这对 JSR-347 的定义有所帮助。

JSR-347 定义了回收、复制、分发和事务的行为。JSR-347 花费了更多的精力去定义一套健壮的异步非阻塞 API，这对数据网格来说是很重要的。JSR-347 会增加更多的 API，也会同时支持 JSR-107 的 API。

InfoQ：JSR-107 是不是只关注 Java EE？对 Java SE 有关注么？

JCache 是针对 Java EE 的，但并不妨碍 Java SE 使用它。Ehcache 等实现在 Java SE、Java EE 和 Spring 上都能运行。

API 分成两部分：没有依赖的基本 Profile，这在 Java SE 上就可以使用；添加了 JTA 和缓存方法注解的完整 Profile。完整版本是针对 Java EE 6、Spring 和其他企业环境的，在现有的企业环境里都能工作。被纳入 Java EE 7 之后，Java 开发人员就会意识到可以使用它。我们希望 JSR 166 组能为 JDK 8 构建一个简单的进程内缓存。

InfoQ：JCache 的进展、过程和设计有哪些主要的变化和改进？

我们已经构建了 API、RI（参考实现）和 TCK（技术兼容性套件），正在把它们发布到 oss.sonatype.org 上。所有的源代码都放在 GitHub 上。GitHub 上的 Readme 给出了完整的介绍和链接。整个过程和规范都是开放的，源代码和社区也都是开放的。

从设计的角度看，基本组成部分有一个 CacheManager，用来持有、控制缓存集合。缓存有一些条目。我们还有一个类似 API 的映射，可以和以下附加功能进行交互：

1. 原子操作
2. 通过缓存读取
3. 通过缓存写入
4. 缓存事件监听器
5. 统计
6. 事务
7. 注解

缓存很多地方都用了泛型。我们不限制分布式缓存的拓扑结构，处理分布式缓存时也比较谨慎。Terracotta 和 Oracle 都出售分布式缓存产品，我们打算让这套 API 有助于这些产品的应用。

开发人员会发现这套 API 简单而强大，并且涵盖了大多数情况。

JSR-107 公开了它的邮件列表，把规范也发布为公开的 Google 文件，对 JSR 如何公开来说，这已经达到一定高的标准了。和过去的一些 JSR 相比，JSR-107 的做法是一个里程碑。

JSR-107 姗姗来迟，但最终会问世。分布式缓存在提升性能和可伸缩性时举足轻重，好在 Java 将有用于缓存的标准 API。Java 世界里，分布式缓存的需求有非常大的潜力，JSR-107 最有可能为 Java 的前景锦上添花。

查看英文原文： JSR-107, JCache: Alive and Going to be Part of Java EE 7