癥狀:使用自定義MyBatis分頁插件,只有分頁參數(shù)不同的方法在短時(shí)間內(nèi)使用不同分頁參數(shù)查詢出來的結(jié)果相同颊咬。
病因:自定義MyBatis插件攔截目標(biāo)為StatementHandler,而在同一個(gè)SqlSession中螃征,在StatementHandler.prepare之前短曾,MyBatis的已經(jīng)命中了一級緩存,所以直接返回了緩存中的內(nèi)容逗宁。
治療方案:重寫自定義MyBatis分頁插件使之?dāng)r截Executor,或增加新的插件梦湘,使之?dāng)r截Executor清除一級緩存瞎颗。
這是我最近在一個(gè)項(xiàng)目中排查的一個(gè)問題件甥,在這里記錄一下以備后查。
首先這個(gè)項(xiàng)目并沒有使用比較流行的PageHelper插件哼拔,而是自己實(shí)現(xiàn)了一個(gè)引有,由于不是本人的代碼,就不貼出來了倦逐。網(wǎng)上搜一下的話也有很多類似的譬正,主要的實(shí)現(xiàn)原理是使用MyBatis提供的@Intercepts
攔截StatementHandler
類的prepare
方法,通過反射獲取到MappedStatement
和BoundSql
檬姥。如果執(zhí)行的是約定的分頁方法(MappedStatement
的id帶有Page后綴)曾我,那么就把BoundSql
中的sql
字段更改為帶有分頁功能的sql。如果要使用分頁查詢穿铆,那么分頁方法的參數(shù)需要帶有分頁參數(shù)您单,同時(shí)分頁方法名需要帶有約定的Page后綴。乍一看沒有什么問題荞雏,但是在真正使用的時(shí)候,由于MyBatis一級緩存的存在平酿,同一個(gè)SqlSession中后續(xù)的分頁方法生成了相同的CacheKey凤优,導(dǎo)致直接返回了緩存中的內(nèi)容。這里主要的問題是攔截的時(shí)機(jī)蜈彼,攔截發(fā)生在MyBatis決定是否要使用緩存之后V妗!
關(guān)于MyBatis的緩存機(jī)制幸逆,網(wǎng)上有很多資料講的很詳細(xì)棍辕,不清楚的可以先了解了解』够妫總的來說楚昭,在同一個(gè)SqlSession中,執(zhí)行同一條sql MyBatis會直接返回緩存拍顷。不過對于我們碰到的問題抚太,一開始我是帶著疑慮的,兩次執(zhí)行的方法明明分頁參數(shù)是不同的昔案,怎么會命中同一個(gè)緩存呢尿贫?帶著這個(gè)疑問我們debug MyBatis的源碼,查看其生成CacheKey的邏輯踏揣。首先當(dāng)執(zhí)行一條sql的時(shí)候庆亡,會進(jìn)到4參數(shù)CachingExecutor.query
,(網(wǎng)上一查,這個(gè)類是用來處理二級緩存的捞稿,明明沒用二級緩存又谋,為何會用到這個(gè)類钝尸?這里先留個(gè)懸念,后面再說):
@Override
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
BoundSql boundSql = ms.getBoundSql(parameterObject);
CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
再看這里緩存key的生成方法搂根,實(shí)際上是調(diào)用了delegate
的createCacheKey
方法珍促。(那這個(gè)delegate
又是個(gè)啥?我們待會一起說):
@Override
public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) {
return delegate.createCacheKey(ms, parameterObject, rowBounds, boundSql);
}
查看createCacheKey方法的實(shí)現(xiàn)類剩愧,就只有CachingExecutor
和BaseExecutor
猪叙,所以這里是使用了BaseExecutor.createCacheKey
生成緩存key:
@Override
public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) {
if (closed) {
throw new ExecutorException("Executor was closed.");
}
CacheKey cacheKey = new CacheKey();
cacheKey.update(ms.getId());
cacheKey.update(rowBounds.getOffset());
cacheKey.update(rowBounds.getLimit());
cacheKey.update(boundSql.getSql());
List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
TypeHandlerRegistry typeHandlerRegistry = ms.getConfiguration().getTypeHandlerRegistry();
// mimic DefaultParameterHandler logic
for (ParameterMapping parameterMapping : parameterMappings) {
if (parameterMapping.getMode() != ParameterMode.OUT) {
Object value;
String propertyName = parameterMapping.getProperty();
if (boundSql.hasAdditionalParameter(propertyName)) {
value = boundSql.getAdditionalParameter(propertyName);
} else if (parameterObject == null) {
value = null;
} else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {
value = parameterObject;
} else {
MetaObject metaObject = configuration.newMetaObject(parameterObject);
value = metaObject.getValue(propertyName);
}
cacheKey.update(value);
}
}
if (configuration.getEnvironment() != null) {
// issue #176
cacheKey.update(configuration.getEnvironment().getId());
}
return cacheKey;
}
這里可以看到,CacheKey由四組參數(shù)組成仁卷,簡單說就是待執(zhí)行的
- SQL代碼的ID(
ms.getId()
)穴翩, - MyBatis自帶的內(nèi)存分頁邊界(
rowBounds.getOffset()
與rowBounds.getLimit()
), - xml中的sql語句(
boundSql.getSql()
)锦积, - 實(shí)際執(zhí)行的參數(shù)(通過獲取
boundSql.getParameterMappings()
并將parameterObject
映射獲得)芒帕。
雖然由于分頁參數(shù)不同,我們這里每次傳入的parameterObject
不同丰介,但是由于分頁sql是在StatementHandler
中進(jìn)行拼裝背蟆,xml中的sql并沒有寫相應(yīng)的參數(shù)去接受分頁參數(shù),所以boundSql.getParameterMappings()
并沒有包含我們的分頁參數(shù)哮幢,不同的parameterObject
也就并沒有造成不同的CacheKey带膀。
搞明白了問題的原因,接下來我們要來解決這個(gè)問題橙垢。思路有四條垛叨,A:參考網(wǎng)上比較流行的PageHelper,將我們的分頁插件改寫成攔截Executor柜某,在生成CacheKey前就拼裝好SQL嗽元;B:執(zhí)行分頁方法時(shí)disable一級緩存;C:直接使用PageHelper替換喂击;D:將分頁參數(shù)寫入xml中剂癌,如where #{pageNum} = #{pageNum} and #{pageSize} = #{pageSize}
。這樣不會影響執(zhí)行結(jié)果惭等,也能保證每次CacheKey值不同珍手,實(shí)際上我們發(fā)現(xiàn)問題后的臨時(shí)解決方案就是這個(gè)。最終評估改造成本后辞做,決定使用B方案琳要。
要disable緩存,我們得知道緩存再何時(shí)被使用秤茅。那我們繼續(xù)debug稚补,發(fā)現(xiàn)4參數(shù)數(shù)的CachingExecutor.query
中生成CacheKey后調(diào)用了內(nèi)部6參數(shù)的query
方法:
@Override
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
throws SQLException {
Cache cache = ms.getCache();
if (cache != null) {
flushCacheIfRequired(ms);
if (ms.isUseCache() && resultHandler == null) {
ensureNoOutParams(ms, parameterObject, boundSql);
@SuppressWarnings("unchecked")
List<E> list = (List<E>) tcm.getObject(cache, key);
if (list == null) {
list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
tcm.putObject(cache, key, list); // issue #578 and #116
}
return list;
}
}
return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
這里有段if (cache != null)
的判斷邏輯,一開始還以為這里就是緩存起效的邏輯框喳,但debug后發(fā)現(xiàn)并不是课幕,每次進(jìn)來這邊cache取到的都是null厦坛,排除這里使用cache的可能。(那這里的cache是個(gè)啥乍惊?別急杜秸,待會和前面兩個(gè)問題一塊說。)這邊最后調(diào)用了delegate.query
润绎,也就是BaseExecutor.query
:
@Override
public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
ErrorContext.instance().resource(ms.getResource()).activity("executing a query").object(ms.getId());
if (closed) {
throw new ExecutorException("Executor was closed.");
}
if (queryStack == 0 && ms.isFlushCacheRequired()) {
clearLocalCache();
}
List<E> list;
try {
queryStack++;
list = resultHandler == null ? (List<E>) localCache.getObject(key) : null;
if (list != null) {
handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
} else {
list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
}
} finally {
queryStack--;
}
if (queryStack == 0) {
for (DeferredLoad deferredLoad : deferredLoads) {
deferredLoad.load();
}
// issue #601
deferredLoads.clear();
if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
// issue #482
clearLocalCache();
}
}
return list;
}
終于我們找到了我們要找的方法撬碟,我們看到這里通過localCache.getObject(key)
獲取緩存,如果存在直接返回莉撇,否則執(zhí)行去數(shù)據(jù)庫查詢結(jié)果queryFromDatabase
呢蛤,再看queryFromDatabase
:
private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
List<E> list;
localCache.putObject(key, EXECUTION_PLACEHOLDER);
try {
list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
} finally {
localCache.removeObject(key);
}
localCache.putObject(key, list);
if (ms.getStatementType() == StatementType.CALLABLE) {
localOutputParameterCache.putObject(key, parameter);
}
return list;
}
這里通過localCache.putObject
存放一級緩存。
由于我們每次調(diào)用CacheKey都相同棍郎,所以在BaseExecutor.query
中就直接使用了緩存返回其障。那我們的攔截器是在哪里生效的?我們可以繼續(xù)往下看涂佃,這里的doQuery
方法調(diào)用了具體子類的doQuery
方法励翼,如SimpleExecutor.doQuery
:
@Override
public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
Statement stmt = null;
try {
Configuration configuration = ms.getConfiguration();
StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
stmt = prepareStatement(handler, ms.getStatementLog());
return handler.<E>query(stmt, resultHandler);
} finally {
closeStatement(stmt);
}
}
private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException {
Statement stmt;
Connection connection = getConnection(statementLog);
stmt = handler.prepare(connection, transaction.getTimeout());
handler.parameterize(stmt);
return stmt;
}
而這里的handler.prepare
才是真正被我們的分頁攔截器攔截到的方法,而這個(gè)時(shí)候緩存的使用早就被決定了巡李。
那么我們?nèi)绾蝑isable緩存呢抚笔?我們回過頭去看BaseExecutor.query
方法,這里有一個(gè)關(guān)鍵的判斷:
if (queryStack == 0 && ms.isFlushCacheRequired()) {
clearLocalCache();
}
顯然侨拦,我們可以通過將ms
的flushCacheRequired
設(shè)置為true來強(qiáng)行清除緩存。增加一個(gè)攔截器攔截Executor.query
辐宾,利用反射強(qiáng)改flushCacheRequired
屬性狱从。注意,這里只能攔截4參數(shù)的query方法而不能攔截到6參數(shù)的叠纹,由于6參數(shù)的query方法是通過內(nèi)部調(diào)用的季研,無法被動(dòng)態(tài)代理。具體代碼如下供大家參考:
@Intercepts({@Signature(type = Executor.class, method = "query", args = {MappedStatement.class, Object.class,
RowBounds.class, ResultHandler.class})})
public class PageLocalCacheDisableInterceptor implements Interceptor {
private static final String DEFAULT_PAGE_SQLID = ".*Page$";
@Override
public Object intercept(Invocation invocation) throws Throwable {
Object[] args = invocation.getArgs();
MappedStatement ms = (MappedStatement) args[0];
if (ms.getId().matches(DEFAULT_PAGE_SQLID)) {
Class<?> clazz = ms.getClass();
Field flushLocalCache = clazz.getDeclaredField("flushCacheRequired");
flushLocalCache.setAccessible(true);
flushLocalCache.set(ms, true);
}
return invocation.proceed();
}
@Override
public Object plugin(Object target) {
return Plugin.wrap(target, this);
}
@Override
public void setProperties(Properties properties) {
//do nothing
}
}
說完了解決方案誉察,我們解決下之前留下的三個(gè)疑問:
- 為什么會用到
CachingExecutor
与涡? -
CachingExecutor
中的delegate
是什么? -
CachingExecutor
中的cache
是什么持偏?
MyBatis的二級緩存
實(shí)際上要弄明白這些問題驼卖,只需要搞明白MyBatis的二級緩存是什么就好了。我們繼續(xù)看源碼:
public CachingExecutor(Executor delegate) {
this.delegate = delegate;
delegate.setExecutorWrapper(this);
}
發(fā)現(xiàn)delegate
就是個(gè)Executor鸿秆,并且在CachingExecutor
構(gòu)造函數(shù)中傳入酌畜,由于CachingExecutor
本身也實(shí)現(xiàn)了Executor
,那其實(shí)就是設(shè)計(jì)模式中的裝飾者模式了卿叽。這時(shí)候我們就可以順著這條線繼續(xù)調(diào)查為啥MyBatis要用CachingExecutor
裝飾Executor桥胞,查看構(gòu)造函數(shù)的調(diào)用方恳守,發(fā)現(xiàn)只有一處調(diào)用,即Configuration.newExecutor
:
public Executor newExecutor(Transaction transaction, ExecutorType executorType) {
executorType = executorType == null ? defaultExecutorType : executorType;
executorType = executorType == null ? ExecutorType.SIMPLE : executorType;
Executor executor;
if (ExecutorType.BATCH == executorType) {
executor = new BatchExecutor(this, transaction);
} else if (ExecutorType.REUSE == executorType) {
executor = new ReuseExecutor(this, transaction);
} else {
executor = new SimpleExecutor(this, transaction);
}
if (cacheEnabled) {
executor = new CachingExecutor(executor);
}
executor = (Executor) interceptorChain.pluginAll(executor);
return executor;
}
這里首先會根據(jù)executorType
為executor實(shí)例化一個(gè)對應(yīng)的實(shí)現(xiàn)類贩虾,同時(shí)根據(jù)cacheEnabled
是否為true來決定是否要用CachingExecutor
裝飾催烘。而我們看到這個(gè)cacheEnabled
是有初始值true的,并且在XMLConfigBuilder
構(gòu)造配置相的時(shí)候會設(shè)置true為缺省值缎罢,所以默認(rèn)就會帶上CachingExecutor
:
protected boolean cacheEnabled = true;
configuration.setCacheEnabled(booleanValueOf(props.getProperty("cacheEnabled"), true));
那如果我們確定不用二級緩存伊群,其實(shí)可以通過設(shè)置參數(shù)來關(guān)閉這個(gè)修飾器,這樣原本執(zhí)行的CachingExecutor.query
就不會被執(zhí)行屁使,取而代之的是本身BaseExecutor.query
方法在岂,這樣可以簡化調(diào)用鏈路。設(shè)置如下:
<configuration>
<settings>
<!-- 打印查詢語句 -->
<setting name="logImpl" value="STDOUT_LOGGING"/>
<!-- 二級緩存關(guān)閉-->
<setting name="cacheEnabled" value="false"/>
</settings>
<typeAliases>
</typeAliases>
<!--plugins插件之 分頁攔截器-->
<plugins>
<plugin interceptor="com.nfsq.member.coupon.common.PaginationInterceptor"></plugin>
<plugin interceptor="com.nfsq.member.coupon.common.PageLocalCacheDisableInterceptor"></plugin>
</plugins>
</configuration>
現(xiàn)在可以來解答一下之前留下的三個(gè)疑問了:
- 由于默認(rèn)二級緩存是開啟的蛮寂,就算我們沒有使用二級緩存蔽午,MyBatis每次創(chuàng)建Executor的時(shí)候也都會用CachingExecutor裝飾實(shí)際的Executor對象。
-
CachingExecutor
中的delegate
即被裝飾的Executor對象酬蹋。 -
CachingExecutor
中的cache
是二級緩存及老,MyBatis會優(yōu)先使用二級緩存,如果沒有二級緩存范抓,再使用一級緩存骄恶,如果連一級緩存也沒有,那就連接數(shù)據(jù)庫查詢匕垫。雖然二級緩存默認(rèn)開啟僧鲁,但是是需要人為配置才能使用的,我們沒有配置象泵,所以每次都是null寞秃。