重新認識下JVM級別的本地快取框架Guava Cache(2)——深入解讀其容量限制與資料淘汰策略

大家好，又見面了，

本文是筆者作為掘金技術社區簽約作者的身份輸出的快取專欄系列內容，將會通過系列專題，講清楚快取的方方面面，如果感興趣，歡迎關注以獲取后續更新，

通過《重新認識下JVM級別的本地快取框架Guava Cache——優秀從何而來》一文，我們知道了Guava Cache作為JVM級別的本地快取組件的諸多暖心特性，也一步步地學習了在專案中集成并使用Guava Cache進行快取相關操作，Guava Cache作為一款優秀的本地快取組件，其內部很多實作機制與設計策略，同樣值得開發人員深入的掌握與借鑒，

作為系列專欄，本篇文章我們將在上一文的基礎上，繼續探討下Guava Cache對于快取容量限制與資料清理相關的使用與設計機制，進而讓我們在專案中使用起來可以更加的游刃有余，解鎖更多使用技巧，

容量限制時的Size與Weight區別

弄清Size與Weight

Guava Cache提供了對快取總量的限制，并且支持從兩個維度進行限制，這里我們首先要厘清size與weight兩個概念的區別與聯系，

• 限制快取條數size

public Cache<String, User> createUserCache() {
    return CacheBuilder.newBuilder().maximumSize(10000L).build();
}

• 限制快取權重weight

public Cache<String, String> createUserCache() {
    return CacheBuilder.newBuilder()
            .maximumWeight(50000)
            .weigher((key, value) -> (int) Math.ceil(value.length() / 1000))
            .build();
    }

一般而言，我們限制容器的容量的初衷，是為了防止記憶體占用過大導致記憶體溢位，所以本質上是限制記憶體的占用量，從實作層面，往往會根據總記憶體占用量與預估每條記錄位元組數進行估算，將其轉換為對快取記錄條數的限制，這種做法相對簡單易懂，但是對于單條快取記錄占用位元組數差異較大的情況下，會導致基于條數控制的結果不夠精準，

比如：

需要限制快取最大占用500M總量，快取記錄可能大小范圍是1k~100k，按照每條50k進行估算，設定快取容器最大容量為限制最大容量1w條，如果存盤的都是1k大小的記錄，則記憶體總占用量才10M（記憶體沒有被有效利用起來）；若都存盤的是100k大小的記錄，又會導致記憶體占用為1000M，遠大于預期的記憶體占用量（容易造成記憶體溢位），

為了解決這個問題，Guava Cache中提供了一種相對精準的控制策略，即基于權重的總量控制，根據一定的規則，計算出每條value記錄所占的權重值，然后以權重值進行總量的計算，

還是上面的例子，我們按照權重進行設定，假定1k對應基礎權重1，則100k可轉換為權重100，這樣一來：

限制快取最大占用500M，1k對應權重1,Nk代表權重N，則我們可以限制總權重為50w，這樣假如存盤的都是1k的記錄，則最多可以快取5w條記錄；而如果都是100k大小的記錄，則最多僅可以快取5000條記錄，根據存盤資料的大小不同，最大存盤的記錄條數也不相同，但是最終占用的總體量可以實作基本吻合，

所以，基于weight權重的控制方式，比較適用于這種對容器體量控制精度有嚴格訴求的場景，可以在創建容器的時候指定每條記錄的權重計算策略（比如基于字串長度或者基于bytes陣列長度進行計算權重），

使用約束說明

在實際使用中，這幾個引數之間有一定的使用約束，需要特別注意一下：

• 如果沒有指定weight實作邏輯，則使用maximumSize來限制最大容量，按照容器中快取記錄的條數進行限制；這種情況下，即使設定了maximumWeight也不會生效，

• 如果指定了weight實作邏輯，則必須使用 maximumWeight 來限制最大容量，按照容器中每條快取記錄的weight值累加后的總weight值進行限制，

看下面的一個反面示例，指定了weighter和maximumSize，卻沒有指定 maximumWeight屬性：

public static void main(String[] args) {
    try {
        Cache<String, String> cache = CacheBuilder.newBuilder()
            .weigher((key, value) -> 2)
            .maximumSize(2)
            .build();
        cache.put("key1", "value1");
        cache.put("key2", "value2");
        System.out.println(cache.size());
    } catch (Exception e) {
        e.printStackTrace();
    }
}

執行的時候，會報錯，提示weighter和maximumSize不可以混合使用：

java.lang.IllegalStateException: maximum size can not be combined with weigher
	at com.google.common.base.Preconditions.checkState(Preconditions.java:502)
	at com.google.common.cache.CacheBuilder.maximumSize(CacheBuilder.java:484)
	at com.veezean.skills.cache.guava.CacheService.main(CacheService.java:205)

