本文是上周去技術(shù)沙龍聽了一下愛奇藝的Java緩存之路有感寫出來的。先簡單介紹一下愛奇藝的java緩存道路的發(fā)展吧。

可以看見圖中分為幾個(gè)階段:

• 第一階段:數(shù)據(jù)同步加redis

通過消息隊(duì)列進(jìn)行數(shù)據(jù)同步至redis，然后Java應(yīng)用直接去取緩存 這個(gè)階段優(yōu)點(diǎn)是:由于是使用的分布式緩存，所以數(shù)據(jù)更新快。缺點(diǎn)也比較明顯:依賴Redis的穩(wěn)定性，一旦redis掛了，整個(gè)緩存系統(tǒng)不可用，造成緩存雪崩，所有請求打到DB。

• 第二、三階段:JavaMap到Guava cache

這個(gè)階段使用進(jìn)程內(nèi)緩存作為一級(jí)緩存，redis作為二級(jí)。優(yōu)點(diǎn):不受外部系統(tǒng)影響，其他系統(tǒng)掛了，依然能使用。缺點(diǎn):進(jìn)程內(nèi)緩存無法像分布式緩存那樣做到實(shí)時(shí)更新。由于java內(nèi)存有限，必定緩存得設(shè)置大小，然后有些緩存會(huì)被淘汰，就會(huì)有命中率的問題。

• 第四階段: Guava Cache刷新

為了解決上面的問題，利用Guava Cache可以設(shè)置寫后刷新時(shí)間，進(jìn)行刷新。解決了一直不更新的問題，但是依然沒有解決實(shí)時(shí)刷新。

• 第五階段: 外部緩存異步刷新

• 
  

這個(gè)階段擴(kuò)展了Guava Cache,利用redis作為消息隊(duì)列通知機(jī)制，通知其他java應(yīng)用程序進(jìn)行刷新。

這里簡單介紹一下愛奇藝緩存發(fā)展的五個(gè)階段，當(dāng)然還有一些其他的優(yōu)化，比如GC調(diào)優(yōu)，緩存穿透，緩存覆蓋的一些優(yōu)化等等。有興趣的同學(xué)可以關(guān)注公眾號(hào)，聯(lián)系我進(jìn)行交流。

上面說的是愛奇藝的一個(gè)進(jìn)化線路，但是在大家的一般開發(fā)過程中，第一步一般都沒有redis，而是直接查庫。

在流量不大的時(shí)候，查數(shù)據(jù)庫或者讀取文件是最為方便，也能完全滿足我們的業(yè)務(wù)要求。

當(dāng)我們應(yīng)用有一定流量之后或者查詢數(shù)據(jù)庫特別頻繁，這個(gè)時(shí)候就可以祭出我們的java中自帶的HashMap或者ConcurrentHashMap。我們可以在代碼中這么寫:

但是這樣做就有個(gè)問題HashMap無法進(jìn)行數(shù)據(jù)淘汰，內(nèi)存會(huì)無限制的增長，所以hashMap很快也被淘汰了。當(dāng)然并不是說他完全就沒用，就像我們古代社會(huì)也不是所有的東西都是過時(shí)的，比如我們中華名族的傳統(tǒng)美德是永不過時(shí)的，就像這個(gè)hashMap一樣的可以在某些場景下作為緩存，當(dāng)不需要淘汰機(jī)制的時(shí)候，比如我們利用反射，如果我們每次都通過反射去搜索Method,field，性能必定低效，這時(shí)我們用HashMap將其緩存起來，性能能提升很多。

在古代社會(huì)中難住我們的問題無法進(jìn)行數(shù)據(jù)淘汰，這樣會(huì)導(dǎo)致我們內(nèi)存無限膨脹,顯然我們是不可以接受的。有人就說我把一些數(shù)據(jù)給淘汰掉唄，這樣不就對(duì)了，但是怎么淘汰呢？隨機(jī)淘汰嗎？當(dāng)然不行，試想一下你剛把A裝載進(jìn)緩存，下一次要訪問的時(shí)候就被淘汰了，那又會(huì)訪問我們的數(shù)據(jù)庫了，那我們要緩存干嘛呢？

