Caffeine：Java8中Guava的替代者

系统管理员 2021-06-10 20:40 609阅读 0赞

话说，中间件的选择上，Spring（SpringBoot）一直是业界的风向标。比如Spring一直使用**「Jackson」**，而没有使用Gson和fastjson。SpringBoot2.0默认数据库连接池从TomcatPool换到了**「HikariCP」**。在本地缓存方面，SpringFramework5.0（SpringBoot2.0）放弃了Google的GuavaCache，选择了**「Caffeine」**（Drop Guava caching - superseded by Caffeine \[SPR-13797\] \#18370）。那么Caffeine有什么魔力，能干掉Google的Guava呢？

# 压力测试 #

我们用数据说话。Caffeine官方利用最权威的压测工具**「JMH」**对Caffeine、ConcurrentMap、GuavaCache、ehcache等做了详细的压测对比，结果如下：![format_png][]

更多压测对比请参考：https://github.com/ben-manes/caffeine/wiki/Benchmarks。从官方的压测结果来看，无论是全读场景、全写场景、或者读写混合场景，无论是8个线程，还是16个线程，Caffeine都是完胜、碾压，简直就是拿着望远镜都看不到对手。

# 简介 #

官方介绍Caffeine是基于JDK8的高性能本地缓存库，提供了几乎完美的命中率。它有点类似JDK中的ConcurrentMap，实际上，Caffeine中的LocalCache接口就是实现了JDK中的ConcurrentMap接口，但两者并不完全一样。最根本的区别就是，ConcurrentMap保存所有添加的元素，除非显示删除之（比如调用remove方法）。而本地缓存一般会配置自动剔除策略，为了保护应用程序，限制内存占用情况，防止内存溢出。

Caffeine提供了灵活的构造方法，从而创建可以满足如下特性的本地缓存：

1.  自动把数据加载到本地缓存中，并且可以配置异步；
2.  基于数量剔除策略；
3.  基于失效时间剔除策略，这个时间是从最后一次访问或者写入算起；
4.  异步刷新；
5.  Key会被包装成Weak引用；
6.  Value会被包装成Weak或者Soft引用，从而能被GC掉，而不至于内存泄漏；
7.  数据剔除提醒；
8.  写入广播机制；
9.  缓存访问可以统计；

# 使用 #

Caffeine使用还是非常简单的，如果你用过GuavaCache，那就更简单了，因为Caffeine的API设计大量借鉴了GuavaCache。首先，引入Maven依赖：

<dependency>
        <groupId>com.github.ben-manes.caffeine</groupId>
        <artifactId>caffeine</artifactId>
        <version>2.8.4</version>
    </dependency>

然后构造Cache使用即可：

Cache<String, String> cache = Caffeine.newBuilder()
            // 数量上限
            .maximumSize(1024)
            // 过期机制
            .expireAfterWrite(5, TimeUnit.MINUTES)
            // 弱引用key
            .weakKeys()
            // 弱引用value
            .weakValues()
            // 剔除监听
            .removalListener((RemovalListener<String, String>) (key, value, cause) -> 
                    System.out.println("key:" + key + ", value:" + value + ", 删除原因:" + cause.toString()))
            .build();
    // 将数据放入本地缓存中
    cache.put("username", "afei");
    cache.put("password", "123456");
    // 从本地缓存中取出数据
    System.out.println(cache.getIfPresent("username"));
    System.out.println(cache.getIfPresent("password"));
    System.out.println(cache.get("blog", key -> {
        // 本地缓存没有的话，从数据库或者Redis中获取
        return getValue(key);
    }));

当然，使用本地缓存时，我们也可以使用异步加载机制：

