期策略：TTL與TTI的關(guān)鍵差異與實(shí)戰(zhàn)解析)
1. 題面解析先把標(biāo)準(zhǔn)答案釘死最近又有人在群里貼出這道JCache基礎(chǔ)篇的面試題JCacheJSR-107標(biāo)準(zhǔn)要求實(shí)現(xiàn)必須支持哪兩種緩存過(guò)期策略題目很短答錯(cuò)率卻很高。有人脫口而出“TTL和TTI”有人愣一下說(shuō)“TTL和TTI不是一回事嗎”還有人干脆把“LRU和LFU”搬出來(lái)。說(shuō)實(shí)話能把LRU當(dāng)過(guò)期策略來(lái)答說(shuō)明對(duì)緩存兩個(gè)核心機(jī)制——過(guò)期和淘汰——還沒(méi)完全分清楚。今天就用實(shí)戰(zhàn)視角把這道題徹底拆開(kāi)從規(guī)范要求、接口設(shè)計(jì)、代碼驗(yàn)證到面試追問(wèn)一次說(shuō)透。1.1 標(biāo)準(zhǔn)答案TTL 與 TTI正確答案是JCacheJSR-107要求實(shí)現(xiàn)必須支持兩種基于時(shí)間的過(guò)期策略分別是TTLTime-To-Live存活時(shí)間和TTITime-To-Idle空閑時(shí)間。用JCache術(shù)語(yǔ)再翻譯一遍就是“基于條目創(chuàng)建時(shí)間的過(guò)期策略”和“基于最后訪問(wèn)時(shí)間的過(guò)期策略”。TTL的計(jì)時(shí)起點(diǎn)是緩存條目被創(chuàng)建或者被更新的時(shí)刻。比如設(shè)置TTL為5分鐘那么無(wú)論這5分鐘內(nèi)被讀取多少次只要到了時(shí)間點(diǎn)條目就該被視為過(guò)期。TTI的計(jì)時(shí)起點(diǎn)是最后一次成功的訪問(wèn)操作每次讀取都會(huì)讓計(jì)時(shí)器歸零重新開(kāi)始。所以一條數(shù)據(jù)如果持續(xù)被高頻讀取TTI會(huì)被不斷續(xù)期只有連續(xù)空閑超過(guò)設(shè)定時(shí)間它才會(huì)過(guò)期。這兩種策略解決的是完全不同的緩存場(chǎng)景后面會(huì)詳細(xì)展開(kāi)。但先記住這個(gè)結(jié)論規(guī)范里“必須支持”這四個(gè)字非常重要它不是建議而是所有合格實(shí)現(xiàn)的最低門(mén)檻。1.2 很多人掉進(jìn)去的坑過(guò)期策略不等于淘汰策略這道題最容易翻車的地方不是答不出TTL和TTI而是把過(guò)期策略和淘汰策略混為一談。過(guò)期策略關(guān)心的是“這個(gè)條目什么時(shí)候失效”核心是時(shí)間維度。緩存框架會(huì)在讀取時(shí)判斷條目是否過(guò)期或者通過(guò)后臺(tái)任務(wù)定期清理過(guò)期后再次get會(huì)得到null。淘汰策略關(guān)心的是“緩存空間滿了我該先扔掉誰(shuí)”核心是空間維度。LRULeast Recently Used淘汰最近最少使用的LFULeast Frequently Used淘汰訪問(wèn)頻率最低的這些東西解決的是容量壓力不是時(shí)間失效。一個(gè)典型場(chǎng)景用戶會(huì)話數(shù)據(jù)設(shè)置30分鐘TTI它不一定占滿空間但超過(guò)30分鐘不訪問(wèn)就該失效這是過(guò)期策略的活。如果緩存容量不夠我們可以用LRU把不常用的會(huì)話先擠掉這是淘汰策略的活。兩者可以共存但不能互相替代。面試官問(wèn)出這道題就是想看你能不能清晰區(qū)分這兩個(gè)維度。1.3 面試官問(wèn)這道題到底想考什么表面上它是一道送分題背下來(lái)就行。但面試官真正考察的是三個(gè)層次第一你是否知道JCache是Java官方的緩存規(guī)范它把緩存API標(biāo)準(zhǔn)化到了javax.cache這個(gè)包里JSR-107是這個(gè)規(guī)范的編號(hào)。第二你是否知道規(guī)范對(duì)實(shí)現(xiàn)方有強(qiáng)制性要求而不是只給了一堆可選的API。第三你是否能把兩種策略對(duì)應(yīng)到實(shí)際的業(yè)務(wù)場(chǎng)景而不是停留在背概念。所以答題時(shí)最好三步走先給出標(biāo)準(zhǔn)答案再解釋兩種策略的計(jì)時(shí)規(guī)則最后各配一個(gè)典型使用場(chǎng)景。這樣既展示了記憶準(zhǔn)確又體現(xiàn)了理解深度。下面我們就進(jìn)入規(guī)范背后的設(shè)計(jì)邏輯看看為什么偏偏是這兩種策略被強(qiáng)制要求。2. 規(guī)范背后的設(shè)計(jì)邏輯為什么非要強(qiáng)制這兩種JSR-107在制定時(shí)并不是拍腦袋定下“必須支持TTL和TTI”而是從大量緩存應(yīng)用中抽象出來(lái)的最低共識(shí)。如果你看過(guò)Caffeine、Guava、Redis這些緩存方案的源代碼或者配置項(xiàng)會(huì)發(fā)現(xiàn)它們都擺脫不了這兩個(gè)基本的失效維度。JCache只是把最核心的那個(gè)交集抽成了規(guī)范。2.1 從業(yè)務(wù)場(chǎng)景反推TTL 和 TTI 各自的價(jià)值先看TTL。它的語(yǔ)義是“從寫(xiě)入開(kāi)始計(jì)時(shí)到期就失效”。典型場(chǎng)景包括驗(yàn)證碼、臨時(shí)token、優(yōu)惠券快照、配置推送。比如一個(gè)活動(dòng)的商品價(jià)格頁(yè)我們從上游接口拉取價(jià)格后緩存60秒60秒后必須重新拉取這就是TTL。這類數(shù)據(jù)的特征非常明顯數(shù)據(jù)從出生開(kāi)始就有固定的保鮮期不管用戶看不看到期就得作廢。再看TTI。它的語(yǔ)義是“從上一次被訪問(wèn)開(kāi)始計(jì)時(shí)空閑超過(guò)閾值就失效”。典型場(chǎng)景是用戶登錄會(huì)話、表單填寫(xiě)狀態(tài)、需要高頻訪問(wèn)的熱點(diǎn)數(shù)據(jù)。比如一個(gè)用戶在電商網(wǎng)站瀏覽商品只要他不斷點(diǎn)擊會(huì)話就不該過(guò)期他離開(kāi)半小時(shí)后再回來(lái)會(huì)話應(yīng)該已經(jīng)失效。TTI對(duì)這種“有活動(dòng)就續(xù)命沒(méi)活動(dòng)就回收”的需求特別匹配。如果規(guī)范只要求支持一種實(shí)現(xiàn)方的自由度太大業(yè)務(wù)方一旦需要另一種就只能自己造輪子。如果要求支持太多比如把進(jìn)程內(nèi)緩存常用的弱引用、軟引用也納入強(qiáng)制那又會(huì)給分布式緩存實(shí)現(xiàn)造成巨大負(fù)擔(dān)。所以JCache選擇把TTL和TTI這兩個(gè)普適性最強(qiáng)的時(shí)間策略定為硬性要求。2.2 ExpiryPolicy三個(gè)方法對(duì)應(yīng)三種時(shí)機(jī)在JCache的javax.cache.expiry包里有一個(gè)核心接口ExpiryPolicy它定義了三個(gè)方法getExpiryForCreation、getExpiryForAccess、getExpiryForUpdate。getExpiryForCreation決定了條目剛創(chuàng)建時(shí)從哪個(gè)時(shí)刻開(kāi)始算過(guò)期TTL主要落在這里。getExpiryForAccess決定了條目在每次讀取命中后應(yīng)該被賦予多長(zhǎng)的續(xù)期TTI主要落在這里。getExpiryForUpdate決定了條目在更新值之后重新計(jì)算過(guò)期時(shí)間常見(jiàn)做法是把它當(dāng)TTL重新開(kāi)始計(jì)算。理解這三個(gè)方法比單純背TTL和TTI更接近規(guī)范本意。TTL不是一個(gè)獨(dú)立方法TTI也不是一個(gè)獨(dú)立方法它們都是ExpiryPolicy在不同訪問(wèn)時(shí)機(jī)下返回Duration的具體體現(xiàn)。規(guī)范要求實(shí)現(xiàn)必須支持“基于創(chuàng)建時(shí)間的過(guò)期”和“基于最后訪問(wèn)時(shí)間的過(guò)期”落到代碼層面就是默認(rèn)提供的ExpiryPolicyBuilder必須能幫你構(gòu)建出這兩種策略并且底層緩存必須能正確處理訪問(wèn)時(shí)間戳的更新。2.3 Duration 的黑話ZERO、ETERNAL 和負(fù)數(shù)ExpiryPolicy的三個(gè)方法返回的類型是javax.cache.expiry.Duration不是java.time.Duration這一點(diǎn)很容易踩坑。JCache的Duration內(nèi)部有兩個(gè)常量ZERO表示立即過(guò)期ETERNAL表示永不過(guò)期。ZERO的使用非常微妙。如果你在自定義ExpiryPolicy的getExpiryForAccess里返回Duration.ZERO意味著條目在創(chuàng)建后第一次訪問(wèn)就會(huì)立即過(guò)期這通常不是你想要的效果。ETERNAL則是默認(rèn)行為JCache默認(rèn)情況下緩存條目是永不過(guò)期的除非你顯式配置了過(guò)期策略。至于負(fù)數(shù)規(guī)范明確不允許返回負(fù)數(shù)。如果你傳入一個(gè)負(fù)的Duration輕則被忽略重則拋異常。所以生產(chǎn)環(huán)境里如果有外部配置的動(dòng)態(tài)過(guò)期時(shí)間一定先做鉗制校驗(yàn)別把負(fù)數(shù)傳給ExpiryPolicyBuilder。這個(gè)細(xì)節(jié)在面試追問(wèn)里很常見(jiàn)也是實(shí)際開(kāi)發(fā)中容易被忽略的坑。3. 代碼實(shí)操親手驗(yàn)證兩種過(guò)期策略講原理總歸有點(diǎn)虛我們直接寫(xiě)代碼驗(yàn)證。這里只使用JCache規(guī)范提供的接口具體實(shí)現(xiàn)只需要選擇一個(gè)實(shí)現(xiàn)了JSR-107的開(kāi)源庫(kù)放到classpath里。為了避免被具體廠商牽著走我會(huì)盡量保持代碼只依賴javax.cache的標(biāo)準(zhǔn)API。3.1 環(huán)境準(zhǔn)備只依賴規(guī)范接口也能跑首先引入JCache API。如果你的項(xiàng)目是Maven結(jié)構(gòu)依賴坐標(biāo)一般是group為javax.cache、artifact為cache-api的jar這是官方規(guī)范接口。還需要一個(gè)具體的JCache實(shí)現(xiàn)類庫(kù)每個(gè)實(shí)現(xiàn)的坐標(biāo)不同這里就不展開(kāi)寫(xiě)死你自己選一個(gè)主流的JSR-107實(shí)現(xiàn)即可。然后我們需要一段最基礎(chǔ)的初始化代碼獲取CachingProvider和CacheManagerimport javax.cache.Cache; import javax.cache.CacheManager; import javax.cache.Caching; import javax.cache.configuration.MutableConfiguration; import javax.cache.expiry.Duration; import javax.cache.expiry.ExpiryPolicy; import javax.cache.expiry.ExpiryPolicyBuilder; import javax.cache.spi.CachingProvider; import java.time.temporal.ChronoUnit; import java.util.concurrent.TimeUnit; CachingProvider provider Caching.getCachingProvider(); CacheManager cacheManager provider.getCacheManager(); MutableConfigurationString, String config new MutableConfiguration(); CacheString, String cache cacheManager.createCache(demo-cache, config);這里要提醒一點(diǎn)同一個(gè)CacheManager里創(chuàng)建同名緩存會(huì)拋異常。如果你反復(fù)調(diào)試要么換緩存名要么在創(chuàng)建前先判斷緩存是否存在。另外CacheManager本身也是一個(gè)資源用完最好調(diào)用close()尤其在單元測(cè)試?yán)镱l繁創(chuàng)建時(shí)不關(guān)閉可能會(huì)把內(nèi)存堆滿。3.2 配置 TTL5秒后必然消失下面創(chuàng)建一個(gè)TTL為5秒的緩存。我習(xí)慣用lambda給setExpiryPolicyFactory傳參代碼短意圖也清楚MutableConfigurationString, String ttlConfig new MutableConfiguration(); ttlConfig.setExpiryPolicyFactory(() - ExpiryPolicyBuilder.timeToLiveExpiry(Duration.ofSeconds(5))); CacheString, String ttlCache cacheManager.createCache(ttl-demo, ttlConfig); ttlCache.put(orderId, 20250514001); System.out.println(ttlCache.get(orderId)); // 輸出20250514001 TimeUnit.SECONDS.sleep(6); System.out.println(ttlCache.get(orderId)); // 輸出null運(yùn)行之后你會(huì)發(fā)現(xiàn)第一個(gè)get正常返回第二個(gè)get返回null。這就是TTL從put那一刻開(kāi)始倒計(jì)時(shí)5秒期間不管你怎么get計(jì)時(shí)都不會(huì)重置。這里有一個(gè)值得注意的實(shí)現(xiàn)差異有些JCache實(shí)現(xiàn)是惰性過(guò)期也就是get時(shí)才檢查時(shí)間戳有些實(shí)現(xiàn)會(huì)有后臺(tái)線程定期清理。所以你在第5秒整去get結(jié)果可能是null也可能還沒(méi)被物理刪除但邏輯上一定不能返回舊值。規(guī)范要求的是“看起來(lái)過(guò)期”不強(qiáng)制物理刪除時(shí)機(jī)。3.3 配置 TTI訪問(wèn)之后計(jì)時(shí)器重新歸零TTI的驗(yàn)證稍微繞一點(diǎn)需要模擬“訪問(wèn)后重置”MutableConfigurationString, String ttiConfig new MutableConfiguration(); ttiConfig.setExpiryPolicyFactory(() - ExpiryPolicyBuilder.timeToIdleExpiry(Duration.ofSeconds(5))); CacheString, String ttiCache cacheManager.createCache(tti-demo, ttiConfig); ttiCache.put(sessionId, abc123); TimeUnit.SECONDS.sleep(3); System.out.println(ttiCache.get(sessionId)); // 輸出abc123訪問(wèn)把過(guò)期時(shí)間續(xù)到了第8秒 TimeUnit.SECONDS.sleep(3); System.out.println(ttiCache.get(sessionId)); // 輸出abc123距離最后一次訪問(wèn)只過(guò)去3秒未過(guò)期 TimeUnit.SECONDS.sleep(6); System.out.println(ttiCache.get(sessionId)); // 輸出null最后訪問(wèn)后又空閑了6秒超過(guò)5秒閾值這里的邏輯可以這樣理解第一次sleep 3秒時(shí)訪問(wèn)了一次空閑計(jì)時(shí)器被重置過(guò)期時(shí)間點(diǎn)從原來(lái)的第5秒推遲到了第8秒。第二次sleep 3秒后再次訪問(wèn)又重置到第11秒。最后一次連續(xù)空閑6秒超過(guò)5秒于是過(guò)期。TTI在分布式場(chǎng)景里有個(gè)經(jīng)典坑多個(gè)節(jié)點(diǎn)同時(shí)訪問(wèn)同一個(gè)key每個(gè)節(jié)點(diǎn)都會(huì)更新自己的本地訪問(wèn)時(shí)間但如果沒(méi)有統(tǒng)一的訪問(wèn)時(shí)間存儲(chǔ)TTI就名存實(shí)亡。這一點(diǎn)面試官如果追問(wèn)你可以補(bǔ)充“TTL比TTI更容易在分布式環(huán)境下實(shí)現(xiàn)”。3.4 組合策略和自定義防御式寫(xiě)法如果業(yè)務(wù)要求“最長(zhǎng)TTL是10分鐘但連續(xù)空閑3分鐘就過(guò)期”JCache內(nèi)置的builder沒(méi)法直接組合。規(guī)范只強(qiáng)制分別支持TTL和TTI并不保證二者的組合語(yǔ)義。這時(shí)候你需要自己實(shí)現(xiàn)一個(gè)ExpiryPolicypublic class CombinedExpiryPolicy implements ExpiryPolicy { private final Duration ttl; private final Duration tti; public CombinedExpiryPolicy(Duration ttl, Duration tti) { this.ttl ttl; this.tti tti; } Override public Duration getExpiryForCreation() { return ttl; } Override public Duration getExpiryForAccess() { return tti; } Override public Duration getExpiryForUpdate() { return ttl; } }別急著把這段代碼直接上生產(chǎn)這里有一個(gè)語(yǔ)義陷阱創(chuàng)建時(shí)返回ttl但第一次訪問(wèn)后getExpiryForAccess返回tti會(huì)把原有的ttl覆蓋掉。也就是說(shuō)如果創(chuàng)建后第5秒你訪問(wèn)了一次后續(xù)實(shí)際過(guò)期時(shí)間就變成了“這次訪問(wèn)后的3分鐘”而不是原來(lái)剩余的ttl。真正要同時(shí)保證“最長(zhǎng)不超過(guò)10分鐘”和“空閑超過(guò)3分鐘過(guò)期”必須在getExpiryForAccess里做計(jì)算取剩余TTL和新的TTI中更早的那個(gè)。這個(gè)計(jì)算邏輯實(shí)現(xiàn)難度不大但需要緩存框架能拿到“當(dāng)前時(shí)間”和“已存活時(shí)間”JCache規(guī)范并沒(méi)有統(tǒng)一暴露這些內(nèi)部時(shí)間戳。所以更務(wù)實(shí)的做法是在業(yè)務(wù)代碼里做好定時(shí)續(xù)期或過(guò)期判斷不要過(guò)度依賴自定義組合策略。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這塊內(nèi)容來(lái)自我實(shí)際接手的幾個(gè)項(xiàng)目問(wèn)題很多坑不是配置錯(cuò)了而是大家對(duì)“過(guò)期”這個(gè)動(dòng)作的理解有偏差。4.1 過(guò)期條目為什么不會(huì)立刻物理刪除這是剛開(kāi)始用JCache時(shí)最常見(jiàn)的困惑TTL設(shè)了5秒sleep6秒后一查內(nèi)存緩存條目還在只是get不到了。原因很簡(jiǎn)單JCache規(guī)范只要求“get的時(shí)候必須返回null”并沒(méi)有強(qiáng)制要求實(shí)現(xiàn)必須同步刪除物理?xiàng)l目。有些實(shí)現(xiàn)采用惰性刪除只有訪問(wèn)過(guò)期條目時(shí)才真正移除有些實(shí)現(xiàn)使用后臺(tái)清理線程每隔一段時(shí)間掃描刪除。從用戶視角看條目邏輯上已經(jīng)過(guò)期物理殘留與否不影響正確性但會(huì)影響內(nèi)存占用。如果你的緩存容器長(zhǎng)期存在大量過(guò)期條目?jī)?nèi)存曲線會(huì)越來(lái)越難看的。這時(shí)可以去你的JCache實(shí)現(xiàn)里找有沒(méi)有“定期清理”的配置項(xiàng)把清理間隔適當(dāng)調(diào)小或者手動(dòng)遍歷緩存并觸發(fā)get來(lái)加速失效。不過(guò)這類操作在分布式緩存上要小心遍歷大緩存可能拖垮線上性能。4.2 為什么TTI緩存在高并發(fā)下看著像“永遠(yuǎn)不過(guò)期”這是TTI的天然特性只要每個(gè)請(qǐng)求都來(lái)訪問(wèn)這個(gè)key空閑計(jì)時(shí)器就一直在重置理論上這個(gè)key永遠(yuǎn)不會(huì)因?yàn)門(mén)TI過(guò)期。如果你的訪問(wèn)量非常高TTI緩存里的所謂“熱點(diǎn)數(shù)據(jù)”可能會(huì)長(zhǎng)時(shí)間不失效導(dǎo)致數(shù)據(jù)新鮮度變差。我之前遇到過(guò)一個(gè)問(wèn)題團(tuán)隊(duì)用TTI緩存一套價(jià)格規(guī)則想著3分鐘不訪問(wèn)就作廢結(jié)果這套規(guī)則是全站每個(gè)請(qǐng)求都會(huì)讀的TTI永遠(yuǎn)被續(xù)期價(jià)格規(guī)則幾乎一整天都沒(méi)有重新加載。最后改成TTL才解決問(wèn)題。所以選型時(shí)要想清楚如果你希望數(shù)據(jù)必須定期重新拉取不管有沒(méi)有人訪問(wèn)請(qǐng)用TTL。如果你只希望清理那些長(zhǎng)時(shí)間沒(méi)人用的數(shù)據(jù)用TTI。二者沒(méi)有優(yōu)劣只有適用場(chǎng)景不同。4.3 五大高頻坑不是配置錯(cuò)了是理解錯(cuò)了現(xiàn)象根因解決建議設(shè)置了TTL但緩存一直有效用的可能是Caffeine的expireAfterWrite但JCache適配層沒(méi)真正應(yīng)用檢查配置是否傳到了底層Cache的expiryPolicyFactoryget之后TTI不重置實(shí)現(xiàn)可能只在寫(xiě)操作時(shí)更新時(shí)間戳查JCache實(shí)現(xiàn)文檔確認(rèn)是否支持讀續(xù)期Duration傳入負(fù)數(shù)JCache規(guī)范要求Duration非負(fù)配置來(lái)源處做Integer/Duration校驗(yàn)自定義ExpiryPolicy返回null方法返回值不能隨意給null默認(rèn)返回Duration.ETERNAL或顯式指定同一CacheManager重復(fù)createCache同名緩存已存在會(huì)拋異常用cacheManager.getCache(name)判斷或try-catch這些坑在單個(gè)實(shí)現(xiàn)里不一定會(huì)全遇到但它們都有共性不要拿“用過(guò)某個(gè)緩存框架”就直接替代對(duì)規(guī)范的理解。JCache是API標(biāo)準(zhǔn)底層實(shí)現(xiàn)各有各的實(shí)現(xiàn)策略面試官其實(shí)很愛(ài)從這個(gè)角度問(wèn)下去。4.4 這種Error/Exception到底怎么排查有一次線上緩存突然大量失效日志里刷“expiry duration is not positive”一類的錯(cuò)誤。排查后發(fā)現(xiàn)是我們一個(gè)外部配置項(xiàng)傳了負(fù)數(shù)配置中心改了數(shù)據(jù)但代碼沒(méi)做鉗制。后來(lái)我總結(jié)了一條排查路徑第一復(fù)現(xiàn)時(shí)先看配置的Duration到底是多少第二在自定義ExpiryPolicy的三個(gè)方法入口加日志打印每次返回的Duration第三確認(rèn)實(shí)現(xiàn)是否啟用后臺(tái)清理線程把清理日志打開(kāi)第四區(qū)分緩存命中不到底是因?yàn)檫^(guò)期還是因?yàn)樘蕴?。這四條走完大部分問(wèn)題都能定位。5. 面試答題的節(jié)奏與我的實(shí)戰(zhàn)感受這道題雖然簡(jiǎn)單但答得好不好很能拉開(kāi)差距。下面給出一個(gè)我驗(yàn)證過(guò)比較好用的答題結(jié)構(gòu)以及一些面試之外的實(shí)際心得。5.1 一個(gè)可以直接復(fù)用的答題模板面試官問(wèn)出“JCache標(biāo)準(zhǔn)要求實(shí)現(xiàn)必須支持哪兩種緩存過(guò)期策略”時(shí)你可以這樣回答第一層給結(jié)論必須支持TTL和TTI也就是基于創(chuàng)建時(shí)間的過(guò)期和基于最后訪問(wèn)時(shí)間的過(guò)期。第二層解釋差異TTL從寫(xiě)入開(kāi)始計(jì)時(shí)訪問(wèn)不會(huì)重置TTI從上次訪問(wèn)開(kāi)始計(jì)時(shí)每次命中會(huì)續(xù)期。第三層落場(chǎng)景比如驗(yàn)證碼用TTL用戶會(huì)話用TTI。第四層補(bǔ)深度JCache里的ExpiryPolicy接口有三個(gè)方法分別對(duì)應(yīng)創(chuàng)建、訪問(wèn)、更新三種時(shí)機(jī)TTL和TTI的本質(zhì)是這三個(gè)方法在不同時(shí)機(jī)返回不同Duration。如果面試官追問(wèn)“淘汰策略和過(guò)期策略的區(qū)別”你還可以順帶說(shuō)一句LRU、LFU這類淘汰策略和TTL、TTI不沖突前者管容量后者管時(shí)效。這樣整個(gè)回答就立體起來(lái)了。5.2 我在項(xiàng)目里踩過(guò)的TTI續(xù)期坑說(shuō)一個(gè)我自己的真實(shí)經(jīng)歷。當(dāng)時(shí)做一個(gè)活動(dòng)頁(yè)面需要把用戶最近瀏覽過(guò)的商品列表緩存起來(lái)30分鐘不活躍就清空。我當(dāng)時(shí)很自然地選了TTI覺(jué)得非常合適。結(jié)果上線后發(fā)現(xiàn)一個(gè)問(wèn)題只要用戶在活動(dòng)頁(yè)掛著不動(dòng)每5分鐘會(huì)有一個(gè)前端心跳請(qǐng)求打過(guò)來(lái)把整個(gè)列表的TTI不斷續(xù)期導(dǎo)致用戶其實(shí)早就沒(méi)看了但緩存里還是裝著半小時(shí)前的瀏覽記錄。后來(lái)我把心跳請(qǐng)求排除在TTI的訪問(wèn)更新之外或者用最后業(yè)務(wù)操作時(shí)間來(lái)判斷才算解決了。這個(gè)案例說(shuō)明TTI不是一個(gè)純粹的“最后一次讀取”概念在真實(shí)系統(tǒng)里什么是“有效訪問(wèn)”需要你自定義。5.3 學(xué)習(xí)建議從API到規(guī)范原文如果你正在準(zhǔn)備Java面試我建議不要只背JCache的API可以找一下規(guī)范原文重點(diǎn)讀關(guān)于ExpiryPolicy和CacheEntry的章節(jié)。那部分內(nèi)容寫(xiě)得很清楚會(huì)告訴你默認(rèn)策略是ETERNAL會(huì)告訴你實(shí)現(xiàn)必須支持哪些Duration語(yǔ)義也會(huì)告訴你訪問(wèn)操作如何影響過(guò)期時(shí)間。讀完規(guī)范再去看具體實(shí)現(xiàn)源碼你會(huì)發(fā)現(xiàn)很多“反直覺(jué)”的行為都有據(jù)可循。比如某些實(shí)現(xiàn)把TTL的檢查放在get路徑里某些實(shí)現(xiàn)用一個(gè)環(huán)形時(shí)間輪批量刪除過(guò)期條目。這些細(xì)節(jié)面試官未必會(huì)問(wèn)但你能聊出來(lái)就會(huì)讓整個(gè)回答從“背題”變成“懂行”。我個(gè)人在實(shí)際排查緩存問(wèn)題時(shí)最深的體會(huì)是與其對(duì)著具體緩存框架的配置項(xiàng)猜來(lái)猜去不如先把JCache這套最小語(yǔ)義吃透。TTL和TTI只是起點(diǎn)真正難的是理解規(guī)范方法背后的時(shí)機(jī)模型以及它在你當(dāng)前技術(shù)棧里落地時(shí)的各種偏差。把這道題當(dāng)成一次切入口順帶把ExpiryPolicy的源碼和規(guī)范原文過(guò)一遍絕對(duì)不虧。 JCache緩存過(guò)期策略：TTL與TTI的關(guān)鍵差異與實(shí)戰(zhàn)解析
1. 題面解析先把標(biāo)準(zhǔn)答案釘死最近又有人在群里貼出這道JCache基礎(chǔ)篇的面試題JCacheJSR-107標(biāo)準(zhǔn)要求實(shí)現(xiàn)必須支持哪兩種緩存過(guò)期策略題目很短答錯(cuò)率卻很高。有人脫口而出“TTL和TTI”有人愣一下說(shuō)“TTL和TTI不是一回事嗎”還有人干脆把“LRU和LFU”搬出來(lái)。說(shuō)實(shí)話能把LRU當(dāng)過(guò)期策略來(lái)答說(shuō)明對(duì)緩存兩個(gè)核心機(jī)制——過(guò)期和淘汰——還沒(méi)完全分清楚。今天就用實(shí)戰(zhàn)視角把這道題徹底拆開(kāi)從規(guī)范要求、接口設(shè)計(jì)、代碼驗(yàn)證到面試追問(wèn)一次說(shuō)透。1.1 標(biāo)準(zhǔn)答案TTL 與 TTI正確答案是JCacheJSR-107要求實(shí)現(xiàn)必須支持兩種基于時(shí)間的過(guò)期策略分別是TTLTime-To-Live存活時(shí)間和TTITime-To-Idle空閑時(shí)間。用JCache術(shù)語(yǔ)再翻譯一遍就是“基于條目創(chuàng)建時(shí)間的過(guò)期策略”和“基于最后訪問(wèn)時(shí)間的過(guò)期策略”。TTL的計(jì)時(shí)起點(diǎn)是緩存條目被創(chuàng)建或者被更新的時(shí)刻。比如設(shè)置TTL為5分鐘那么無(wú)論這5分鐘內(nèi)被讀取多少次只要到了時(shí)間點(diǎn)條目就該被視為過(guò)期。TTI的計(jì)時(shí)起點(diǎn)是最后一次成功的訪問(wèn)操作每次讀取都會(huì)讓計(jì)時(shí)器歸零重新開(kāi)始。所以一條數(shù)據(jù)如果持續(xù)被高頻讀取TTI會(huì)被不斷續(xù)期只有連續(xù)空閑超過(guò)設(shè)定時(shí)間它才會(huì)過(guò)期。這兩種策略解決的是完全不同的緩存場(chǎng)景后面會(huì)詳細(xì)展開(kāi)。但先記住這個(gè)結(jié)論規(guī)范里“必須支持”這四個(gè)字非常重要它不是建議而是所有合格實(shí)現(xiàn)的最低門(mén)檻。1.2 很多人掉進(jìn)去的坑過(guò)期策略不等于淘汰策略這道題最容易翻車的地方不是答不出TTL和TTI而是把過(guò)期策略和淘汰策略混為一談。過(guò)期策略關(guān)心的是“這個(gè)條目什么時(shí)候失效”核心是時(shí)間維度。緩存框架會(huì)在讀取時(shí)判斷條目是否過(guò)期或者通過(guò)后臺(tái)任務(wù)定期清理過(guò)期后再次get會(huì)得到null。淘汰策略關(guān)心的是“緩存空間滿了我該先扔掉誰(shuí)”核心是空間維度。LRULeast Recently Used淘汰最近最少使用的LFULeast Frequently Used淘汰訪問(wèn)頻率最低的這些東西解決的是容量壓力不是時(shí)間失效。一個(gè)典型場(chǎng)景用戶會(huì)話數(shù)據(jù)設(shè)置30分鐘TTI它不一定占滿空間但超過(guò)30分鐘不訪問(wèn)就該失效這是過(guò)期策略的活。如果緩存容量不夠我們可以用LRU把不常用的會(huì)話先擠掉這是淘汰策略的活。兩者可以共存但不能互相替代。面試官問(wèn)出這道題就是想看你能不能清晰區(qū)分這兩個(gè)維度。1.3 面試官問(wèn)這道題到底想考什么表面上它是一道送分題背下來(lái)就行。但面試官真正考察的是三個(gè)層次第一你是否知道JCache是Java官方的緩存規(guī)范它把緩存API標(biāo)準(zhǔn)化到了javax.cache這個(gè)包里JSR-107是這個(gè)規(guī)范的編號(hào)。第二你是否知道規(guī)范對(duì)實(shí)現(xiàn)方有強(qiáng)制性要求而不是只給了一堆可選的API。第三你是否能把兩種策略對(duì)應(yīng)到實(shí)際的業(yè)務(wù)場(chǎng)景而不是停留在背概念。所以答題時(shí)最好三步走先給出標(biāo)準(zhǔn)答案再解釋兩種策略的計(jì)時(shí)規(guī)則最后各配一個(gè)典型使用場(chǎng)景。這樣既展示了記憶準(zhǔn)確又體現(xiàn)了理解深度。下面我們就進(jìn)入規(guī)范背后的設(shè)計(jì)邏輯看看為什么偏偏是這兩種策略被強(qiáng)制要求。2. 規(guī)范背后的設(shè)計(jì)邏輯為什么非要強(qiáng)制這兩種JSR-107在制定時(shí)并不是拍腦袋定下“必須支持TTL和TTI”而是從大量緩存應(yīng)用中抽象出來(lái)的最低共識(shí)。如果你看過(guò)Caffeine、Guava、Redis這些緩存方案的源代碼或者配置項(xiàng)會(huì)發(fā)現(xiàn)它們都擺脫不了這兩個(gè)基本的失效維度。JCache只是把最核心的那個(gè)交集抽成了規(guī)范。2.1 從業(yè)務(wù)場(chǎng)景反推TTL 和 TTI 各自的價(jià)值先看TTL。它的語(yǔ)義是“從寫(xiě)入開(kāi)始計(jì)時(shí)到期就失效”。典型場(chǎng)景包括驗(yàn)證碼、臨時(shí)token、優(yōu)惠券快照、配置推送。比如一個(gè)活動(dòng)的商品價(jià)格頁(yè)我們從上游接口拉取價(jià)格后緩存60秒60秒后必須重新拉取這就是TTL。這類數(shù)據(jù)的特征非常明顯數(shù)據(jù)從出生開(kāi)始就有固定的保鮮期不管用戶看不看到期就得作廢。再看TTI。它的語(yǔ)義是“從上一次被訪問(wèn)開(kāi)始計(jì)時(shí)空閑超過(guò)閾值就失效”。典型場(chǎng)景是用戶登錄會(huì)話、表單填寫(xiě)狀態(tài)、需要高頻訪問(wèn)的熱點(diǎn)數(shù)據(jù)。比如一個(gè)用戶在電商網(wǎng)站瀏覽商品只要他不斷點(diǎn)擊會(huì)話就不該過(guò)期他離開(kāi)半小時(shí)后再回來(lái)會(huì)話應(yīng)該已經(jīng)失效。TTI對(duì)這種“有活動(dòng)就續(xù)命沒(méi)活動(dòng)就回收”的需求特別匹配。如果規(guī)范只要求支持一種實(shí)現(xiàn)方的自由度太大業(yè)務(wù)方一旦需要另一種就只能自己造輪子。如果要求支持太多比如把進(jìn)程內(nèi)緩存常用的弱引用、軟引用也納入強(qiáng)制那又會(huì)給分布式緩存實(shí)現(xiàn)造成巨大負(fù)擔(dān)。所以JCache選擇把TTL和TTI這兩個(gè)普適性最強(qiáng)的時(shí)間策略定為硬性要求。2.2 ExpiryPolicy三個(gè)方法對(duì)應(yīng)三種時(shí)機(jī)在JCache的javax.cache.expiry包里有一個(gè)核心接口ExpiryPolicy它定義了三個(gè)方法getExpiryForCreation、getExpiryForAccess、getExpiryForUpdate。getExpiryForCreation決定了條目剛創(chuàng)建時(shí)從哪個(gè)時(shí)刻開(kāi)始算過(guò)期TTL主要落在這里。getExpiryForAccess決定了條目在每次讀取命中后應(yīng)該被賦予多長(zhǎng)的續(xù)期TTI主要落在這里。getExpiryForUpdate決定了條目在更新值之后重新計(jì)算過(guò)期時(shí)間常見(jiàn)做法是把它當(dāng)TTL重新開(kāi)始計(jì)算。理解這三個(gè)方法比單純背TTL和TTI更接近規(guī)范本意。TTL不是一個(gè)獨(dú)立方法TTI也不是一個(gè)獨(dú)立方法它們都是ExpiryPolicy在不同訪問(wèn)時(shí)機(jī)下返回Duration的具體體現(xiàn)。規(guī)范要求實(shí)現(xiàn)必須支持“基于創(chuàng)建時(shí)間的過(guò)期”和“基于最后訪問(wèn)時(shí)間的過(guò)期”落到代碼層面就是默認(rèn)提供的ExpiryPolicyBuilder必須能幫你構(gòu)建出這兩種策略并且底層緩存必須能正確處理訪問(wèn)時(shí)間戳的更新。2.3 Duration 的黑話ZERO、ETERNAL 和負(fù)數(shù)ExpiryPolicy的三個(gè)方法返回的類型是javax.cache.expiry.Duration不是java.time.Duration這一點(diǎn)很容易踩坑。JCache的Duration內(nèi)部有兩個(gè)常量ZERO表示立即過(guò)期ETERNAL表示永不過(guò)期。ZERO的使用非常微妙。如果你在自定義ExpiryPolicy的getExpiryForAccess里返回Duration.ZERO意味著條目在創(chuàng)建后第一次訪問(wèn)就會(huì)立即過(guò)期這通常不是你想要的效果。ETERNAL則是默認(rèn)行為JCache默認(rèn)情況下緩存條目是永不過(guò)期的除非你顯式配置了過(guò)期策略。至于負(fù)數(shù)規(guī)范明確不允許返回負(fù)數(shù)。如果你傳入一個(gè)負(fù)的Duration輕則被忽略重則拋異常。所以生產(chǎn)環(huán)境里如果有外部配置的動(dòng)態(tài)過(guò)期時(shí)間一定先做鉗制校驗(yàn)別把負(fù)數(shù)傳給ExpiryPolicyBuilder。這個(gè)細(xì)節(jié)在面試追問(wèn)里很常見(jiàn)也是實(shí)際開(kāi)發(fā)中容易被忽略的坑。3. 代碼實(shí)操親手驗(yàn)證兩種過(guò)期策略講原理總歸有點(diǎn)虛我們直接寫(xiě)代碼驗(yàn)證。這里只使用JCache規(guī)范提供的接口具體實(shí)現(xiàn)只需要選擇一個(gè)實(shí)現(xiàn)了JSR-107的開(kāi)源庫(kù)放到classpath里。為了避免被具體廠商牽著走我會(huì)盡量保持代碼只依賴javax.cache的標(biāo)準(zhǔn)API。3.1 環(huán)境準(zhǔn)備只依賴規(guī)范接口也能跑首先引入JCache API。如果你的項(xiàng)目是Maven結(jié)構(gòu)依賴坐標(biāo)一般是group為javax.cache、artifact為cache-api的jar這是官方規(guī)范接口。還需要一個(gè)具體的JCache實(shí)現(xiàn)類庫(kù)每個(gè)實(shí)現(xiàn)的坐標(biāo)不同這里就不展開(kāi)寫(xiě)死你自己選一個(gè)主流的JSR-107實(shí)現(xiàn)即可。然后我們需要一段最基礎(chǔ)的初始化代碼獲取CachingProvider和CacheManagerimport javax.cache.Cache; import javax.cache.CacheManager; import javax.cache.Caching; import javax.cache.configuration.MutableConfiguration; import javax.cache.expiry.Duration; import javax.cache.expiry.ExpiryPolicy; import javax.cache.expiry.ExpiryPolicyBuilder; import javax.cache.spi.CachingProvider; import java.time.temporal.ChronoUnit; import java.util.concurrent.TimeUnit; CachingProvider provider Caching.getCachingProvider(); CacheManager cacheManager provider.getCacheManager(); MutableConfigurationString, String config new MutableConfiguration(); CacheString, String cache cacheManager.createCache(demo-cache, config);這里要提醒一點(diǎn)同一個(gè)CacheManager里創(chuàng)建同名緩存會(huì)拋異常。如果你反復(fù)調(diào)試要么換緩存名要么在創(chuàng)建前先判斷緩存是否存在。另外CacheManager本身也是一個(gè)資源用完最好調(diào)用close()尤其在單元測(cè)試?yán)镱l繁創(chuàng)建時(shí)不關(guān)閉可能會(huì)把內(nèi)存堆滿。3.2 配置 TTL5秒后必然消失下面創(chuàng)建一個(gè)TTL為5秒的緩存。我習(xí)慣用lambda給setExpiryPolicyFactory傳參代碼短意圖也清楚MutableConfigurationString, String ttlConfig new MutableConfiguration(); ttlConfig.setExpiryPolicyFactory(() - ExpiryPolicyBuilder.timeToLiveExpiry(Duration.ofSeconds(5))); CacheString, String ttlCache cacheManager.createCache(ttl-demo, ttlConfig); ttlCache.put(orderId, 20250514001); System.out.println(ttlCache.get(orderId)); // 輸出20250514001 TimeUnit.SECONDS.sleep(6); System.out.println(ttlCache.get(orderId)); // 輸出null運(yùn)行之后你會(huì)發(fā)現(xiàn)第一個(gè)get正常返回第二個(gè)get返回null。這就是TTL從put那一刻開(kāi)始倒計(jì)時(shí)5秒期間不管你怎么get計(jì)時(shí)都不會(huì)重置。這里有一個(gè)值得注意的實(shí)現(xiàn)差異有些JCache實(shí)現(xiàn)是惰性過(guò)期也就是get時(shí)才檢查時(shí)間戳有些實(shí)現(xiàn)會(huì)有后臺(tái)線程定期清理。所以你在第5秒整去get結(jié)果可能是null也可能還沒(méi)被物理刪除但邏輯上一定不能返回舊值。規(guī)范要求的是“看起來(lái)過(guò)期”不強(qiáng)制物理刪除時(shí)機(jī)。3.3 配置 TTI訪問(wèn)之后計(jì)時(shí)器重新歸零TTI的驗(yàn)證稍微繞一點(diǎn)需要模擬“訪問(wèn)后重置”MutableConfigurationString, String ttiConfig new MutableConfiguration(); ttiConfig.setExpiryPolicyFactory(() - ExpiryPolicyBuilder.timeToIdleExpiry(Duration.ofSeconds(5))); CacheString, String ttiCache cacheManager.createCache(tti-demo, ttiConfig); ttiCache.put(sessionId, abc123); TimeUnit.SECONDS.sleep(3); System.out.println(ttiCache.get(sessionId)); // 輸出abc123訪問(wèn)把過(guò)期時(shí)間續(xù)到了第8秒 TimeUnit.SECONDS.sleep(3); System.out.println(ttiCache.get(sessionId)); // 輸出abc123距離最后一次訪問(wèn)只過(guò)去3秒未過(guò)期 TimeUnit.SECONDS.sleep(6); System.out.println(ttiCache.get(sessionId)); // 輸出null最后訪問(wèn)后又空閑了6秒超過(guò)5秒閾值這里的邏輯可以這樣理解第一次sleep 3秒時(shí)訪問(wèn)了一次空閑計(jì)時(shí)器被重置過(guò)期時(shí)間點(diǎn)從原來(lái)的第5秒推遲到了第8秒。第二次sleep 3秒后再次訪問(wèn)又重置到第11秒。最后一次連續(xù)空閑6秒超過(guò)5秒于是過(guò)期。TTI在分布式場(chǎng)景里有個(gè)經(jīng)典坑多個(gè)節(jié)點(diǎn)同時(shí)訪問(wèn)同一個(gè)key每個(gè)節(jié)點(diǎn)都會(huì)更新自己的本地訪問(wèn)時(shí)間但如果沒(méi)有統(tǒng)一的訪問(wèn)時(shí)間存儲(chǔ)TTI就名存實(shí)亡。這一點(diǎn)面試官如果追問(wèn)你可以補(bǔ)充“TTL比TTI更容易在分布式環(huán)境下實(shí)現(xiàn)”。3.4 組合策略和自定義防御式寫(xiě)法如果業(yè)務(wù)要求“最長(zhǎng)TTL是10分鐘但連續(xù)空閑3分鐘就過(guò)期”JCache內(nèi)置的builder沒(méi)法直接組合。規(guī)范只強(qiáng)制分別支持TTL和TTI并不保證二者的組合語(yǔ)義。這時(shí)候你需要自己實(shí)現(xiàn)一個(gè)ExpiryPolicypublic class CombinedExpiryPolicy implements ExpiryPolicy { private final Duration ttl; private final Duration tti; public CombinedExpiryPolicy(Duration ttl, Duration tti) { this.ttl ttl; this.tti tti; } Override public Duration getExpiryForCreation() { return ttl; } Override public Duration getExpiryForAccess() { return tti; } Override public Duration getExpiryForUpdate() { return ttl; } }別急著把這段代碼直接上生產(chǎn)這里有一個(gè)語(yǔ)義陷阱創(chuàng)建時(shí)返回ttl但第一次訪問(wèn)后getExpiryForAccess返回tti會(huì)把原有的ttl覆蓋掉。也就是說(shuō)如果創(chuàng)建后第5秒你訪問(wèn)了一次后續(xù)實(shí)際過(guò)期時(shí)間就變成了“這次訪問(wèn)后的3分鐘”而不是原來(lái)剩余的ttl。真正要同時(shí)保證“最長(zhǎng)不超過(guò)10分鐘”和“空閑超過(guò)3分鐘過(guò)期”必須在getExpiryForAccess里做計(jì)算取剩余TTL和新的TTI中更早的那個(gè)。這個(gè)計(jì)算邏輯實(shí)現(xiàn)難度不大但需要緩存框架能拿到“當(dāng)前時(shí)間”和“已存活時(shí)間”JCache規(guī)范并沒(méi)有統(tǒng)一暴露這些內(nèi)部時(shí)間戳。所以更務(wù)實(shí)的做法是在業(yè)務(wù)代碼里做好定時(shí)續(xù)期或過(guò)期判斷不要過(guò)度依賴自定義組合策略。4. 常見(jiàn)問(wèn)題與排查技巧實(shí)錄這塊內(nèi)容來(lái)自我實(shí)際接手的幾個(gè)項(xiàng)目問(wèn)題很多坑不是配置錯(cuò)了而是大家對(duì)“過(guò)期”這個(gè)動(dòng)作的理解有偏差。4.1 過(guò)期條目為什么不會(huì)立刻物理刪除這是剛開(kāi)始用JCache時(shí)最常見(jiàn)的困惑TTL設(shè)了5秒sleep6秒后一查內(nèi)存緩存條目還在只是get不到了。原因很簡(jiǎn)單JCache規(guī)范只要求“get的時(shí)候必須返回null”并沒(méi)有強(qiáng)制要求實(shí)現(xiàn)必須同步刪除物理?xiàng)l目。有些實(shí)現(xiàn)采用惰性刪除只有訪問(wèn)過(guò)期條目時(shí)才真正移除有些實(shí)現(xiàn)使用后臺(tái)清理線程每隔一段時(shí)間掃描刪除。從用戶視角看條目邏輯上已經(jīng)過(guò)期物理殘留與否不影響正確性但會(huì)影響內(nèi)存占用。如果你的緩存容器長(zhǎng)期存在大量過(guò)期條目?jī)?nèi)存曲線會(huì)越來(lái)越難看的。這時(shí)可以去你的JCache實(shí)現(xiàn)里找有沒(méi)有“定期清理”的配置項(xiàng)把清理間隔適當(dāng)調(diào)小或者手動(dòng)遍歷緩存并觸發(fā)get來(lái)加速失效。不過(guò)這類操作在分布式緩存上要小心遍歷大緩存可能拖垮線上性能。4.2 為什么TTI緩存在高并發(fā)下看著像“永遠(yuǎn)不過(guò)期”這是TTI的天然特性只要每個(gè)請(qǐng)求都來(lái)訪問(wèn)這個(gè)key空閑計(jì)時(shí)器就一直在重置理論上這個(gè)key永遠(yuǎn)不會(huì)因?yàn)門(mén)TI過(guò)期。如果你的訪問(wèn)量非常高TTI緩存里的所謂“熱點(diǎn)數(shù)據(jù)”可能會(huì)長(zhǎng)時(shí)間不失效導(dǎo)致數(shù)據(jù)新鮮度變差。我之前遇到過(guò)一個(gè)問(wèn)題團(tuán)隊(duì)用TTI緩存一套價(jià)格規(guī)則想著3分鐘不訪問(wèn)就作廢結(jié)果這套規(guī)則是全站每個(gè)請(qǐng)求都會(huì)讀的TTI永遠(yuǎn)被續(xù)期價(jià)格規(guī)則幾乎一整天都沒(méi)有重新加載。最后改成TTL才解決問(wèn)題。所以選型時(shí)要想清楚如果你希望數(shù)據(jù)必須定期重新拉取不管有沒(méi)有人訪問(wèn)請(qǐng)用TTL。如果你只希望清理那些長(zhǎng)時(shí)間沒(méi)人用的數(shù)據(jù)用TTI。二者沒(méi)有優(yōu)劣只有適用場(chǎng)景不同。4.3 五大高頻坑不是配置錯(cuò)了是理解錯(cuò)了現(xiàn)象根因解決建議設(shè)置了TTL但緩存一直有效用的可能是Caffeine的expireAfterWrite但JCache適配層沒(méi)真正應(yīng)用檢查配置是否傳到了底層Cache的expiryPolicyFactoryget之后TTI不重置實(shí)現(xiàn)可能只在寫(xiě)操作時(shí)更新時(shí)間戳查JCache實(shí)現(xiàn)文檔確認(rèn)是否支持讀續(xù)期Duration傳入負(fù)數(shù)JCache規(guī)范要求Duration非負(fù)配置來(lái)源處做Integer/Duration校驗(yàn)自定義ExpiryPolicy返回null方法返回值不能隨意給null默認(rèn)返回Duration.ETERNAL或顯式指定同一CacheManager重復(fù)createCache同名緩存已存在會(huì)拋異常用cacheManager.getCache(name)判斷或try-catch這些坑在單個(gè)實(shí)現(xiàn)里不一定會(huì)全遇到但它們都有共性不要拿“用過(guò)某個(gè)緩存框架”就直接替代對(duì)規(guī)范的理解。JCache是API標(biāo)準(zhǔn)底層實(shí)現(xiàn)各有各的實(shí)現(xiàn)策略面試官其實(shí)很愛(ài)從這個(gè)角度問(wèn)下去。4.4 這種Error/Exception到底怎么排查有一次線上緩存突然大量失效日志里刷“expiry duration is not positive”一類的錯(cuò)誤。排查后發(fā)現(xiàn)是我們一個(gè)外部配置項(xiàng)傳了負(fù)數(shù)配置中心改了數(shù)據(jù)但代碼沒(méi)做鉗制。后來(lái)我總結(jié)了一條排查路徑第一復(fù)現(xiàn)時(shí)先看配置的Duration到底是多少第二在自定義ExpiryPolicy的三個(gè)方法入口加日志打印每次返回的Duration第三確認(rèn)實(shí)現(xiàn)是否啟用后臺(tái)清理線程把清理日志打開(kāi)第四區(qū)分緩存命中不到底是因?yàn)檫^(guò)期還是因?yàn)樘蕴?。這四條走完大部分問(wèn)題都能定位。5. 面試答題的節(jié)奏與我的實(shí)戰(zhàn)感受這道題雖然簡(jiǎn)單但答得好不好很能拉開(kāi)差距。下面給出一個(gè)我驗(yàn)證過(guò)比較好用的答題結(jié)構(gòu)以及一些面試之外的實(shí)際心得。5.1 一個(gè)可以直接復(fù)用的答題模板面試官問(wèn)出“JCache標(biāo)準(zhǔn)要求實(shí)現(xiàn)必須支持哪兩種緩存過(guò)期策略”時(shí)你可以這樣回答第一層給結(jié)論必須支持TTL和TTI也就是基于創(chuàng)建時(shí)間的過(guò)期和基于最后訪問(wèn)時(shí)間的過(guò)期。第二層解釋差異TTL從寫(xiě)入開(kāi)始計(jì)時(shí)訪問(wèn)不會(huì)重置TTI從上次訪問(wèn)開(kāi)始計(jì)時(shí)每次命中會(huì)續(xù)期。第三層落場(chǎng)景比如驗(yàn)證碼用TTL用戶會(huì)話用TTI。第四層補(bǔ)深度JCache里的ExpiryPolicy接口有三個(gè)方法分別對(duì)應(yīng)創(chuàng)建、訪問(wèn)、更新三種時(shí)機(jī)TTL和TTI的本質(zhì)是這三個(gè)方法在不同時(shí)機(jī)返回不同Duration。如果面試官追問(wèn)“淘汰策略和過(guò)期策略的區(qū)別”你還可以順帶說(shuō)一句LRU、LFU這類淘汰策略和TTL、TTI不沖突前者管容量后者管時(shí)效。這樣整個(gè)回答就立體起來(lái)了。5.2 我在項(xiàng)目里踩過(guò)的TTI續(xù)期坑說(shuō)一個(gè)我自己的真實(shí)經(jīng)歷。當(dāng)時(shí)做一個(gè)活動(dòng)頁(yè)面需要把用戶最近瀏覽過(guò)的商品列表緩存起來(lái)30分鐘不活躍就清空。我當(dāng)時(shí)很自然地選了TTI覺(jué)得非常合適。結(jié)果上線后發(fā)現(xiàn)一個(gè)問(wèn)題只要用戶在活動(dòng)頁(yè)掛著不動(dòng)每5分鐘會(huì)有一個(gè)前端心跳請(qǐng)求打過(guò)來(lái)把整個(gè)列表的TTI不斷續(xù)期導(dǎo)致用戶其實(shí)早就沒(méi)看了但緩存里還是裝著半小時(shí)前的瀏覽記錄。后來(lái)我把心跳請(qǐng)求排除在TTI的訪問(wèn)更新之外或者用最后業(yè)務(wù)操作時(shí)間來(lái)判斷才算解決了。這個(gè)案例說(shuō)明TTI不是一個(gè)純粹的“最后一次讀取”概念在真實(shí)系統(tǒng)里什么是“有效訪問(wèn)”需要你自定義。5.3 學(xué)習(xí)建議從API到規(guī)范原文如果你正在準(zhǔn)備Java面試我建議不要只背JCache的API可以找一下規(guī)范原文重點(diǎn)讀關(guān)于ExpiryPolicy和CacheEntry的章節(jié)。那部分內(nèi)容寫(xiě)得很清楚會(huì)告訴你默認(rèn)策略是ETERNAL會(huì)告訴你實(shí)現(xiàn)必須支持哪些Duration語(yǔ)義也會(huì)告訴你訪問(wèn)操作如何影響過(guò)期時(shí)間。讀完規(guī)范再去看具體實(shí)現(xiàn)源碼你會(huì)發(fā)現(xiàn)很多“反直覺(jué)”的行為都有據(jù)可循。比如某些實(shí)現(xiàn)把TTL的檢查放在get路徑里某些實(shí)現(xiàn)用一個(gè)環(huán)形時(shí)間輪批量刪除過(guò)期條目。這些細(xì)節(jié)面試官未必會(huì)問(wèn)但你能聊出來(lái)就會(huì)讓整個(gè)回答從“背題”變成“懂行”。我個(gè)人在實(shí)際排查緩存問(wèn)題時(shí)最深的體會(huì)是與其對(duì)著具體緩存框架的配置項(xiàng)猜來(lái)猜去不如先把JCache這套最小語(yǔ)義吃透。TTL和TTI只是起點(diǎn)真正難的是理解規(guī)范方法背后的時(shí)機(jī)模型以及它在你當(dāng)前技術(shù)棧里落地時(shí)的各種偏差。把這道題當(dāng)成一次切入口順帶把ExpiryPolicy的源碼和規(guī)范原文過(guò)一遍絕對(duì)不虧。