所以聰明的人們就發(fā)明了幾種淘汰算法，下面列舉下常見的三種FIFO,LRU,LFU（還有一些ARC,MRU感興趣的可以自行搜索）:

• FIFO:先進(jìn)先出，在這種淘汰算法中，先進(jìn)入緩存的會(huì)先被淘汰。這種可謂是最簡單的了，但是會(huì)導(dǎo)致我們命中率很低。試想一下我們?nèi)绻袀€(gè)訪問頻率很高的數(shù)據(jù)是所有數(shù)據(jù)第一個(gè)訪問的，而那些不是很高的是后面再訪問的，那這樣就會(huì)把我們的首個(gè)數(shù)據(jù)但是他的訪問頻率很高給擠出。

• LRU:最近最少使用算法。在這種算法中避免了上面的問題，每次訪問數(shù)據(jù)都會(huì)將其放在我們的隊(duì)尾，如果需要淘汰數(shù)據(jù)，就只需要淘汰隊(duì)首即可。但是這個(gè)依然有個(gè)問題，如果有個(gè)數(shù)據(jù)在1個(gè)小時(shí)的前59分鐘訪問了1萬次(可見這是個(gè)熱點(diǎn)數(shù)據(jù)),再后一分鐘沒有訪問這個(gè)數(shù)據(jù)，但是有其他的數(shù)據(jù)訪問，就導(dǎo)致了我們這個(gè)熱點(diǎn)數(shù)據(jù)被淘汰。

• LFU:最近最少頻率使用。在這種算法中又對(duì)上面進(jìn)行了優(yōu)化，利用額外的空間記錄每個(gè)數(shù)據(jù)的使用頻率，然后選出頻率最低進(jìn)行淘汰。這樣就避免了LRU不能處理時(shí)間段的問題。

上面列舉了三種淘汰策略，對(duì)于這三種，實(shí)現(xiàn)成本是一個(gè)比一個(gè)高，同樣的命中率也是一個(gè)比一個(gè)好。而我們一般來說選擇的方案居中即可，即實(shí)現(xiàn)成本不是太高，而命中率也還行的LRU,如何實(shí)現(xiàn)一個(gè)LRUMap呢？我們可以通過繼承LinkedHashMap，重寫removeEldestEntry方法，即可完成一個(gè)簡單的LRUMap。

在LinkedHashMap中維護(hù)了一個(gè)entry(用來放key和value的對(duì)象)鏈表。在每一次get或者put的時(shí)候都會(huì)把插入的新entry，或查詢到的老entry放在我們鏈表末尾。 可以注意到我們在構(gòu)造方法中，設(shè)置的大小特意設(shè)置到max*1.4，在下面的removeEldestEntry方法中只需要size>max就淘汰，這樣我們這個(gè)map永遠(yuǎn)也走不到擴(kuò)容的邏輯了，通過重寫LinkedHashMap，幾個(gè)簡單的方法我們實(shí)現(xiàn)了我們的LruMap。

在近代社會(huì)中已經(jīng)發(fā)明出來了LRUMap,用來進(jìn)行緩存數(shù)據(jù)的淘汰，但是有幾個(gè)問題:

• 鎖競爭嚴(yán)重，可以看見我的代碼中，Lock是全局鎖，在方法級(jí)別上面的，當(dāng)調(diào)用量較大時(shí)，性能必然會(huì)比較低。

• 不支持過期時(shí)間

• 不支持自動(dòng)刷新

所以谷歌的大佬們對(duì)于這些問題，按捺不住了，發(fā)明了Guava cache，在Guava cache中你可以如下面的代碼一樣，輕松使用:

我將會(huì)從guava cache原理中，解釋guava cache是如何解決LRUMap的幾個(gè)問題的。

5.1、鎖競爭

guava cache采用了類似ConcurrentHashMap的思想，分段加鎖，在每個(gè)段里面各自負(fù)責(zé)自己的淘汰的事情。在Guava根據(jù)一定的算法進(jìn)行分段，這里要說明的是，如果段太少那競爭依然很嚴(yán)重，如果段太多會(huì)容易出現(xiàn)隨機(jī)淘汰，比如大小為100的，給他分100個(gè)段，那也就是讓每個(gè)數(shù)據(jù)都獨(dú)占一個(gè)段，而每個(gè)段會(huì)自己處理淘汰的過程，所以會(huì)出現(xiàn)隨機(jī)淘汰。在guava cache中通過如下代碼，計(jì)算出應(yīng)該如何分段。

上面segmentCount就是我們最后的分段數(shù)，其保證了每個(gè)段至少10個(gè)Entry。如果沒有設(shè)置concurrencyLevel這個(gè)參數(shù)，那么默認(rèn)就會(huì)是4，最后分段數(shù)也最多為4，例如我們size為100，會(huì)分為4段，每段最大的size是25。 在guava cache中對(duì)于寫操作直接加鎖，對(duì)于讀操作，如果讀取的數(shù)據(jù)沒有過期，且已經(jīng)加載就緒，不需要進(jìn)行加鎖，如果沒有讀到會(huì)再次加鎖進(jìn)行二次讀，如果還沒有需要進(jìn)行緩存加載，也就是通過我們配置的CacheLoader，我這里配置的是直接返回Key，在業(yè)務(wù)中通常配置從數(shù)據(jù)庫中查詢。 如下圖所示:

5.2、過期時(shí)間

相比于LRUMap多了兩種過期時(shí)間，一個(gè)是寫后多久過期expireAfterWrite，一個(gè)是讀后多久過期expireAfterAccess。很有意思的事情是，在guava cache中對(duì)于過期的Entry并沒有馬上過期(也就是并沒有后臺(tái)線程一直在掃)，而是通過進(jìn)行讀寫操作的時(shí)候進(jìn)行過期處理，這樣做的好處是避免后臺(tái)線程掃描的時(shí)候進(jìn)行全局加鎖。看下面的代碼:

從這個(gè)結(jié)果中我們知道，在put的時(shí)候才進(jìn)行的過期處理。特別注意的是我上面concurrencyLevel(1)我這里將分段最大設(shè)置為1，不然不會(huì)出現(xiàn)這個(gè)實(shí)驗(yàn)效果的，在上面一節(jié)中已經(jīng)說過，我們是以段位單位進(jìn)行過期處理。在每個(gè)Segment中維護(hù)了兩個(gè)隊(duì)列:

writeQueue維護(hù)了寫隊(duì)列，隊(duì)頭代表著寫得早的數(shù)據(jù)，隊(duì)尾代表寫得晚的數(shù)據(jù)。 accessQueue維護(hù)了訪問隊(duì)列,和LRU一樣，用來我們進(jìn)行訪問時(shí)間的淘汰，如果當(dāng)這個(gè)Segment超過最大容量，比如我們上面所說的25，超過之后，就會(huì)把a(bǔ)ccessQueue這個(gè)隊(duì)列的第一個(gè)元素進(jìn)行淘汰。

上面就是guava cache處理過期Entries的過程，會(huì)對(duì)兩個(gè)隊(duì)列一次進(jìn)行peek操作，如果過期就進(jìn)行刪除。一般處理過期Entries可以在我們的put操作的前后，或者讀取數(shù)據(jù)時(shí)發(fā)現(xiàn)過期了，然后進(jìn)行整個(gè)Segment的過期處理，又或者進(jìn)行二次讀lockedGetOrLoad操作的時(shí)候調(diào)用。

