## 一、關於 Caffeine Cache

在推薦服務中，雖然允許少量請求因計算超時等原因返回預設列表。但從運營指標來說，**越高的“完算率”意味著越完整的演算法效果呈現，也意味著越高的商業收益。**（完算率類比影片的完播率，成功完成整個推薦線上流程計算的請求次數/總請求次數）

為了能夠儘可能快地完成計算，多級快取方案已經成為推薦線上服務的標配。其中本地快取顯得尤為重要，而 Caffeine Cache 就是近幾年脫穎而出的高效能本地快取庫。Caffeine Cache 已經在 Spring Boot 2.0 中取代了 Google Guava 成為預設快取框架，足見其成熟和可靠。

關於 Caffeine 的介紹文章有很多，不再累述，可閱讀文末的參考資料瞭解 Caffeine 的簡述、效能基準測試結果、基本 API 用法和 Window-TinyLFU 快取演算法原理等。雖然接觸 Caffeine 的時間不長，但其簡潔的 API 和如絲般順滑的非同步載入能力簡直不要太好用。而本菜鳥在使用的過程中也踩了一些坑，使用不當甚至快取也能卡得和磁碟 IO 一樣慢。

經過一番學習嘗試，總算了解到 Caffeine Cache 如絲般順滑的奧秘，總結下來分享一下。

## 二、Caffeine Cache 配置套路

使用 Caffeine Cache，除了 Spring 中常見的 @EnableCache、@Cacheable 等註解外，直接使用 Caffeine.newBuilder().build() 方法建立 LoadingCache 也是推薦服務常用的方式。

