重新认识下JVM级别的本地缓存框架Guava Cache——优秀从何而来

灰太狼 2023-09-23 13:06 105阅读 0赞

### Guava Cache初识 ###

**Guava**是Google提供的一套JAVA的工具包，而`Guava Cache`则是该工具包中提供的一套完善的**JVM级别**的高并发缓存框架。其实现机制类似*ConcurrentHashMap*，但是进行了众多的封装与能力扩展。作为JVM级别的本地缓存框架，`Guava Cache`具备缓存框架该有的众多基础特性。当然，Guava Cache能从众多本地缓存类产品中脱颖而出，除了具备上述基础缓存特性外，还有众多贴心的*能力增强*，绝对算得上是工具包届的**超级暖男**！为什么这么说呢？我们一起看下*Guava Cache*的能力介绍，应该可以有所体会。

![format_png][]

#### 支持缓存记录的过期设定 ####

作为一个合格的缓存容器，支持缓存记录过期是一个基础能力。`Guava Cache`不但支持设定过期时间，还支持选择是根据`插入时间`进行过期处理（**创建过期**）、或者是根据最后`访问时间`进行过期处理（**访问过期**）。

<table> 
 <thead> 
  <tr> 
   <th>过期策略</th> 
   <th>具体说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>创建过期</td> 
   <td>基于缓存记录的插入时间判断。比如设定10分钟过期，则记录加入缓存之后，<em>不管有没有访问</em>，10分钟时间到则</td> 
  </tr> 
  <tr> 
   <td>访问过期</td> 
   <td>基于最后一次的访问时间来判断是否过期。比如设定10分钟过期，如果缓存记录被访问到，则以最后一次访问时间重新计时；只有连续10分钟没有被访问的时候才会过期，否则将一直存在缓存中不会被过期。</td> 
  </tr> 
 </tbody> 
</table>

实际使用的时候，可以在创建缓存容器的时候指定过期策略即可：

*  基于**创建时间**过期

public Cache<String, User> createUserCache() {
        return CacheBuilder.newBuilder()
            .expireAfterWrite(30L, TimeUnit.MINUTES)
            .build();
    }
    复制代码

*  基于**访问时间**过期

public Cache<String, User> createUserCache() {
        return CacheBuilder.newBuilder()
            .expireAfterAccess(30L, TimeUnit.MINUTES)
            .build();
    }
    复制代码

是不是很方便？

![format_png 1][]

#### 支持缓存容量限制与不同淘汰策略 ####

作为内存型缓存，必须要防止出现内存溢出的风险。Guava Cache支持设定缓存容器的最大存储上限，并支持根据缓存记录`条数`或者基于每条缓存记录的`权重`（后面会具体介绍）进行判断是否达到容量阈值。

当容量触达阈值后，支持根据`FIFO + LRU`策略实施具体淘汰处理以腾出位置给新的记录使用。

<table> 
 <thead> 
  <tr> 
   <th>淘汰策略</th> 
   <th>具体说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>FIFO</td> 
   <td>根据缓存记录写入的顺序，先写入的先淘汰</td> 
  </tr> 
  <tr> 
   <td>LRU</td> 
   <td>根据访问顺序，淘汰最久没有访问的记录</td> 
  </tr> 
 </tbody> 
</table>

实际使用的时候，同样是在创建缓存容器的时候指定容量上限与淘汰策略，这样就可以放心大胆的使用而不用担心内存溢出问题咯。

*  限制缓存**记录条数**

public Cache<String, User> createUserCache() {
        return CacheBuilder.newBuilder()
                .maximumSize(10000L)
                .build();
    }
    复制代码

*  限制缓存**记录权重**

public Cache<String, User> createUserCache() {
        return CacheBuilder.newBuilder()
                .maximumWeight(10000L)
                .weigher((key, value) -> (int) Math.ceil(instrumentation.getObjectSize(value) / 1024L))
                .build();
        }
    复制代码

