为何需要规范

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

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

千古一帝 秦始皇 统一天下后，颁布了 书同文 、车同轨 等一系列法规制度，使得所有的车辆都遵循统一的轴距，然后都可以在官道上正常的通行，大大提升了流通性。而正所谓“国有国法、行有行规”，为了保证 缓存 框架的通用性、提升项目的可移植性， 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规范中，定义的缓存框架相关接口类之间的关系逻辑梳理如下：

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

作为通用规范，这里将CachingProvider定义为了一个 SPI接口 （Service Provider Interface，服务提供接口），主要是借助 JDK 自带的服务提供发现能力，来实现按需加载各自实现的功能逻辑，有点IOC的意味。这样设计有一定的好处：

• 对于框架 ：

需要遵循规范，提供上述接口的实现类。然后可以实现热插拔，与业务 解耦 。

• 对于业务 ：

先指定需要使用的SPI的具体实现类，然后业务逻辑中便无需感知缓存具体的实现，直接基于JCache API通用接口进行使用即可。后续如果需要更换缓存实现框架，只需要切换下使用的SPI的具体实现类即可。

根据上述介绍，一个基于 JCache API 实现的缓存框架在实际项目中使用时的对象层级关系可能会是下面这种场景（假设使用 LRU策 略存储部门信息、使用 普通策略 存储用户信息）：

那么如何去理解JCache API中几个接口类的关系呢？

几个简单的说明：

1. CachingProvider 并无太多实际逻辑层面的功能，只是用来基于SPI机制，方便项目中集成插拔使用。内部持有CacheManager对象，实际的缓存管理能力，由CacheManager负责提供。
2. CacheManager 负责具体的缓存管理相关能力实现，实例由CachingProvider提供并持有，CachingProvider可以持有一个或者多个不同的CacheManager对象。这些CacheManager对象可以是相同类型，也可以是不同类型，比如我们可以实现2种缓存框架，一种是基于内存的缓存，一种是基于磁盘的缓存，则可以分别提供两种不同的 CacheManager ，供业务按需调用。
3. Cache 是CacheManager负责创建并管理的具体的缓存容器，也可以有一个或者多个，如业务中会涉及到为用户列表和部门列表分别创建独立的Cache存储。此外，Cache容器也可以根据需要提供不同的Cache容器类型，以满足不同场景对于缓存容器的不同诉求，如我们可以实现一个类似 HashMap 的普通键值对Cache容器，也可以提供一个基于 LRU 淘汰策略的Cache容器。

至此呢，我们厘清了 JCache API 规范的大致内容。

插叙 —— SPI何许人也

按照JSR107规范试编写缓存具体能力时，我们需要实现一个 SPI接口 的实现类，然后由JDK提供的加载能力将我们扩展的缓存服务加载到 JVM 中供使用。

提到 API 我们都耳熟能详，也就是我们常规而言的接口。但说起 SPI 也许很多小伙伴就有点陌生了。其实SPI也并非是什么新鲜玩意，它是 JDK内置 的一种服务的 提供 与 发现 、 加载 机制。按照JAVA的面向对象编码的思想，为了降低代码的 耦合度 、提升代码的灵活性，往往需要利用好抽象这一特性，比如一般会比较推荐基于接口进行编码、而尽量避免强依赖某个具体的功能实现类 —— 这样才能让构建出的系统具有更好的扩展性，更符合面向对象设计原则中的里式替换原则。SPI便是为了支持这一诉求而提供的能力，它允许将接口具体的实现类交由业务或者三方进行独立构建，然后加载到JVM中以供业务进行使用。

为了这一点，我们需要在resource/META-INF/services目录下新建一个文件，文件名即为SPI接口名称javax.cache.spi.CachingProvider，然后在文件内容中，写入我们要注入进入的我们自己的 Provider 实现类：

这样，我们就完成了将我们自己的MyCachingProvider功能注入到系统中。在业务使用时，可以通过Caching.getCachingProvider()获取到注入的自定义 Provider 。

 public  static   void  main(String[] args) {
    CachingProvider provider =  Caching.getCachingProvider();
    System.out.println(provider);
}
复制代码  

