這篇博文是我之前關於 JSR-107 的文章 的後續。新增 JSR-107 支援給了我們一個機會來審查我們自己的快取，看看兩者如何能夠和諧共處。Spring 4.1 還包含了一系列社群反饋的改進。

我也很高興地宣佈，一本專門介紹快取抽象的全新入門指南已經發布，請檢視 《使用 Spring 快取資料》！

CacheResolver

我們在 JSR-107 中發現的最有用的功能之一是能夠在執行時解析要使用的快取，這是基於實際的方法執行。到目前為止，我們自己的支援一直依賴於在註解（或 aspect 定義）級別指定快取名稱。出現了幾個問題，報告稱當使用多個 CacheManager 時，需要能夠自定義將這些名稱解析到的 manager。

我們最終的做法是建立了一個類似的 CacheResolver 抽象，以提供最靈活的選項。正如您可能猜到的，預設實現接受一個 CacheManager，並根據提供的快取名稱解析要使用的快取。由於不再需要這些名稱，Spring 4.1 允許您編寫以下內容

@Cacheable
public Book findBook(ISBN isbn) {...}

當然，您必須指定自己的 CacheResolver，它知道如何處理此特定呼叫，或者您需要以不同的方式提供要使用的快取（請繼續閱讀）。

就像註解的 value 屬性不再是必需的一樣，只要設定了 CacheResolver，就可以省略 CacheManager。如果您有自己的實現，它可能根本不依賴於 CacheManager，而是以其他方式管理您的 Cache 例項。

操作級別的自定義

社群還反映，他們希望能夠更精細地控制快取行為。Spring 4.1 允許您為每個操作指定要使用的 CacheResolver（或 CacheManager）和 KeyGenerator。

例如，以下程式碼將自定義 KeyGenerator 應用於此特定操作

@Cacheable(value="book", keyGenerator="myKeyGenerator")
public Book findBook(ISBN isbn, boolean checkWarehouse, boolean includeUsed)

這會查詢名為 myKeyGenerator 的 KeyGenerator bean。CacheManager 和 cache resolver 例項可以以類似的方式設定。

類級別的自定義

社群的另一項反饋是能夠**在不**啟用任何預設快取行為的情況下，在方法級別共享這些自定義。引入 @CacheConfig，它在類級別提供相同的自定義，即快取名稱、CacheResolver（或 CacheManager）和 KeyGenerator。

@CacheConfig(cacheNames="book", keyGenerator="myKeyGenerator") 
public class BookRepository {

    @Cacheable
    public Book findBook(ISBN isbn) {...}

    public Book thisIsNotCached(String someArg) {...}
}

JCache 整合

我們在實現 JSR-107 支援時的一個主要目標是利用我們已有的抽象，以便現有應用程式能夠非常平滑地遷移。JCache 支援實際上在內部使用了 Spring 的快取抽象，這允許您使用標準註解重用現有的快取基礎設施。當您指定 JSR-107 自定義元件（如 javax.cache.annotation.CacheResolver 或 javax.cache.annotation.CacheKeyGenerator）時，我們會透過介面卡將其路由到我們的抽象。

具體來說，這意味著您可以保留現有的基礎設施，並選擇您想要的任何機制。例如，您可以使用一個 ConcurrentMapCacheManager，它在後臺使用 ConcurrentHashMap，並配合標準的 JSR-107 註解。

如果您想嘗試一下，請檢視 這個指南的 fork，它使用 JCache 而不是 Spring 註解（提交 32fea97 顯示了實際的更改內容）。

總結

Spring 4.1 即將於今年夏天釋出，它將對其快取抽象進行重大增強；新增對 JSR-107 的支援幫助我們進一步改進了它。還有其他一些未在此博文中介紹的小改進，例如更好的異常處理以及 Cache 介面上方便的 putIfAbsent 方法。

一如既往，我們歡迎社群的反饋，請試用這些功能，並讓我們知道您是否遇到任何問題。