JAVA缓存规范 —— 虽迟但到的JCache API与天生不俗的Spring Cache

大家好，又见面了。

本文是笔者作为掘金技术社区签约作者的身份输出的缓存专栏系列内容，将会通过系列专题，讲清楚缓存的方方面面。如果感兴趣，欢迎关注以获取后续更新。

有诗云“纸上得来终觉浅，绝知此事要躬行”，在上一篇文章《手写本地缓存实战2—— 打造正规军，构建通用本地缓存框架》中，我们一起论证并逐步实现了一套简化版本的通用本地缓存框架，并在过程中逐步剖析了缓存设计关键要素的实现策略。本篇文章中，我们一起来聊一聊缓存框架实现所需要遵循的规范。

为何需要规范

上一章中构建的简化版本的缓存框架，虽然可以使用，但是也存在一个问题，就是它对外提供的实现接口都是框架根据自己的需要而自定义的。这样一来，项目集成了此缓存框架，后续如果想要更换缓存框架的时候，业务层面的改动会比较大。 —— 因为是自定义的框架接口，无法基于里氏替换原则来进行灵活的更换。

在业界各大厂商或者开源团队都会构建并提供一些自己实现的缓存框架或者组件，提供给开发者按需选择使用。如果大家都是各自闭门造车，势必导致业务中集成并使用某一缓存实现之后，想要更换缓存实现组件会难于登天。

千古一帝秦始皇统一天下后，颁布了书同文、车同轨等一系列法规制度，使得所有的车辆都遵循统一的轴距，然后都可以在官道上正常的通行，大大提升了流通性。而正所谓“国有国法、行有行规”，为了保证缓存框架的通用性、提升项目的可移植性，JAVA行业也迫切需要这么一个缓存规范，来约束各个缓存提供商给出的缓存框架都遵循相同的规范接口，业务中按照标准接口进行调用，无需与缓存框架进行深度耦合，使得缓存组件的更换成为一件简单点的事情。

在JAVA的缓存领域，流传比较广泛的主要是JCache API和Spring Cache两套规范，下面就一起来看下。

虽迟但到的JSR107 —— JCache API

提到JAVA中的“行业规矩”，JSR是一个绕不开的话题。它的全称为Java Specification Requests，意思是JAVA规范提案。在该规范标准中，有公布过一个关于JAVA缓存体系的规范定义，也即JSR 107规范（JCache API），主要明确了JAVA中基于内存进行对象缓存构建的一些要求，涵盖内存对象的创建、查询、更新、删除、一致性保证等方面内容。

JSR107规范早在2012年时草案就被提出，但却直到2014年才正式披露规范版本，也即JCache API 1.0.0版本，至此JAVA领域总算是有个正式的关于缓存的官方规范要求。

揭秘JSR107 —— JCache API内容探究

JSR107规范具体的要求形式，都以接口的形式封装在javax.cache包中进行提供。我们要实现的缓存框架需要遵循该规范，也就是需要引入javax.cache依赖包，并实现其中提供的相关接口即可。对于使用maven构建的项目中，可以在pom.xml中引入javax.cache依赖：

<dependency>
    <groupId>javax.cache</groupId>
    <artifactId>cache-api</artifactId>
    <version>1.1.1</version>
</dependency>

在JCache API规范中，定义的缓存框架相关接口类之间的关系逻辑梳理如下：

我们要实现自己的本地缓存框架，也即需要实现上述各个接口。对上述各接口类的含义介绍说明如下：