从输出的结果可以看出，获取到了自定义的Provider对象：

 com.veezean.skills.cache.fwk.MyCachingProvider@7adf9f5f
复制代码  

获取到Provider之后，便可以进一步的获取到Manager对象，进而业务层面层面可以正常使用。

JCache API规范的实现

JSR 作为JAVA领域正统行规，制定的时候往往考虑到各种可能的灵活性与通用性。作为JSR中根正苗红的JCache API规范，也沿袭了这一风格特色，框架接口的定义与实现也非常的丰富，几乎可以扩展自定义任何你需要的处理策略。 —— 但恰是这一点，也让其整个框架的接口定义过于 重量级 。对于缓存框架实现者而言，遵循JCache API需要实现众多的接口，需要做很多额外的实现处理。

比如，我们实现CacheManager的时候，需要实现如下这么多的接口：

 public class  MemCache Manager implements CacheManager {
     private  CachingProvider cachingProvider;
    private ConcurrentHashMap<String, Cache> caches;
    public MemCacheManager(CachingProvider cachingProvider,  ConcurrentHashMap <String, Cache> caches) {
        this.cachingProvider = cachingProvider;
        this.caches = caches;
    }
    @Override
    public CachingProvider getCachingProvider() {
    }
    @Override
    public URI getURI() {
    }
    @Override
    public ClassLoader getClassLoader() {
    }
    @Override
    public Properties getProperties() {
    }
    @Override
    public <K, V, C  extends  Configuration<K, V>> Cache<K, V> createCache(String s, C c) throws IllegalArgument Exception  {
    }
    @Override
    public <K, V> Cache<K, V> getCache(String s, Class<K> aClass, Class<V> aClass1) {
    }
    @Override
    public <K, V> Cache<K, V> getCache(String s) {
    }
    @Override
    public Iterable<String> getCacheNames() {
    }
    @Override
    public void destroyCache(String s) {
    }
    @Override
    public void enableManagement(String s,  boolean  b) {
    }
    @Override
    public void enableStatistics(String s, boolean b) {
    }
    @Override
    public void close() {
    }
    @Override
    public boolean isClosed() {
    }
    @Override
    public <T> T unwrap(Class<T> aClass) {
    }
}
复制代码  

长长的一摞接口等着实现，看着都 令人上头 ，作为缓存提供商，便需要按照自己的能力去实现这些接口，以保证相关缓存能力是按照规范对外提供。也正是因为JCache API这种不接地气的表现，让其虽是JAVA 领域的正统规范，却经常被 束之高阁 ，沦落成为了一种名义规范。业界主流的本地缓存框架中，比较出名的当属 Ehcache 了（当然，Spring4.1中也增加了对JSR规范的支持）。此外， Redis 的本地客户端Redisson也有实现全套JCache API规范，用户可以基于 Redisson 调用JCache API的标准接口来进行缓存数据的操作。

JSR107提供的注解操作方法

前面提到了作为供应商想要实现 JSR107 规范的时候会比较复杂，需要做很多自己的处理逻辑。但是对于业务使用者而言，JSR107还是比较贴心的。比如JSR107中就将一些常用的API方法封装为注解，利用注解来大大简化编码的复杂度，降低缓存对于业务逻辑的 侵入性 ，使得业务开发人员可以更加专注于业务本身的开发。

JSR107规范中常用的一些缓存操作注解方法梳理如下面的表格：

上述 注解 主要是添加在方法上面，用于自动将方法的入参与返回结果之间进行一个映射与自动缓存，对于后续请求如果命中缓存则直接返回缓存结果而无需再次执行方法的具体处理，以此来提升接口的响应速度与承压能力。

比如下面的查询接口上，通过@CacheResult注解可以将查询请求与查询结果缓存起来进行使用：

 @CacheResult(cacheName = "books")
public Book findBookByName(@CacheKey String bookName) {
    return bookDao.queryByName(bookName);
}
复制代码  

当 Book 信息发生变更的时候，为了保证缓存数据的准确性，需要同步更新缓存内容。可以通过在更新方法上面添加@CachePut接口即可达成目的：

 @CachePut(cacheName = "books")
public void updateBookInfo(@CacheKey String bookName, @CacheValue Book book) {
    bookDao.updateBook(bookName, book);
}
复制代码  