上面是我們驅(qū)逐Entry的時(shí)候的代碼，可以看見訪問的是accessQueue對(duì)其隊(duì)頭進(jìn)行驅(qū)逐。而驅(qū)逐策略一般是在對(duì)segment中的元素發(fā)生變化時(shí)進(jìn)行調(diào)用，比如插入操作，更新操作，加載數(shù)據(jù)操作。

5.3、自動(dòng)刷新

自動(dòng)刷新操作，在guava cache中實(shí)現(xiàn)相對(duì)比較簡單，直接通過查詢，判斷其是否滿足刷新條件，進(jìn)行刷新。

5.4、其他特性

在Guava cache中還有一些其他特性:

虛引用

在Guava cache中，key和value都能進(jìn)行虛引用的設(shè)定，在Segment中的有兩個(gè)引用隊(duì)列:

這兩個(gè)隊(duì)列用來記錄被回收的引用，其中每個(gè)隊(duì)列記錄了每個(gè)被回收的Entry的hash，這樣回收了之后通過這個(gè)隊(duì)列中的hash值就能把以前的Entry進(jìn)行刪除。

刪除監(jiān)聽器

在guava cache中，當(dāng)有數(shù)據(jù)被淘汰時(shí)，但是你不知道他到底是過期，還是被驅(qū)逐，還是因?yàn)樘撘玫膶?duì)象被回收？這個(gè)時(shí)候你可以調(diào)用這個(gè)方法removalListener(RemovalListener listener)添加監(jiān)聽器進(jìn)行數(shù)據(jù)淘汰的監(jiān)聽，可以打日志或者一些其他處理，可以用來進(jìn)行數(shù)據(jù)淘汰分析。

在RemovalCause記錄了所有被淘汰的原因:被用戶刪除，被用戶替代，過期，驅(qū)逐收集，由于大小淘汰。

guava cache的總結(jié)

細(xì)細(xì)品讀guava cache的源碼總結(jié)下來，其實(shí)就是一個(gè)性能不錯(cuò)的，api豐富的LRU Map。愛奇藝的緩存的發(fā)展也是基于此之上，通過對(duì)guava cache的二次開發(fā)，讓其可以進(jìn)行java應(yīng)用服務(wù)之間的緩存更新。

guava cache的功能的確是很強(qiáng)大，滿足了絕大多數(shù)的人的需求，但是其本質(zhì)上還是LRU的一層封裝,所以在眾多其他較為優(yōu)良的淘汰算法中就相形見絀了。而caffeine cache實(shí)現(xiàn)了W-TinyLFU(LFU+LRU算法的變種)。下面是不同算法的命中率的比較:

其中Optimal是最理想的命中率，LRU和其他算法相比的確是個(gè)弟弟。而我們的W-TinyLFU 是最接近理想命中率的。當(dāng)然不僅僅是命中率caffeine優(yōu)于了guava cache，在讀寫吞吐量上面也是完爆guava cache。

這個(gè)時(shí)候你肯定會(huì)好奇為啥這么caffeine這么牛逼呢？別著急下面慢慢給你道來。

6.1、W-TinyLFU

上面已經(jīng)說過了傳統(tǒng)的LFU是怎么一回事。在LFU中只要數(shù)據(jù)訪問模式的概率分布隨時(shí)間保持不變時(shí)，其命中率就能變得非常高。這里我還是拿愛奇藝舉例，比如有部新劇出來了，我們使用LFU給他緩存下來，這部新劇在這幾天大概訪問了幾億次，這個(gè)訪問頻率也在我們的LFU中記錄了幾億次。但是新劇總會(huì)過氣的，比如一個(gè)月之后這個(gè)新劇的前幾集其實(shí)已經(jīng)過氣了，但是他的訪問量的確是太高了，其他的電視劇根本無法淘汰這個(gè)新劇，所以在這種模式下是有局限性。所以各種LFU的變種出現(xiàn)了，基于時(shí)間周期進(jìn)行衰減，或者在最近某個(gè)時(shí)間段內(nèi)的頻率。同樣的LFU也會(huì)使用額外空間記錄每一個(gè)數(shù)據(jù)訪問的頻率，即使數(shù)據(jù)沒有在緩存中也需要記錄，所以需要維護(hù)的額外空間很大。