Guava Cache淘汰策略

為了簡單描述，我們將資料從快取容器中移除的操作統稱資料淘汰，按照觸發形態不同，我們可以將資料的清理與淘汰策略分為被動淘汰與主動淘汰兩種，

被動淘汰

• 基于資料量（size或者weight）

當容器內的快取數量接近（注意是接近、而非達到）設定的最大閾值的時候，會觸發guava cache的資料清理機制，會基于LRU或FIFO洗掉一些不常用的key-value鍵值對，這種方式需要在創建容器的時候指定其maximumSize或者maximumWeight，然后才會基于size或者weight進行判斷并執行上述的清理操作，

看下面的實驗代碼：

public static void main(String[] args) {
    try {
        Cache<String, String> cache = CacheBuilder.newBuilder()
                .maximumSize(2)
                .removalListener(notification -> {
                    System.out.println("---監聽到快取移除事件：" + notification);
                })
                .build();
        System.out.println("put放入key1");
        cache.put("key1", "value1");
        System.out.println("put放入key2");
        cache.put("key2", "value1");
        System.out.println("put放入key3");
        cache.put("key3", "value1");
        System.out.println("put操作后，當前快取記錄數：" + cache.size());
        System.out.println("查詢key1對應值：" + cache.getIfPresent("key1"));
    } catch (Exception e) {
        e.printStackTrace();
    }
}

上面代碼中，沒有設定資料的過期時間，理論上資料是長期有效、不會被過期洗掉，為了便于測驗，我們設定快取最大容量為2條記錄，然后往快取容器中插入3條記錄，觀察下輸出結果如下：

put放入key1
put放入key2
put放入key3
---監聽到快取移除事件：key1=value1
put操作后，當前快取記錄數：2
查詢key1對應值：null

從輸出結果可以看到，即使資料并沒有過期，但在插入第3條記錄的時候，快取容器還是自動將最初寫入的key1記錄給移除了，挪出了空間用于新的資料的插入，這個就是因為觸發了Guava Cache的被動淘汰機制，以確保快取容器中的資料量始終是在可控范圍內，

• 基于過期時間

Guava Cache支持根據創建時間或者根據訪問時間來設定資料過期處理，實際使用的時候可以根據具體需要來選擇對應的方式，

看下面的實驗代碼：

public static void main(String[] args) {
    try {
        Cache<String, String> cache = CacheBuilder.newBuilder()
                .expireAfterWrite(1L, TimeUnit.SECONDS)
                .recordStats()
                .build();
        cache.put("key1", "value1");
        cache.put("key2", "value2");
        cache.put("key3", "value3");
        System.out.println("put操作后，當前快取記錄數：" + cache.size());
        System.out.println("查詢key1對應值：" + cache.getIfPresent("key1"));
        System.out.println("統計資訊：" + cache.stats());
        System.out.println("-------sleep 等待超過過期時間-------");
        Thread.sleep(1100L);
        System.out.println("執行key1查詢操作：" + cache.getIfPresent("key1"));
        System.out.println("當前快取記錄數：" + cache.size());
        System.out.println("當前統計資訊：" + cache.stats());
        System.out.println("剩余資料資訊：" + cache.asMap());
    } catch (Exception e) {
        e.printStackTrace();
    }
}

在實驗代碼中，我們設定了快取記錄1s有效期，然后等待其過期之后查看其快取中資料情況，代碼執行結果如下：

put操作后，當前快取記錄數：3
查詢key1對應值：value1
統計資訊：CacheStats{hitCount=1, missCount=0, loadSuccessCount=0, loadExceptionCount=0, totalLoadTime=0, evictionCount=0}
-------sleep 等待超過過期時間-------
執行key1查詢操作：null
當前快取記錄數：1
當前統計資訊：CacheStats{hitCount=1, missCount=1, loadSuccessCount=0, loadExceptionCount=0, totalLoadTime=0, evictionCount=2}
剩余資料資訊：{}

從結果中可以看出，超過過期時間之后，再次執行get操作已經獲取不到已過期的記錄，相關記錄也被從快取容器中移除了，請注意，上述代碼中我們特地是在過期之后執行了一次get請求然后才去查看快取容器中存留記錄數量與統計資訊的，主要是因為Guava Cache的過期資料淘汰是一種被動觸發技能，

當然，細心的小伙伴可能會發現上面的執行結果有一個“問題”，就是前面一起put寫入了3條記錄，等到超過過期時間之后，只移除了2條過期資料，還剩了一條記錄在里面？但是去獲取剩余快取里面的資料的時候又顯示快取里面是空的？

