還在用 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開發手冊（嵩山版）》最新發布，速速下載！

以爲不錯，別忘了隨手點贊+轉發哦！