这里需要注意：按照权重进行限制缓存容量的时候必须要指定`weighter`属性才可以生效。上面代码中我们通过计算`value`对象的字节数（byte）来计算其权重信息，每1kb的字节数作为1个权重，整个缓存容器的总权重限制为1w，这样就可以实现将缓存内存占用控制在`10000*1k≈10M`左右。

有没有很省心？

![format_png 2][]

#### 支持集成数据源能力 ####

在前面文章中，我们有介绍过缓存的**三种模型**，分别是`旁路型`、`穿透型`、`异步型`。Guava Cache作为一个封装好的缓存框架，是一个典型的**穿透型缓存**。正常业务使用缓存时通常会使用旁路型缓存，即先去缓存中尝试查询获取数据，如果获取不到则会从数据库中进行查询并加入到缓存中；而为了简化业务端使用复杂度，Guava Cache支持集成数据源，业务层面调用接口查询缓存数据的时候，如果缓存数据不存在，则会*自动*去数据源中进行数据获取并加入缓存中。

public User findUser(Cache<String, User> cache, String userId) {
        try {
            return cache.get(userId, () -> {
                System.out.println(userId + "用户缓存不存在，尝试回源查找并回填...");
                return userDao.getUser(userId);
            });
        } catch (ExecutionException e) {
            e.printStackTrace();
        }
        return null;
    }
    复制代码

实际使用的时候如果查询的用户不存在，则会自动去回源查找并写入缓存里，再次获取的时候便可以从缓存直接获取：

![format_png 3][]

上面的方法里，是通过在get方法里传入`Callable`实现的方式指定回源获取数据的方式，来实现缓存不存在情况的自动数据拉取与回填到缓存中的。实际使用的时候，除了Callable方式，还有一种`CacheLoader`的模式，也可以实现这一效果。

需要我们在创建缓存容器的时候声明容器为**LoadingCache**类型（下面的章节中有介绍），并且指定`CacheLoader`处理逻辑：

public LoadingCache<String, User> createUserCache() {
        return CacheBuilder.newBuilder()
                .build(new CacheLoader<String, User>() {
                    @Override
                    public User load(String key) throws Exception {
                        System.out.println(key + "用户缓存不存在，尝试CacheLoader回源查找并回填...");
                        return userDao.getUser(key);
                    }
                });
        }
    复制代码

这样，获取不到数据的时候，也会自动回源查询并填充。比如我们执行如下调用逻辑：

public static void main(String[] args) {
            CacheService cacheService = new CacheService();
            LoadingCache<String, User> cache = cacheService.createUserCache();
            try {
                System.out.println(cache.get("123"));
                System.out.println(cache.get("124"));
                System.out.println(cache.get("123"));
            } catch (Exception e) {
                e.printStackTrace();
            }
        }
    复制代码

执行结果如下：

两种方式都可以实现这一效果，实际可以根据需要与场景选择合适的方式。

当然，有些时候，可能也会涉及到`CacheLoader`与`Callable`两种方式结合使用的场景，这种情况下**优先**会执行*Callable*提供的逻辑，Callable缺失的场景会使用*CacheLoader*提供的逻辑。

public static void main(String[] args) {
        CacheService cacheService = new CacheService();
        LoadingCache<String, User> cache = cacheService.createUserCache();
        try {
            System.out.println(cache.get("123", () -> new User("xxx")));
            System.out.println(cache.get("124"));
            System.out.println(cache.get("123"));
        } catch (Exception e) {
            e.printStackTrace();
        }
    }
    复制代码

执行后，可以看出Callable逻辑被*优先执行*，而CacheLoader作为*兜底策略*存在：

User(userId=xxx, userName=null, department=null)
    124用户缓存不存在，尝试CacheLoader回源查找并回填...
    User(userId=124, userName=翠花, department=测试部)
    User(userId=xxx, userName=null, department=null)
    复制代码

![format_png 4][]

