這期內(nèi)容當中小編將會給大家?guī)碛嘘P使用MyBatis如何實現(xiàn)一級緩存與二級緩存，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

臨潁ssl適用于網(wǎng)站、小程序/APP、API接口等需要進行數(shù)據(jù)傳輸應用場景，ssl證書未來市場廣闊！成為成都創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：028-86922220（備注：SSL證書合作）期待與您的合作！

MyBatis緩存

我們知道，頻繁的數(shù)據(jù)庫操作是非常耗費性能的（主要是因為對于DB而言，數(shù)據(jù)是持久化在磁盤中的，因此查詢操作需要通過IO，IO操作速度相比內(nèi)存操作速度慢了好幾個量級），尤其是對于一些相同的查詢語句，完全可以把查詢結(jié)果存儲起來，下次查詢同樣的內(nèi)容的時候直接從內(nèi)存中獲取數(shù)據(jù)即可，這樣在某些場景下可以大大提升查詢效率。

MyBatis的緩存分為兩種：

一級緩存，一級緩存是SqlSession級別的緩存，對于相同的查詢，會從緩存中返回結(jié)果而不是查詢數(shù)據(jù)庫

二級緩存，二級緩存是Mapper級別的緩存，定義在Mapper文件的標簽中并需要開啟此緩存，多個Mapper文件可以共用一個緩存，依賴標簽配置

下面來詳細看一下MyBatis的一二級緩存。

MyBatis一級緩存工作流程

接著看一下MyBatis一級緩存工作流程。前面說了，MyBatis的一級緩存是SqlSession級別的緩存，當openSession()的方法運行完畢或者主動調(diào)用了SqlSession的close方法，SqlSession就被回收了，一級緩存與此同時也一起被回收掉了。前面的文章有說過，在MyBatis中，無論selectOne還是selectList方法，最終都被轉(zhuǎn)換為了selectList方法來執(zhí)行，那么看一下SqlSession的selectList方法的實現(xiàn)：

public  List selectList(String statement, Object parameter, RowBounds rowBounds) {
  try {
   MappedStatement ms = configuration.getMappedStatement(statement);
   return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
  } catch (Exception e) {
   throw ExceptionFactory.wrapException("Error querying database. Cause: " + e, e);
  } finally {
   ErrorContext.instance().reset();
  }
}

繼續(xù)跟蹤第4行的代碼，到BaseExeccutor的query方法：

 public  List query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
   BoundSql boundSql = ms.getBoundSql(parameter);
   CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);
   return query(ms, parameter, rowBounds, resultHandler, key, boundSql);
 }

 第3行構(gòu)建緩存條件CacheKey，這里涉及到怎么樣條件算是和上一次查詢是同一個條件的一個問題，因為同一個條件就可以返回上一次的結(jié)果回去，這部分代碼留在下一部分分析。

接著看第4行的query方法的實現(xiàn)，代碼位于CachingExecutor中：

public  List 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 list = (List) tcm.getObject(cache, key);
    if (list == null) {
     list = delegate. query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
     tcm.putObject(cache, key, list); // issue #578 and #116
    }
    return list;
   }
  }
  return delegate. query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}

第3行~第16行的代碼先不管，繼續(xù)跟第17行的query方法，代碼位于BaseExecutor中：

public  List 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 list;
  try {
   queryStack++;
   list = resultHandler == null ? (List) localCache.getObject(key) : null;
   if (list != null) {
    handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
   } else {
    list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
   }
  } finally {
   queryStack--;
  }
  ...
}

看12行，query的時候會嘗試從localCache中去獲取查詢結(jié)果，如果獲取到的查詢結(jié)果為null，那么執(zhí)行16行的代碼從DB中撈數(shù)據(jù)，撈完之后會把CacheKey作為key，把查詢結(jié)果作為value放到localCache中。

MyBatis一級緩存存儲流程看完了，接著我們從這段代碼中可以得到三個結(jié)論：

MyBatis的一級緩存是SqlSession級別的，但是它并不定義在SqlSessio接口的實現(xiàn)類DefaultSqlSession中，而是定義在DefaultSqlSession的成員變量Executor中，Executor是在openSession的時候被實例化出來的，它的默認實現(xiàn)為SimpleExecutor

MyBatis中的一級緩存，與有沒有配置無關，只要SqlSession存在，MyBastis一級緩存就存在，localCache的類型是PerpetualCache，它其實很簡單，一個id屬性+一個HashMap屬性而已，id是一個名為"localCache"的字符串，HashMap用于存儲數(shù)據(jù)，Key為CacheKey，Value為查詢結(jié)果

MyBatis的一級緩存查詢的時候默認都是會先嘗試從一級緩存中獲取數(shù)據(jù)的，但是我們看第6行的代碼做了一個判斷，ms.isFlushCacheRequired()，即想每次查詢都走DB也行，將標簽中的flushCache屬性設置為true即可，這意味著每次查詢的時候都會清理一遍PerpetualCache，PerpetualCache中沒數(shù)據(jù)，自然只能走DB

從MyBatis一級緩存來看，它以單純的HashMap做緩存，沒有容量控制，而一次SqlSession中通常來說并不會有大量的查詢操作，因此只適用于一次SqlSession，如果用到二級緩存的Mapper級別的場景，有可能緩存數(shù)據(jù)不斷碰到而導致內(nèi)存溢出。

還有一點，差點忘了寫了，、、最終都會轉(zhuǎn)換為update方法，看一下BaseExecutor的update方法：

public int update(MappedStatement ms, Object parameter) throws SQLException {
  ErrorContext.instance().resource(ms.getResource()).activity("executing an update").object(ms.getId());
  if (closed) {
   throw new ExecutorException("Executor was closed.");
  }
  clearLocalCache();
  return doUpdate(ms, parameter);
}

第6行clearLocalCache()方法，這意味著所有的增、刪、改都會清空本地緩存，這和是否配置了flushCache=true是無關的。

這很好理解，因為增、刪、改這三種操作都可能會導致查詢出來的結(jié)果并不是原來的結(jié)果，如果增、刪、改不清理緩存，那么可能導致讀取出來的數(shù)據(jù)是臟數(shù)據(jù)。

一級緩存的CacheKey

接著我們看下一個問題：怎么樣的查詢條件算和上一次查詢是一樣的查詢，從而返回同樣的結(jié)果回去？這個問題，得從CacheKey說起。

我們先看一下CacheKey的數(shù)據(jù)結(jié)構(gòu)：

public class CacheKey implements Cloneable, Serializable {
 private static final long serialVersionUID = 1146682552656046210L;
 public static final CacheKey NULL_CACHE_KEY = new NullCacheKey();
 private static final int DEFAULT_MULTIPLYER = 37;
 private static final int DEFAULT_HASHCODE = 17;
 private int multiplier;
 private int hashcode;
 private long checksum;
 private int count;
 private List