AsyncLoadingCache<String, String> cache = Caffeine.newBuilder()
            // 数量上限
            .maximumSize(2)
            // 失效时间
            .expireAfterWrite(5, TimeUnit.MINUTES)
            .refreshAfterWrite(1, TimeUnit.MINUTES)
            // 异步加载机制
            .buildAsync(new CacheLoader<String, String>() {
                @Nullable
                @Override
                public String load(@NonNull String key) throws Exception {
                    return getValue(key);
                }
            });
    System.out.println(cache.get("username").get());
    System.out.println(cache.get("password").get(10, TimeUnit.MINUTES));
    System.out.println(cache.get("username").get(10, TimeUnit.MINUTES));
    System.out.println(cache.get("blog").get());

接下来，我们对一些重要特性进行更加深入的分析。

### 过期机制 ###

本地缓存的过期机制是非常重要的，因为本地缓存中的数据并不像业务数据那样需要保证不丢失。本地缓存的数据一般都会要求保证命中率的前提下，尽可能的占用更少的内存，并可在极端情况下，可以被GC掉。

Caffeine的过期机制都是在构造Cache的时候申明，主要有如下几种：

1.  expireAfterWrite：表示自从最后一次写入后多久就会过期；
2.  expireAfterAccess：表示自从最后一次访问（写入或者读取）后多久就会过期；
3.  expireAfter：自定义过期策略；

### 刷新机制 ###

在构造Cache时通过refreshAfterWrite方法指定刷新周期，例如refreshAfterWrite(10, TimeUnit.SECONDS)表示10秒钟刷新一次：

.build(new CacheLoader<String, String>() {
        @Override
        public String load(String k) {
            // 这里我们就可以从数据库或者其他地方查询最新的数据
            return getValue(k);
        }
    });

需要注意的是，Caffeine的刷新机制是**「被动」**的。举个例子，假如我们申明了10秒刷新一次。我们在时间T访问并获取到值v1，在T+5秒的时候，数据库中这个值已经更新为v2。但是在T+12秒，即已经过了10秒我们通过Caffeine从本地缓存中获取到的**「还是v1」**，并不是v2。在这个获取过程中，Caffeine发现时间已经过了10秒，然后会将v2加载到本地缓存中，下一次获取时才能拿到v2。即它的实现原理是在get方法中，调用afterRead的时候，调用refreshIfNeeded方法判断是否需要刷新数据。这就意味着，如果不读取本地缓存中的数据的话，无论刷新时间间隔是多少，本地缓存中的数据永远是旧的数据！

### 剔除机制 ###

在构造Cache时可以通过removalListener方法申明剔除监听器，从而可以跟踪本地缓存中被剔除的数据历史信息。根据RemovalCause.java枚举值可知，剔除策略有如下5种：

*  **「EXPLICIT」**：调用方法（例如：cache.invalidate(key)、cache.invalidateAll）显示剔除数据；
 *  **「REPLACED」**：不是真正被剔除，而是用户调用一些方法（例如：put()，putAll()等）盖了之前的值；
 *  **「COLLECTED」**：表示缓存中的Key或者Value被垃圾回收掉了；
 *  **「EXPIRED」**: expireAfterWrite/expireAfterAccess约定时间内没有任何访问导致被剔除；
 *  **「SIZE」**：超过maximumSize限制的元素个数被剔除的原因；

# GuavaCache和Caffeine差异 #

1.  剔除算法方面，GuavaCache采用的是**「LRU」**算法，而Caffeine采用的是**「Window TinyLFU」**算法，这是两者之间最大，也是根本的区别。
2.  立即失效方面，Guava会把立即失效 (例如：expireAfterAccess(0) and expireAfterWrite(0)) 转成设置最大Size为0。这就会导致剔除提醒的原因是SIZE而不是EXPIRED。Caffiene能正确识别这种剔除原因。
3.  取代提醒方面，Guava只要数据被替换，不管什么原因，都会触发剔除监听器。而Caffiene在取代值和先前值的引用完全一样时不会触发监听器。
4.  异步化方方面，Caffiene的很多工作都是交给线程池去做的（默认：ForkJoinPool.commonPool()），例如：剔除监听器，刷新机制，维护工作等。

# 内存占用对比 #

Caffeine可以根据使用情况延迟初始化，或者动态调整它内部数据结构。这样能减少对内存的占用。如下图所示，使用了gradle memoryOverhead对内存占用进行了压测。结果可能会受到JVM的指针压缩、对象Padding等影响：![format_png 1][]

