溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇文章給大家分享的是有關深入淺析MyBatis中的一級緩存與二級緩存，小編覺得挺實用的，因此分享給大家學習，希望大家閱讀完這篇文章后可以有所收獲，話不多說，跟著小編一起來看看吧。
MyBatis緩存
我們知道，頻繁的數據庫操作是非常耗費性能的（主要是因為對于DB而言，數據是持久化在磁盤中的，因此查詢操作需要通過IO，IO操作速度相比內存操作速度慢了好幾個量級），尤其是對于一些相同的查詢語句，完全可以把查詢結果存儲起來，下次查詢同樣的內容的時候直接從內存中獲取數據即可，這樣在某些場景下可以大大提升查詢效率。
MyBatis的緩存分為兩種：
一級緩存，一級緩存是SqlSession級別的緩存，對于相同的查詢，會從緩存中返回結果而不是查詢數據庫
二級緩存，二級緩存是Mapper級別的緩存，定義在Mapper文件的<cache>標簽中并需要開啟此緩存，多個Mapper文件可以共用一個緩存，依賴<cache-ref>標簽配置
下面來詳細看一下MyBatis的一二級緩存。
MyBatis一級緩存工作流程
接著看一下MyBatis一級緩存工作流程。前面說了，MyBatis的一級緩存是SqlSession級別的緩存，當openSession()的方法運行完畢或者主動調用了SqlSession的close方法，SqlSession就被回收了，一級緩存與此同時也一起被回收掉了。前面的文章有說過，在MyBatis中，無論selectOne還是selectList方法，最終都被轉換為了selectList方法來執行，那么看一下SqlSession的selectList方法的實現：
public <E> List<E> 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();
}
}繼續跟蹤第4行的代碼，到BaseExeccutor的query方法：
public <E> List<E> 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行構建緩存條件CacheKey，這里涉及到怎么樣條件算是和上一次查詢是同一個條件的一個問題，因為同一個條件就可以返回上一次的結果回去，這部分代碼留在下一部分分析。
接著看第4行的query方法的實現，代碼位于CachingExecutor中：
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);
}第3行~第16行的代碼先不管，繼續跟第17行的query方法，代碼位于BaseExecutor中：
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--;
}
...
}看12行，query的時候會嘗試從localCache中去獲取查詢結果，如果獲取到的查詢結果為null，那么執行16行的代碼從DB中撈數據，撈完之后會把CacheKey作為key，把查詢結果作為value放到localCache中。
MyBatis一級緩存存儲流程看完了，接著我們從這段代碼中可以得到三個結論：
1、MyBatis的一級緩存是SqlSession級別的，但是它并不定義在SqlSessio接口的實現類DefaultSqlSession中，而是定義在DefaultSqlSession的成員變量Executor中，Executor是在openSession的時候被實例化出來的，它的默認實現為SimpleExecutor
2、MyBatis中的一級緩存，與有沒有配置無關，只要SqlSession存在，MyBastis一級緩存就存在，localCache的類型是PerpetualCache，它其實很簡單，一個id屬性+一個HashMap屬性而已，id是一個名為"localCache"的字符串，HashMap用于存儲數據，Key為CacheKey，Value為查詢結果
3、MyBatis的一級緩存查詢的時候默認都是會先嘗試從一級緩存中獲取數據的，但是我們看第6行的代碼做了一個判斷，ms.isFlushCacheRequired()，即想每次查詢都走DB也行，將<select>標簽中的flushCache屬性設置為true即可，這意味著每次查詢的時候都會清理一遍PerpetualCache，PerpetualCache中沒數據，自然只能走DB
從MyBatis一級緩存來看，它以單純的HashMap做緩存，沒有容量控制，而一次SqlSession中通常來說并不會有大量的查詢操作，因此只適用于一次SqlSession，如果用到二級緩存的Mapper級別的場景，有可能緩存數據不斷碰到而導致內存溢出。
還有一點，差點忘了寫了，<insert>、<delete>、<update>最終都會轉換為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是無關的。
這很好理解，因為增、刪、改這三種操作都可能會導致查詢出來的結果并不是原來的結果，如果增、刪、改不清理緩存，那么可能導致讀取出來的數據是臟數據。
一級緩存的CacheKey
接著我們看下一個問題：怎么樣的查詢條件算和上一次查詢是一樣的查詢，從而返回同樣的結果回去？這個問題，得從CacheKey說起。
我們先看一下CacheKey的數據結構：
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<Object> updateList;
...
}其中最重要的是第14行的updateList這個兩個屬性，為什么這么說，因為HashMap的Key是CacheKey，而HashMap的get方法是先判斷hashCode，在hashCode沖突的情況下再進行equals判斷，因此最終無論如何都會進行一次equals的判斷，看下equals方法的實現：
public boolean equals(Object object) {
if (this == object) {
return true;
}
if (!(object instanceof CacheKey)) {
return false;
}
final CacheKey cacheKey = (CacheKey) object;
if (hashcode != cacheKey.hashcode) {
return false;
}
if (checksum != cacheKey.checksum) {
return false;
}
if (count != cacheKey.count) {
return false;
}
for (int i = 0; i < updateList.size(); i++) {
Object thisObject = updateList.get(i);
Object thatObject = cacheKey.updateList.get(i);
if (thisObject == null) {
if (thatObject != null) {
return false;
}
} else {
if (!thisObject.equals(thatObject)) {
return false;
}
}
}
return true;
}看到整個方法的流程都是圍繞著updateList中的每個屬性進行逐一比較，因此再進一步的，我們要看一下updateList中到底存儲了什么。
關于updateList里面存儲的數據我們可以看下哪里使用了updateList的add方法，然后一步一步反推回去即可。updateList中數據的添加是在doUpdate方法中：
private void doUpdate(Object object) {
int baseHashCode = object == null ? 1 : object.hashCode();
count++;
checksum += baseHashCode;
baseHashCode *= count;
hashcode = multiplier * hashcode + baseHashCode;
updateList.add(object);
}它的調用方為update方法：
public void update(Object object) {
if (object != null && object.getClass().isArray()) {
int length = Array.getLength(object);
for (int i = 0; i < length; i++) {
Object element = Array.get(object, i);
doUpdate(element);
}
} else {
doUpdate(object);
}
}這里主要是對輸入參數是數組類型進行了一次判斷，是數組就遍歷逐一做doUpdate，否則就直接做doUpdate。再看update方法的調用方，其實update方法的調用方有挺多處，但是這里我們要看的是Executor中的，看一下BaseExecutor中的createCacheKey方法實現：
... CacheKey cacheKey = new CacheKey(); cacheKey.update(ms.getId()); cacheKey.update(rowBounds.getOffset()); cacheKey.update(rowBounds.getLimit()); cacheKey.update(boundSql.getSql()); ...
到了這里應當一目了然了，MyBastis從三個維度判斷兩次查詢是相同的：
1、<select>標簽所在的Mapper的Namespace+<select>標簽的id屬性
2、RowBounds的offset和limit屬性，RowBounds是MyBatis用于處理分頁的一個類，offset默認為0，limit默認為Integer.MAX_VALUE
3、<select>標簽中定義的sql語句
即只要兩次查詢滿足以上三個條件且沒有定義flushCache="true"，那么第二次查詢會直接從MyBatis一級緩存PerpetualCache中返回數據，而不會走DB。
MyBatis二級緩存
上面說完了MyBatis，接著看一下MyBatis二級緩存，還是從二級緩存工作流程開始。還是從DefaultSqlSession的selectList方法進去：
public <E> List<E> 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();
}
}執行query方法，方法位于CachingExecutor中：
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);
}繼續跟第4行的query方法，同樣位于CachingExecutor中：
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);
}從這里看到，執行第17行的BaseExecutor的query方法之前，會先拿Mybatis二級緩存，而BaseExecutor的query方法會優先讀取MyBatis一級緩存，由此可以得出一個重要結論：假如定義了MyBatis二級緩存，那么MyBatis二級緩存讀取優先級高于MyBatis一級緩存。
而第3行~第16行的邏輯：
1、第5行的方法很好理解，根據flushCache=true或者flushCache=false判斷是否要清理二級緩存
2、第7行的方法是保證MyBatis二級緩存不會存儲存儲過程的結果
3、第9行的方法先嘗試從tcm中獲取查詢結果，這個tcm解釋一下，這又是一個裝飾器模式（數數MyBatis用到了多少裝飾器模式了），創建一個事物緩存TranactionalCache，持有Cache接口，Cache接口的實現類就是根據我們在Mapper文件中配置的<cache>創建的Cache實例
4、第10行~第12行，如果沒有從MyBatis二級緩存中拿到數據，那么就會查一次數據庫，然后放到MyBatis二級緩存中去
至于如何判定上次查詢和這次查詢是一次查詢？由于這里的CacheKey和MyBatis一級緩存使用的是同一個CacheKey，因此它的判定條件和前文寫過的MyBatis一級緩存三個維度的判定條件是一致的。
最后再來談一點，"Cache cache = ms.getCache()"這句代碼十分重要，這意味著Cache是從MappedStatement中獲取到的，而MappedStatement又和每一個<insert>、<delete>、<update>、<select>綁定并在MyBatis啟動的時候存入Configuration中：
protected final Map<String, MappedStatement> mappedStatements = new StrictMap<MappedStatement>("Mapped Statements collection");因此MyBatis二級緩存的生命周期即整個應用的生命周期，應用不結束，定義的二級緩存都會存在在內存中。
從這個角度考慮，為了避免MyBatis二級緩存中數據量過大導致內存溢出，MyBatis在配置文件中給我們增加了很多配置例如size（緩存大小）、flushInterval（緩存清理時間間隔）、eviction（數據淘汰算法）來保證緩存中存儲的數據不至于太過龐大。
MyBatis二級緩存實例化過程
接著看一下MyBatis二級緩存<cache>實例化的過程，代碼位于XmlMapperBuilder的cacheElement方法中：
private void cacheElement(XNode context) throws Exception {
if (context != null) {
String type = context.getStringAttribute("type", "PERPETUAL");
Class<? extends Cache> typeClass = typeAliasRegistry.resolveAlias(type);
String eviction = context.getStringAttribute("eviction", "LRU");
Class<? extends Cache> evictionClass = typeAliasRegistry.resolveAlias(eviction);
Long flushInterval = context.getLongAttribute("flushInterval");
Integer size = context.getIntAttribute("size");
boolean readWrite = !context.getBooleanAttribute("readOnly", false);
boolean blocking = context.getBooleanAttribute("blocking", false);
Properties props = context.getChildrenAsProperties();
builderAssistant.useNewCache(typeClass, evictionClass, flushInterval, size, readWrite, blocking, props);
}
}這里分別取<cache>中配置的各個屬性，關注一下兩個默認值：
1、type表示緩存實現，默認是PERPETUAL，根據typeAliasRegistry中注冊的，PERPETUAL實際對應PerpetualCache，這和MyBatis一級緩存是一致的
2、eviction表示淘汰算法，默認是LRU算法
第3行~第11行拿到了所有屬性，那么調用12行的useNewCache方法創建緩存：
public Cache useNewCache(Class<? extends Cache> typeClass,
Class<? extends Cache> evictionClass,
Long flushInterval,
Integer size,
boolean readWrite,
boolean blocking,
Properties props) {
Cache cache = new CacheBuilder(currentNamespace)
.implementation(valueOrDefault(typeClass, PerpetualCache.class))
.addDecorator(valueOrDefault(evictionClass, LruCache.class))
.clearInterval(flushInterval)
.size(size)
.readWrite(readWrite)
.blocking(blocking)
.properties(props)
.build();
configuration.addCache(cache);
currentCache = cache;
return cache;
}這里又使用了建造者模式，跟一下第16行的build()方法，在此之前該傳入的參數都已經傳入了CacheBuilder：
public Cache build() {
setDefaultImplementations();
Cache cache = newBaseCacheInstance(implementation, id);
setCacheProperties(cache);
// issue #352, do not apply decorators to custom caches
if (PerpetualCache.class.equals(cache.getClass())) {
for (Class<? extends Cache> decorator : decorators) {
cache = newCacheDecoratorInstance(decorator, cache);
setCacheProperties(cache);
}
cache = setStandardDecorators(cache);
} else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) {
cache = new LoggingCache(cache);
}
return cache;
}第3行的代碼，構建基礎的緩存，implementation指的是type配置的值，這里是默認的PerpetualCache。
第6行的代碼，如果是PerpetualCache，那么繼續裝飾（又是裝飾器模式，可以數數這幾篇MyBatis源碼解析的文章里面出現了多少次裝飾器模式了），這里的裝飾是根據eviction進行裝飾，到這一步，給PerpetualCache加上了LRU的功能。
第11行的代碼，繼續裝飾，這次MyBatis將它命名為標準裝飾，setStandardDecorators方法實現為：
private Cache setStandardDecorators(Cache cache) {
try {
MetaObject metaCache = SystemMetaObject.forObject(cache);
if (size != null && metaCache.hasSetter("size")) {
metaCache.setValue("size", size);
}
if (clearInterval != null) {
cache = new ScheduledCache(cache);
((ScheduledCache) cache).setClearInterval(clearInterval);
}
if (readWrite) {
cache = new SerializedCache(cache);
}
cache = new LoggingCache(cache);
cache = new SynchronizedCache(cache);
if (blocking) {
cache = new BlockingCache(cache);
}
return cache;
} catch (Exception e) {
throw new CacheException("Error building standard cache decorators. Cause: " + e, e);
}
}這次是根據其它的配置參數來：
如果配置了flushInterval，那么繼續裝飾為ScheduledCache，這意味著在調用Cache的getSize、putObject、getObject、removeObject四個方法的時候都會進行一次時間判斷，如果到了指定的清理緩存時間間隔，那么就會將當前緩存清空
如果readWrite=true，那么繼續裝飾為SerializedCache，這意味著緩存中所有存儲的內存都必須實現Serializable接口
跟配置無關，將之前裝飾好的Cache繼續裝飾為LoggingCache與SynchronizedCache，前者在getObject的時候會打印緩存命中率，后者將Cache接口中所有的方法都加了Synchronized關鍵字進行了同步處理
如果blocking=true，那么繼續裝飾為BlockingCache，這意味著針對同一個CacheKey，拿數據與放數據、刪數據是互斥的，即拿數據的時候必須沒有在放數據、刪數據
Cache全部裝飾完畢，返回，至此MyBatis二級緩存生成完畢。
最后說一下，MyBatis支持三種類型的二級緩存：
MyBatis默認的緩存，type為空，Cache為PerpetualCache
自定義緩存
第三方緩存
從build()方法來看，后兩種場景的Cache，MyBatis只會將其裝飾為LoggingCache，理由很簡單，這些緩存的定期清除功能、淘汰過期數據功能開發者自己或者第三方緩存都已經實現好了，根本不需要依賴MyBatis本身的裝飾。
以上就是深入淺析MyBatis中的一級緩存與二級緩存，小編相信有部分知識點可能是我們日常工作會見到或用到的。希望你能通過這篇文章學到更多知識。更多詳情敬請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