可以試想我們對(duì)這個(gè)維護(hù)空間建立一個(gè)hashMap，每個(gè)數(shù)據(jù)項(xiàng)都會(huì)存在這個(gè)hashMap中，當(dāng)數(shù)據(jù)量特別大的時(shí)候，這個(gè)hashMap也會(huì)特別大。

再回到LRU，我們的LRU也不是那么一無是處，LRU可以很好的應(yīng)對(duì)突發(fā)流量的情況，因?yàn)樗恍枰塾?jì)數(shù)據(jù)頻率。

所以W-TinyLFU結(jié)合了LRU和LFU，以及其他的算法的一些特點(diǎn)。

6.2、頻率記錄

首先要說到的就是頻率記錄的問題，我們要實(shí)現(xiàn)的目標(biāo)是利用有限的空間可以記錄隨時(shí)間變化的訪問頻率。在W-TinyLFU中使用Count-Min Sketch記錄我們的訪問頻率，而這個(gè)也是布隆過濾器的一種變種。如下圖所示:

如果需要記錄一個(gè)值，那我們需要通過多種Hash算法對(duì)其進(jìn)行處理hash，然后在對(duì)應(yīng)的hash算法的記錄中+1，為什么需要多種hash算法呢？由于這是一個(gè)壓縮算法必定會(huì)出現(xiàn)沖突，比如我們建立一個(gè)Long的數(shù)組，通過計(jì)算出每個(gè)數(shù)據(jù)的hash的位置。比如張三和李四，他們兩有可能hash值都是相同，比如都是1那Long[1]這個(gè)位置就會(huì)增加相應(yīng)的頻率，張三訪問1萬次，李四訪問1次那Long[1]這個(gè)位置就是1萬零1，如果取李四的訪問評(píng)率的時(shí)候就會(huì)取出是1萬零1，但是李四命名只訪問了1次啊，為了解決這個(gè)問題，所以用了多個(gè)hash算法可以理解為long[][]二維數(shù)組的一個(gè)概念，比如在第一個(gè)算法張三和李四沖突了，但是在第二個(gè)，第三個(gè)中很大的概率不沖突，比如一個(gè)算法大概有1%的概率沖突，那四個(gè)算法一起沖突的概率是1%的四次方。通過這個(gè)模式我們?nèi)±钏牡脑L問率的時(shí)候取所有算法中，李四訪問最低頻率的次數(shù)。所以他的名字叫Count-Min Sketch。

這里和以前的做個(gè)對(duì)比，簡單的舉個(gè)例子:如果一個(gè)hashMap來記錄這個(gè)頻率，如果我有100個(gè)數(shù)據(jù)，那這個(gè)HashMap就得存儲(chǔ)100個(gè)這個(gè)數(shù)據(jù)的訪問頻率。哪怕我這個(gè)緩存的容量是1，因?yàn)長fu的規(guī)則我必須全部記錄這個(gè)100個(gè)數(shù)據(jù)的訪問頻率。如果有更多的數(shù)據(jù)我就有記錄更多的。

在Count-Min Sketch中，我這里直接說caffeine中的實(shí)現(xiàn)吧(在FrequencySketch這個(gè)類中),如果你的緩存大小是100，他會(huì)生成一個(gè)long數(shù)組大小是和100最接近的2的冪的數(shù)，也就是128。而這個(gè)數(shù)組將會(huì)記錄我們的訪問頻率。在caffeine中他規(guī)則頻率最大為15，15的二進(jìn)制位1111，總共是4位，而Long型是64位。所以每個(gè)Long型可以放16種算法，但是caffeine并沒有這么做，只用了四種hash算法，每個(gè)Long型被分為四段，每段里面保存的是四個(gè)算法的頻率。這樣做的好處是可以進(jìn)一步減少Hash沖突，原先128大小的hash，就變成了128X4。

