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