#### 支持更新锁定能力 ####

这个是与上面数据源集成一起的辅助增强能力。在高并发场景下，如果某个key值没有命中缓存，大量的请求同步打到下游模块处理的时候，很容易造成**缓存击穿**问题。

![format_png 5][]

为了防止缓存击穿问题，可以通过**加锁**的方式来规避。当缓存不可用时，仅`持锁的线程`负责从数据库中查询数据并写入缓存中，其余请求重试时先尝试从缓存中获取数据，避免所有的并发请求全部同时打到数据库上。

作为穿透型缓存的保护策略之一，*Guava Cache*自带了`并发锁定`机制，同一时刻仅允许一个请求去回源获取数据并回填到缓存中，而其余请求则阻塞等待，不会造成数据源的压力过大。

有没有被暖心到？

![format_png 6][]

#### 提供了缓存相关的一些监控统计 ####

引入缓存的一个初衷是希望缓存能够提升系统的处理性能，而有限缓存容量中仅存储部分数据的时候，我们会希望存储的有限数据可以尽可能的覆盖并抗住大部分的请求流量，所以对缓存的**命中率**会非常关注。

Guava Cache深知这一点，所以提供了`stat`统计日志，支持查看缓存数据的*加载*或者*命中*情况统计。我们可以基于命中情况，不断的去优化代码中缓存的数据策略，以发挥出缓存的最大价值。

Guava Cache的统计信息封装为`CacheStats`对象进行承载，主要包含一下几个关键指标项：

<table> 
 <thead> 
  <tr> 
   <th>指标</th> 
   <th>含义说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>hitCount</td> 
   <td>命中缓存次数</td> 
  </tr> 
  <tr> 
   <td>missCount</td> 
   <td>没有命中缓存次数（查询的时候内存中没有）</td> 
  </tr> 
  <tr> 
   <td>loadSuccessCount</td> 
   <td>回源加载的时候加载成功次数</td> 
  </tr> 
  <tr> 
   <td>loadExceptionCount</td> 
   <td>回源加载但是加载失败的次数</td> 
  </tr> 
  <tr> 
   <td>totalLoadTime</td> 
   <td>回源加载操作总耗时</td> 
  </tr> 
  <tr> 
   <td>evictionCount</td> 
   <td>删除记录的次数</td> 
  </tr> 
 </tbody> 
</table>

缓存容器创建的时候，可以通过`recordStats()`开启缓存行为的统计记录：