我們先來看看 Caffeine#builder 都有哪些配置套路：
![](https://img-blog.csdnimg.cn/img_convert/fed35dc008201653c4e48afd176492ac.png)

### 2.1 追問三連

#### 2.1.1 ObjectPool

當然可以，光腳的不怕穿鞋的，上線後別走……

#### 2.1.2 expireAfterWrite、expireAfterAccess 都配置？

雖然 expireAfterWrite 和 expireAfterAccess 同時配置不報錯，但 access 包含了 write，所以選一個就好了親。

#### 2.1.3 reference-based 驅逐有啥特點？

只要配置上都會使用 == 來比較物件相等，而不是 equals；還有一個非常重要的配置，也是決定快取如絲般順滑的秘訣：重新整理策略 refreshAfterWrite。該配置使得 Caffeine 可以在資料載入後超過給定時間時重新整理資料。下文詳解。

**機智如我在 Builder 上也能踩坑**

和 lombok 的 builder 不同，Caffeine#builder 的策略呼叫兩次將會導致執行時異常！這是因為 Caffeine 構建時每個策略都儲存了已設定的標記位，所以重複設定並不是覆蓋而是直接拋異常：

```java
public Caffeine<k v=""> maximumWeight(@NonNegative long maximumWeight) {
  requireState(this.maximumWeight == UNSET_INT,
      "maximum weight was already set to %s", this.maximumWeight);
  requireState(this.maximumSize == UNSET_INT,
      "maximum size was already set to %s", this.maximumSize);
  this.maximumWeight = maximumWeight;
  requireArgument(maximumWeight >= 0, "maximum weight must not be negative");
  return this;
}
```

比如上述程式碼，maximumWeight() 呼叫兩次的話就會丟擲異常並提示 maximum weight was already set to xxx。

## 三、Caffeine Cache 精華

### 3.1 get 方法都做了什麼？

首先在實現類 LocalLoadingCache<k v=""> 中可以看到；

```java
default @Nullable V get(K key) {
    return cache().computeIfAbsent(key, mappingFunction());
}
```

但突然發現這個 get 方法沒有實現類！Why？我們跟蹤 cache() 方法就可以發現端倪：

```java
public BoundedLocalCache<k v=""> cache() {
    return cache;
}
public UnboundedLocalCache<k v=""> cache() {
    return cache;
}
```

根據呼叫 Caffeine.newBuilder().build() 的過程，決定了具體生成的是 BoundedLocalCache 還是 UnboundedLocalCache；

判定 BoundedLocalCache 的條件如下：

```java
public <k1 extends="" k="" v1="" v=""> LoadingCache<k1 v1=""> build(
    @NonNull CacheLoader super K1, V1> loader) {
  requireWeightWithWeigher();
 
  @SuppressWarnings("unchecked")
  Caffeine<k1 v1=""> self = (Caffeine<k1 v1="">) this;
  return isBounded() || refreshes()
      ? new BoundedLocalCache.BoundedLocalLoadingCache<>(self, loader)
      : new UnboundedLocalCache.UnboundedLocalLoadingCache<>(self, loader);
}
```

其中的 isBounded()、refreshes() 方法分別如下：

```java
boolean isBounded() {
  return (maximumSize != UNSET_INT)
      || (maximumWeight != UNSET_INT)
      || (expireAfterAccessNanos != UNSET_INT)
      || (expireAfterWriteNanos != UNSET_INT)
      || (expiry != null)
      || (keyStrength != null)
      || (valueStrength != null);
}
boolean refreshes() {
  // 呼叫了 refreshAfter 就會返回 false
  return refreshNanos != UNSET_INT;
}
```

可以看到一般情況下常規的配置都是 BoundedLocalCache。所以我們以它為例繼續看 BoundedLocalCache#computeIfAbsent 方法吧：

```java
  public @Nullable V computeIfAbsent(K key,
    Function super K, ? extends V> mappingFunction,
    boolean recordStats, boolean recordLoad) {
  // 常用的 LoadingCache#get 方法 recordStats、recordLoad 都為 true
  // mappingFunction 即 builder 中傳入的 CacheLoader 例項包裝
 
  requireNonNull(key);
  requireNonNull(mappingFunction);
  // 預設的 ticker read 返回的是 System.nanoTime();
  // 關於其他的 ticker 見文末參考文獻，可以讓使用者自定義超時的計時方式
  long now = expirationTicker().read();
 
  // data 是 ConcurrentHashMap<object node="" v="">>
  // key 根據程式碼目前都是 LookupKeyReference 物件
  // 可以發現 LookupKeyReference 儲存的是 System.identityHashCode(key) 結果
  // 關於 identityHashCode 和 hashCode 的區別可閱讀文末參考資料
  Node<k v=""> node = data.get(nodeFactory.newLookupKey(key));
  if (node != null) {
    V value = node.getValue();
    if ((value != null) && !hasExpired(node, now)) {
      // isComputingAsync 中將會判斷當前是否為非同步類的快取例項
      // 是的話再判斷 node.getValue 是否完成。BoundedLocaCache 總是返回 false
      if (!isComputingAsync(node)) {
        // 此處在 BoundedLocaCache 中也是直接 return 不會執行
        tryExpireAfterRead(node, key, value, expiry(), now);
        setAccessTime(node, now);
      }
 
      // 非同步驅逐任務提交、非同步重新整理操作
      // CacheLoader#asyncReload 就在其中的 refreshIfNeeded 方法被呼叫
      afterRead(node, now, recordStats);
      return value;
    }
  }
  if (recordStats) {
    // 記錄快取的載入成功、失敗等統計資訊
    mappingFunction = statsAware(mappingFunction, recordLoad);
  }
 
  // 這裡2.8.0版本不同實現類生成的都是 WeakKeyReference
  Object keyRef = nodeFactory.newReferenceKey(key, keyReferenceQueue());
 
  // 本地快取沒有，使用載入函式讀取到快取
  return doComputeIfAbsent(key, keyRef, mappingFunction,
    new long[] { now }, recordStats);
}
```

上文中 hasExpired 判斷資料是否過期，看程式碼就很明白了：是透過 builder 的配置 + 時間計算來判斷的。

```java
boolean hasExpired(Node<k v=""> node, long now) {
  return
    (expiresAfterAccess() &&
      (now - node.getAccessTime() >= expiresAfterAccessNanos()))
  | (expiresAfterWrite() &&
      (now - node.getWriteTime() >= expiresAfterWriteNanos()))
  | (expiresVariable() &&
      (now - node.getVariableTime() >= 0));
}
```

繼續看程式碼，doComputeIfAbsent 方法主要內容如下：

```java
  @Nullable V doComputeIfAbsent(K key, Object keyRef,
    Function super K, ? extends V> mappingFunction,
    long[] now, boolean recordStats) {
  @SuppressWarnings("unchecked")
  V[] oldValue = (V[]) new Object[1];
  @SuppressWarnings("unchecked")
  V[] newValue = (V[]) new Object[1];
  @SuppressWarnings("unchecked")
  K[] nodeKey = (K[]) new Object[1];
  @SuppressWarnings({"unchecked", "rawtypes"})
  Node<k v="">[] removed = new Node[1];
 
  int[] weight = new int[2]; // old, new
  RemovalCause[] cause = new RemovalCause[1];
 
  // 對 data 這個 ConcurrentHashMap 呼叫 compute 方法，計算 key 對應的值
  // compute 方法的執行是原子的，並且會對 key 加鎖
  // JDK 註釋說明 compute 應該短而快並且不要在其中更新其他的 key-value
  Node<k v=""> node = data.compute(keyRef, (k, n) -> {
    if (n == null) {
      // 沒有值的時候呼叫 builder 傳入的 CacheLoader#load 方法
      // mappingFunction 是在 LocalLoadingCache#newMappingFunction 中建立的
      newValue[0] = mappingFunction.apply(key);
      if (newValue[0] == null) {
        return null;
      }
      now[0] = expirationTicker().read();
 
      // builder 沒有指定 weigher 時，這裡預設為 SingletonWeigher，總是返回 1
      weight[1] = weigher.weigh(key, newValue[0]);
      n = nodeFactory.newNode(key, keyReferenceQueue(),
          newValue[0], valueReferenceQueue(), weight[1], now[0]);
      setVariableTime(n, expireAfterCreate(key, newValue[0], expiry(), now[0]));
      return n;
    }
 
    // 有值的時候對 node 例項加同步塊
    synchronized (n) {
      nodeKey[0] = n.getKey();
      weight[0] = n.getWeight();
      oldValue[0] = n.getValue();
 
      // 設定驅逐原因，如果資料有效直接返回
      if ((nodeKey[0] == null) || (oldValue[0] == null)) {
        cause[0] = RemovalCause.COLLECTED;
      } else if (hasExpired(n, now[0])) {
        cause[0] = RemovalCause.EXPIRED;
      } else {
        return n;
      }
 
      // 預設的配置 writer 是 CacheWriter.disabledWriter()，無操作；
      // 自己定義的 CacheWriter 一般用於驅逐資料時得到回撥進行外部資料來源操作
      // 詳情可以參考文末的資料
      writer.delete(nodeKey[0], oldValue[0], cause[0]);
      newValue[0] = mappingFunction.apply(key);
      if (newValue[0] == null) {
        removed[0] = n;
        n.retire();
        return null;
      }
      weight[1] = weigher.weigh(key, newValue[0]);
      n.setValue(newValue[0], valueReferenceQueue());
      n.setWeight(weight[1]);
 
      now[0] = expirationTicker().read();
      setVariableTime(n, expireAfterCreate(key, newValue[0], expiry(), now[0]));
      setAccessTime(n, now[0]);
      setWriteTime(n, now[0]);
      return n;
    }
  });
 
  // 剩下的程式碼主要是呼叫 afterWrite、notifyRemoval 等方法
  // 進行後置操作，後置操作中將會再次嘗試快取驅逐
  // ...
  return newValue[0];
}
```

看完上面的程式碼，遇到這些問題也就心裡有數了。

### 3.2 快取的資料什麼時候淘汰？

顯式呼叫 invalid 方法時；弱引用、軟引用可回收時；get 方法老值存在且已完成非同步載入後呼叫 afterRead。

get 方法老值不存在，呼叫 doComputeIfAbsent 載入完資料後呼叫 afterWrite。

### 3.3 CacheLoader#load和 CacheLoader#asyncReload 有什麼區別？

首先 CacheLoader#load 方法是必須提供的，快取呼叫時將是同步操作（回顧上文 data.compute 方法），會阻塞當前執行緒。

而 CacheLoader#asyncReload 需要配合builder#refreshAfterWrite 使用這樣將在computeIfAbsent->afterRead->refreshIfNeeded 中呼叫，並非同步更新到 data 物件上；並且，load 方法沒有傳入oldValue，而 asyncReload 方法提供了oldValue，這意味著如果觸發 load 操作時，快取是不能保證 oldValue 是否存在的（可能是首次，也可能是已失效）。

### 3.4 載入資料耗時較長，對效能的影響是什麼？

CacheLoader#load 耗時長，將會導致快取執行過程中查詢資料時阻塞等待載入，當多個執行緒同時查詢同一個 key 時，業務請求可能阻塞，甚至超時失敗；

CacheLoader#asyncReload 耗時長，在時間週期滿足的情況下，即使耗時長，對業務的影響也較小

### 3.5 說好的如絲般順滑呢？

首要前提是外部資料查詢能保證單次查詢的效能（一次查詢天長地久那加本地快取也於事無補）；然後，我們在構建 LoadingCache 時，配置 refreshAfterWrite 並在 CacheLoader 例項上定義 asyncReload 方法；

**靈魂追問：只有以上兩步就夠了嗎？**

機智的我突然覺得事情並不簡單。還有一個時間設定的問題，我們來看看：

> 如果 expireAfterWrite 週期 < refreshAfterWrite 週期會如何？此時查詢失效資料時總是會呼叫 load 方法，refreshAfterWrite 根本沒用！
>

> 如果 CacheLoader#asyncReload 有額外操作，導致它自身實際執行查詢耗時超過 expireAfterWrite 又會如何？還是 CacheLoader#load 生效，refreshAfterWrite 還是沒用！

所以絲滑的正確開啟方式，是 refreshAfterWrite 週期明顯小於 expireAfterWrite 週期，並且 CacheLoader#asyncReload 本身也有較好的效能，才能如絲般順滑地載入資料。此時就會發現業務不斷進行 get 操作，根本感知不到資料載入時的卡頓！

### 3.6 用本地快取會不會出現快取穿透？怎麼防止？

computeIfAbsent 和 doComputeIfAbsent 方法可以看出如果載入結果是 null，那麼每次從快取查詢，都會觸發 mappingFunction.apply，進一步呼叫 CacheLoader#load。從而流量會直接打到後端資料庫，造成快取穿透。

防止的方法也比較簡單，在業務可接受的情況下，如果未能查詢到結果，則返回一個非 null 的“假物件”到本地快取中。

**靈魂追問：如果查不到，new 一個物件返回行不行？**

key 範圍不大時可以，builder 設定了 size-based 驅逐策略時可以，但都存在消耗較多記憶體的風險，可以定義一個預設的 PLACE_HOLDER 靜態物件作為引用。

**靈魂追問：都用同一個假物件引用真的大丈夫（沒問題）？**

這麼大的坑本菜鳥怎麼能錯過！快取中存的是物件引用，如果業務 get 後修改了物件的內容，那麼其他執行緒再次獲取到這個物件時，將會得到修改後的值！鬼知道那個深夜定位出這個問題的我有多興奮（蒼蠅搓手）。

當時快取中儲存的是 List<item>，而不同執行緒中對這些 item 的 score 進行了不同的 set 操作，導致同一個 item 排序後的分數和順序變幻莫測。本菜鳥一度以為是推薦之神降臨，冥冥中加持 CTR 所以把 score 變來變去。

**靈魂追問：那怎麼解決快取被意外修改的問題呢？怎麼 copy 一個物件呢？**

So easy，就在 get 的時候 copy 一下物件就好了。

靈魂追問4：怎麼 copy 一個物件？……停！我們們以後有機會再來說說這個淺複製和深複製，以及常見的複製工具吧，聚焦聚焦……

### 3.7 某次載入資料失敗怎麼辦，還能用之前的快取值嗎？

根據 CacheLoader#load和 CacheLoader#asyncReload 的引數區別，我們可以發現：

應該在 asyncReload 中來處理，如果查詢資料庫異常，則可以返回 oldValue 來繼續使用之前的快取；否則只能透過 load 方法中返回預留空物件來解決。使用哪一種方法需要根據具體的業務場景來決定。

【踩坑】返回 null 將導致 Caffeine 認為該值不需要快取，下次查詢還會繼續呼叫 load 方法，快取並沒生效。

### 3.8 多個執行緒同時 get 一個本地快取不存在的值，會如何？

根據程式碼可以知道，已經進入 doComputeIfAbsent 的執行緒將阻塞在 data.compute 方法上；

比如短時間內有 N 個執行緒同時 get 相同的 key 並且 key 不存在，則這 N 個執行緒最終都會反覆執行 compute 方法。但只要 data 中該 key 的值更新成功，其他進入 computeIfAbsent 的執行緒都可直接獲得結果返回，不會出現阻塞等待載入；

所以，如果一開始就有大量請求進入 doComputeIfAbsent 阻塞等待資料，就會造成短時間請求掛起、超時的問題。由此在大流量場景下升級服務時，需要考慮在接入流量前對快取進行預熱（我查我自己，嗯），防止瞬時請求太多導致大量請求掛起或超時。

靈魂追問：如果一次 load 耗時 100ms，一開始有 10 個執行緒冷啟動，最終等待時間會是 1s 左右嗎？

其實……要看情況，回顧一下 data.compute 裡面的程式碼：

```java
if (n == null) {
    // 這部分程式碼其他後續執行緒進入後已經有值，不再執行
}
synchronized (n) {
  // ...
 
  if ((nodeKey[0] == null) || (oldValue[0] == null)) {
    cause[0] = RemovalCause.COLLECTED;
  } else if (hasExpired(n, now[0])) {
    cause[0] = RemovalCause.EXPIRED;
  } else {
    // 未失效時在這裡返回，不會觸發 load 函式
    return n;
  }
 
  // ...
}

```

所以，如果 load 結果不是 null，那麼只第一個執行緒花了 100ms，後續執行緒會盡快返回，最終時長應該只比 100ms 多一點。但如果 load 結果返回 null（快取穿透），相當於沒有查到資料，於是後續執行緒還會再次執行 load，最終時間就是 1s 左右。

以上就是本菜鳥目前總結的內容，如有疏漏歡迎指出。在學習原始碼的過程中，Caffeine Cache 還使用了其他編碼小技巧，我們們下次有空接著聊。

## 三、參考資料

1.[Caffeine使用及原理](https://www.jianshu.com/p/a7c99ce5b080)

2.[Caffeine Cache-高效能Java本地快取元件](https://www.cnblogs.com/rickiyang/p/11074158.html)

3.[Eviction和Ticker相關介紹](https://github.com/ben-manes/caffeine/wiki/Eviction)

4.[Efficiency](https://github.com/ben-manes/caffeine/wiki/Efficiency)

5.[CacheWriter](https://github.com/ben-manes/caffeine/wiki/Writer)

6.[System.identityHashCode(obj)與obj.hashcode](https://www.jianshu.com/p/24fa4bdb9b9d)

> 作者：vivo 網際網路伺服器團隊-Li Haoxuan</item></k></k></k></k></object></k1></k1></k1></k1></k></k></k></k>

如何把 Caffeine Cache 用得如絲般順滑？

相關文章