还在用 Guava Cache？它才是 Java 本地缓存之王！

做者：rickiyang
来源：http://www.javashuo.com/article/p-apxfgrkx-nz.html

Guava Cache 的优势是封装了get，put操做；提供线程安全的缓存操做；提供过时策略；提供回收策略；缓存监控。当缓存的数据超过最大值时，使用LRU算法替换。

这一篇咱们将要谈到一个新的本地缓存框架：Caffeine Cache。它也是站在巨人的肩膀上-Guava Cache，借着它的思想优化了算法发展而来。

本篇博文主要介绍Caffine Cache 的使用方式。另外，Java 缓存系列面试题和答案我都整理好了，关注下公众号Java技术栈，在后台回复 "面试" 进行获取。

1. Caffine Cache 在算法上的优势-W-TinyLFU

说到优化，Caffine Cache到底优化了什么呢？咱们刚提到过LRU，常见的缓存淘汰算法还有FIFO，LFU：

1. FIFO：先进先出，在这种淘汰算法中，先进入缓存的会先被淘汰，会致使命中率很低。
2. LRU：最近最少使用算法，每次访问数据都会将其放在咱们的队尾，若是须要淘汰数据，就只须要淘汰队首便可。仍然有个问题，若是有个数据在 1 分钟访问了 1000次，再后 1 分钟没有访问这个数据，可是有其余的数据访问，就致使了咱们这个热点数据被淘汰。
3. 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中四种引用类型

引用类型	被垃圾回收时间	用途	生存时间
强引用 Strong Reference	历来不会	对象的通常状态	JVM中止运行时终止
软引用 Soft Reference	在内存不足时	对象缓存	内存不足时终止
弱引用 Weak Reference	在垃圾回收时	对象缓存	gc运行后终止
虚引用 Phantom Reference	历来不会	能够用虚引用来跟踪对象被垃圾回收器回收的活动，当一个虚引用关联的对象被垃圾收集器回收以前会收到一条系统通知	JVM中止运行时终止

// 当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));

若是你有多级缓存的状况下，这个方法仍是很实用。

注意：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(): 加载新值的平均时间

另外，Java 缓存系列面试题和答案我都整理好了，关注下公众号Java技术栈，在后台回复 "面试" 进行获取。
近期热文推荐：

1.Java 15 正式发布， 14 个新特性，刷新你的认知！！

2.终于靠开源项目弄到 IntelliJ IDEA 激活码了，真香！

3.我用 Java 8 写了一段逻辑，同事直呼看不懂，你试试看。。

4.吊打 Tomcat ，Undertow 性能很炸！！

5.《Java开发手册（嵩山版）》最新发布，速速下载！

以为不错，别忘了随手点赞+转发哦！