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