疑難雜癥-MyBatis一級緩存引起的分頁插件失效

癥狀:使用自定義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方法,通過反射獲取到MappedStatementBoundSql檬姥。如果執(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)用了delegatecreateCacheKey方法珍促。(那這個(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)類剩愧,就只有CachingExecutorBaseExecutor猪叙,所以這里是使用了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í)行的

  1. SQL代碼的ID(ms.getId())穴翩,
  2. MyBatis自帶的內(nèi)存分頁邊界(rowBounds.getOffset()rowBounds.getLimit()),
  3. xml中的sql語句(boundSql.getSql())锦积,
  4. 實(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();
    }

顯然侨拦,我們可以通過將msflushCacheRequired設(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è)疑問:

  1. 為什么會用到CachingExecutor与涡?
  2. CachingExecutor中的delegate是什么?
  3. 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è)疑問了:

  1. 由于默認(rèn)二級緩存是開啟的蛮寂,就算我們沒有使用二級緩存蔽午,MyBatis每次創(chuàng)建Executor的時(shí)候也都會用CachingExecutor裝飾實(shí)際的Executor對象。
  2. CachingExecutor中的delegate即被裝飾的Executor對象酬蹋。
  3. CachingExecutor中的cache是二級緩存及老,MyBatis會優(yōu)先使用二級緩存,如果沒有二級緩存范抓,再使用一級緩存骄恶,如果連一級緩存也沒有,那就連接數(shù)據(jù)庫查詢匕垫。雖然二級緩存默認(rèn)開啟僧鲁,但是是需要人為配置才能使用的,我們沒有配置象泵,所以每次都是null寞秃。
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個(gè)濱河市偶惠,隨后出現(xiàn)的幾起案子春寿,更是在濱河造成了極大的恐慌,老刑警劉巖忽孽,帶你破解...
    沈念sama閱讀 212,686評論 6 492
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件绑改,死亡現(xiàn)場離奇詭異,居然都是意外死亡兄一,警方通過查閱死者的電腦和手機(jī)厘线,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 90,668評論 3 385
  • 文/潘曉璐 我一進(jìn)店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來瘾腰,“玉大人皆的,你說我怎么就攤上這事√E瑁” “怎么了费薄?”我有些...
    開封第一講書人閱讀 158,160評論 0 348
  • 文/不壞的土叔 我叫張陵硝全,是天一觀的道長。 經(jīng)常有香客問我楞抡,道長伟众,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 56,736評論 1 284
  • 正文 為了忘掉前任召廷,我火速辦了婚禮凳厢,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘竞慢。我一直安慰自己先紫,他們只是感情好,可當(dāng)我...
    茶點(diǎn)故事閱讀 65,847評論 6 386
  • 文/花漫 我一把揭開白布筹煮。 她就那樣靜靜地躺著遮精,像睡著了一般。 火紅的嫁衣襯著肌膚如雪败潦。 梳的紋絲不亂的頭發(fā)上本冲,一...
    開封第一講書人閱讀 50,043評論 1 291
  • 那天,我揣著相機(jī)與錄音劫扒,去河邊找鬼檬洞。 笑死,一個(gè)胖子當(dāng)著我的面吹牛沟饥,可吹牛的內(nèi)容都是我干的添怔。 我是一名探鬼主播,決...
    沈念sama閱讀 39,129評論 3 410
  • 文/蒼蘭香墨 我猛地睜開眼贤旷,長吁一口氣:“原來是場噩夢啊……” “哼澎灸!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起遮晚,我...
    開封第一講書人閱讀 37,872評論 0 268
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎拦止,沒想到半個(gè)月后县遣,有當(dāng)?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 44,318評論 1 303
  • 正文 獨(dú)居荒郊野嶺守林人離奇死亡汹族,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點(diǎn)故事閱讀 36,645評論 2 327
  • 正文 我和宋清朗相戀三年萧求,在試婚紗的時(shí)候發(fā)現(xiàn)自己被綠了。 大學(xué)時(shí)的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片顶瞒。...
    茶點(diǎn)故事閱讀 38,777評論 1 341
  • 序言:一個(gè)原本活蹦亂跳的男人離奇死亡夸政,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出榴徐,到底是詐尸還是另有隱情守问,我是刑警寧澤匀归,帶...
    沈念sama閱讀 34,470評論 4 333
  • 正文 年R本政府宣布,位于F島的核電站耗帕,受9級特大地震影響穆端,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜仿便,卻給世界環(huán)境...
    茶點(diǎn)故事閱讀 40,126評論 3 317
  • 文/蒙蒙 一体啰、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧嗽仪,春花似錦荒勇、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 30,861評論 0 21
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至鲤氢,卻和暖如春搀擂,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背卷玉。 一陣腳步聲響...
    開封第一講書人閱讀 32,095評論 1 267
  • 我被黑心中介騙來泰國打工哨颂, 沒想到剛下飛機(jī)就差點(diǎn)兒被人妖公主榨干…… 1. 我叫王不留,地道東北人相种。 一個(gè)月前我還...
    沈念sama閱讀 46,589評論 2 362
  • 正文 我出身青樓威恼,卻偏偏與公主長得像,于是被迫代替她去往敵國和親寝并。 傳聞我的和親對象是個(gè)殘疾皇子箫措,可洞房花燭夜當(dāng)晚...
    茶點(diǎn)故事閱讀 43,687評論 2 351

推薦閱讀更多精彩內(nèi)容