本地缓存Caffeine
文章目录
介绍
Caffeine 是基于Java 1.8 的高性能本地缓存库，由 Guava 改进而来，而且在 Spring5 开始的默认缓存实现就将 Caffeine 代替原来的Google Guava，官方说明指出，其缓存命中率已经接近最优值。
实际上Caffeine这样的本地缓存和 ConcurrentMap 很像，即支持并发，并且支持O(1)时间复杂度的数据存取。二者的主要区别在于：
- ConcurrentMap 将存储所有存入的数据，直到你显式将其移除
- Caffeine将通过给定的配置，自动移除“不常用”的数据，以保持内存的合理占用。
因此，一种更好的理解方式是：Cache是一种带有存储和移除策略的Map。
Caffeine 基础
使用Caffeine，需要在工程中引入如下依赖
1<dependency>
2 <groupId>com.github.ben-manes.caffeine</groupId>
3 <artifactId>caffeine</artifactId>
4 <!--https://mvnrepository.com/artifact/com.github.ben-manes.caffeine/caffeinez找最新版-->
5 <version>3.0.5</version>
6</dependency>
1. 缓存加载策略
1.1 Cache手动创建
最普通的一种缓存，无需指定加载方式，需要手动调用 put()进行加载。需要注意的是 put() 方法对于已存在的 key 将进行覆盖，这点和 Map 的表现是一致的。
在获取缓存值时，如果想要在缓存值不存在时，原子地将值写入缓存，则可以调用 get(key, k -> value) 方法，该方法将避免写入竞争。在多线程情况下，当使用 get(key, k -> value) 时，如果有另一个线程同时调用本方法进行竞争，则后一线程会被阻塞，直到前一线程更新缓存完成；而若另一线程调用getIfPresent()方法，则会立即返回null，不会被阻塞。
调用 invalidate() 方法，将手动移除缓存。
1Cache<Object, Object> cache = Caffeine.newBuilder()
2 //初始数量
3 .initialCapacity(10)
4 //最大条数
5 .maximumSize(10)
6 //expireAfterWrite 和 expireAfterAccess同时存在时，以 expireAfterWrite 为准
7 //最后一次写操作后经过指定时间过期
8 .expireAfterWrite(1, TimeUnit.SECONDS)
9 //最后一次读或写操作后经过指定时间过期
10 .expireAfterAccess(1, TimeUnit.SECONDS)
11 //监听缓存被移除
12 .removalListener((key, val, removalCause) -> { })
13 //记录命中
14 .recordStats()
15 .build();
16
17cache.put("1","张三");
18//张三
19System.out.println(cache.getIfPresent("1"));
20//存储的是默认值
21System.out.println(cache.get("2", o -> "默认值"));
1/**
2 * 手动加载
3 * @param key
4 * @return
5 */
6public Object manulOperator(String key) {
7 Cache<String, Object> cache = Caffeine.newBuilder()
8 .expireAfterWrite(1, TimeUnit.SECONDS)
9 .expireAfterAccess(1, TimeUnit.SECONDS)
10 .maximumSize(10)
11 .build();
12 //如果一个key不存在，那么会进入指定的函数生成value
13 Object value = cache.get(key, t -> setValue(key).apply(key));
14 cache.put("hello",value);
15
16 //判断是否存在如果不存返回null
17 Object ifPresent = cache.getIfPresent(key);
18 //移除一个key
19 cache.invalidate(key);
20 return value;
21}
22
23public Function<String, Object> setValue(String key){
24 return t -> key + "value";
25}
1.2 Loading Cache自动创建
LoadingCache 是一种自动加载的缓存。其和普通缓存不同的地方在于，当缓存不存在/缓存已过期时，若调用 get() 方法，则会自动调用 CacheLoader.load() 方法加载最新值。调用getAll() 方法将遍历所有的 key 调用 get()，除非实现了 CacheLoader.loadAll() 方法。
使用 LoadingCache 时，需要指定 CacheLoader ，并实现其中的 load() 方法供缓存缺失时自动加载。
在多线程情况下，当两个线程同时调用 get()，则后一线程将被阻塞，直至前一线程更新缓存完成。
1LoadingCache<String, String> loadingCache = Caffeine.newBuilder()
2 //创建缓存或者最近一次更新缓存后经过指定时间间隔，刷新缓存；refreshAfterWrite 仅支持 LoadingCache
3 .refreshAfterWrite(10, TimeUnit.SECONDS)
4 .expireAfterWrite(10, TimeUnit.SECONDS)
5 .expireAfterAccess(10, TimeUnit.SECONDS)
6 .maximumSize(10)
7 //根据key查询数据库里面的值，这里是个lamba表达式
8 .build(key -> new Date().toString());
1/**
2 * 同步加载
3 * @param key
4 * @return
5 */
6public Object syncOperator(String key){
7 LoadingCache<String, Object> cache = Caffeine.newBuilder()
8 .maximumSize(100)
9 .expireAfterWrite(1, TimeUnit.MINUTES)
10 .build(k -> setValue(key).apply(key));
11 return cache.get(key);
12}
13
14public Function<String, Object> setValue(String key){
15 return t -> key + "value";
16}
1.3 Async Cache异步获取
AsyncCache 是 Cache 的一个变体，其响应结果均为 CompletableFuture，通过这种方式，AsyncCache 对异步编程模式进行了适配。
默认情况下，缓存计算使用 ForkJoinPool.commonPool() 作为线程池，如果想要指定线程池，则可以覆盖并实现 Caffeine.executor(Executor) 方法。
synchronous() 提供了阻塞直到异步缓存生成完毕的能力，它将以Cache进行返回。
在多线程情况下，当两个线程同时调用 get(key, k -> value)，则会返回同一个 CompletableFuture 对象。由于返回结果本身不进行阻塞，可以根据业务设计自行选择阻塞等待或者非阻塞。
1AsyncLoadingCache<String, String> asyncLoadingCache = Caffeine.newBuilder()
2 //创建缓存或者最近一次更新缓存后经过指定时间间隔刷新缓存；仅支持LoadingCache
3 .refreshAfterWrite(1, TimeUnit.SECONDS)
4 .expireAfterWrite(1, TimeUnit.SECONDS)
5 .expireAfterAccess(1, TimeUnit.SECONDS)
6 .maximumSize(10)
7 //根据key查询数据库里面的值
8 .buildAsync(key -> {
9 Thread.sleep(1000);
10 return new Date().toString();
11 });
12
13//异步缓存返回的是CompletableFuture
14CompletableFuture<String> future = asyncLoadingCache.get("1");
15future.thenAccept(System.out::println);
1/**
2 * 异步加载
3 *
4 * @param key
5 * @return
6 */
7public Object asyncOperator(String key){
8 AsyncLoadingCache<String, Object> cache = Caffeine.newBuilder()
9 .maximumSize(100)
10 .expireAfterWrite(1, TimeUnit.MINUTES)
11 .buildAsync(k -> setAsyncValue(key).get());
12
13 return cache.get(key);
14}
15
16public CompletableFuture<Object> setAsyncValue(String key){
17 return CompletableFuture.supplyAsync(() -> {
18 return key + "value";
19 });
20}
2. 驱逐策略
驱逐策略(回收策略)在创建缓存的时候进行指定。
常用的有基于容量的驱逐和基于时间的驱逐。
- 基于容量的驱逐需要指定缓存容量的最大值，当缓存容量达到最大时，Caffeine将使用LRU策略对缓存进行淘汰；
- 基于时间的驱逐策略如字面意思，可以设置在最后访问/写入一个缓存经过指定时间后，自动进行淘汰。
驱逐策略可以组合使用，任意驱逐策略生效后，该缓存条目即被驱逐。
- FIFO：先进先出
- LRU：最近最少使用，淘汰最长时间没有被使用的条目
- LFU：最不经常使用，淘汰一段时间内使用次数最少的条目
Caffeine有4种缓存淘汰设置:
- 大小 （LFU算法进行淘汰）
- 权重 （大小与权重 只能二选一）
- 时间
- 引用 （不常用，本文不介绍）
2.1 基于大小的过期
1Cache<Integer, Integer> cache = Caffeine.newBuilder()
2 //超过10个后会使用W-TinyLFU算法进行淘汰
3 .maximumSize(10)
4 .evictionListener((key, val, removalCause) -> {
5 log.info("淘汰缓存：key:{} val:{}", key, val);
6 })
7 .build();
8
9for (int i = 1; i < 20; i++) {
10 cache.put(i, i);
11}
12Thread.sleep(500);//缓存淘汰是异步的
13
14// 打印还没被淘汰的缓存
15System.out.println(cache.asMap());
1// 根据缓存的计数进行驱逐
2LoadingCache<String, Object> cache = Caffeine.newBuilder()
3 .maximumSize(10000)
4 .build(key -> function(key));
2.2 基于权重的过期
maximumWeight与maximumSize不可以同时使用
1Cache<Integer, Integer> cache = Caffeine.newBuilder()
2 //限制总权重，若所有缓存的权重加起来>总权重就会淘汰权重小的缓存
3 .maximumWeight(100)
4 .weigher((Weigher<Integer, Integer>) (key, value) -> key)
5 .evictionListener((key, val, removalCause) -> {
6 log.info("淘汰缓存：key:{} val:{}", key, val);
7 })
8 .build();
9
10//总权重其实是=所有缓存的权重加起来
11int maximumWeight = 0;
12for (int i = 1; i < 20; i++) {
13 cache.put(i, i);
14 maximumWeight += i;
15}
16System.out.println("总权重=" + maximumWeight);
17Thread.sleep(500);//缓存淘汰是异步的
18
19// 打印还没被淘汰的缓存
20System.out.println(cache.asMap());
1// 根据缓存的权重来进行驱逐（权重只是用于确定缓存大小，不会用于决定该缓存是否被驱逐）
2LoadingCache<String, Object> cache1 = Caffeine.newBuilder()
3 .maximumWeight(10000)
4 .weigher(key -> function1(key))
5 .build(key -> function(key));
2.3 基于时间的过期
1/**
2 * 访问后到期（每次访问都会重置时间，也就是说如果一直被访问就不会被淘汰）
3 */
4@Test
5public void expireAfterAccessTest() throws InterruptedException {
6 Cache<Integer, Integer> cache = Caffeine.newBuilder()
7 .expireAfterAccess(1, TimeUnit.SECONDS)
8 //可以指定调度程序来及时删除过期缓存项，而不是等待Caffeine触发定期维护
9 //若不设置scheduler，则缓存会在下一次调用get的时候才会被动删除
10 .scheduler(Scheduler.systemScheduler())
11 .evictionListener((key, val, removalCause) -> {
12 log.info("淘汰缓存：key:{} val:{}", key, val);
13 })
14 .build();
15 cache.put(1, 2);
16 System.out.println(cache.getIfPresent(1));
17 Thread.sleep(3000);
18 System.out.println(cache.getIfPresent(1));//null
19}
20
21
22/**
23 * 写入后到期
24 */
25@Test
26public void expireAfterWriteTest() throws InterruptedException {
27 Cache<Integer, Integer> cache = Caffeine.newBuilder()
28 .expireAfterWrite(1, TimeUnit.SECONDS)
29 //可以指定调度程序来及时删除过期缓存项，而不是等待Caffeine触发定期维护
30 //若不设置scheduler，则缓存会在下一次调用get的时候才会被动删除
31 .scheduler(Scheduler.systemScheduler())
32 .evictionListener((key, val, removalCause) -> {
33 log.info("淘汰缓存：key:{} val:{}", key, val);
34 })
35 .build();
36 cache.put(1, 2);
37 Thread.sleep(3000);
38 System.out.println(cache.getIfPresent(1));//null
39}
1// 基于固定的到期策略进行退出
2LoadingCache<String, Object> cache = Caffeine.newBuilder()
3 .expireAfterAccess(5, TimeUnit.MINUTES)
4 .build(key -> function(key));
5LoadingCache<String, Object> cache1 = Caffeine.newBuilder()
6 .expireAfterWrite(10, TimeUnit.MINUTES)
7 .build(key -> function(key));
8
9// 基于不同的到期策略进行退出
10LoadingCache<String, Object> cache2 = Caffeine.newBuilder()
11 .expireAfter(new Expiry<String, Object>() {
12 @Override
13 public long expireAfterCreate(String key, Object value, long currentTime) {
14 return TimeUnit.SECONDS.toNanos(seconds);
15 }
16
17 @Override
18 public long expireAfterUpdate(@Nonnull String s, @Nonnull Object o, long l, long l1) {
19 return 0;
20 }
21
22 @Override
23 public long expireAfterRead(@Nonnull String s, @Nonnull Object o, long l, long l1) {
24 return 0;
25 }
26 }).build(key -> function(key));
Caffeine提供了三种定时驱逐策略:
- expireAfterAccess(long, TimeUnit):在最后一次访问或者写入后开始计时，在指定的时间后过期。假如一直有请求访问该key，那么这个缓存将一直不会过期。
- expireAfterWrite(long, TimeUnit): 在最后一次写入缓存后开始计时，在指定的时间后过期。
- expireAfter(Expiry): 自定义策略，过期时间由Expiry实现独自计算。
缓存的删除策略使用的是惰性删除和定时删除。这两个删除策略的时间复杂度都是o(1)。
3. 刷新机制
refreshAfterWrite() 表示x秒后自动刷新缓存的策略可以配合淘汰策略使用，注意的是刷新机制只支持 LoadingCache 和 AsyncLoadingCache
1private static int NUM = 0;
2
3@Test
4public void refreshAfterWriteTest() throws InterruptedException {
5 LoadingCache<Integer, Integer> cache = Caffeine.newBuilder()
6 .refreshAfterWrite(1, TimeUnit.SECONDS)
7 //模拟获取数据，每次获取就自增1
8 .build(integer -> ++NUM);
9
10 //获取ID=1的值，由于缓存里还没有，所以会自动放入缓存
11 System.out.println(cache.get(1));// 1
12
13 // 延迟2秒后，理论上自动刷新缓存后取到的值是2
14 // 但其实不是，值还是1，因为refreshAfterWrite并不是设置了n秒后重新获取就会自动刷新
15 // 而是x秒后&&第二次调用getIfPresent的时候才会被动刷新
16 Thread.sleep(2000);
17 System.out.println(cache.getIfPresent(1));// 1
18
19 //此时才会刷新缓存，而第一次拿到的还是旧值
20 System.out.println(cache.getIfPresent(1));// 2
21}
4. 移除事件监听
1Cache<String, Object> cache = Caffeine.newBuilder()
2 .removalListener((String key, Object value, RemovalCause cause) ->
3 System.out.printf("Key %s was removed (%s)%n", key, cause))
4 .build();
5. 写入外部存储
CacheWriter 方法可以将缓存中所有的数据写入到第三方。
1LoadingCache<String, Object> cache2 = Caffeine.newBuilder()
2 .writer(new CacheWriter<String, Object>() {
3 @Override public void write(String key, Object value) {
4 // 写入到外部存储
5 }
6 @Override public void delete(String key, Object value, RemovalCause cause) {
7 // 删除外部存储
8 }
9 })
10 .build(key -> function(key));
如果你有多级缓存的情况下，这个方法还是很实用。注意：CacheWriter不能与弱键或AsyncLoadingCache一起使用。
6. 统计
1LoadingCache<String, String> cache = Caffeine.newBuilder()
2 //创建缓存或者最近一次更新缓存后经过指定时间间隔，刷新缓存；refreshAfterWrite仅支持LoadingCache
3 .refreshAfterWrite(1, TimeUnit.SECONDS)
4 .expireAfterWrite(1, TimeUnit.SECONDS)
5 .expireAfterAccess(1, TimeUnit.SECONDS)
6 .maximumSize(10)
7 //开启记录缓存命中率等信息
8 .recordStats()
9 //根据key查询数据库里面的值
10 .build(key -> {
11 Thread.sleep(1000);
12 return new Date().toString();
13 });
14
15
16cache.put("1", "shawn");
17cache.get("1");
18
19/*
20 * hitCount :命中的次数
21 * missCount:未命中次数
22 * requestCount:请求次数
23 * hitRate:命中率
24 * missRate:丢失率
25 * loadSuccessCount:成功加载新值的次数
26 * loadExceptionCount:失败加载新值的次数
27 * totalLoadCount:总条数
28 * loadExceptionRate:失败加载新值的比率
29 * totalLoadTime:全部加载时间
30 * evictionCount:丢失的条数
31 */
32System.out.println(cache.stats());
5. 总结
上述一些策略在创建时都可以进行自由组合，一般情况下有两种方法
- 设置 maxSize、refreshAfterWrite，不设置 expireAfterWrite/expireAfterAccess。设置 expireAfterWrite 当缓存过期时会同步加锁获取缓存，所以设置 expireAfterWrite 时性能较好，但是某些时候会取旧数据，适合允许取到旧数据的场景
- 设置 maxSize、expireAfterWrite/expireAfterAccess，不设置 refreshAfterWrite。数据一致性好，不会获取到旧数据，但是性能没那么好（对比起来），适合获取数据时不耗时的场景
SpringBoot整合Caffeine
1. 相关注解
1.1 相关依赖
如果要使用@Cacheable注解，需要引入相关依赖，并在任一配置类文件上添加@EnableCaching注解
1<dependency>
2 <groupId>org.springframework.boot</groupId>
3 <artifactId>spring-boot-starter-cache</artifactId>
4</dependency>
1.2 常用注解
- @Cacheable ：表示该方法支持缓存。当调用被注解的方法时，如果对应的键已经存在缓存，则不再执行方法体，而从缓存中直接返回。当方法返回null时，将不进行缓存操作。
- @CachePut ：表示执行该方法后，其值将作为最新结果更新到缓存中，每次都会执行该方法。
- @CacheEvict ：表示执行该方法后，将触发缓存清除操作。
- @Caching ：用于组合前三个注解，例如
1@Caching(cacheable = @Cacheable("CacheConstants.GET_USER"),
2 evict = {@CacheEvict("CacheConstants.GET_DYNAMIC",allEntries = true)}
3public User find(Integer id) {
4 return null;
5}
1.3 常用注解属性
- cacheNames/value ：缓存组件的名字，即cacheManager中缓存的名称。
- key ：缓存数据时使用的key。默认使用方法参数值，也可以使用SpEL表达式进行编写。
- keyGenerator ：和key二选一使用。
- cacheManager ：指定使用的缓存管理器。
- condition ：在方法执行开始前检查，在符合condition的情况下，进行缓存
- unless ：在方法执行完成后检查，在符合unless的情况下，不进行缓存
- sync ：是否使用同步模式。若使用同步模式，在多个线程同时对一个key进行load时，其他线程将被阻塞。
1.4 缓存同步模式
sync 开启或关闭，在 Cache 和 LoadingCache 中的表现是不一致的：
- Cache中，sync表示是否需要所有线程同步等待
- LoadingCache中，sync表示在读取不存在/已驱逐的key时，是否执行被注解方法
2. 实战
2.1 引入依赖
1<dependency>
2 <groupId>org.springframework.boot</groupId>
3 <artifactId>spring-boot-starter-cache</artifactId>
4</dependency>
5
6<dependency>
7 <groupId>com.github.ben-manes.caffeine</groupId>
8 <artifactId>caffeine</artifactId>
9</dependency>
2.2 添加注解开启缓存支持
添加@EnableCaching注解：
1@SpringBootApplication
2@EnableCaching
3public class SingleDatabaseApplication {
4
5 public static void main(String[] args) {
6 SpringApplication.run(SingleDatabaseApplication.class, args);
7 }
8}
2.3 配置文件的方式注入相关参数
properties文件
1spring.cache.cache-names=cache1
2spring.cache.caffeine.spec=initialCapacity=50,maximumSize=500,expireAfterWrite=10s
或Yaml文件
1spring:
2 cache:
3 type: caffeine
4 cache-names:
5 - userCache
6 caffeine:
7 spec: maximumSize=1024,refreshAfterWrite=60s
如果使用refreshAfterWrite配置,必须指定一个CacheLoader.不用该配置则无需这个bean,如上所述,该CacheLoader将关联被该缓存管理器管理的所有缓存，所以必须定义为CacheLoader<Object, Object>，自动配置将忽略所有泛型类型。
1import com.github.benmanes.caffeine.cache.CacheLoader;
2import org.springframework.context.annotation.Bean;
3import org.springframework.context.annotation.Configuration;
4
5/**
6 * @author: rickiyang
7 * @date: 2019/6/15
8 * @description:
9 */
10@Configuration
11public class CacheConfig {
12
13 /**
14 * 相当于在构建LoadingCache对象的时候 build()方法中指定过期之后的加载策略方法
15 * 必须要指定这个Bean，refreshAfterWrite=60s属性才生效
16 * @return
17 */
18 @Bean
19 public CacheLoader<String, Object> cacheLoader() {
20 CacheLoader<String, Object> cacheLoader = new CacheLoader<String, Object>() {
21 @Override
22 public Object load(String key) throws Exception {
23 return null;
24 }
25 // 重写这个方法将oldValue值返回回去，进而刷新缓存
26 @Override
27 public Object reload(String key, Object oldValue) throws Exception {
28 return oldValue;
29 }
30 };
31 return cacheLoader;
32 }
33}
Caffeine常用配置说明：
1initialCapacity=[integer]: 初始的缓存空间大小
2
3maximumSize=[long]: 缓存的最大条数
4
5maximumWeight=[long]: 缓存的最大权重
6
7expireAfterAccess=[duration]: 最后一次写入或访问后经过固定时间过期
8
9expireAfterWrite=[duration]: 最后一次写入后经过固定时间过期
10
11refreshAfterWrite=[duration]: 创建缓存或者最近一次更新缓存后经过固定的时间间隔，刷新缓存
12
13weakKeys: 打开key的弱引用
14
15weakValues：打开value的弱引用
16
17softValues：打开value的软引用
18
19recordStats：开发统计功能
20
21注意：
22
23expireAfterWrite和expireAfterAccess同时存在时，以expireAfterWrite为准。
24
25maximumSize和maximumWeight不可以同时使用
26
27weakValues和softValues不可以同时使用
需要说明的是，使用配置文件的方式来进行缓存项配置，一般情况能满足使用需求，但是灵活性不是很高，如果我们有很多缓存项的情况下写起来会导致配置文件很长。所以一般情况下你也可以选择使用bean的方式来初始化Cache实例。
下面的演示使用bean的方式来注入：
1package com.rickiyang.learn.cache;
2
3import com.github.benmanes.caffeine.cache.CacheLoader;
4import com.github.benmanes.caffeine.cache.Caffeine;
5import org.apache.commons.compress.utils.Lists;
6import org.springframework.cache.CacheManager;
7import org.springframework.cache.caffeine.CaffeineCache;
8import org.springframework.cache.support.SimpleCacheManager;
9import org.springframework.context.annotation.Bean;
10import org.springframework.context.annotation.Configuration;
11import org.springframework.context.annotation.Primary;
12
13import java.util.ArrayList;
14import java.util.List;
15import java.util.concurrent.TimeUnit;
16
17/**
18 * @author: rickiyang
19 * @date: 2019/6/15
20 * @description:
21 */
22@Configuration
23public class CacheConfig {
24
25
26 /**
27 * 创建基于Caffeine的Cache Manager
28 * 初始化一些key存入
29 * @return
30 */
31 @Bean
32 @Primary
33 public CacheManager caffeineCacheManager() {
34 SimpleCacheManager cacheManager = new SimpleCacheManager();
35 ArrayList<CaffeineCache> caches = Lists.newArrayList();
36 List<CacheBean> list = setCacheBean();
37 for(CacheBean cacheBean : list){
38 caches.add(new CaffeineCache(cacheBean.getKey(),
39 Caffeine.newBuilder().recordStats()
40 .expireAfterWrite(cacheBean.getTtl(), TimeUnit.SECONDS)
41 .maximumSize(cacheBean.getMaximumSize())
42 .build()));
43 }
44 cacheManager.setCaches(caches);
45 return cacheManager;
46 }
47
48
49 /**
50 * 初始化一些缓存的 key
51 * @return
52 */
53 private List<CacheBean> setCacheBean(){
54 List<CacheBean> list = Lists.newArrayList();
55 CacheBean userCache = new CacheBean();
56 userCache.setKey("userCache");
57 userCache.setTtl(60);
58 userCache.setMaximumSize(10000);
59
60 CacheBean deptCache = new CacheBean();
61 deptCache.setKey("userCache");
62 deptCache.setTtl(60);
63 deptCache.setMaximumSize(10000);
64
65 list.add(userCache);
66 list.add(deptCache);
67
68 return list;
69 }
70
71 class CacheBean {
72 private String key;
73 private long ttl;
74 private long maximumSize;
75
76 public String getKey() {
77 return key;
78 }
79
80 public void setKey(String key) {
81 this.key = key;
82 }
83
84 public long getTtl() {
85 return ttl;
86 }
87
88 public void setTtl(long ttl) {
89 this.ttl = ttl;
90 }
91
92 public long getMaximumSize() {
93 return maximumSize;
94 }
95
96 public void setMaximumSize(long maximumSize) {
97 this.maximumSize = maximumSize;
98 }
99 }
100
101}
创建了一个SimpleCacheManager作为Cache的管理对象，然后初始化了两个Cache对象，分别存储user，dept类型的缓存。当然构建Cache的参数设置我写的比较简单，你在使用的时候酌情根据需要配置参数。
2.4 使用注解来对 cache 增删改查
我们可以使用spring提供的 @Cacheable、@CachePut、@CacheEvict等注解来方便的使用caffeine缓存。
如果使用了多个cahce，比如redis、caffeine等，必须指定某一个CacheManage为@primary，在@Cacheable注解中没指定 cacheManager 则使用标记为primary的那个。
cache方面的注解主要有以下5个：
- @Cacheable 触发缓存入口（这里一般放在创建和获取的方法上，
- @Cacheable注解会先查询是否已经有缓存，有会使用缓存，没有则会执行方法并缓存）
- @CacheEvict 触发缓存的eviction（用于删除的方法上）
- @CachePut 更新缓存且不影响方法执行（用于修改的方法上，该注解下的方法始终会被执行）
- @Caching 将多个缓存组合在一个方法上（该注解可以允许一个方法同时设置多个注解）
- @CacheConfig 在类级别设置一些缓存相关的共同配置（与其它缓存配合使用）
说一下@Cacheable 和 @CachePut的区别：
- @Cacheable：它的注解的方法是否被执行取决于Cacheable中的条件，方法很多时候都可能不被执行。
- @CachePut：这个注解不会影响方法的执行，也就是说无论它配置的条件是什么，方法都会被执行，更多的时候是被用到修改上。
简要说一下Cacheable类中各个方法的使用
1ublic @interface Cacheable {
2
3 /**
4 * 要使用的cache的名字
5 */
6 @AliasFor("cacheNames")
7 String[] value() default {};
8
9 /**
10 * 同value()，决定要使用那个/些缓存
11 */
12 @AliasFor("value")
13 String[] cacheNames() default {};
14
15 /**
16 * 使用SpEL表达式来设定缓存的key，如果不设置默认方法上所有参数都会作为key的一部分
17 */
18 String key() default "";
19
20 /**
21 * 用来生成key，与key()不可以共用
22 */
23 String keyGenerator() default "";
24
25 /**
26 * 设定要使用的cacheManager，必须先设置好cacheManager的bean，这是使用该bean的名字
27 */
28 String cacheManager() default "";
29
30 /**
31 * 使用cacheResolver来设定使用的缓存，用法同cacheManager，但是与cacheManager不可以同时使用
32 */
33 String cacheResolver() default "";
34
35 /**
36 * 使用SpEL表达式设定出发缓存的条件，在方法执行前生效
37 */
38 String condition() default "";
39
40 /**
41 * 使用SpEL设置出发缓存的条件，这里是方法执行完生效，所以条件中可以有方法执行后的value
42 */
43 String unless() default "";
44
45 /**
46 * 用于同步的，在缓存失效（过期不存在等各种原因）的时候，如果多个线程同时访问被标注的方法
47 * 则只允许一个线程通过去执行方法
48 */
49 boolean sync() default false;
50
51}
基于注解的使用方法：
1package com.rickiyang.learn.cache;
2
3import com.rickiyang.learn.entity.User;
4import org.springframework.cache.annotation.CacheEvict;
5import org.springframework.cache.annotation.CachePut;
6import org.springframework.cache.annotation.Cacheable;
7import org.springframework.stereotype.Service;
8
9/**
10 * @author: rickiyang
11 * @date: 2019/6/15
12 * @description: 本地cache
13 */
14@Service
15public class UserCacheService {
16
17
18 /**
19 * 查找
20 * 先查缓存，如果查不到，会查数据库并存入缓存
21 * @param id
22 */
23 @Cacheable(value = "userCache", key = "#id", sync = true)
24 public void getUser(long id){
25 //查找数据库
26 }
27
28 /**
29 * 更新/保存
30 * @param user
31 */
32 @CachePut(value = "userCache", key = "#user.id")
33 public void saveUser(User user){
34 //todo 保存数据库
35 }
36
37
38 /**
39 * 删除
40 * @param user
41 */
42 @CacheEvict(value = "userCache",key = "#user.id")
43 public void delUser(User user){
44 //todo 保存数据库
45 }
46}
如果你不想使用注解的方式去操作缓存，也可以直接使用SimpleCacheManager获取缓存的key进而进行操作。注意: 上面的key使用了spEL 表达式，这个可以查阅spring的官方文档。
Caffine Cache 在算法上的优点：W-TinyLFU
说到优化，Caffine Cache到底优化了什么呢？
常见的缓存淘汰算法还有FIFO，LRU，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。
参考链接：