这里分别适用了@CacheKey和@CacheValue指定了需要更新的缓存记录key值，以及需要将其更新为的新的value值。

同样地，借助注解@CacheRemove可以完成对应缓存记录的删除：

 @CacheRemove(cacheName = "books")
public void deleteBookInfo(@CacheKey String bookName) {
    bookDao.deleteBookByName(bookName)
}
复制代码  

爱屋及乌 —— Spring 框架制定的Cache规范

JSR 107（JCache API）规范的诞生可谓是一路坎坷，拖拖拉拉直到 2014 年才发布了首个1.0.0版本规范。但是在JAVA界风头无两的 Spring 框架早在2011年就已经在其3.1版本中提供了缓存抽象层的规范定义，并借助Spring的优秀设计与良好生态，迅速得到了各个 软件开发 团体的青睐，各大缓存厂商也陆续提供了符合Spring Cache规范的自家缓存产品。

Spring Cache 并非是一个具体的缓存实现，而是和JSR107类似的一套 缓存规范 ，基于注解并可实现与Spring的各种高级特性无缝集成，受到了广泛的追捧。各大缓存提供商几乎都有基于Spring Cache规范进行实现的缓存组件。比如后面我们会专门介绍的Guava Cache、Caffeine Cache以及同样支持JSR107规范的Ehcache等等。

得力于Spring在JAVA领域无可撼动的地位，造就了 Spring Cache 已成为JAVA缓存领域的“事实标准”，深有“ 功高盖主 ”的味道。

Spring Cache使用不同缓存组件

如果要基于Spring Cache规范来进行缓存的操作，首先在项目中需要引入此规范的定义：

 <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-cache</artifactId>
</dependency>
复制代码  

这样，在业务代码中，就可以使用Spring Cache规范中定义的一些注解方法。前面有提过， Spring Cache只是一个规范声明 ，可以理解为一堆接口定义，而并没有提供具体的接口功能实现。具体的功能实现，由业务根据实际选型需要，引入相应缓存组件的 jar 库文件依赖即可 —— 这一点是Spring框架中极其普遍的一种做法。

假如我们需要使用Guava Cache来作为我们实际缓存能力提供者，则我们只需要引入对应的依赖即可：

 <dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>30.1.1-jre</version>
</dependency>
复制代码  

这样一来，我们便实现了使用Guava cache作为存储服务提供者、且基于Spring Cache接口规范进行缓存操作。Spring作为JAVA领域的一个相当优秀的框架，得益于其优秀的 封装 设计思想，使得更换缓存组件也显得非常容易。比如现在想要将上面的 Guava cache 更换为Caffeine cache作为新的缓存能力提供者，则业务代码中将依赖包改为Caffeine cache并简单的做一些细节配置即可：

 <dependency>
    <groupId>com.github.ben-manes.caffeine</groupId>
    <artifactId>caffeine</artifactId>
    <version>3.1.1</version>
</dependency>
复制代码  

这样一来，对于业务使用者而言，可以方便的进行缓存具体实现者的替换。而作为缓存能力提供商而言，自己可以轻易的被同类产品替换掉，所以也鞭策自己去提供更好更强大的产品，巩固自己的地位，也由此促进整个生态的 良性演进 。

Spring Cache规范提供的注解

需要注意的是，使用Spring Cache缓存前，需要先手动开启对于缓存能力的支持，可以通过@EnableCaching注解来完成。

除了 @EnableCaching ，在Spring Cache中还定义了一些其它的常用注解方法，梳理归纳如下：

具体的使用上，其实和JSR107规范中提供的注解用法相似。

当然了，JAVA领域缓存事实规范地位虽已奠定，但是Spring Cache依旧是保持着一个兼收并蓄的姿态，并积极的兼容了JCache API相关规范，比如Spring4.1起项目中可以使用JSR107规范提供的相关注解方法来操作。

小结回顾

好啦，关于JAVA中的 JSR107 规范以及 Spring Cache 规范，以及各自典型代表，我们就聊到这里。

那么，关于本文中提及的缓存规范的内容，你是否有自己的一些想法与见解呢？欢迎评论区一起交流下，期待和各位小伙伴们一起切磋、共同成长。