Caffeine本地缓存框架
hi，我是阿昌，今天记录一下Java最强本地缓存Caffeine
1、缓存介绍
缓存(Cache)，在软件无处不在。从底层CPU多级缓存，再到客户页面缓存，和服务器数据缓存，导出都存在着缓存的身影；
从本质上讲，缓存是一种空间换时间的手段，一种计算完后，使下次进行访问数据，不再重复处理，节省时间整体的处理时间；
针对Java而言，对应的常用缓存解决方案有很多，例如数据库缓存框架EhCache，分布式缓存Memcached/redis等，这些缓存方案实际上都是为了提升服务吞吐效率，避免持久层压力过大。
对于常见缓存类型而言，可以分为本地缓存以及分布式缓存两种，Caffeine就是一种优秀的本地缓存，而Redis可以用来做分布式缓存；
2、Caffeine介绍
Caffeine，基于Java8开发的一个高性能java本地缓存，它由Guava改进而来，在Spring5开始的默认缓存实现就将Caffeine代替原来的Google Guava，官方也称缓存命中率已经接近最优值；
它类似java中的ConcurrentMap，即支持并发，并且支持O(1)时间复杂度的数据存取，但又不完全相同，缓存通常会设置缓存自动过期策略，以限制优化缓存对内存占用；
它与ConcurrentMap的主要区别在于：
- ConcurrentMap会保留所有添加到其中的元素，直到它们被明确删除。
- Caffeine将通过给定的配置，自动移除“不常用”的数据，以保持内存的合理占用，即缓存自动过期策略。
因此，一种更好的理解方式是：Caffeine是一种带有存储和移除策略的Map。
3、Caffeine基础
官方开发分档，以下基于maven包管理，使用Caffeine，需要在工程中引入如下依赖
<dependency><groupId>com.github.ben-manes.caffeine</groupId><artifactId>caffeine</artifactId><version>3.0.5</version>
</dependency>
a、添加
Caffeine提供了四种缓存添加策略：
- 手动加载
- 自动加载
- 手动异步加载
- 自动异步加载
手动加载
Cache<String, String> cache = Caffeine.newBuilder().expireAfterWrite(1, TimeUnit.MINUTES).maximumSize(10_000).build();// 查找一个缓存元素， 没有查找到的时候返回null
String value = cache.getIfPresent("key");
// 查找缓存，如果缓存不存在则生成缓存元素, 如果无法生成则返回null
value = cache.get("key", k -> "value");
// 添加或者更新一个缓存元素
cache.put("key", "value");
// 移除一个缓存元素
cache.invalidate("key");
最普通的一种缓存，无需指定加载方式，需要手动调用put()进行加载。**put()**方法对于已存在的key将进行覆盖，这点和Map的表现是一致的。
在获取缓存值时，如果想要在缓存值不存在时，原子地将值写入缓存，则可以调用get(“key”, k -> “value”)方法，该方法将避免写入竞争。在多线程情况下，当使用get(key, k -> value)时，如果有另一个线程同时调用本方法进行竞争，则后一线程会被阻塞，直到前一线程更新缓存完成；
若另一线程调用**getIfPresent()**方法，则会立即返回null，不会被阻塞。
调用invalidate()方法，将手动移除缓存。
自动加载
LoadingCache<Key, Graph> cache = Caffeine.newBuilder().maximumSize(10_000).expireAfterWrite(10, TimeUnit.MINUTES).build(key -> createExpensiveGraph(key));// 查找缓存，如果缓存不存在则生成缓存元素, 如果无法生成则返回null
Graph graph = cache.get(key);
// 批量查找缓存，如果缓存不存在则生成缓存元素
Map<Key, Graph> graphs = cache.getAll(keys);
LoadingCache是一种自动加载的缓存。其和普通缓存不同的地方在于，当缓存不存在/缓存已过期时，若调用**get()**方法，则会自动调用CacheLoader.load()方法加载最新值。使用LoadingCache时，需要指定CacheLoader，并实现其中的load()方法供缓存缺失时自动加载。
调用**getAll()**方法将遍历所有的key调用get()，除非实现了CacheLoader.loadAll()方法。
在多线程情况下，当两个线程同时调用get()，则后一线程将被阻塞，直至前一线程更新缓存完成。
手动异步加载
AsyncCache<Key, Graph> cache = Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES).maximumSize(10_000).buildAsync();// 查找一个缓存元素， 没有查找到的时候返回null
CompletableFuture<Graph> graph = cache.getIfPresent(key);
// 查找缓存元素，如果不存在，则异步生成
graph = cache.get(key, k -> createExpensiveGraph(key));
// 添加或者更新一个缓存元素
cache.put(key, graph);
// 移除一个缓存元素
cache.synchronous().invalidate(key);
AsyncCache 是 Cache 的一个变体，响应结果均为 CompletableFuture。
默认情况下，缓存计算com.github.benmanes.caffeine.cache.Caffeine#getExecutor使用 ForkJoinPool.commonPool()[作为线程池，如果想要指定线程池，可以覆盖并实现 Caffeine.executor(Executor) 方法
synchronous() 提供了阻塞直到异步缓存生成完毕的能力，它将以 Cache 进行返回
自动异步加载
AsyncLoadingCache<Key, Graph> cache = Caffeine.newBuilder().maximumSize(10_000).expireAfterWrite(10, TimeUnit.MINUTES)// 你可以选择: 去异步的封装一段同步操作来生成缓存元素.buildAsync(key -> createExpensiveGraph(key));// 你也可以选择: 构建一个异步缓存元素操作并返回一个future.buildAsync((key, executor) -> createExpensiveGraphAsync(key, executor));// 查找缓存元素，如果其不存在，将会异步进行生成
CompletableFuture<Graph> graph = cache.get(key);
// 批量查找缓存元素，如果其不存在，将会异步进行生成
CompletableFuture<Map<Key, Graph>> graphs = cache.getAll(keys);
一个 AsyncLoadingCache 是一个 AsyncCache 加上 AsyncCacheLoader 能力的实现
与自动加载 LoadingCache 类似，AsyncLoadingCache 也需要指定 CacheLoader ，同时需要实现 load() 方法供供缓存缺失时的自动加载。
默认以 ForkJoinPool.commonPool()作为线程池来提交，如果想要指定线程池，可以覆盖并实现 AsyncCacheLoader.aysncLoad() 方法
b、驱逐策略
Caffeine 提供了三种驱逐策略，分别是
- 基于容量
- 基于时间
- 基于引用
基于容量
// 基于缓存内的元素个数进行驱逐
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().maximumSize(10_000).build(key -> createExpensiveGraph(key));
如果缓存容量不希望超过某个特定的数量，可以使用Caffeine.maximumSize(long)，来指定最大容量。缓存将会尝试通过基于就近度和频率的算法来驱逐掉不会再被使用到的元素。
缓存可能中的元素可能存在不同的“权重”，缓存中的元素可能有不同的内存占用–可以用Caffeine.weigher(Weigher) 方法来界定每个元素的权重并通过 Caffeine.maximumWeight(long)方法来界定缓存中元素的总权重来实现上述的场景。
// 基于缓存内元素权重进行驱逐
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().maximumWeight(10_000).weigher((Key key, Graph graph) -> graph.vertices().size()).build(key -> createExpensiveGraph(key));
在基于权重驱逐的策略下，一个缓存元素的权重计算是在其创建和更新时，此后其权重值都是静态存在的，在两个元素之间进行权重的比较时，并不会根据进行相对权重的比较。
基于时间
// 基于固定的过期时间驱逐策略
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().expireAfterAccess(5, TimeUnit.MINUTES).build(key -> createExpensiveGraph(key));
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().expireAfterWrite(10, TimeUnit.MINUTES).build(key -> createExpensiveGraph(key));// 基于不同的过期驱逐策略
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().expireAfter(new Expiry<Key, Graph>() {public long expireAfterCreate(Key key, Graph graph, long currentTime) {// Use wall clock time, rather than nanotime, if from an external resourcelong seconds = graph.creationDate().plusHours(5).minus(System.currentTimeMillis(), MILLIS).toEpochSecond();return TimeUnit.SECONDS.toNanos(seconds);}public long expireAfterUpdate(Key key, Graph graph, long currentTime, long currentDuration) {return currentDuration;}public long expireAfterRead(Key key, Graph graph,long currentTime, long currentDuration) {return currentDuration;}}).build(key -> createExpensiveGraph(key));
Caffeine提供了三种基于时间的驱逐:
expireAfterAccess(long, TimeUnit):一个元素在上一次读写操作后一段时间之后，在指定的时间后没有被再次访问将会被认定为过期项。在当被缓存的元素时被绑定在一个session上时，当session因为不活跃而使元素过期的情况下，这是理想的选择。expireAfterWrite(long, TimeUnit):一个元素将会在其创建或者最近一次被更新之后的一段时间后被认定为过期项。在对被缓存的元素的时效性存在要求的场景下，这是理想的选择。expireAfter(Expiry):一个元素将会在指定的时间后被认定为过期项。当被缓存的元素过期时间收到外部资源影响的时候，这是理想的选择。
驱逐策略可以自由组合，在任意驱逐策略生效后，该缓存将会被清除
在写操作，和偶尔的读操作中将会进行周期性的过期事件的执行。过期事件的调度和触发将会在O(1)的时间复杂度内完成。
为了使过期更有效率，可以通过在你的Cache构造器中通过Scheduler接口和Caffeine.scheduler(Scheduler) 方法去指定一个调度线程代替在缓存活动中去对过期事件进行调度。使用Java 9以上版本的用户可以选择Scheduler.systemScheduler()利用系统范围内的调度线程。
当测试基于时间的驱逐策略的时候，不需要坐在板凳上等待现实时钟的转动。
使用Ticker接口和 Caffeine.ticker(Ticker)方法在你的Cache构造器中去指定一个时间源可以避免苦苦等待时钟转动的麻烦。Guava的测试库也提供了FakeTicker去达到同样的目的。
基于引用
// 当key和缓存元素都不再存在其他强引用的时候驱逐
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().weakKeys().weakValues().build(key -> createExpensiveGraph(key));// 当进行GC的时候进行驱逐
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().softValues().build(key -> createExpensiveGraph(key));
Caffeine 允许你配置你的缓存去让GC去帮助清理缓存当中的元素，其中key支持弱引用，而value则支持弱引用和软引用。 AsyncCache不支持软引用和弱引用。
Caffeine.weakKeys() 在保存key的时候将会进行弱引用。这允许在GC的过程中，当key没有被任何强引用指向的时候去将缓存元素回收。
由于GC只依赖于引用相等性。这导致在这个情况下，缓存将会通过引用相等(==)而不是对象相等 equals()去进行key之间的比较。
Caffeine.weakValues()在保存value的时候将会使用弱引用。这允许在GC的过程中，当value没有被任何强引用指向的时候去将缓存元素回收。由于GC只依赖于引用相等性。这导致在这个情况下，缓存将会通过引用相等(==)而不是对象相等 equals()去进行value之间的比较。
Caffeine.softValues()在保存value的时候将会使用软引用。为了相应内存的需要，在GC过程中被软引用的对象将会被通过LRU算法回收。由于使用软引用可能会影响整体性能，我们还是建议通过使用基于缓存容量的驱逐策略代替软引用的使用。同样的，使用 softValues() 将会通过引用相等(==)而不是对象相等 equals()去进行value之间的比较。
c、移除
手动显式移除
在任何时候，都可以手动去让某个缓存元素失效而不是只能等待其因为策略而被驱逐。
// 失效key
cache.invalidate(key)
// 批量失效key
cache.invalidateAll(keys)
// 失效所有的key
cache.invalidateAll()
移除监听器
简单说就是在一个缓存被移除了后，异步回调移除监听器中的方法
Cache<Key, Graph> graphs = Caffeine.newBuilder().evictionListener((Key key, Graph graph, RemovalCause cause) ->System.out.printf("Key %s was evicted (%s)%n", key, cause)).removalListener((Key key, Graph graph, RemovalCause cause) ->System.out.printf("Key %s was removed (%s)%n", key, cause)).build();
可以为一个缓存通过Caffeine.removalListener(RemovalListener)方法定义一个移除监听器在一个元素被移除的时候进行相应的操作。这些操作是使用 Executor 异步执行的，其中默认的 Executor 实现是 ForkJoinPool.commonPool() 并且可以通过覆盖Caffeine.executor(Executor)方法自定义线程池的实现。
当移除之后的自定义操作必须要同步执行的时候，需要使用 Caffeine.evictionListener(RemovalListener) 。这个监听器将在 RemovalCause.wasEvicted() 为 true 的时候被触发。为了移除操作能够明确生效， Cache.asMap() 提供了方法来执行原子操作。
d、刷新
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().maximumSize(10_000).expireAfterWrite(Duration.ofMinutes(5)).refreshAfterWrite(Duration.ofMinutes(1)).build(key -> createExpensiveGraph(key));
刷新和驱逐并不相同。可以通过LoadingCache.refresh(K)方法，异步为key对应的缓存元素刷新一个新的值。
与驱逐不同的是，在刷新的期间如果查询缓存元素，则还是返回旧值，直到该元素的刷新完毕后结束后才会返回刷新后的新值。
与 expireAfterWrite相反，refreshAfterWrite 将会使在写操作之后的一段时间后允许key对应的缓存元素进行刷新，但是只有在这个key被真正查询到的时候才会正式进行刷新操作。所以打个比方，可以在同一个缓存中同时用到 refreshAfterWrite和expireAfterWrite ，这样缓存元素的在被允许刷新的时候不会直接刷新使得过期时间被盲目重置。当一个元素在其被允许刷新但是没有被主动查询的时候，这个元素也会被视为过期。
一个CacheLoader可以通过覆盖重写 CacheLoader.reload(K, V) 方法使得在刷新中可以将旧值也参与到更新的过程中去，这也使得刷新操作显得更加智能。
LoadingCache.refresh(K)可用于显式刷新条目，并在请求时重复请求。返回的未来值可用于实现后备缓存，在后备缓存中，条目会被重新加载以从源获取最新值，但如果失败，则会查找并返回缓存值。
更新操作将会异步执行在一个Executor上。默认的线程池实现是ForkJoinPool.commonPool()当然也可以通过覆盖Caffeine.executor(Executor)方法自定义线程池的实现。
在刷新的过程中，如果抛出任何异常，都会使旧值被保留，并且异常将会被打印日志 (通过 System.Logger )并被吞食。
e、刷新
Cache<Key, Graph> graphs = Caffeine.newBuilder().maximumSize(10_000)//开启数据收集.recordStats().build();
通过使用Caffeine.recordStats()方法可以打开数据收集功能。
Cache.stats()方法将会返回一个CacheStats对象，其将会含有一些统计指标，比如：
hitRate():查询缓存的命中率evictionCount():被驱逐的缓存数量averageLoadPenalty():新值被载入的平均耗时
这些统计指标在缓存的调优中十分重要，强烈的建议性能指标严格的程序中去留意这些统计指标。
这些缓存统计指标可以被基于push/pull模式的报告系统进行集成。基于pull模式的系统可以通过调用Cache.stats() 方法获取当前缓存最新的统计快照。一个基于push的系统可以通过自定义一个StatsCounter对象达到在缓存操作发生时自动推送更新指标的目的。
f、清理
定时清理，在默认情况下，当一个缓存元素过期的时候，Caffeine不会自动立即将其清理和驱逐。而它将会在写操作之后进行少量的维护工作，在写操作较少的情况下，也偶尔会在读操作之后进行。
如果缓存吞吐量较高，那么不用去担心这个缓存的过期维护问题。但是如果缓存读写操作都很少，可以像下文所描述的方式额外通过一个线程去通过Cache.cleanUp() 方法在合适的时候触发清理操作。
LoadingCache<Key, Graph> graphs = Caffeine.newBuilder().scheduler(Scheduler.systemScheduler()).expireAfterWrite(10, TimeUnit.MINUTES).build(key -> createExpensiveGraph(key));
Scheduler可以提前触发过期元素清理移除。在过期事件之间进行调度，以期在短时间内最小化连续的批处理操作的数量。这里的调度是尽可能做到合理，并不能保证在一个元素过期的时候就将其清除。
Java 9以上的用户可以通过Scheduler.systemScheduler()来利用专用的系统范围内的调度线程。
Cache<Key, Graph> graphs = Caffeine.newBuilder().weakValues().build();Cleaner cleaner = Cleaner.create();
cleaner.register(graph, graphs::cleanUp);
graphs.put(key, graph);
Java 9以上的也可以通过Cleaner去触发移除关于基于引用的元素(在使用了 weakKeys, weakValues, 或者 softValues的情况下)。
只要将key或者缓存的元素value注册到Cleaner上，就可以在程序运行中调用Cache.cleanUp()方法触发缓存的维护工作。
4、本地变量缓存通知
本地缓存实现，基于redisson 事件通知，进行分布式过期处理
@Slf4j
@Component
@RequiredArgsConstructor
public class LocalCacheService {private final RedissonClient redissonClient;public static String topicKey = "env_cache_key";//创建guava cachepublic final LocalCache<String, String> userEnvcache = new LocalCache<>(topicKey,500,2000,30);public RedissonDistributeEvent redissonDistributeEvent;/*** 开启监听*/@PostConstructvoid init() {redissonDistributeEvent = new RedissonDistributeEvent(topicKey,redissonClient,new MessageListener<String>() {@Overridepublic void onMessage(CharSequence topic, String msg) {consume(msg);}});}public void produceInvalidateMsg(String key) {try {if (redissonDistributeEvent != null) {redissonDistributeEvent.publishAsync(key);}} catch (Exception e) {log.error("produceInvalidateMsg failed：{}", e.getMessage(), e);}}void consume(String msg) {expireUserEnv(msg);}public void expireUserEnv(String key) {userEnvcache.invalidate(key);}public String getUserEnvStr(String key, Function<String, String> function) {return userEnvcache.get(key, () -> function.apply(key));}}
![[JAVAEE] 多线程的案例(二) - 阻塞队列 生产者消费者模型](https://i-blog.csdnimg.cn/direct/68adff2182994635a8e55e56754e8ed6.png)
