面試官拋來(lái)一個(gè)很基礎(chǔ)的問(wèn)題你 Service 里注入了一個(gè) Mapper 接口方法名寫好了SQL 寫在 XML 里但接口根本沒(méi)有實(shí)現(xiàn)類這一調(diào)怎么就執(zhí)行了緊接著又問(wèn)同一個(gè)事務(wù)里同一個(gè)查詢調(diào)兩次走緩存嗎一級(jí)緩存和二級(jí)緩存誰(shuí)在前大多數(shù)平時(shí)寫業(yè)務(wù)的人能用但真被問(wèn)到就有點(diǎn)卡殼。這篇文章不繞圈子直接從源碼拆 MyBatis 的 Mapper 動(dòng)態(tài)代理、一級(jí)緩存和二級(jí)緩存的完整鏈路最后再給幾個(gè)實(shí)戰(zhàn)中排查緩存、打印 SQL、自定義緩存的操作既能當(dāng)面試復(fù)習(xí)材料也能當(dāng)項(xiàng)目排坑手冊(cè)。1. Mapper 動(dòng)態(tài)代理為什么接口沒(méi)有實(shí)現(xiàn)類也能干活1.1 從 JDBC 到 Mapper 接口你少寫了的那層膠水回想沒(méi)用 MyBatis 的時(shí)候?qū)懸粋€(gè)數(shù)據(jù)庫(kù)操作要經(jīng)歷什么獲取 Connection創(chuàng)建 PreparedStatement手動(dòng) setParameter執(zhí)行 executeQuery再手動(dòng)遍歷 ResultSet 轉(zhuǎn)成對(duì)象最后還要關(guān)掉一堆資源。后來(lái)用 MyBatis你只需要定義接口方法、寫一個(gè) XML 里的 SQL或者用注解寫一行 SQL然后在 Service 里直接注入 Mapper 調(diào)方法。中間那幾千行樣板代碼全部消失了。但這引出第一個(gè)疑問(wèn)接口不能 newMyBatis 到底往接口里塞了什么答案不是字節(jié)碼增強(qiáng)插樁而是 JDK 自帶的一個(gè)通行做法——?jiǎng)討B(tài)代理。MyBatis 在啟動(dòng)階段掃描 Mapper 接口給每個(gè)接口生成一個(gè)代理對(duì)象你調(diào)用接口方法實(shí)際上是調(diào)到了代理對(duì)象的 invoke 方法上。代理內(nèi)部再做兩件事定位這條 SQL然后交給 SqlSession 去執(zhí)行。1.2 MapperProxy 與 Proxy.newProxyInstance動(dòng)態(tài)代理的入口所有 Mapper 接口代理的源頭在MapperRegistry。MyBatis 啟動(dòng)解析配置文件時(shí)會(huì)把你配置的每個(gè) Mapper 接口通過(guò)registry.addMapper(Class)注冊(cè)進(jìn)去每個(gè)接口對(duì)應(yīng)生成一個(gè)MapperProxyFactory。后面你需要這個(gè)接口的實(shí)例時(shí)工廠調(diào)用public T newInstance(SqlSession sqlSession) { MapperProxyT mapperProxy new MapperProxy(sqlSession, mapperInterface, methodCache); return newInstance(mapperProxy); } protected T newInstance(MapperProxyT mapperProxy) { return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy); }關(guān)鍵就在Proxy.newProxyInstance它要求目標(biāo)必須是接口Mapper 恰好是接口然后動(dòng)態(tài)生成一個(gè)實(shí)現(xiàn)這些接口的代理類。以后你調(diào)用userMapper.selectById(1)其實(shí)是調(diào)用到MapperProxy.invoke上。很多初學(xué)者會(huì)把 Spring AOP 和這個(gè)搞混。這里沒(méi)有 CGLIB、沒(méi)有 Aspect 切面就是 JDK 原生動(dòng)態(tài)代理。也正因如此Mapper 接口在設(shè)計(jì)上天生不能被寫成普通類只能接口否則就無(wú)法走 JDK 代理這條路。1.3 MapperMethod 的分發(fā)邏輯一個(gè)方法如何找到對(duì)應(yīng)的 SQLinvoke方法并不直接執(zhí)行 SQL它先過(guò)濾掉Object類的方法比如toString、hashCode、equals剩下的業(yè)務(wù)方法交給MapperMethod處理public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { if (Object.class.equals(method.getDeclaringClass())) { return method.invoke(this, args); } return cachedInvoker(method).invoke(proxy, method, args, sqlSession); }MapperMethod構(gòu)造時(shí)會(huì)解析兩樣?xùn)|西SqlCommand和MethodSignature。SqlCommand做的是從方法名去Configuration.mappedStatements里找對(duì)應(yīng)的MappedStatement并根據(jù) SQL 類型分成 UNKNOWN、INSERT、UPDATE、DELETE、SELECT。MethodSignature做的是解析方法參數(shù)搞清楚有多少個(gè)參數(shù)、是否需要Param注解、返回類型是 List 還是單個(gè)對(duì)象、有沒(méi)有分頁(yè)參數(shù)等。真正執(zhí)行時(shí)execute方法會(huì)按 SQL 命令類型分發(fā)switch (command.getType()) { case INSERT: { return sqlSession.insert(command.getName(), param); } case SELECT: { if (method.returnsVoid() method.hasResultHandler()) { sqlSession.select(command.getName(), param, method.getResultHandler()); return null; } else if (method.returnsMany()) { return sqlSession.selectList(command.getName(), param); } else { return sqlSession.selectOne(command.getName(), param); } } ... }到這里一個(gè) Mapper 方法被映射成了一次普通的 SqlSession 調(diào)用。剩下的查詢過(guò)程就進(jìn)入 Executor 鏈路也就是緩存發(fā)揮作用的地方。提示如果你在自定義攔截器里想拿到 Mapper 方法的注解或方法名通常是通過(guò)Invocation.getArgs()[0]即 mappedStatement.getId()反推Mapper接口的完全限定名和方法名原理就是這里講的動(dòng)態(tài)代理鏈路。2. 一級(jí)緩存藏在 Executor 里的那張查重表2.1 一級(jí)緩存的數(shù)據(jù)結(jié)構(gòu)PerpetualCache 與 CacheKey一級(jí)緩存官方叫 Local Cache作用域是 SqlSession 級(jí)別。大多數(shù)人知道它存在但不知道它長(zhǎng)什么樣。其實(shí) MyBatis 的緩存實(shí)現(xiàn)很樸素緩存對(duì)象統(tǒng)一實(shí)現(xiàn)Cache接口一級(jí)緩存用的是PerpetualCache內(nèi)部就是一個(gè)普通HashMappublic class PerpetualCache implements Cache { private final String id; private final MapObject, Object cache new HashMap(); }注意這個(gè) HashMap 沒(méi)有任何加鎖保護(hù)所以一級(jí)緩存不是線程安全的它天然只服務(wù)于當(dāng)前 SqlSession。那緩存 key 是什么不能簡(jiǎn)單拿 SQL 字符串做 key因?yàn)橥粋€(gè) SQL 傳不同參數(shù)就是不同結(jié)果。MyBatis 封裝了一個(gè)CacheKey核心字段包括MappedStatement 的 id、查詢 SQL、參數(shù)對(duì)象、RowBounds 偏移量甚至還會(huì)往里追加一些環(huán)境標(biāo)識(shí)。最終生成一個(gè) hash 值作為 HashMap 的 key。所以“同一條 SQL 但參數(shù)不同”“同一個(gè)方法但 offset/limit 不同”都會(huì)被識(shí)別為不同緩存項(xiàng)。2.2 什么情況命中、什么情況失效一次完整查詢的判定過(guò)程一級(jí)緩存的查詢動(dòng)作發(fā)生在BaseExecutor.query。這段邏輯是整個(gè)緩存體系的心臟值得記清楚先從 BoundSql 和參數(shù)構(gòu)建出 CacheKey。查一級(jí)緩存localCache.getObject(key)。如果有值直接返回如果沒(méi)值進(jìn)入數(shù)據(jù)庫(kù)查詢queryFromDatabase查到結(jié)果后放進(jìn)localCache。返回結(jié)果前如果當(dāng)前處于嵌套查詢中還要把結(jié)果保存到localOutputParameterCache這是處理存儲(chǔ)過(guò)程輸出參數(shù)的細(xì)節(jié)。那么什么時(shí)候清空四個(gè)時(shí)機(jī)執(zhí)行了任意 insert/update/delete。因?yàn)閷懖僮骱髷?shù)據(jù)變了再拿著舊緩存沒(méi)意義MyBatis 默認(rèn)在寫操作前執(zhí)行clearLocalCache()。手動(dòng)調(diào)用sqlSession.commit()、rollback()或close()。在select標(biāo)簽上顯式設(shè)置flushCachetrue每次查詢前先清緩存。查詢涉及嵌套結(jié)果映射且localCacheScope設(shè)置為 STATEMENT 時(shí)每條語(yǔ)句結(jié)束后清緩存。這里有個(gè)容易踩的坑一級(jí)緩存默認(rèn)就是開啟的不需要任何配置。同一個(gè) SqlSession 里前一個(gè) SQL 查過(guò)的數(shù)據(jù)下一次完全相同的查詢直接命中緩存根本不走數(shù)據(jù)庫(kù)?？雌饋?lái)是好事但如果你的業(yè)務(wù)場(chǎng)景是“同一個(gè)事務(wù)里先查一次然后別的系統(tǒng)改了庫(kù)你再查一次想拿最新數(shù)據(jù)”拿到的還是舊值。這不是 bug是緩存語(yǔ)義如此。2.3 最容易誤解的一點(diǎn)Spring 整合后一級(jí)緩存并不是全程有效單獨(dú)用 MyBatis 時(shí)SqlSession 生命周期由你控制一級(jí)緩存的行為很好理解。但到了 Spring/Spring Boot 中事情就變了你的 Service 通常沒(méi)開事務(wù)也沒(méi)手動(dòng)拿 SqlSession一切靠SqlSessionTemplate和SqlSessionInterceptor代理。SqlSessionTemplate內(nèi)部每次調(diào)用方法會(huì)通過(guò)SqlSessionUtils.getSqlSession()獲取 SqlSession。如果你當(dāng)前沒(méi)有 Spring 事務(wù)這個(gè)方法會(huì)新建一個(gè) SqlSession用完后立刻 close。兩次獨(dú)立的 Mapper 調(diào)用其實(shí)是兩個(gè)不同的 SqlSession一級(jí)緩存完全不共享等于每次查詢都重新查庫(kù)。一旦 Service 方法加上Transactional情況就不同了Spring 事務(wù)管理器會(huì)把 SqlSession 和事務(wù)綁定在當(dāng)前線程上整個(gè)事務(wù)范圍內(nèi)的多次查詢復(fù)用同一個(gè) SqlSession一級(jí)緩存這才真正生效。所以你在網(wǎng)上會(huì)看到兩種矛盾的說(shuō)法有人說(shuō) MyBatis 一級(jí)緩存默認(rèn)開啟很好用有人說(shuō)自己試了發(fā)現(xiàn)沒(méi)用。兩種說(shuō)法都對(duì)區(qū)別就在于是不是處在 Spring 事務(wù)中。這也是一個(gè)非常經(jīng)典的面試考點(diǎn)。提示如果在 Spring 環(huán)境里你確實(shí)想模擬“每次查詢強(qiáng)制走庫(kù)”最干凈的辦法是在對(duì)應(yīng)的 select 標(biāo)簽上加flushCachetrue而不是幻想著關(guān)掉一級(jí)緩存本身。MyBatis 雖然給了localCacheScopeSTATEMENT這個(gè)配置但它清緩存的動(dòng)作在 Spring 無(wú)事務(wù)環(huán)境下意義不大因?yàn)?SqlSession 本身已經(jīng)是全新的了。3. 二級(jí)緩存namespace 邊界上的共享倉(cāng)庫(kù)3.1 開啟二級(jí)緩存的條件cacheEnabled 與 標(biāo)簽缺一不可二級(jí)緩存作用域是 namespace也就是一個(gè) Mapper 接口/XML 文件對(duì)應(yīng)一個(gè)緩存?zhèn)}庫(kù)。網(wǎng)上不少人搞混一件事mybatis.configuration.cache-enabled默認(rèn)是 true就以為默認(rèn)開了二級(jí)緩存。實(shí)際上cacheEnabled只決定Configuration.newExecutor時(shí)要不要給你的 Executor 套上CachingExecutor裝飾器。真正的開關(guān)還有一道你的 Mapper XML 里必須寫了cache標(biāo)簽或者通過(guò)注解CacheNamespace啟用。兩道閘都打開后查詢鏈路就變成CachingExecutor先查二級(jí)緩存。二級(jí)緩存沒(méi)命中進(jìn)入BaseExecutor查一級(jí)緩存。一級(jí)緩存也沒(méi)有查數(shù)據(jù)庫(kù)。兩個(gè)緩存的作用域差異決定了一級(jí)緩存是會(huì)話私有的二級(jí)緩存是 namespace 內(nèi)多個(gè) SqlSession 共享的。這也是它名字里“二級(jí)”的意義——跨會(huì)話共享。3.2 TransactionalCache為什么要等事務(wù)提交才真正寫入二級(jí)緩存最容易讓人想當(dāng)然的地方是寫入時(shí)機(jī)?？碈achingExecutor.query源碼命中二級(jí)緩存直接返回沒(méi)命中查詢數(shù)據(jù)庫(kù)后它并不會(huì)立刻把結(jié)果放進(jìn)二級(jí)緩存而是先放進(jìn)一個(gè)TransactionalCache的臨時(shí)區(qū)。TransactionalCache內(nèi)部有兩個(gè)關(guān)鍵結(jié)構(gòu)entriesToAddOnCommit本事務(wù)內(nèi)準(zhǔn)備寫入二級(jí)緩存的數(shù)據(jù)先放這里。entriesMissedInCache本事務(wù)內(nèi)查過(guò)但沒(méi)命中的 key 也先記下來(lái)提交時(shí)把這些 key 標(biāo)記為“緩存了空值”。只有當(dāng) SqlSession 提交時(shí)TransactionalCacheManager.commit()才會(huì)把entriesToAddOnCommit真正刷進(jìn)二級(jí)緩存?zhèn)}庫(kù)。為什么這樣設(shè)計(jì)因?yàn)槿绻愕牟樵冞€沒(méi)提交就寫進(jìn)二級(jí)緩存另一個(gè) SqlSession 可能讀到一條事務(wù)未提交的數(shù)據(jù)這就是臟讀。MyBatis 用一個(gè)“延遲寫入提交時(shí)落庫(kù)”的機(jī)制規(guī)避了這個(gè)問(wèn)題。同時(shí)事務(wù)回滾時(shí)會(huì)調(diào)用rollback()把臨時(shí)區(qū)數(shù)據(jù)直接丟棄避免已回滾的數(shù)據(jù)進(jìn)入共享緩存。理解了這一點(diǎn)你就明白為什么有人遇到“明明查了數(shù)據(jù)二級(jí)緩存命中率卻不高”——大概率是 SqlSession 一直沒(méi)提交數(shù)據(jù)始終壓在臨時(shí)區(qū)里。3.3 readOnly、flushInterval、eviction 這些參數(shù)到底改了什么cache標(biāo)簽的典型配置長(zhǎng)這樣cache evictionLRU flushInterval60000 size512 readOnlytrue /每個(gè)參數(shù)背后都對(duì)應(yīng)一個(gè)裝飾器參數(shù)默認(rèn)值作用對(duì)應(yīng)實(shí)現(xiàn)evictionLRU緩存淘汰策略控制容量滿時(shí)移除誰(shuí)LruCache、FifoCacheflushInterval無(wú)定時(shí)清空緩存的毫秒數(shù)到期后下次查詢會(huì)刷新倉(cāng)庫(kù)ScheduledCachesize1024最多緩存多少個(gè)對(duì)象引用外層裝飾器控制readOnlyfalse返回緩存對(duì)象的策略SerializedCachereadOnly是最值得展開的參數(shù)。默認(rèn)readOnlyfalse時(shí)二級(jí)緩存返回的對(duì)象不是原來(lái)那個(gè)實(shí)例而是通過(guò)序列化反序列化復(fù)制出來(lái)的副本。這就強(qiáng)制要求所有放進(jìn)二級(jí)緩存的對(duì)象實(shí)現(xiàn)Serializable接口。好處是安全調(diào)用方隨便改返回對(duì)象都不會(huì)污染緩存?zhèn)}庫(kù)里的原數(shù)據(jù)。壞處是性能開銷大每次命中都要做一次序列化拷貝。readOnlytrue時(shí)MyBatis 直接返回緩存里那個(gè)對(duì)象引用性能高很多但調(diào)用方一旦修改對(duì)象倉(cāng)庫(kù)里的數(shù)據(jù)也跟著變。業(yè)務(wù)代碼如果沒(méi)意識(shí)到這一點(diǎn)很容易出現(xiàn)“緩存被悄悄改掉”的詭異問(wèn)題。我的建議是只有確認(rèn)對(duì)象不會(huì)被修改、且讀取極頻繁的場(chǎng)景才用readOnlytrue否則老老實(shí)實(shí)保持默認(rèn)。3.4 多表關(guān)聯(lián)場(chǎng)景下的臟數(shù)據(jù)為什么大家都說(shuō)二級(jí)緩存要慎用二級(jí)緩存有一個(gè)先天短板它只知道 namespace不知道你 SQL 里到底碰了哪些表。舉個(gè)例子OrderMapper里有個(gè)查詢 join 了user表查出來(lái)的訂單列表帶著用戶昵稱這些數(shù)據(jù)被放進(jìn)了OrderMapper的二級(jí)緩存。另一個(gè)UserMapper執(zhí)行更新MyBatis 只清UserMapper自己的緩存OrderMapper緩存里那些舊昵稱還在。下次再查訂單命中的是臟數(shù)據(jù)。這就是二級(jí)緩存臟讀的經(jīng)典場(chǎng)景。官方文檔對(duì)此的表述很含蓄但業(yè)內(nèi)實(shí)踐早就形成共識(shí)二級(jí)緩存適合字典表、配置表這類極少更新的只讀數(shù)據(jù)不適合頻繁變更的業(yè)務(wù)主表尤其不適合 join 查詢很多的接口。如果一定要在多 Mapper 間共享一塊緩存可以用cache-ref namespace其他Mapper全限定名/讓兩個(gè) namespace 指向同一個(gè)緩存?zhèn)}庫(kù)但你要在業(yè)務(wù)上保證所有變更語(yǔ)句都會(huì)刷到同一個(gè)倉(cāng)庫(kù)否則還是躲不過(guò)臟讀。提示項(xiàng)目里遇到“改了數(shù)據(jù)庫(kù)但查詢結(jié)果沒(méi)變”的線上事故第一反應(yīng)應(yīng)該是看二級(jí)緩存。尤其是你最近給某個(gè) Mapper 加了cache標(biāo)簽但沒(méi)細(xì)想它 SQL 涉及哪些表事故率非常高。4. 實(shí)戰(zhàn)排查緩存命中率、SQL 打印與自定義緩存擴(kuò)展4.1 配置 SQL 打印日志實(shí)現(xiàn)類的選擇與效果對(duì)比排查緩存問(wèn)題第一步永遠(yuǎn)是看清 SQL 到底有沒(méi)有真正發(fā)到數(shù)據(jù)庫(kù)。MyBatis 的日志輸出靠LogImpl配置常見(jiàn)兩種# 控制臺(tái)直接輸出適合本地調(diào)試 mybatis.configuration.log-implorg.apache.ibatis.logging.stdout.StdOutImpl # 接入 Slf4j適合生產(chǎn)環(huán)境按級(jí)別過(guò)濾 mybatis.configuration.log-implorg.apache.ibatis.logging.slf4j.Slf4jImpl logging.level.你的Mapper包路徑debug選 Slf4j 更合理因?yàn)榭梢耘浜蟣ogback或log4j2把 SQL 日志單獨(dú)輸出到文件不至于刷爆應(yīng)用日志。StdOutImpl就是往System.out直接 println本地調(diào)試方便上生產(chǎn)最好不要用日志格式不可控。日志打印的 SQL 是預(yù)處理語(yǔ)句能看到類似Preparing: SELECT * FROM user WHERE id ?以及Parameters: 1(String)。如果兩次相同查詢只有第一次出現(xiàn)Preparing第二次沒(méi)了說(shuō)明走了緩存每次都出現(xiàn)Preparing說(shuō)明緩存沒(méi)有命中或者當(dāng)前會(huì)話一級(jí)緩存已經(jīng)失效。4.2 手寫一個(gè)帶命中率統(tǒng)計(jì)的 Cache覆蓋官方實(shí)現(xiàn)我排查緩存問(wèn)題時(shí)最喜歡先看一眼命中率。MyBatis 自帶的LoggingCache其實(shí)會(huì)記錄命中率信息只要在配置里把緩存對(duì)應(yīng) namespace 的日志級(jí)別調(diào)到 DEBUG日志里就會(huì)輸出Cache Hit Ratio。如果你不想依賴日志級(jí)別也可以自己寫一個(gè)統(tǒng)計(jì)包裝器public class HitRateCache implements Cache { private final Cache delegate; private final AtomicLong hits new AtomicLong(); private final AtomicLong total new AtomicLong(); public HitRateCache(Cache delegate) { this.delegate delegate; } Override public Object getObject(Object key) { total.incrementAndGet(); Object value delegate.getObject(key); if (value ! null) { hits.incrementAndGet(); } return value; } Override public void putObject(Object key, Object value) { delegate.putObject(key, value); } Override public double getHitRate() { long t total.get(); return t 0 ? 0 : (double) hits.get() / t; } Override public String getId() { return delegate.getId(); } // removeObject、clear、getSize 直接透?jìng)?}然后在cache配置里用cache type你的類全限定名/替換默認(rèn)實(shí)現(xiàn)。不過(guò)要注意用type指定后MyBatis 默認(rèn)那一套 LRU、Serialized 裝飾器就被跳過(guò)了你需要自己在HitRateCache里把需要的策略組合起來(lái)比如再包一層LruCache和SerializedCache。最簡(jiǎn)單的做法是讓自定義類內(nèi)部持有一個(gè)組裝好的Cache鏈條而不是全部自己重寫。4.3 自定義 Redis 二級(jí)緩存Cache 接口的落地細(xì)節(jié)單機(jī)多線程下用內(nèi)置緩存沒(méi)問(wèn)題但應(yīng)用一上多實(shí)例問(wèn)題立刻暴露每個(gè)實(shí)例的二級(jí)緩存互相獨(dú)立一個(gè)實(shí)例更新了數(shù)據(jù)其他實(shí)例還是舊值。這需求本質(zhì)是“分布式緩存”很多人都會(huì)動(dòng)手實(shí)現(xiàn)一個(gè) Redis 版本。MyBatis 的Cache接口非常小實(shí)現(xiàn)思路是public class RedisCache implements Cache { private final String id; private final RedisTemplateObject, Object redisTemplate; public RedisCache(String id) { this.id id; this.redisTemplate SpringContextHolder.getBean(RedisTemplate.class); } Override public void putObject(Object key, Object value) { redisTemplate.opsForValue().set(getKey(key), value, 30, TimeUnit.MINUTES); } Override public Object getObject(Object key) { return redisTemplate.opsForValue().get(getKey(key)); } Override public void clear() { // 按 namespace 前綴刪除注意性能 } // 其他方法略 }落地時(shí)有幾個(gè)坑值得提前說(shuō)構(gòu)造函數(shù)必須只有一個(gè)String id參數(shù)MyBatis 解析cache時(shí)靠反射調(diào)用它。普通RedisTemplate序列化方案要統(tǒng)一建議用 JSON 序列化或自定義序列化器否則存入的對(duì)象變更字段后反序列化容易出兼容性問(wèn)題。Cache接口沒(méi)有批量刪除能力clear()只能按前綴掃描刪除量大會(huì)有性能隱患。事務(wù)未提交時(shí)數(shù)據(jù)不寫真實(shí)緩存這個(gè)語(yǔ)義由TransactionalCache保證自定義RedisCache只需要實(shí)現(xiàn)最基本的存取即可。待定如果你同時(shí)在配置里設(shè)置了flushIntervalScheduledCache裝飾器依然會(huì)生效要留意定時(shí)清空和 Redis 過(guò)期時(shí)間會(huì)雙重疊加。5. 面試與源碼閱讀常見(jiàn)問(wèn)題背后的源碼證據(jù)5.1 高頻面試題盤點(diǎn)從動(dòng)態(tài)代理到緩存失效這幾年 MyBatis 相關(guān)的面試題翻來(lái)翻去就是下面幾個(gè)把源碼位置記清楚回答就能落到底為什么 Mapper 接口不需要實(shí)現(xiàn)類答案是 JDK 動(dòng)態(tài)代理入口在MapperProxyFactory和MapperProxy核心是Proxy.newProxyInstance。一個(gè) Mapper 方法怎么找到對(duì)應(yīng)的 SQL入口是MapperMethod它會(huì)根據(jù)方法名從Configuration.mappedStatements里找到MappedStatement再根據(jù) SQL 類型調(diào)用SqlSession對(duì)應(yīng)方法。一級(jí)緩存和二級(jí)緩存有什么區(qū)別一級(jí)緩存作用域是 SqlSession存儲(chǔ)結(jié)構(gòu)是PerpetualCacheHashMap執(zhí)行 insert/update/delete 或 commit/rollback/close 時(shí)清空二級(jí)緩存作用域是 namespace要cacheEnabled和cache同時(shí)開啟才有效。二級(jí)緩存為什么會(huì)有臟數(shù)據(jù)緩存只按 namespace 組織無(wú)法感知 SQL 涉及的真實(shí)表多表 join 和跨 Mapper 更新時(shí)其他 namespace 的緩存不會(huì)主動(dòng)失效。Spring 事務(wù)下緩存為什么表現(xiàn)不同無(wú)事務(wù)時(shí)每次 Mapper 調(diào)用新建和關(guān)閉 SqlSession一級(jí)緩存失效有事務(wù)時(shí)整個(gè)事務(wù)復(fù)用同一個(gè) SqlSession一級(jí)緩存能命中。還有一道容易被問(wèn)倒的緩存命中后返回對(duì)象和原對(duì)象是同一個(gè)嗎取決于二級(jí)緩存的readOnly。readOnlyfalse時(shí)對(duì)象經(jīng)過(guò)序列化拷貝不是同一個(gè)引用readOnlytrue時(shí)是同一個(gè)引用。一級(jí)緩存則直接返回原對(duì)象引用所以通過(guò)一級(jí)緩存拿到的對(duì)象被修改會(huì)影響下次命中結(jié)果。5.2 源碼閱讀路徑從 Configuration 到 Executor 的調(diào)用鏈如果你只想讀一遍關(guān)鍵源碼就能把整個(gè)查詢鏈路串起來(lái)我建議按這個(gè)方法走拿到源碼后別從頭讀直接從一個(gè)真實(shí)查詢跟蹤調(diào)用鏈。步驟如下先看SqlSessionTemplate.selectList這里是 Spring 整合后進(jìn)入 MyBatis 的入口。順著SqlSessionUtils.getSqlSession看 Spring 怎么管理 SqlSession 生命周期。進(jìn)入DefaultSqlSession.selectList它調(diào)用Executor.query?？碈achingExecutor.query這里判斷二級(jí)緩存是否存在、flushCache 是否開啟。沒(méi)命中后落到BaseExecutor.query這里操作一級(jí)緩存CacheKey 在這里構(gòu)建。一級(jí)緩存也沒(méi)命中進(jìn)入SimpleExecutor.doQuery到這里才真正創(chuàng)建 PreparedStatement。整個(gè)鏈路一層層剝下來(lái)比單獨(dú)看任何一個(gè)類都有效。建議自己寫兩個(gè) Mapper、一個(gè)帶cache、一個(gè)不帶然后在CachingExecutor.query和BaseExecutor.query打上斷點(diǎn)看兩次相同查詢分別停在哪里緩存行為立刻一目了然。提示讀源碼時(shí)有個(gè)很容易忽略的小地方——Configuration.newExecutor決定是否包上CachingExecutor而這個(gè)方法是被SqlSessionFactory創(chuàng)建時(shí)調(diào)用的。Spring Boot 里SqlSessionFactoryBean裝配完畢后這個(gè) executor 鏈就固定了后續(xù)改cacheEnabled配置需要重啟才生效。最后再分享一個(gè)排查心得我自己的經(jīng)驗(yàn)是遇到 MyBatis 緩存相關(guān)問(wèn)題先別急著懷疑框架 bug按“二級(jí)緩存是否開啟→當(dāng)前有沒(méi)有事務(wù)→SQL 是否真的發(fā)出→對(duì)象是否被修改”這個(gè)順序排查。很多“緩存不生效”其實(shí)是 Spring 事務(wù)沒(méi)開導(dǎo)致一級(jí)緩存作用域不符合預(yù)期很多“緩存臟數(shù)據(jù)”其實(shí)是多表操作撞上了 namespace 隔離的墻。另外給團(tuán)隊(duì)定一條規(guī)矩默認(rèn)不開啟二級(jí)緩存除非這個(gè) Mapper 的 SQL 足夠簡(jiǎn)單、數(shù)據(jù)更新頻率足夠低并且在代碼評(píng)審時(shí)明確說(shuō)明涉及哪些表、為什么安全。MyBatis 的緩存機(jī)制本身設(shè)計(jì)得相當(dāng)精巧但精巧的默認(rèn)值并不等于放之四海而皆準(zhǔn)業(yè)務(wù)場(chǎng)景才是最終的尺子。希望這篇文章能把這條鏈路講透下次再有人問(wèn)起動(dòng)態(tài)代理和兩級(jí)緩存你至少能直接告訴他答案在源碼的哪個(gè)位置。