一、快取模組
MyBatis作為一個強大的持久層框架,快取是其必不可少的功能之一,Mybatis中的快取分為一級快取和二級快取。但本質上是一樣的,都是使用Cache介面實現的。快取位於 org.apache.ibatis.cache包下。
通過結構能夠發現Cache其實使用到了裝飾器模式來實現快取的處理。先來看看Cache中的基礎類的API;Cache介面的實現類很多,但是大部分都是裝飾器,只有PerpetualCache提供了Cache介面的基本實現。
1.1 Cache介面
Cache介面是快取模組中最核心的介面,它定義了所有快取的基本行為,Cache介面的定義如下:
public interface Cache { /** * 快取物件的 ID * @return The identifier of this cache */ String getId(); /** * 向快取中新增資料,一般情況下 key是CacheKey value是查詢結果 * @param key Can be any object but usually it is a {@link CacheKey} * @param value The result of a select. */ void putObject(Object key, Object value); /** * 根據指定的key,在快取中查詢對應的結果物件 * @param key The key * @return The object stored in the cache. */ Object getObject(Object key); /** * As of 3.3.0 this method is only called during a rollback * for any previous value that was missing in the cache. * This lets any blocking cache to release the lock that * may have previously put on the key. * A blocking cache puts a lock when a value is null * and releases it when the value is back again. * This way other threads will wait for the value to be * available instead of hitting the database. * 刪除key對應的快取資料 * * @param key The key * @return Not used */ Object removeObject(Object key); /** * Clears this cache instance. * 清空快取 */ void clear(); /** * Optional. This method is not called by the core. * 快取的個數。 * @return The number of elements stored in the cache (not its capacity). */ int getSize(); /** * Optional. As of 3.2.6 this method is no longer called by the core. * <p> * Any locking needed by the cache must be provided internally by the cache provider. * 獲取讀寫鎖 * @return A ReadWriteLock */ default ReadWriteLock getReadWriteLock() { return null; } }
1.2 PerpetualCache
PerpetualCache在快取模組中扮演了ConcreteComponent的角色,其實現比較簡單,底層使用HashMap記錄快取項,具體的實現如下
/** * 在裝飾器模式用 用來被裝飾的物件 * 快取中的 基本快取處理的實現 * 其實就是一個 HashMap 的基本操作 * @author Clinton Begin */ public class PerpetualCache implements Cache { private final String id; // Cache 物件的唯一標識 // 用於記錄快取的Map物件 private final Map<Object, Object> cache = new HashMap<>(); public PerpetualCache(String id) { this.id = id; } @Override public String getId() { return id; } @Override public int getSize() { return cache.size(); } @Override public void putObject(Object key, Object value) { cache.put(key, value); } @Override public Object getObject(Object key) { return cache.get(key); } @Override public Object removeObject(Object key) { return cache.remove(key); } @Override public void clear() { cache.clear(); } @Override public boolean equals(Object o) { if (getId() == null) { throw new CacheException("Cache instances require an ID."); } if (this == o) { return true; } if (!(o instanceof Cache)) { return false; } Cache otherCache = (Cache) o; // 只關心ID return getId().equals(otherCache.getId()); } @Override public int hashCode() { if (getId() == null) { throw new CacheException("Cache instances require an ID."); } // 只關心ID return getId().hashCode(); } }
然後可以來看看cache.decorators包下提供的裝飾器。他們都實現了Cache介面。這些裝飾器都在PerpetualCache的基礎上提供了一些額外的功能,通過多個組合實現一些特殊的需求。
1.3 BlockingCache
這是一個阻塞同步的快取,它保證只有一個執行緒到快取中查詢指定的key對應的資料
/** * Simple blocking decorator * 阻塞版的快取 裝飾器 * Simple and inefficient version of EhCache's BlockingCache decorator. * It sets a lock over a cache key when the element is not found in cache. * This way, other threads will wait until this element is filled instead of hitting the database. * * @author Eduardo Macarron * */ public class BlockingCache implements Cache { private long timeout; // 阻塞超時時長 private final Cache delegate; // 被裝飾的底層 Cache 物件 // 每個key 都有物件的 ReentrantLock 物件 private final ConcurrentHashMap<Object, ReentrantLock> locks; public BlockingCache(Cache delegate) { // 被裝飾的 Cache 物件 this.delegate = delegate; this.locks = new ConcurrentHashMap<>(); } @Override public String getId() { return delegate.getId(); } @Override public int getSize() { return delegate.getSize(); } @Override public void putObject(Object key, Object value) { try { // 執行 被裝飾的 Cache 中的方法 delegate.putObject(key, value); } finally { // 釋放鎖 releaseLock(key); } } @Override public Object getObject(Object key) { acquireLock(key); // 獲取鎖 Object value = delegate.getObject(key); // 獲取快取資料 if (value != null) { // 有資料就釋放掉鎖,否則繼續持有鎖 releaseLock(key); } return value; } @Override public Object removeObject(Object key) { // despite of its name, this method is called only to release locks releaseLock(key); return null; } @Override public void clear() { delegate.clear(); } private ReentrantLock getLockForKey(Object key) { return locks.computeIfAbsent(key, k -> new ReentrantLock()); } private void acquireLock(Object key) { Lock lock = getLockForKey(key); if (timeout > 0) { try { boolean acquired = lock.tryLock(timeout, TimeUnit.MILLISECONDS); if (!acquired) { throw new CacheException("Couldn't get a lock in " + timeout + " for the key " + key + " at the cache " + delegate.getId()); } } catch (InterruptedException e) { throw new CacheException("Got interrupted while trying to acquire lock for key " + key, e); } } else { lock.lock(); } } private void releaseLock(Object key) { ReentrantLock lock = locks.get(key); if (lock.isHeldByCurrentThread()) { lock.unlock(); } } public long getTimeout() { return timeout; } public void setTimeout(long timeout) { this.timeout = timeout; } }
通過原始碼我們能夠發現,BlockingCache本質上就是在操作快取資料的前後通過ReentrantLock物件來實現了加鎖和解鎖操作。
快取實現類 | 快取實現類 | 作用 | 裝飾條件 |
基本快取 |
快取基本實現類 |
預設是PerpetualCache,也可以自定義比如RedisCache、EhCache等,具備基本功能的快取類 | 無 |
LruCache |
LRU策略的快取 |
當快取到達上限時候,刪除最近最少使用的快取(Least Recently Use) |
eviction="LRU"(預設) |
FifoCache |
FIFO策略的快取 |
當快取到達上限時候,刪除最先入隊的快取 |
eviction="FIFO" |
SoftCacheWeakCache |
帶清理策略的快取 |
通過JVM的軟引用和弱引用來實現快取,當JVM記憶體不足時,會自動清理掉這些快取,基於SoftReference和WeakReference |
eviction="SOFT"eviction="WEAK" |
LoggingCache |
帶日誌功能的快取 |
比如:輸出快取命中率 | 基本 |
SynchronizedCache |
同步快取 |
基於synchronized關鍵字實現,解決併發問題 |
基本 |
BlockingCache |
阻塞快取 |
通過在get/put方式中加鎖,保證只有一個執行緒操作快取,基於Java重入鎖實現 |
blocking=true |
SerializedCache |
支援序列化的快取 |
將物件序列化以後存到快取中,取出時反序列化 |
readOnly=false(預設) |
ScheduledCache |
定時排程的快取 |
在進行get/put/remove/getSize等操作前,判斷快取時間是否超過了設定的最長快取時間(預設 |
flushInterval不為空 |
TransactionalCache |
事務快取 |
在二級快取中使用,可一次存入多個快取,移除多個快取 |
在TransactionalCacheManager中用Map維護對應關係 |
1.4 快取的應用
1.4.1 快取對應的初始化
在之前寫的程式碼中斷個點看下可能直接點,在斷點前說明下要求,如要開啟快取要在配置檔案開啟一級和二級快取
然後呢在mapper.XML檔案加入<cache/>標籤就可以了
下面來斷點看下
通過上面截圖可以很清楚的看到這是一個裝飾器過程,接下來看下在Configuration初始化的時候怎麼給我們的各種Cache實現註冊對應的別名
在解析settings標籤的時候,設定的預設值有如下;因為前面原始碼跟了好多次,這裡面我直接進到解析這一段程式碼了
public Configuration parse() { //檢查是否已經解析過了 if (parsed) { throw new BuilderException("Each XMLConfigBuilder can only be used once."); } parsed = true; // XPathParser,dom 和 SAX 都有用到 >> parseConfiguration(parser.evalNode("/configuration")); return configuration; }
private void parseConfiguration(XNode root) { try { //issue #117 read properties first // 對於全域性配置檔案各種標籤的解析 propertiesElement(root.evalNode("properties")); // 解析 settings 標籤 Properties settings = settingsAsProperties(root.evalNode("settings")); // 讀取檔案 loadCustomVfs(settings); // 日誌設定 loadCustomLogImpl(settings); // 型別別名 typeAliasesElement(root.evalNode("typeAliases")); // 外掛 pluginElement(root.evalNode("plugins")); // 用於建立物件 objectFactoryElement(root.evalNode("objectFactory")); // 用於對物件進行加工 objectWrapperFactoryElement(root.evalNode("objectWrapperFactory")); // 反射工具箱 reflectorFactoryElement(root.evalNode("reflectorFactory")); // settings 子標籤賦值,預設值就是在這裡提供的 >> settingsElement(settings); // read it after objectFactory and objectWrapperFactory issue #631 // 建立了資料來源 >> environmentsElement(root.evalNode("environments")); //解析databaseIdProvider標籤,生成DatabaseIdProvider物件(用來支援不同廠商的資料庫)。 databaseIdProviderElement(root.evalNode("databaseIdProvider")); typeHandlerElement(root.evalNode("typeHandlers")); // 解析引用的Mapper對映器 mapperElement(root.evalNode("mappers")); } catch (Exception e) { throw new BuilderException("Error parsing SQL Mapper Configuration. Cause: " + e, e); } }
在上面的全域性配置檔案中在settingsElement(settings);的賦值中會做一些預設的處理,點進去看下
通過上面發現cacheEnabled預設為true,localCacheScope預設為 SESSION,在初始化過程中關鍵的還是對映檔案的解析,點選mapperElement(root.evalNode("mappers"));進去看下
private void mapperElement(XNode parent) throws Exception { if (parent != null) { for (XNode child : parent.getChildren()) { // 不同的定義方式的掃描,最終都是呼叫 addMapper()方法(新增到 MapperRegistry)。這個方法和 getMapper() 對應 // package 包 if ("package".equals(child.getName())) { String mapperPackage = child.getStringAttribute("name"); configuration.addMappers(mapperPackage); } else { String resource = child.getStringAttribute("resource"); String url = child.getStringAttribute("url"); String mapperClass = child.getStringAttribute("class"); if (resource != null && url == null && mapperClass == null) { // resource 相對路徑 ErrorContext.instance().resource(resource); InputStream inputStream = Resources.getResourceAsStream(resource); XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, resource, configuration.getSqlFragments()); // 解析 Mapper.xml,總體上做了兩件事情 >> mapperParser.parse(); } else if (resource == null && url != null && mapperClass == null) { // url 絕對路徑 ErrorContext.instance().resource(url); InputStream inputStream = Resources.getUrlAsStream(url); XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, url, configuration.getSqlFragments()); mapperParser.parse(); } else if (resource == null && url == null && mapperClass != null) { // class 單個介面 Class<?> mapperInterface = Resources.classForName(mapperClass); configuration.addMapper(mapperInterface); } else { throw new BuilderException("A mapper element may only specify a url, resource or class, but not more than one."); } } } } }
直接進入他的關鍵程式碼mapperParser.parse();,
public void parse() { // 總體上做了兩件事情,對於語句的註冊和介面的註冊 if (!configuration.isResourceLoaded(resource)) { // 1、具體增刪改查標籤的解析。 // 一個標籤一個MappedStatement。 >> configurationElement(parser.evalNode("/mapper")); configuration.addLoadedResource(resource); // 2、把namespace(介面型別)和工廠類繫結起來,放到一個map。 // 一個namespace 一個 MapperProxyFactory >> bindMapperForNamespace(); } parsePendingResultMaps(); parsePendingCacheRefs(); parsePendingStatements(); }
上面是對映檔案的解析操作,可以看他進了標籤的解析,進去看下
private void configurationElement(XNode context) { try { String namespace = context.getStringAttribute("namespace"); if (namespace == null || namespace.equals("")) { throw new BuilderException("Mapper's namespace cannot be empty"); } builderAssistant.setCurrentNamespace(namespace); // 新增快取物件 cacheRefElement(context.evalNode("cache-ref")); // 解析 cache 屬性,新增快取物件 cacheElement(context.evalNode("cache")); // 建立 ParameterMapping 物件 parameterMapElement(context.evalNodes("/mapper/parameterMap")); // 建立 List<ResultMapping> resultMapElements(context.evalNodes("/mapper/resultMap")); // 解析可以複用的SQL sqlElement(context.evalNodes("/mapper/sql")); // 解析增刪改查標籤,得到 MappedStatement >> buildStatementFromContext(context.evalNodes("select|insert|update|delete")); } catch (Exception e) { throw new BuilderException("Error parsing Mapper XML. The XML location is '" + resource + "'. Cause: " + e, e); } }
看到這裡好像找到了想找的東西,可以看到上面程式碼我標的兩個地方的標籤解析,跟進去看下
private void cacheElement(XNode context) { // 只有 cache 標籤不為空才解析 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); } }
會發現上面開始解析相關的屬性資訊了,並在最後一步進行了儲存,繼續跟進去看下
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; }
然後可以發現 如果儲存 cache 標籤,那麼對應的 Cache物件會被儲存在 currentCache 屬性中。
進而在 Cache 物件 儲存在了 MapperStatement 物件的 cache 屬性中。這就是cache節點建立的整個過程。
1.4.2 一級快取
一級快取也叫本地快取(Local Cache),MyBatis的一級快取是在會話(SqlSession)層面進行快取的。MyBatis的一級快取是預設開啟的,不需要任何的配置(如果要關閉,localCacheScope設定為STATEMENT)。在BaseExecutor物件的query方法中有關閉一級快取的邏輯
從上面的效果可以很清楚的感受到在一個會話內,第二次查詢是直接走快取的,在不同會話內快取是不起效的。下面會了解快取做了啥跟進程式碼看下。入口從上面演示就可以猜到是從
SqlSession sqlSession = factory.openSession();進入的
@Override public SqlSession openSession() { return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, false); }
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) { //事務物件 Transaction tx = null; try { final Environment environment = configuration.getEnvironment(); // 獲取事務工廠 final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment); // 建立事務 tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit); // 根據事務工廠和預設的執行器型別,建立執行器 >>執行SQL語句操作 final Executor executor = configuration.newExecutor(tx, execType); return new DefaultSqlSession(configuration, executor, autoCommit); } catch (Exception e) { closeTransaction(tx); // may have fetched a connection so lets call close() throw ExceptionFactory.wrapException("Error opening session. Cause: " + e, e); } finally { ErrorContext.instance().reset(); } }
在建立對應的執行器的時候會有快取的操作
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) {//針對Statement做快取 executor = new ReuseExecutor(this, transaction); } else { // 預設 SimpleExecutor,每一次只是SQL操作都建立一個新的Statement物件 executor = new SimpleExecutor(this, transaction); } // 二級快取開關,settings 中的 cacheEnabled 預設是 true if (cacheEnabled) { executor = new CachingExecutor(executor); } // 植入外掛的邏輯,至此,四大物件已經全部攔截完畢;這裡面是一個攔截器鏈 executor = (Executor) interceptorChain.pluginAll(executor); return executor; }
從上面程式碼可以知道如果 cacheEnabled 為 true 就會通過 CachingExecutor 來裝飾executor 物件,然後就是在執行SQL操作的時候會涉及到快取的具體使用。這個就分為一級快取和二級快取,通過這個跟蹤會發現在建立會話時會建立執行器,而執行器裡面跟快取有關係的是二級快取,跟我想找的一級快取沒什麼關係;那麼一級快取在哪呢,這時候我想一級快取是跟會話有關,那麼他的位置一定在會話內的這段程式碼裡,那我就找下一段程式碼
// 4.通過SqlSession中提供的 API方法來運算元據庫 List<User1> list = sqlSession.selectList("com.ghy.mapper.UserMapper.selectUserList");
進入selectList看下
@Override public <E> List<E> selectList(String statement) { return this.selectList(statement, null); }
@Override public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) { try { MappedStatement ms = configuration.getMappedStatement(statement); // 如果 cacheEnabled = true(預設),Executor會被 CachingExecutor裝飾 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(); } }
在上面程式碼中可以看到一個查詢操作,那肯定是要進去看下他在查詢前有沒有快取判斷,如果沒有說明selectList程式碼是不走快取的;
在上面程式碼中發現了一些跟快取相關的操作CacheKey
@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()); // 0 cacheKey.update(rowBounds.getLimit()); // 2147483647 = 2^31-1 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); // development } } if (configuration.getEnvironment() != null) { // issue #176 cacheKey.update(configuration.getEnvironment().getId()); } return cacheKey; }
發現上面是一個快取建立的邏輯,這個東西debugger看一下其實就明白了;其實這寫了一堆就是生成一個東西,生成一個快取的KEY,而且這個KEY是跟我們寫的SQL有關;明白了這個key的作用後回退一步跟進query看他拿這個key去做了什麼
@Override public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { // 異常體系之 ErrorContext 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()) { // flushCache="true"時,即使是查詢,也清空一級快取 clearLocalCache(); } List<E> list; try { // 防止遞迴查詢重複處理快取 queryStack++; // 查詢一級快取 // ResultHandler 和 ResultSetHandler的區別 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; }
從上面就找到了查詢一級快取的位置了,如果list判斷是空說明快取沒資料他會走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 { // 三種 Executor 的區別,看doUpdate // 預設Simple 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; }
1.4.3 二級快取
二級快取是用來解決一級快取不能跨會話共享的問題的,範圍是namespace級別的,可以被多個SqlSession共享(只要是同一個介面裡面的相同方法,都可以共享),生命週期和應用同步。二級快取的設定,首先是settings中的cacheEnabled要設定為true,當然預設的就是為true,這個步驟決定了在建立Executor物件的時候是否通過CachingExecutor來裝飾。前面原始碼中也有說明過;要想看二級快取效果,</cache>標籤要開啟
然後把一級快取配置關閉了,其實由於一級快取的作用域太小,在實際生產中用的也比較少
從上面可以發現第二次查詢就沒走資料庫查詢,說明二級快取生效了。接下來看下二級快取原始碼,其實在上面已經寫出來了,入口是factory.openSession();
@Override public SqlSession openSession() { return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, false); }
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) { //事務物件 Transaction tx = null; try { final Environment environment = configuration.getEnvironment(); // 獲取事務工廠 final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment); // 建立事務 tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit); // 根據事務工廠和預設的執行器型別,建立執行器 >>執行SQL語句操作 final Executor executor = configuration.newExecutor(tx, execType); return new DefaultSqlSession(configuration, executor, autoCommit); } catch (Exception e) { closeTransaction(tx); // may have fetched a connection so lets call close() throw ExceptionFactory.wrapException("Error opening session. Cause: " + e, e); } finally { ErrorContext.instance().reset(); } }
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) {//針對Statement做快取 executor = new ReuseExecutor(this, transaction); } else { // 預設 SimpleExecutor,每一次只是SQL操作都建立一個新的Statement物件 executor = new SimpleExecutor(this, transaction); } // 二級快取開關,settings 中的 cacheEnabled 預設是 true if (cacheEnabled) { executor = new CachingExecutor(executor); } // 植入外掛的邏輯,至此,四大物件已經全部攔截完畢;這裡面是一個攔截器鏈 executor = (Executor) interceptorChain.pluginAll(executor); return executor; }
從這裡可以看到如果判斷成立,那麼會對executor做一個裝飾;後面做查詢操作時就要從sqlSession.selectList("com.ghy.mapper.UserMapper.selectUserList");跟蹤起了
@Override public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) { try { MappedStatement ms = configuration.getMappedStatement(statement); // 如果 cacheEnabled = true(預設),Executor會被 CachingExecutor裝飾 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裡面了,這裡面是二級快取的東西
@Override public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException { // 獲取SQL BoundSql boundSql = ms.getBoundSql(parameterObject); // 建立CacheKey:什麼樣的SQL是同一條SQL? >> CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql); return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); }
這裡面建立createCacheKey的過程和一級快取一樣,這裡就不想再寫一次了;
@Override public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException { Cache cache = ms.getCache(); // cache 物件是在哪裡建立的? XMLMapperBuilder類 xmlconfigurationElement() // 由 <cache> 標籤決定 if (cache != null) { // flushCache="true" 清空一級二級快取 >> flushCacheIfRequired(ms); if (ms.isUseCache() && resultHandler == null) { ensureNoOutParams(ms, boundSql); // 獲取二級快取 // 快取通過 TransactionalCacheManager、TransactionalCache 管理 @SuppressWarnings("unchecked") List<E> list = (List<E>) 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; } } // 走到 SimpleExecutor | ReuseExecutor | BatchExecutor return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); }
這就是二級快取過程;
cache屬性詳解:
屬性 | 含義 | 取值 |
type |
快取實現類 |
需要實現Cache介面,預設是PerpetualCache,可以使用第三方快取 |
size |
最多快取物件個數 |
預設1024 |
eviction |
回收策略(快取淘汰演算法) |
LRU – 最近最少使用的:移除最長時間不被使用的物件(預設)。FIFO |
flushInterval |
定時自動清空快取間隔 |
自動重新整理時間,單位 ms,未配置時只有呼叫時重新整理 |
readOnly |
是否只讀 |
true:只讀快取;會給所有呼叫者返回快取物件的相同例項。因此這些 |
blocking |
啟用阻塞快取 |
通過在get/put方式中加鎖,保證只有一個執行緒操作快取,基於Java重入鎖實現 |
1.4.4 第三方快取
在實際開發的時候我們一般也很少使用MyBatis自帶的二級快取,這時我們會使用第三方的快取工具Ehcache獲取Redis來實現 https://github.com/mybatis/redis-cache
新增依賴
<dependency> <groupId>org.mybatis.caches</groupId> <artifactId>mybatis-redis</artifactId> <version>1.0.0-beta2</version> </dependency>
然後加上Cache標籤的配置
<cache type="org.mybatis.caches.redis.RedisCache" eviction="FIFO" flushInterval="60000" size="512" readOnly="true"/>
然後新增redis的屬性檔案
這樣快取就存入redis中了,至於怎麼讀到redis.properites檔案的,這個可以從原始碼中找下
從上面看到在構造方法中會做一些初始的操作,其中的JedisPool是操作連線去操作redis的;
public RedisConfig parseConfiguration() { return parseConfiguration(getClass().getClassLoader()); }
從原始碼中可以發現他已經做好了redis連線配置檔案的預設命名了;