一個(gè)Long的結(jié)構(gòu)如下:

我們的4個(gè)段分為A,B,C,D，在后面我也會(huì)這么叫它們。而每個(gè)段里面的四個(gè)算法我叫他s1,s2,s3,s4。下面舉個(gè)例子如果要添加一個(gè)訪問50的數(shù)字頻率應(yīng)該怎么做？我們這里用size=100來舉例。

首先確定50這個(gè)hash是在哪個(gè)段里面，通過hash & 3必定能獲得小于4的數(shù)字，假設(shè)hash & 3=0，那就在A段。

對(duì)50的hash再用其他hash算法再做一次hash，得到long數(shù)組的位置。假設(shè)用s1算法得到1，s2算法得到3，s3算法得到4，s4算法得到0。

然后在long[1]的A段里面的s1位置進(jìn)行+1,簡稱1As1加1，然后在3As2加1，在4As3加1，在0As4加1。

這個(gè)時(shí)候有人會(huì)質(zhì)疑頻率最大為15的這個(gè)是否太小？沒關(guān)系在這個(gè)算法中，比如size等于100，如果他全局提升了1000次就會(huì)全局除以2衰減，衰減之后也可以繼續(xù)增加，這個(gè)算法再W-TinyLFU的論文中證明了其可以較好的適應(yīng)時(shí)間段的訪問頻率。

6.3、讀寫性能

在guava cache中我們說過其讀寫操作中夾雜著過期時(shí)間的處理，也就是你在一次Put操作中有可能還會(huì)做淘汰操作，所以其讀寫性能會(huì)受到一定影響，可以看上面的圖中，caffeine的確在讀寫操作上面完爆guava cache。主要是因?yàn)樵赾affeine，對(duì)這些事件的操作是通過異步操作，他將事件提交至隊(duì)列，這里的隊(duì)列的數(shù)據(jù)結(jié)構(gòu)是RingBuffer。然后通過會(huì)通過默認(rèn)的ForkJoinPool.commonPool()，或者自己配置線程池，進(jìn)行取隊(duì)列操作，然后在進(jìn)行后續(xù)的淘汰，過期操作。

當(dāng)然讀寫也是有不同的隊(duì)列，在caffeine中認(rèn)為緩存讀比寫多很多，所以對(duì)于寫操作是所有線程共享一個(gè)Ringbuffer。

對(duì)于讀操作比寫操作更加頻繁，進(jìn)一步減少競爭，其為每個(gè)線程配備了一個(gè)RingBuffer：

6.4、數(shù)據(jù)淘汰策略

在caffeine所有的數(shù)據(jù)都在ConcurrentHashMap中，這個(gè)和guava cache不同，guava cache是自己實(shí)現(xiàn)了個(gè)類似ConcurrentHashMap的結(jié)構(gòu)。在caffeine中有三個(gè)記錄引用的LRU隊(duì)列:

• Eden隊(duì)列:在caffeine中規(guī)定只能為緩存容量的%1,如果size=100,那這個(gè)隊(duì)列的有效大小就等于1。這個(gè)隊(duì)列中記錄的是新到的數(shù)據(jù)，防止突發(fā)流量由于之前沒有訪問頻率，而導(dǎo)致被淘汰。比如有一部新劇上線，在最開始其實(shí)是沒有訪問頻率的，防止上線之后被其他緩存淘汰出去，而加入這個(gè)區(qū)域。伊甸區(qū)，最舒服最安逸的區(qū)域，在這里很難被其他數(shù)據(jù)淘汰。

