还在用 Guava Cache？它才是 Java 本地缓存之王！
来源：cnblogs.com/rickiyang/p/11074158.html
前面刚说到 Guava Cache，他的优点是封装了 get，put 操作；提供线程安全的缓存操作；提供过期策略；提供回收策略；缓存监控。
当缓存的数据超过最大值时，使用 LRU 算法替换。这一篇我们将要谈到一个新的本地缓存框架：Caffeine Cache。它也是站在巨人的肩膀上-Guava Cache，借着他的思想优化了算法发展而来。
本篇博文主要介绍 Caffine Cache 的使用方式，以及 Caffine Cache 在 SpringBoot 中的使用。
1. Caffine Cache 在算法上的优点-W-TinyLFU
说到优化，Caffine Cache 到底优化了什么呢？我们刚提到过 LRU，常见的缓存淘汰算法还有 FIFO，LFU：
FIFO：先进先出，在这种淘汰算法中，先进入缓存的会先被淘汰，会导致命中率很低。
LRU：最近最少使用算法，每次访问数据都会将其放在我们的队尾，如果需要淘汰数据，就只需要淘汰队首即可。仍然有个问题，如果有个数据在 1 分钟访问了 1000 次，再后 1 分钟没有访问这个数据，但是有其他的数据访问，就导致了我们这个热点数据被淘汰。
LFU：最近最少频率使用，利用额外的空间记录每个数据的使用频率，然后选出频率最低进行淘汰。这样就避免了 LRU 不能处理时间段的问题。
上面三种策略各有利弊，实现的成本也是一个比一个高，同时命中率也是一个比一个好。Guava Cache 虽然有这么多的功能，但是本质上还是对 LRU 的封装，如果有更优良的算法，并且也能提供这么多功能，相比之下就相形见绌了。
LFU 的局限性：在 LFU 中只要数据访问模式的概率分布随时间保持不变时，其命中率就能变得非常高。比如有部新剧出来了，我们使用 LFU 给他缓存下来，这部新剧在这几天大概访问了几亿次，这个访问频率也在我们的 LFU 中记录了几亿次。但是新剧总会过气的，比如一个月之后这个新剧的前几集其实已经过气了，但是他的访问量的确是太高了，其他的电视剧根本无法淘汰这个新剧，所以在这种模式下是有局限性。
LRU 的优点和局限性：LRU 可以很好的应对突发流量的情况，因为他不需要累计数据频率。但 LRU 通过历史数据来预测未来是局限的，它会认为最后到来的数据是最可能被再次访问的，从而给与它最高的优先级。
在现有算法的局限性下，会导致缓存数据的命中率或多或少的受损，而命中略又是缓存的重要指标。HighScalability 网站刊登了一篇文章，由前 Google 工程师发明的 W-TinyLFU——一种现代的缓存 。Caffine Cache 就是基于此算法而研发。
Caffeine 因使用?Window TinyLfu?回收策略，提供了一个近乎最佳的命中率。
当数据的访问模式不随时间变化的时候，LFU 的策略能够带来最佳的缓存命中率。然而 LFU 有两个缺点：
首先，它需要给每个记录项维护频率信息，每次访问都需要更新，这是个巨大的开销；
其次，如果数据访问模式随时间有变，LFU 的频率信息无法随之变化，因此早先频繁访问的记录可能会占据缓存，而后期访问较多的记录则无法被命中。
因此，大多数的缓存设计都是基于 LRU 或者其变种来进行的。相比之下，LRU 并不需要维护昂贵的缓存记录元信息，同时也能够反应随时间变化的数据访问模式。然而，在许多负载之下，LRU 依然需要更多的空间才能做到跟 LFU 一致的缓存命中率。因此，一个“现代”的缓存，应当能够综合两者的长处。
TinyLFU 维护了近期访问记录的频率信息，作为一个过滤器，当新记录来时，只有满足 TinyLFU 要求的记录才可以被插入缓存。如前所述，作为现代的缓存，它需要解决两个挑战：
一个是如何避免维护频率信息的高开销；
另一个是如何反应随时间变化的访问模式。
首先来看前者，TinyLFU 借助了数据流 Sketching 技术，Count-Min Sketch 显然是解决这个问题的有效手段，它可以用小得多的空间存放频率信息，而保证很低的 False Positive Rate。但考虑到第二个问题，就要复杂许多了，因为我们知道，任何 Sketching 数据结构如果要反应时间变化都是一件困难的事情，在 Bloom Filter 方面，我们可以有 Timing Bloom Filter，但对于 CMSketch 来说，如何做到 Timing CMSketch 就不那么容易了。
TinyLFU 采用了一种基于滑动窗口的时间衰减设计机制，借助于一种简易的 reset 操作：每次添加一条记录到 Sketch 的时候，都会给一个计数器上加 1，当计数器达到一个尺寸 W 的时候，把所有记录的 Sketch 数值都除以 2，该 reset 操作可以起到衰减的作用 。
W-TinyLFU 主要用来解决一些稀疏的突发访问元素。在一些数目很少但突发访问量很大的场景下，TinyLFU 将无法保存这类元素，因为它们无法在给定时间内积累到足够高的频率。因此 W-TinyLFU 就是结合 LFU 和 LRU，前者用来应对大多数场景，而 LRU 用来处理突发流量。
在处理频率记录的方案中，你可能会想到用 hashMap 去存储，每一个 key 对应一个频率值。那如果数据量特别大的时候，是不是这个 hashMap 也会特别大呢。由此可以联想到 Bloom Filter，对于每个 key，用 n 个 byte 每个存储一个标志用来判断 key 是否在集合中。原理就是使用 k 个 hash 函数来将 key 散列成一个整数。
在 W-TinyLFU 中使用 Count-Min Sketch 记录我们的访问频率，而这个也是布隆过滤器的一种变种。如下图所示:
在这里插入图片描述
如果需要记录一个值，那我们需要通过多种 Hash 算法对其进行处理 hash，然后在对应的 hash 算法的记录中+1，为什么需要多种 hash 算法呢？由于这是一个压缩算法必定会出现冲突，比如我们建立一个 byte 的数组，通过计算出每个数据的 hash 的位置。
比如张三和李四，他们两有可能 hash 值都是相同，比如都是 1 那 byte[1]这个位置就会增加相应的频率，张三访问 1 万次，李四访问 1 次那 byte[1]这个位置就是 1 万零 1，如果取李四的访问评率的时候就会取出是 1 万零 1，但是李四命名只访问了 1 次啊，为了解决这个问题，所以用了多个 hash 算法可以理解为 long[][]二维数组的一个概念，比如在第一个算法张三和李四冲突了，但是在第二个，第三个中很大的概率不冲突，比如一个算法大概有 1%的概率冲突，那四个算法一起冲突的概率是 1%的四次方。通过这个模式我们取李四的访问率的时候取所有算法中，李四访问最低频率的次数。所以他的名字叫 Count-Min Sketch。
2. 使用
Caffeine Cache 的 github 地址：
https://github.com/ben-manes/caffeine
目前的最新版本是：
<dependency>
<groupId>com.github.ben-manes.caffeine</groupId>
<artifactId>caffeine</artifactId>
<version>2.6.2</version>
</dependency>
2.1 缓存填充策略
Caffeine Cache 提供了三种缓存填充策略：手动、同步加载和异步加载。
1.手动加载
在每次 get key 的时候指定一个同步的函数，如果 key 不存在就调用这个函数生成一个值。
/**
*?手动加载
*?@param?key
*?@return
*/
public?Object?manulOperator(String?key)?{
Cache<String,?Object>?cache?=?Caffeine.newBuilder()
.expireAfterWrite(1,?TimeUnit.SECONDS)
.expireAfterAccess(1,?TimeUnit.SECONDS)
.maximumSize(10)
.build();
//如果一个 key 不存在，那么会进入指定的函数生成 value
Object?value?=?cache.get(key,?t?->?setValue(key).apply(key));
cache.put("hello",value);
//判断是否存在如果不存返回 null
Object?ifPresent?=?cache.getIfPresent(key);
//移除一个 key
cache.invalidate(key);
return?value;
}
public?Function<String,?Object>?setValue(String?key){
return?t?->?key?+?"value";
}
2. 同步加载
构造 Cache 时候，build 方法传入一个 CacheLoader 实现类。实现 load 方法，通过 key 加载 value。
/**
*?同步加载
*?@param?key
*?@return
*/
public?Object?syncOperator(String?key){
LoadingCache<String,?Object>?cache?=?Caffeine.newBuilder()
.maximumSize(100)
.expireAfterWrite(1,?TimeUnit.MINUTES)
.build(k?->?setValue(key).apply(key));
return?cache.get(key);
}
public?Function<String,?Object>?setValue(String?key){
return?t?->?key?+?"value";
}
3. 异步加载
AsyncLoadingCache 是继承自 LoadingCache 类的，异步加载使用 Executor 去调用方法并返回一个 CompletableFuture。异步加载缓存使用了响应式编程模型。
如果要以同步方式调用时，应提供 CacheLoader。要以异步表示时，应该提供一个 AsyncCacheLoader，并
返回一个 CompletableFuture。
/**
*?异步加载
*?@param?key
*?@return
*/
public?Object?asyncOperator(String?key){
AsyncLoadingCache<String,?Object>?cache?=?Caffeine.newBuilder()
.maximumSize(100)
.expireAfterWrite(1,?TimeUnit.MINUTES)
.buildAsync(k?->?setAsyncValue(key).get());
return?cache.get(key);
}
public?CompletableFuture<Object>?setAsyncValue(String?key){
return?CompletableFuture.supplyAsync(()?->?{
return?key?+?"value";
});
}
2.2 回收策略
Caffeine 提供了 3 种回收策略：基于大小回收，基于时间回收，基于引用回收。
1. 基于大小的过期方式
基于大小的回收策略有两种方式：一种是基于缓存大小，一种是基于权重。
//?根据缓存的计数进行驱逐
LoadingCache<String,?Object>?cache?=?Caffeine.newBuilder()
.maximumSize(10000)
.build(key?->?function(key));
//?根据缓存的权重来进行驱逐（权重只是用于确定缓存大小，不会用于决定该缓存是否被驱逐）
LoadingCache<String,?Object>?cache1?=?Caffeine.newBuilder()
.maximumWeight(10000)
.weigher(key?->?function1(key))
.build(key?->?function(key));
maximumWeight 与 maximumSize 不可以同时使用。
2.基于时间的过期方式
//?基于固定的到期策略进行退出
LoadingCache<String,?Object>?cache?=?Caffeine.newBuilder()
.expireAfterAccess(5,?TimeUnit.MINUTES)
.build(key?->?function(key));
LoadingCache<String,?Object>?cache1?=?Caffeine.newBuilder()
.expireAfterWrite(10,?TimeUnit.MINUTES)
.build(key?->?function(key));
//?基于不同的到期策略进行退出
LoadingCache<String,?Object>?cache2?=?Caffeine.newBuilder()
.expireAfter(new?Expiry<String,?Object>()?{
@Override
public?long?expireAfterCreate(String?key,?Object?value,?long?currentTime)?{
return?TimeUnit.SECONDS.toNanos(seconds);
}
@Override
public?long?expireAfterUpdate(@Nonnull?String?s,?@Nonnull?Object?o,?long?l,?long?l1)?{
return?0;
}
@Override
public?long?expireAfterRead(@Nonnull?String?s,?@Nonnull?Object?o,?long?l,?long?l1)?{
return?0;
}
}).build(key?->?function(key));
Caffeine 提供了三种定时驱逐策略：
expireAfterAccess(long, TimeUnit):在最后一次访问或者写入后开始计时，在指定的时间后过期。假如一直有请求访问该 key，那么这个缓存将一直不会过期。
expireAfterWrite(long, TimeUnit): 在最后一次写入缓存后开始计时，在指定的时间后过期。
expireAfter(Expiry): 自定义策略，过期时间由 Expiry 实现独自计算。
缓存的删除策略使用的是惰性删除和定时删除。这两个删除策略的时间复杂度都是 O(1)。
3. 基于引用的过期方式
Java 中四种引用类型
//?当 key 和 value 都没有引用时驱逐缓存
LoadingCache<String,?Object>?cache?=?Caffeine.newBuilder()
.weakKeys()
.weakValues()
.build(key?->?function(key));
//?当垃圾收集器需要释放内存时驱逐
LoadingCache<String,?Object>?cache1?=?Caffeine.newBuilder()
.softValues()
.build(key?->?function(key));
注意：AsyncLoadingCache 不支持弱引用和软引用。
Caffeine.weakKeys()：使用弱引用存储 key。如果没有其他地方对该 key 有强引用，那么该缓存就会被垃圾回收器回收。由于垃圾回收器只依赖于身份(identity)相等，因此这会导致整个缓存使用身份 (==) 相等来比较 key，而不是使用 equals()。
Caffeine.weakValues() ：使用弱引用存储 value。如果没有其他地方对该 value 有强引用，那么该缓存就会被垃圾回收器回收。由于垃圾回收器只依赖于身份(identity)相等，因此这会导致整个缓存使用身份 (==) 相等来比较 key，而不是使用 equals()。
Caffeine.softValues() ：使用软引用存储 value。当内存满了过后，软引用的对象以将使用最近最少使用(least-recently-used ) 的方式进行垃圾回收。由于使用软引用是需要等到内存满了才进行回收，所以我们通常建议给缓存配置一个使用内存的最大值。softValues() 将使用身份相等(identity) (==) 而不是 equals() 来比较值。
Caffeine.weakValues()和 Caffeine.softValues()不可以一起使用。
3. 移除事件监听
Cache<String,?Object>?cache?=?Caffeine.newBuilder()
.removalListener((String?key,?Object?value,?RemovalCause?cause)?->
System.out.printf("Key?%s?was?removed?(%s)%n",?key,?cause))
.build();
4. 写入外部存储
CacheWriter 方法可以将缓存中所有的数据写入到第三方。
LoadingCache<String,?Object>?cache2?=?Caffeine.newBuilder()
.writer(new?CacheWriter<String,?Object>()?{
@Override?public?void?write(String?key,?Object?value)?{
//?写入到外部存储
}
@Override?public?void?delete(String?key,?Object?value,?RemovalCause?cause)?{
//?删除外部存储
}
})
.build(key?->?function(key));
如果你有多级缓存的情况下，这个方法还是很实用。（搜索公众号 Java 知音，回复“2021”，送你一份 Java 面试题宝典）
注意：CacheWriter 不能与弱键或 AsyncLoadingCache 一起使用。
5. 统计 #
与 Guava Cache 的统计一样。
Cache<String,?Object>?cache?=?Caffeine.newBuilder()
.maximumSize(10_000)
.recordStats()
.build();
通过使用 Caffeine.recordStats(), 可以转化成一个统计的集合. 通过 Cache.stats() 返回一个 CacheStats。CacheStats 提供以下统计方法：
hitRate():?返回缓存命中率
evictionCount():?缓存回收数量
averageLoadPenalty():?加载新值的平均时间
3. SpringBoot 中默认 Cache-Caffine Cache
SpringBoot 1.x 版本中的默认本地 cache 是 Guava Cache。在 2.x（Spring Boot 2.0(spring 5)?）版本中已经用 Caffine Cache 取代了 Guava Cache。毕竟有了更优的缓存淘汰策略。
下面我们来说在 SpringBoot2.x 版本中如何使用 cache。
1. 引入依赖：
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-cache</artifactId>
</dependency>
<dependency>
<groupId>com.github.ben-manes.caffeine</groupId>
<artifactId>caffeine</artifactId>
<version>2.6.2</version>
</dependency>
2. 添加注解开启缓存支持
添加 @EnableCaching 注解：
@SpringBootApplication
@EnableCaching
public?class?SingleDatabaseApplication?{
public?static?void?main(String[]?args)?{
SpringApplication.run(SingleDatabaseApplication.class,?args);
}
}
3. 配置文件的方式注入相关参数
properties 文件
spring.cache.cache-names=cache1
spring.cache.caffeine.spec=initialCapacity=50,maximumSize=500,expireAfterWrite=10s
或 Yaml 文件
spring:
cache:
type:?caffeine
cache-names:
-?userCache
caffeine:
spec:?maximumSize=1024,refreshAfterWrite=60s
如果使用 refreshAfterWrite 配置,必须指定一个 CacheLoader.不用该配置则无需这个 bean,如上所述,该 CacheLoader 将关联被该缓存管理器管理的所有缓存，所以必须定义为CacheLoader<Object, Object>，自动配置将忽略所有泛型类型。
import?com.github.benmanes.caffeine.cache.CacheLoader;
import?org.springframework.context.annotation.Bean;
import?org.springframework.context.annotation.Configuration;
/**
*?@author:?rickiyang
*?@description:
*/
@Configuration
public?class?CacheConfig?{
/**
*?相当于在构建 LoadingCache 对象的时候?build()方法中指定过期之后的加载策略方法
*?必须要指定这个 Bean，refreshAfterWrite=60s 属性才生效
*?@return
*/
@Bean
public?CacheLoader<String,?Object>?cacheLoader()?{
CacheLoader<String,?Object>?cacheLoader?=?new?CacheLoader<String,?Object>()?{
@Override
public?Object?load(String?key)?throws?Exception?{
return?null;
}
//?重写这个方法将 oldValue 值返回回去，进而刷新缓存
@Override
public?Object?reload(String?key,?Object?oldValue)?throws?Exception?{
return?oldValue;
}
};
return?cacheLoader;
}
}
Caffeine 常用配置说明：
initialCapacity=[integer]: 初始的缓存空间大小maximumSize=[long]: 缓存的最大条数maximumWeight=[long]: 缓存的最大权重expireAfterAccess=[duration]: 最后一次写入或访问后经过固定时间过期expireAfterWrite=[duration]: 最后一次写入后经过固定时间过期refreshAfterWrite=[duration]: 创建缓存或者最近一次更新缓存后经过固定的时间间隔，刷新缓存weakKeys: 打开 key 的弱引用weakValues：打开 value 的弱引用softValues：打开 value 的软引用recordStats：开发统计功能
注意：
expireAfterWrite 和 expireAfterAccess 同时存在时，以 expireAfterWrite 为准。
maximumSize 和 maximumWeight 不可以同时使用
weakValues 和 softValues 不可以同时使用
需要说明的是，使用配置文件的方式来进行缓存项配置，一般情况能满足使用需求，但是灵活性不是很高，如果我们有很多缓存项的情况下写起来会导致配置文件很长。所以一般情况下你也可以选择使用 bean 的方式来初始化 Cache 实例。（搜索公众号 Java 知音，回复“2021”，送你一份 Java 面试题宝典）
下面的演示使用 bean 的方式来注入：
package?com.rickiyang.learn.cache;
import?com.github.benmanes.caffeine.cache.CacheLoader;
import?com.github.benmanes.caffeine.cache.Caffeine;
import?org.apache.commons.compress.utils.Lists;
import?org.springframework.cache.CacheManager;
import?org.springframework.cache.caffeine.CaffeineCache;
import?org.springframework.cache.support.SimpleCacheManager;
import?org.springframework.context.annotation.Bean;
import?org.springframework.context.annotation.Configuration;
import?org.springframework.context.annotation.Primary;
import?java.util.ArrayList;
import?java.util.List;
import?java.util.concurrent.TimeUnit;
/**
*?@author:?rickiyang
*?@description:
*/
@Configuration
public?class?CacheConfig?{
/**
*?创建基于 Caffeine 的 Cache?Manager
*?初始化一些 key 存入
*?@return
*/
@Bean
@Primary
public?CacheManager?caffeineCacheManager()?{
SimpleCacheManager?cacheManager?=?new?SimpleCacheManager();
ArrayList<CaffeineCache>?caches?=?Lists.newArrayList();
List<CacheBean>?list?=?setCacheBean();
for(CacheBean?cacheBean?:?list){
caches.add(new?CaffeineCache(cacheBean.getKey(),
Caffeine.newBuilder().recordStats()
.expireAfterWrite(cacheBean.getTtl(),?TimeUnit.SECONDS)
.maximumSize(cacheBean.getMaximumSize())
.build()));
}
cacheManager.setCaches(caches);
return?cacheManager;
}
/**
*?初始化一些缓存的?key
*?@return
*/
private?List<CacheBean>?setCacheBean(){
List<CacheBean>?list?=?Lists.newArrayList();
CacheBean?userCache?=?new?CacheBean();
userCache.setKey("userCache");
userCache.setTtl(60);
userCache.setMaximumSize(10000);
CacheBean?deptCache?=?new?CacheBean();
deptCache.setKey("userCache");
deptCache.setTtl(60);
deptCache.setMaximumSize(10000);
list.add(userCache);
list.add(deptCache);
评论