public static void main(String[] args) {
            LoadingCache<String, User> cache = CacheBuilder.newBuilder()
                    .recordStats()
                    .build(new CacheLoader<String, User>() {
                        @Override
                        public User load(String key) throws Exception {
                            System.out.println(key + "用户缓存不存在，尝试CacheLoader回源查找并回填...");
                            User user = userDao.getUser(key);
                            if (user == null) {
                                System.out.println(key + "用户不存在");
                            }
                            return user;
                        }
                    });
    
            try {
                System.out.println(cache.get("123");
                System.out.println(cache.get("124"));
                System.out.println(cache.get("123"));
                System.out.println(cache.get("126"));
    
            } catch (Exception e) {
            } finally {
                CacheStats stats = cache.stats();
                System.out.println(stats);
            }
        }
    复制代码

上述代码执行之后结果输出如下：

123用户缓存不存在，尝试CacheLoader回源查找并回填...
    User(userId=123, userName=铁柱, department=研发部)
    124用户缓存不存在，尝试CacheLoader回源查找并回填...
    User(userId=124, userName=翠花, department=测试部)
    User(userId=123, userName=铁柱, department=研发部)
    126用户缓存不存在，尝试CacheLoader回源查找并回填...
    126用户不存在
    CacheStats{hitCount=1, missCount=3, loadSuccessCount=2, loadExceptionCount=1, totalLoadTime=1972799, evictionCount=0}
    复制代码

可以看出，一共执行了4次请求，其中1次命中，3次回源处理，2次回源加载成功，1次回源没找到数据，与打印出来的`CacheStats`统计结果完全吻合。

有着上述能力的加持，前面将Guava Cache称作“**暖男**”不过分吧？

![format_png 7][]

### Guava Cache适用场景 ###

在本系列专栏的第一篇文章《[聊一聊作为高并发系统基石之一的缓存，会用很简单，用好才是技术活][Link 1]》中，我们在缓存的一步步演进介绍中提过本地缓存与集中式缓存的区别，也聊了各自的优缺点。

作为一款纯粹的本地缓存框架，Guava Cache具备本地缓存该有的**优势**，也无可避免的存在着本地缓存的**弊端**。

<table> 
 <thead> 
  <tr> 
   <th>维度</th> 
   <th>简要概述</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>优势</td> 
   <td>基于<strong>空间换时间</strong>的策略，利用内存的高速处理效率，提升机器的处理性能，减少大量对外的<em>IO请求</em>交互，比如读取DB、请求外部网络、读取本地磁盘数据等等操作。</td> 
  </tr> 
  <tr> 
   <td>弊端</td> 
   <td>整体<strong>容量受限</strong>，可能对本机内存造成压力。此外，对于分布式多节点集群部署的场景，缓存更新场景会出现<strong>缓存漂移</strong>问题，导致各个节点之间的缓存<em>数据不一致</em>。</td> 
  </tr> 
 </tbody> 
</table>

鉴于上述优劣综合判断，可以大致圈定`Guava Cache`的实际适用场合：

*  数据**读多写少**且对**一致性要求不高**的场景

这类场景中，会将数据缓存到本地内存中，采用定时触发（或者事件推送）的策略重新加载到内存中。这样业务处理逻辑直接从内存读取需要的数据，修改系统配置项之后，需要等待一定的时间后方可生效。

很多的配置中心采用的都是这个缓存策略。统一配置中心中管理配置数据，然后各个业务节点会从统一配置中心拉取配置并存储在自己本地的内存中然后使用本地内存中的数据。这样可以有效规避配置中心的单点故障问题，降低了配置中心的请求压力，也提升了业务节点自身的业务处理性能（减少了与配置中心之间的网络交互请求）。

*  对**性能**要求**极其严苛**的场景

对于分布式系统而言，集中式缓存是一个常规场景中很好的选项。但是对于一些超大并发量且读性能要求严苛的系统而言，一个请求流程中需要频繁的去与Redis交互，其网络开销也是不可忍受的。所以可以采用将数据本机内存缓存的方式，分散redis的压力，降低对外请求交互的次数，提升接口响应速度。

*  简单的本地数据缓存，作为`HashMap/ConcurrentHashMap`的**替代品**

这种场景也很常见，我们在项目中经常会遇到一些数据的需要临时缓存一下，为了方便很多时候直接使用的`HashMap`或者`ConcurrentHashMap`来实现。而Guava Cache聚焦缓存场景做了很多额外的功能增强（比如数据过期能力支持、容量上限约束等），可以完美替换掉*HashMap/ConcurrentHashMap*，更适合缓存场景使用。

![format_png 8][]

### Guava Cache使用 ###

#### 引入依赖 ####

使用Guava Cache，首先需要引入对应的依赖包。对于Maven项目，可以在`pom.xml`中添加对应的依赖声明即可：

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

这样，就完成了依赖引入。

![format_png 9][]

#### 容器创建 —— CacheBuilder ####

具体使用前首先面临的就是如何创建Guava Cache实例。可以借助`CacheBuilder`以一种优雅的方式来构建出合乎我们诉求的Cache实例。

对*CacheBuilder*中常见的属性方法，归纳说明如下：

<table> 
 <thead> 
  <tr> 
   <th>方法</th> 
   <th>含义说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>newBuilder</td> 
   <td>构造出一个Builder实例类</td> 
  </tr> 
  <tr> 
   <td>initialCapacity</td> 
   <td>待创建的缓存容器的初始容量大小（记录<strong>条数</strong>）</td> 
  </tr> 
  <tr> 
   <td>maximumSize</td> 
   <td>指定此缓存容器的最大容量(最大缓存记录<strong>条数</strong>)</td> 
  </tr> 
  <tr> 
   <td>maximumWeight</td> 
   <td>指定此缓存容器的最大容量（最大<strong>比重</strong>值），需结合<code>weighter</code>方可体现出效果</td> 
  </tr> 
  <tr> 
   <td>expireAfterWrite</td> 
   <td>设定过期策略，按照数据<strong>写入时间</strong>进行计算</td> 
  </tr> 
  <tr> 
   <td>expireAfterAccess</td> 
   <td>设定过期策略，按照数据最后<strong>访问时间</strong>来计算</td> 
  </tr> 
  <tr> 
   <td>weighter</td> 
   <td>入参为一个函数式接口，用于指定每条存入的缓存数据的权重占比情况。这个需要与<code>maximumWeight</code>结合使用</td> 
  </tr> 
  <tr> 
   <td>refreshAfterWrite</td> 
   <td>缓存写入到缓存之后</td> 
  </tr> 
  <tr> 
   <td>concurrencyLevel</td> 
   <td>用于控制缓存的并发处理能力，同时支持多少个线程<strong>并发写入</strong>操作</td> 
  </tr> 
  <tr> 
   <td>recordStats</td> 
   <td>设定开启此容器的数据加载与缓存命中情况统计</td> 
  </tr> 
 </tbody> 
</table>

基于`CacheBuilder`及其提供的各种方法，我们可以轻松的进行缓存容器的构建、并指定容器的各种约束条件。

比如下面这样：

public LoadingCache<String, User> createUserCache() {
        return CacheBuilder.newBuilder()
                .initialCapacity(1000) // 初始容量
                .maximumSize(10000L)   // 设定最大容量
                .expireAfterWrite(30L, TimeUnit.MINUTES) // 设定写入过期时间
                .concurrencyLevel(8)  // 设置最大并发写操作线程数
                .refreshAfterWrite(1L, TimeUnit.MINUTES) // 设定自动刷新数据时间
                .recordStats() // 开启缓存执行情况统计
                .build(new CacheLoader<String, User>() {
                    @Override
                    public User load(String key) throws Exception {
                        return userDao.getUser(key);
                    }
                });
    }
    复制代码

![format_png 10][]

#### 业务层使用 ####

Guava Cache容器对象创建完成后，可以基于其提供的对外接口完成相关缓存的具体操作。首先可以了解下Cache提供的对外操作接口：

![format_png 11][]

对关键接口的含义梳理归纳如下：

<table> 
 <thead> 
  <tr> 
   <th>接口名称</th> 
   <th>具体说明</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>get</td> 
   <td>查询指定key对应的value值，如果缓存中没匹配，则基于给定的<code>Callable</code>逻辑去获取数据回填缓存中并返回</td> 
  </tr> 
  <tr> 
   <td>getIfPresent</td> 
   <td>如果缓存中存在指定的key值，则返回对应的value值，否则返回null（此方法<strong>不会触发</strong>自动回源与回填操作）</td> 
  </tr> 
  <tr> 
   <td>getAllPresent</td> 
   <td>针对传入的key列表，返回缓存中存在的对应value值列表（<strong>不会触发</strong>自动回源与回填操作）</td> 
  </tr> 
  <tr> 
   <td>put</td> 
   <td>往缓存中添加key-value键值对</td> 
  </tr> 
  <tr> 
   <td>putAll</td> 
   <td>批量往缓存中添加key-value键值对</td> 
  </tr> 
  <tr> 
   <td>invalidate</td> 
   <td>从缓存中删除指定的记录</td> 
  </tr> 
  <tr> 
   <td>invalidateAll</td> 
   <td>从缓存中批量删除指定记录，如果无参数，则清空所有缓存</td> 
  </tr> 
  <tr> 
   <td>size</td> 
   <td>获取缓存容器中的总记录数</td> 
  </tr> 
  <tr> 
   <td>stats</td> 
   <td>获取缓存容器当前的统计数据</td> 
  </tr> 
  <tr> 
   <td>asMap</td> 
   <td>将缓存中的数据转换为<code>ConcurrentHashMap</code>格式返回</td> 
  </tr> 
  <tr> 
   <td>cleanUp</td> 
   <td>清理所有的已过期的数据</td> 
  </tr> 
 </tbody> 
</table>

在项目中，可以基于上述接口，实现各种缓存操作功能。

public static void main(String[] args) {
        CacheService cacheService = new CacheService();
        LoadingCache<String, User> cache = cacheService.createUserCache6();
        cache.put("122", new User("122"));
        cache.put("122", new User("122"));
        System.out.println("put操作后查询：" + cache.getIfPresent("122"));
        cache.invalidate("122");
        System.out.println("invalidate操作后查询：" + cache.getIfPresent("122"));
        System.out.println(cache.stats());
    }
    复制代码

执行后，结果如下：

put操作后查询：User(userId=122, userName=null, department=null)
    invalidate操作后查询：null
    CacheStats{hitCount=1, missCount=1, loadSuccessCount=0, loadExceptionCount=0, totalLoadTime=0, evictionCount=0}
    复制代码

当然，上述示例代码中这种使用方式有个明显的弊端就是业务层面对Guava Cache的`私有API`**依赖过深**，后续如果需要替换Cache组件的时候会比较痛苦，需要对业务调用的地方进行大改。所以真正项目里面，最好还是对其适当封装，以实现业务层面的**解耦**。如果你的项目是使用Spring框架，也可以基于`Spring Cache`统一规范来集成并使用Guava Cache，降低对业务逻辑的**侵入**。

![format_png 12][]

### 小结回顾 ###

好啦，关于Guava Cache的功能与关键特性介绍，以及项目中具体的集成与使用方法，就介绍到这里了。总结一下，Guava Cache其实就是一个增强版的大号ConcurrentHashMap，在保证线程安全的情况下，增加了缓存必备的数据过期、容量限制、回源策略等能力，既保证了本身的精简，又使得整体能力足以满足大部分本地缓存场景的使用诉求。也正是由于这些原因，Guava Cache在JAVA领域广受好评，使用范围非常的广泛。

下一篇文章中，我们将继续对Guava Cache展开讨论，跳出使用层面，剖析其内部核心实现逻辑。如果有兴趣，欢迎关注后续文章的更新。

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

[format_png]: https://img-blog.csdnimg.cn/img_convert/65542bfdea7869363de0d9f298d59951.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/f7fe9d2f8929a669e44bb7da2281571e.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/45cd6087101cf0212c9de017fd2164cc.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/e41517f89281c5fc49544525eef5b88a.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/6f226181635a6a9e02a069caa3dc1af0.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/96fe4196d53ce216e0ec4d031d0a5436.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/09afb6486c370b6a7713148b8d34e301.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/1a43dd80bbd173f96e28e1cd74615374.webp?x-oss-process=image/format,png
[Link 1]: https://juejin.cn/post/7151937376578142216
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/dd910eb2840600c2bf392ae825b26d40.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/ae2a5ada6417eb9b56a6464079e5494e.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/98d8a45d1778be939925b2e2aaa03079.webp?x-oss-process=image/format,png
[format_png 11]: https://img-blog.csdnimg.cn/img_convert/193cc53b100f55af44264083b05ea5ee.webp?x-oss-process=image/format,png
[format_png 12]: https://img-blog.csdnimg.cn/img_convert/a4c221b0f1ac758f07177e36f9dabdc3.webp?x-oss-process=image/format,png