#  #

# LRU P.K. W-TinyLFU #

缓存的驱逐策略是为了预测哪些数据在短期内最可能被再次用到，从而提升缓存的命中率。由于简洁的实现、高效的运行时表现以及在常规的使用场景下有不错的命中率，LRU（Least Recently Used）策略或许是最流行的驱逐策略,，它在保持算法简单的前提下，效果还不错。但LRU对未来的预测有明显的局限性，它会认为**「最后到来的数据是最可能被再次访问」**的，从而给予它最高的优先级。

现代缓存扩展了对历史数据的使用，结合就近程度（recency）和访问频次（frequency）来更好的预测数据。其中一种保留历史信息的方式是使用**「popularity sketch」**（一种压缩、概率性的数据结构）来从一大堆访问事件中定位频繁的访问者。可以参考**「CountMin Sketch」**算法，它由计数矩阵和多个哈希方法实现。发生一次读取时，矩阵中每行对应的计数器增加计数，估算频率时，取数据对应是所有行中计数的最小值。这个方法让我们从空间、效率、以及适配矩阵的长宽引起的哈希碰撞的错误率上做权衡：![format_png 2][]

Window TinyLFU（W-TinyLFU）算法将Sketch作为过滤器，当新来的数据比要驱逐的数据高频时，这个数据才会被缓存接纳（admission）。这个许可窗口给予每个数据项积累热度的机会，而**「不是立即过滤掉」**。这避免了持续的未命中，特别是在突然流量暴涨的的场景中，一些短暂的重复流量就不会被长期保留。为了刷新历史数据，一个

时间衰减进程被周期性或增量的执行，给所有计数器减半：![format_png 3][]

对于长期保留的数据，W-TinyLFU使用了分段LRU（Segmented LRU，缩写SLRU）策略。起初，一个数据项存储被存储在试用段（probationary segment）中，在后续被访问到时，它会被提升到保护段（protected segment）中（保护段占总容量的80%）。保护段满后，有的数据会被淘汰回试用段，这也可能级联的触发试用段的淘汰。这套机制确保了访问间隔小的热数据被保存下来，而被重复访问少的冷数据则被回收：

![format_png 4][]

如图中数据库和搜索场景的结果展示，通过考虑就近程度和频率能大大提升LRU的表现。一些高级的策略，像ARC，LIRS和W-TinyLFU都提供了接近最理想的命中率。想看更多的场景测试，请查看相应的论文，也可以在使用simulator来测试自己的场景：![format_png 5][]

# Guava迁移 #

那么，如果我的项目之前用的是GuavaCache，如何以尽可能低的成本迁移到Caffeine上来呢？嘿嘿，Caffeine已经想到了这一点，它提供了一个适配器，让你用Guava的接口操作它的缓存。代码片段如下所示：

// Guava's LoadingCache interface
    LoadingCache<Key, Graph> graphs = CaffeinatedGuava.build(
        Caffeine.newBuilder().maximumSize(10_000),
        new CacheLoader<Key, Graph>() { // Guava's CacheLoader
            @Override public Graph load(Key key) throws Exception {
              return createExpensiveGraph(key);
            }
        });

参考

https://github.com/ben-manes/caffeine/wiki/Design

http://highscalability.com/blog/2016/1/25/design-of-a-modern-cache.html

[format_png]: /images/20210527/ba00af21ae024d299992e8d1ed131ef6.png
[format_png 1]: /images/20210527/fb15917c7a6c4312898c5894ac36f802.png
[format_png 2]: /images/20210527/3b124593d4234722a45b43ac60526e38.png
[format_png 3]: /images/20210527/1b9ecde86b7a41b3beacf70cab94aa48.png
[format_png 4]: /images/20210527/ba32df63663d4316840f7e1c3eaa0af6.png
[format_png 5]: /images/20210527/e07836c8e79946f4b4f7d5dd7215c38b.png