大家好，又見面了。
本文是筆者作為掘金技術社群簽約作者的身份輸出的緩存專欄系列内容，将會通過系列專題，講清楚緩存的方方面面。如果感興趣，歡迎關注以擷取後續更新。
通過《重新認識下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 ：
- 關于本文中涉及的示範代碼的完整示例，我已經整理并送出到github中，如果您有需要，可以自取：https://github.com/veezean/JavaBasicSkills
我是悟道，聊技術、又不僅僅聊技術~
如果覺得有用，請點贊 + 關注讓我感受到您的支援。也可以關注下我的公衆号【架構悟道】，擷取更及時的更新。
期待與你一起探讨，一起成長為更好的自己。