• Probation隊(duì)列:叫做緩刑隊(duì)列，在這個(gè)隊(duì)列就代表你的數(shù)據(jù)相對(duì)比較冷，馬上就要被淘汰了。這個(gè)有效大小為size減去eden減去protected。

• Protected隊(duì)列:在這個(gè)隊(duì)列中，可以稍微放心一下了，你暫時(shí)不會(huì)被淘汰，但是別急，如果Probation隊(duì)列沒有數(shù)據(jù)了或者Protected數(shù)據(jù)滿了，你也將會(huì)被面臨淘汰的尷尬局面。當(dāng)然想要變成這個(gè)隊(duì)列，需要把Probation訪問一次之后，就會(huì)提升為Protected隊(duì)列。這個(gè)有效大小為(size減去eden) X 80% 如果size =100，就會(huì)是79。

這三個(gè)隊(duì)列關(guān)系如下:

所有的新數(shù)據(jù)都會(huì)進(jìn)入Eden。

Eden滿了，淘汰進(jìn)入Probation。

如果在Probation中訪問了其中某個(gè)數(shù)據(jù)，則這個(gè)數(shù)據(jù)升級(jí)為Protected。

如果Protected滿了又會(huì)繼續(xù)降級(jí)為Probation。

對(duì)于發(fā)生數(shù)據(jù)淘汰的時(shí)候，會(huì)從Probation中進(jìn)行淘汰，會(huì)把這個(gè)隊(duì)列中的數(shù)據(jù)隊(duì)頭稱為受害者，這個(gè)隊(duì)頭肯定是最早進(jìn)入的，按照LRU隊(duì)列的算法的話那他其實(shí)他就應(yīng)該被淘汰，但是在這里只能叫他受害者，這個(gè)隊(duì)列是緩刑隊(duì)列，代表馬上要給他行刑了。這里會(huì)取出隊(duì)尾叫候選者，也叫攻擊者。這里受害者會(huì)和攻擊者做PK，通過我們的Count-Min Sketch中的記錄的頻率數(shù)據(jù)有以下幾個(gè)判斷:

• 如果攻擊者大于受害者，那么受害者就直接被淘汰。

• 如果攻擊者<=5，那么直接淘汰攻擊者。這個(gè)邏輯在他的注釋中有解釋:

• 他認(rèn)為設(shè)置一個(gè)預(yù)熱的門檻會(huì)讓整體命中率更高。

• 其他情況，隨機(jī)淘汰。

6.5、如何使用

對(duì)于熟悉Guava的玩家來說如果擔(dān)心有切換成本，那么你完全就多慮了，caffeine的api借鑒了Guava的api，可以發(fā)現(xiàn)其基本一模一樣。

順便一提的是，越來越多的開源框架都放棄了Guava cache，比如Spring5。在業(yè)務(wù)上我也自己曾經(jīng)比較過Guava cache和caffeine最終選擇了caffeine，在線上也有不錯(cuò)的效果。所以不用擔(dān)心caffeine不成熟，沒人使用。

本文系轉(zhuǎn)載自頭條號(hào)開源大學(xué)習(xí)

原文地址：https://www.toutiao.com/i6633537772713935373/?tt_from=weixin&utm_campaign=client_share&wxshare_count=1×tamp=1545617668&app=news_article&utm_source=weixin&iid=54325689039&utm_medium=toutiao_android&group_id=6633537772713935373

推薦閱讀：

parquet嵌套數(shù)據(jù)結(jié)構(gòu)

Spark Streaming 場景應(yīng)用

干貨|kafka流量監(jiān)控的原理及實(shí)現(xiàn)

Emdedding向量技術(shù)在蘑菇街推薦場景的應(yīng)用

總結(jié)

以上是生活随笔為你收集整理的爱奇艺的Java缓存之路，你应该知道的缓存进化史！的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。