Guava Cache作為一款優秀的本地快取工具包，是不可能有這么個大的bug遺留在里面的，那是什么原因呢？

這個現象其實與Guava Cache的快取淘汰實作機制有關系，前面說過Guava Cache的過期資料清理是一種被動觸發技能，我們看下getIfPresent方法對應的實作原始碼，可以很明顯的看出每次get請求的時候都會觸發一次cleanUp操作：

為了實作高效的多執行緒并發控制，Guava Cache采用了類似ConcurrentHashMap一樣的分段鎖機制，資料被分為了不同分片，每個分片同一時間只允許有一個執行緒執行寫操作，這樣降低并發鎖爭奪的競爭壓力，而上面代碼中也可以看出，執行清理的時候，僅針對當前查詢的記錄所在的Segment分片執行清理操作，而其余的分片的過期資料并不會觸發清理邏輯 —— 這個也就是為什么前面例子中，明明3條資料都過期了，卻只清理掉了其中的2條的原因，

為了驗證上述的原因說明，我們可以在創建快取容器的時候將concurrencyLevel設定為允許并發數為1，強制所有的資料都存放在同一個分片中：

public static void main(String[] args) {
    try {
        Cache<String, String> cache = CacheBuilder.newBuilder()
                .expireAfterWrite(1L, TimeUnit.SECONDS)
                .concurrencyLevel(1)  // 添加這一約束，強制所有資料放在一個分片中
                .recordStats()
                .build();

                // ...省略其余邏輯，與上一段代碼相同

    } catch (Exception e) {
        e.printStackTrace();
    }
}

重新運行后，從結果可以看出，這一次3條過期記錄全部被清除了，

put操作后，當前快取記錄數：3
查詢key1對應值：value1
統計資訊：CacheStats{hitCount=1, missCount=0, loadSuccessCount=0, loadExceptionCount=0, totalLoadTime=0, evictionCount=0}
-------sleep 等待超過過期時間-------
執行key1查詢操作：null
當前快取記錄數：0
當前統計資訊：CacheStats{hitCount=1, missCount=1, loadSuccessCount=0, loadExceptionCount=0, totalLoadTime=0, evictionCount=3}
剩余資料資訊：{}

在實際的使用中，我們倒也無需過于關注資料過期是否有被從記憶體中真實移除這一點，因為Guava Cache會在保證業務資料準確的情況下，盡可能的兼顧處理性能，在該清理的時候，自會去執行對應的清理操作，所以也無需過于擔心，

• 基于參考

基于參考回收的策略，核心是利用JVM虛擬機的GC機制來達到資料清理的目的，按照JVM的GC原理，當一個物件不再被參考之后，便會執行一系列的標記清除邏輯，并最終將其回收釋放，這種實際使用的較少，此處不多展開，

主動淘汰

上述通過總體容量限制或者通過過期時間約束來執行的快取資料清理操作，是屬于一種被動觸發的機制，

實際使用的時候也會有很多情況，我們需要從快取中立即將指定的記錄給洗掉掉，比如執行洗掉或者更新操作的時候我們就需要洗掉已有的歷史快取記錄，這種情況下我們就需要主動呼叫 Guava Cache提供的相關洗掉操作介面，來達到對應訴求，

小結回顧

好啦，關于Guava Cache中的容量限制與資料淘汰策略，就介紹到這里了，關于本章的內容，你是否有自己的一些想法與見解呢？歡迎評論區一起交流下，期待和各位小伙伴們一起切磋、共同成長，

?? 補充說明1 ：

本文屬于《深入理解快取原理與實戰設計》系列專欄的內容之一，該專欄圍繞快取這個宏大命題進行展開闡述，全方位、系統性地深度剖析各種快取實作策略與原理、以及快取的各種用法、各種問題應對策略，并一起探討下快取設計的哲學，

如果有興趣，也歡迎關注此專欄，

?? 補充說明2 ：

• 關于本文中涉及的演示代碼的完整示例，我已經整理并提交到github中，如果您有需要，可以自取：https://github.com/veezean/JavaBasicSkills

我是悟道，聊技術、又不僅僅聊技術~

如果覺得有用，請點贊 + 關注讓我感受到您的支持，也可以關注下我的公眾號【架構悟道】，獲取更及時的更新，

期待與你一起探討，一起成長為更好的自己，

本文來自博客園，作者：架構悟道，歡迎關注公眾號[架構悟道]持續獲取更多干貨，轉載請注明原文鏈接：https://www.cnblogs.com/softwarearch/p/16920807.html

標籤：其他

上一篇：是時候考慮升級 JDK 17 了

下一篇：極化碼理論