來源：京東雲開發者

1、簡介

     小編最近在使用系統的時候，發現儘管應用已經使用了redis快取提高查詢效率，但是仍然有進一步最佳化的空間，於是想到了比分散式快取效能更好的本地快取，因此對領域內常用的本地快取進行了一番調研，有早期的Guava快取、在Guava上進一步傳承的Caffine以及自稱在Java中使用最廣泛的EhCache，那麼我們該怎麼選擇適合自己應用的快取呢，小編下面會簡單介紹，並將以上快取進行一個對比，希望幫助大家選擇最適合自己系統的本地快取。

2、Guava快取簡介

      Guava cache是Google開發的Guava工具包中一套完善的JVM本地快取框架，底層實現的資料結構類似於ConcurrentHashMap，但是進行了更多的能力擴充，包括快取過期時間設定、快取容量設定、多種淘汰策略、快取監控等,下面簡單介紹下這些功能及其使用方式。

2.1、快取過期時間設定

       Guava的過期時間設定有基於建立時間和最後一次訪問時間兩種策略.

      (1) 基於建立時間

       透過對比快取記錄的插入時間來判斷，比如設定過期時間為5分鐘，不管中間有沒有訪問，到時過期。

public Cache<String, String> createCache() {    
    return CacheBuilder.newBuilder()
    .expireAfterWrite(5L, TimeUnit.MINUTES)
    .build();
}

       (2) 基於過期時間

       透過對比最近最後一次的訪問時間，比如設定5分鐘，每次訪問之後都會重新整理過期時間為5分鐘，只有持續5分鐘沒有被訪問到才會過期。

public Cache<String, String> createCache() {    
    return CacheBuilder.newBuilder()
    .expireAfterAccess(5L, TimeUnit.MINUTES)
    .build();
}

2.2、快取容量和淘汰策略設定

       Guava cache是記憶體型快取，有記憶體溢位風險，因此需要設定快取的最大儲存上限，透過快取的條數或每條快取的權重來判斷是否達到了設定閾值，當快取的資料量達到設定閾值之後，Guava cache支援使用FIFO和LRU的策略對快取記錄採取淘汰的措施。

       （1）限制快取記錄條數

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

       （2）限制快取記錄權重

public Cache<String, User> createCache() {    
    return CacheBuilder.newBuilder()
    .maximumWeight(100L)
    .weigher((key, value) -> (int) Math.ceil(instrumentation.getObjectSize(value) / 1024L))       
    .build();
}

       使用限制快取記錄權重時要先計算weight的value物件的位元組數，每1kb位元組作為一個權重,對比限制快取記錄，我們就能將快取的總佔用限制在100kb左右。

2.3快取監控

       快取記錄的載入和命中情況是評價快取處理能力的重要指標，Guava cache提供了stat統計日誌對這兩個指標進行了統計，我們只需要在建立快取容器的時候加上recordStats就可以開啟統計。

public Cache<String, User> createCache() {    
    return CacheBuilder.newBuilder()
    .recordStats()
    .build();
}

2.4 Guava cache的優劣勢和適用場景

       優劣勢：Guava cache透過記憶體處理資料，具有減少IO請求，讀寫效能快的優勢，但是受記憶體容量限制，只能處理少量資料的讀寫，還有可能對本機記憶體造成壓力，並且在分散式部署中，會存在不同機器節點資料不一致的情況，即快取漂移。

       適用場景：讀多寫少，對資料一致性要求不高的場景。

3、Caffeine簡介

       Caffeine同樣是Google開發的，是在Guava cache的基礎上改良而來的，底層設計思路、功能和使用方式與Guava非常類似，但是各方面的效能都要遠遠超過前者，可以看做是Guava cache的升級版，因此，之前使用過Guava cache，也能夠很快的上手Caffeine，下面是Caffeine和Guava cache的快取建立對比，基本可以無門檻過渡。

public Cache<String, String> createCache() {
    return Caffeine.newBuilder()
        .initialCapacity(1000)
        .maximumSize(100L)
        .expireAfterWrite(5L, TimeUnit.MINUTES)

        .recordStats()
        .build();
}

