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

架構悟道發表於2022-11-24
JVM快取框架Guava

大家好，又見面了。

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

透過《重新認識下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支援根據建立時間或者根據訪問時間來設定資料過期處理，實際使用的時候可以根據具體需要來選擇對應的方式。

過期策略 具體說明
建立過期 基於快取記錄的插入時間判斷。比如設定10分鐘過期，則記錄加入快取之後，不管有沒有訪問，10分鐘時間到則
訪問過期 基於最後一次的訪問時間來判斷是否過期。比如設定10分鐘過期，如果快取記錄被訪問到，則以最後一次訪問時間重新計時；只有連續10分鐘沒有被訪問的時候才會過期，否則將一直存在快取中不會被過期。

看下面的實驗程式碼：

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提供的相關刪除操作介面，來達到對應訴求。

介面名稱 含義描述
invalidate(key) 刪除指定的記錄
invalidateAll(keys) 批次刪除給定的記錄
invalidateAll() 清空整個快取容器

小結回顧

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

? 補充說明1 ：

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

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

? 補充說明2 ：

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

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

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

相關文章