public Cache<String, String> createCache() {    
    return CacheBuilder.newBuilder()
    .initialCapacity(1000)
    .maximumSize(100L)
    .expireAfterWrite(5L, TimeUnit.MINUTES)
    .recordStats()
    .build();
}

       那麼Caffeine底層又做了哪些最佳化，才能讓其效能高於Guava cache呢？主要包含以下三點：

3.1、對比Guava cache的效能主要最佳化項

       （1）非同步策略

       Guava cache在讀操作中可能會觸發淘汰資料的清理操作，雖然自身也做了一些最佳化來減少讀的時候的清理操作，但是一旦觸發，就會降低查詢效率，對快取效能產生影響。而在Caffeine支援非同步操作，採用非同步處理的策略，查詢請求在觸發淘汰資料的清理操作後，會將清理資料的任務新增到獨立的執行緒池中進行非同步操作，不會阻塞查詢請求，提高了查詢效能。

       （2）ConcurrentHashMap最佳化

        Caffeine底層都是透過ConcurrentHashMap來進行資料的儲存，因此隨著Java8中對ConcurrentHashMap的調整，陣列+連結串列的結構升級為陣列+連結串列+紅黑樹的結構以及分段鎖升級為syschronized+CAS，降低了鎖的粒度，減少了鎖的競爭，這兩個最佳化顯著提高了Caffeine在讀多寫少場景下的查詢效能。

       （3）新型淘汰演算法W-TinyLFU

       傳統的淘汰演算法，如LRU、LFU、FIFO，在實際的快取場景中都存在一些弊端，如FIFO演算法，如果快取使用的頻率較高，那麼快取資料會一直處在進進出出的狀態，間接影響到快取命中率。LRU演算法，在批次重新整理快取資料的場景下，可能會將其他快取資料淘汰掉，從而帶來快取擊穿的風險。LFU演算法，需要儲存快取記錄的訪問次數，帶來記憶體空間的損耗。

       因此，Caffeine引入了W-TinyLFU演算法，由視窗快取、過濾器、主快取組成。快取資料剛進入時會停留在視窗快取中，這個部分只佔總快取的1%，當被擠出視窗快取時，會在過濾器彙總和主快取中淘汰的資料進行比較，如果頻率更高，則進入主快取，否則就被淘汰，主快取被分為淘汰段和保護段，兩段都是LRU演算法，第一次被訪問的元素會進入淘汰段，第二次被訪問會進入保護段，保護段中被淘汰的元素會進入淘汰段，這種演算法實現了高命中率和低記憶體佔用。更詳細的解釋可以參考論文：

3.2、Caffeine的優劣勢和適用場景

       優勢：對比Guava cache有更高的快取效能，劣勢：仍然存在快取漂移的問題；JDK版本過低無法使用

       適用場景：1、適用場景：讀多寫少，對資料一致性要求不高的場景；2、純記憶體快取，JDK8及更高版本中，追求比Guava cache更高的效能。

4、Ehcache簡介

       Guava cache和Caffeine都是JVM快取，會受到記憶體大小的制約，最新的Ehcache採用堆內快取+堆外快取+磁碟的方式，打破了這一制約。堆內快取就是被JVM管理的那一部分快取，而堆外快取，就是在記憶體中另外在開闢一塊不被JVM管理的部分。堆外快取這部分既可以享受記憶體的高速讀寫能力，而且又避免的JVM頻繁的GC，缺點是需要自行清理資料。

        下面是Ehcache快取的建立，指定了堆內、堆外快取和磁碟快取的大小。

ResourcePoolsBuilder.newResourcePoolsBuilder()
    .heap(20, MemoryUnit.MB)
    .offheap(10, MemoryUnit.MB)
    .disk(5, MemoryUnit.GB);

       為了解決快取漂移的問題，Ehcache支援透過叢集的方式，實現了分散式節點之間的資料互通。關於Ehcache的叢集策略，後續文章再詳細闡述。

5、不同本地快取對比