Mybatis 源码分析之一二级缓存
一级缓存
其实关于 Mybatis 的一级缓存是比较抽象的,并没有什么特别的配置,都是在代码中体现出来的。
当调用 Configuration 的 newExecutor 方法来创建 executor:
public Executor newExecutor(Transaction transaction, ExecutorType executorType, boolean autoCommit) { 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, autoCommit); } // 执行对插件的调用 executor = (Executor) interceptorChain.pluginAll(executor); return executor; }
默认的 executorType 是 ExecutorType.SIMPLE(SimpleExecutor)。cacheEnabled 默认为 true ,所以一般情况下都会创建 CachingExecutor。
当我们要使全局的映射器禁用缓存,可以配置 cacheEnabled 为false:
在 CacheingExecutor 的 query 方法中:
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); }
即使没有创建 CachingExecutor,在 BaseExecutor 的 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); }
不同的是,CachingExecutor 会在 MappedStatement 中获取 Cache,如果为 null,直接调用 BaseExecutor 的 query 方法:
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(); } deferredLoads.clear(); // issue #601 if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) { clearLocalCache(); // issue #482 } } return list; }
可以看到默认使用了 localCache,这个 localCache 是 PerpetualCache 类型的,基于 HashMap 实现。不管是使用哪种 Cache,CacheKey 都是通过 BaseExecutor 来创建:
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(); if (parameterMappings.size() > 0 && parameterObject != null) { TypeHandlerRegistry typeHandlerRegistry = ms.getConfiguration().getTypeHandlerRegistry(); if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) { cacheKey.update(parameterObject); } else { MetaObject metaObject = configuration.newMetaObject(parameterObject); for (ParameterMapping parameterMapping : parameterMappings) { String propertyName = parameterMapping.getProperty(); if (metaObject.hasGetter(propertyName)) { cacheKey.update(metaObject.getValue(propertyName)); } else if (boundSql.hasAdditionalParameter(propertyName)) { cacheKey.update(boundSql.getAdditionalParameter(propertyName)); } } } } return cacheKey; }
这个 CacheKey 主要使用 hashCode 来构建唯一标识,默认的 hashCode 为 17,每一次 update 都会更新这个 hashCode :
public void update(Object object) { int baseHashCode = object == null ? 1 : object.hashCode(); count++; checksum += baseHashCode; baseHashCode *= count; hashcode = multiplier * hashcode + baseHashCode; updateList.add(object); }
如果一个查询的 id、分页组件中的 offset 和 limit、sql 语句、参数 都保持不变,那么这个查询产生的 CacheKey一定是不变的。
在一个 SqlSession 的生命周期内,二次同样的查询 CacheKey 是一样的:
-1182036712:853128989:com.fcs.demo.dao.UserMapper.selectUserMaps:0:2147483647:select * from tb_user -1182036712:853128989:com.fcs.demo.dao.UserMapper.selectUserMaps:0:2147483647:select * from tb_user
为什么强调是在一个 SqlSession 的生命周期内? PerpetualCache 类型的 localCache 被 Executor 持有,而特定类型的 Executor 又是被 DefaultSqlSession 持有,当 SqlSession 被关闭后,这些都不复存在。
所以这个 localCache 就是 Mybatis 的一级缓存,不受任何配置影响,SqlSession 级别的。
二级缓存
一开始听说 MyBatis 的一二级缓存,我以为是两种完全沾不上边的东西,后来发现这二者竟然在同一个方法里碰过面,那就是 CachingExecutor 的 query 方法:
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, key, parameterObject, boundSql); if (!dirty) { cache.getReadWriteLock().readLock().lock(); try { @SuppressWarnings("unchecked") List<E> cachedList = (List<E>) cache.getObject(key); if (cachedList != null) return cachedList; } finally { cache.getReadWriteLock().readLock().unlock(); } } List<E> list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); tcm.putObject(cache, key, list); // issue #578. Query must be not synchronized to prevent deadlocks return list; } } return delegate.<E>query(ms, parameterObject, rowBounds, resultHandler, key, boundSql); }
首先 MappedStatement 中获取 cache,这个 cache 就是所谓的二级缓存,如果这个 cache 存在,将优先去这个 cache 中查找,如果找不到结果,那就走一级缓存的路子。
突然觉得这个设计很棒啊,有点层层筛选的意思,这个筛网就是特定的 CacheKey,二级缓存筛出来了,就不需要再到一级缓存去筛了,如果一级也筛不出来,那就掉到最下面的容器里去了(数据库)。
那么二级缓存是什么级别的?这个就要看 Cache 的来源了,上面显示是从 MappedStatement 中取出来的。而 MappedStatement 是通过 MapperBuilderAssistant 的 addMappedStatement 方法构建的:
setStatementCache(isSelect, flushCache, useCache, currentCache, statementBuilder);
这个方法有三个参数值得关注:flushCache、useCache、currentCache。
而 currentCache 在下面这个方法中可以赋值(还有参照缓存相关的 useCacheRef 方法):
public Cache useNewCache(Class<? extends Cache> typeClass, Class<? extends Cache> evictionClass, Long flushInterval, Integer size, boolean readWrite, Properties props) { typeClass = valueOrDefault(typeClass, PerpetualCache.class); evictionClass = valueOrDefault(evictionClass, LruCache.class); Cache cache = new CacheBuilder(currentNamespace) .implementation(typeClass) .addDecorator(evictionClass) .clearInterval(flushInterval) .size(size) .readWrite(readWrite) .properties(props) .build(); configuration.addCache(cache); currentCache = cache; return cache; }
useNewCache 方法是在解析 XML 文件的时候调用的:
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); Properties props = context.getChildrenAsProperties(); builderAssistant.useNewCache(typeClass, evictionClass, flushInterval, size, readWrite, props); } }
可以看到如果仅仅配置一个:
<cache/>
将会采用默认的 type – PERPETUAL(PerpetualCache),默认的 eviction – LRU (最近最少使用的)算法。
官方文档这样描述:
- 映射语句文件中的所有 select 语句将会被缓存。
- 映射语句文件中的所有 insert,update 和 delete 语句会刷新缓存。
- 缓存会使用 Least Recently Used(LRU,最近最少使用的)算法来收回。
- 根据时间表(比如 no Flush Interval,没有刷新间隔), 缓存不会以任何时间顺序来刷新。
- 缓存会存储列表集合或对象(无论查询方法返回什么)的 1024 个引用。
- 缓存会被视为是 read/write(可读/可写)的缓存,意味着对象检索不是共享的,而
且可以安全地被调用者修改,而不干扰其他调用者或线程所做的潜在修改。
再回到开始的那个全局的映射器缓存是否启用的配置,如果 cacheEnabled 为 false,那个 CachingExecutor 就不会创建,即使你这里配置了 cache 也没有用。
参照缓存
某个时候,你会想在命名空间中共享相同的缓存配置和实例。在这样的情况下你可以使用 cache-ref 元素来引用另外一个缓存:
<cache-ref namespace="com.someone.application.data.SomeMapper"/>
在 useCacheRef 方法中是直接按命名空间去拿的:
public Cache useCacheRef(String namespace) { if (namespace == null) { throw new BuilderException("cache-ref element requires a namespace attribute."); } try { unresolvedCacheRef = true; Cache cache = configuration.getCache(namespace); if (cache == null) { throw new IncompleteElementException("No cache for namespace '" + namespace + "' could be found."); } currentCache = cache; unresolvedCacheRef = false; return cache; } catch (IllegalArgumentException e) { throw new IncompleteElementException("No cache for namespace '" + namespace + "' could be found.", e); } }
缓存失效与舍弃
一级缓存失效
再回顾下 Mybatis 和 Spring 结合使用时,mybatis-spring 所做的事:
- MapperFactoryBean 通过继承 SqlSessionDaoSupport 获取了 sqlSession:
public void setSqlSessionFactory(SqlSessionFactory sqlSessionFactory) { if (!this.externalSqlSession) { this.sqlSession = new SqlSessionTemplate(sqlSessionFactory); } }
- SqlSessionTemplate 通过代理来间接操纵 DefaultSqlSession:
public SqlSessionTemplate(SqlSessionFactory sqlSessionFactory, ExecutorType executorType, PersistenceExceptionTranslator exceptionTranslator) { notNull(sqlSessionFactory, "Property 'sqlSessionFactory' is required"); notNull(executorType, "Property 'executorType' is required"); this.sqlSessionFactory = sqlSessionFactory; this.executorType = executorType; this.exceptionTranslator = exceptionTranslator; this.sqlSessionProxy = (SqlSession) newProxyInstance( SqlSessionFactory.class.getClassLoader(), new Class[] { SqlSession.class }, new SqlSessionInterceptor()); }
动态代理构建了方法的执行模板:
private class SqlSessionInterceptor implements InvocationHandler { public Object invoke(Object proxy, Method method, Object[] args) throws Throwable { final SqlSession sqlSession = getSqlSession( SqlSessionTemplate.this.sqlSessionFactory, SqlSessionTemplate.this.executorType, SqlSessionTemplate.this.exceptionTranslator); try { Object result = method.invoke(sqlSession, args); if (!isSqlSessionTransactional(sqlSession, SqlSessionTemplate.this.sqlSessionFactory)) { // force commit even on non-dirty sessions because some databases require // a commit/rollback before calling close() sqlSession.commit(true); } return result; } catch (Throwable t) { Throwable unwrapped = unwrapThrowable(t); if (SqlSessionTemplate.this.exceptionTranslator != null && unwrapped instanceof PersistenceException) { Throwable translated = SqlSessionTemplate.this.exceptionTranslator.translateExceptionIfPossible((PersistenceException) unwrapped); if (translated != null) { unwrapped = translated; } } throw unwrapped; } finally { closeSqlSession(sqlSession, SqlSessionTemplate.this.sqlSessionFactory); } } }
- 通过 SqlSessionUtils 获取和关闭 SqlSession
public static SqlSession getSqlSession(SqlSessionFactory sessionFactory, ExecutorType executorType, PersistenceExceptionTranslator exceptionTranslator) { notNull(sessionFactory, "No SqlSessionFactory specified"); notNull(executorType, "No ExecutorType specified"); SqlSessionHolder holder = (SqlSessionHolder) getResource(sessionFactory); if (holder != null && holder.isSynchronizedWithTransaction()) { if (holder.getExecutorType() != executorType) { throw new TransientDataAccessResourceException("Cannot change the ExecutorType when there is an existing transaction"); } holder.requested(); if (logger.isDebugEnabled()) { logger.debug("Fetched SqlSession [" + holder.getSqlSession() + "] from current transaction"); } return holder.getSqlSession(); } if (logger.isDebugEnabled()) { logger.debug("Creating a new SqlSession"); } SqlSession session = sessionFactory.openSession(executorType); //...... return session; }
获取和关闭并不是直接操作 SqlSession,这里有 SqlSessionHolder,通过 TransactionSynchronizationManager 的 getResource 方法来获取 SqlSessionHolder,如果 holder 不为 null 并且被当前事物锁定,则在 holder 中获取 SqlSession。
public static void closeSqlSession(SqlSession session, SqlSessionFactory sessionFactory) { notNull(session, "No SqlSession specified"); notNull(sessionFactory, "No SqlSessionFactory specified"); SqlSessionHolder holder = (SqlSessionHolder) getResource(sessionFactory); if ((holder != null) && (holder.getSqlSession() == session)) { if (logger.isDebugEnabled()) { logger.debug("Releasing transactional SqlSession [" + session + "]"); } holder.released(); } else { if (logger.isDebugEnabled()) { logger.debug("Closing non transactional SqlSession [" + session + "]"); } session.close(); } }
SqlSession 如果重新获取,必然导致一级缓存失效。如果我们自己打开并关闭 SqlSession,这一切是可控的,但是和 Spring 一起使用时,就要注意这个问题。
二级缓存舍弃
看到了二级缓存,我不由自主找了一下,在我们的项目中并没有这个二级缓存的配置,这是为什么?既然可以避免重复查询,为啥不用呢?
原来不同命名空间下的表存在关联查询的话,其中一个针对某个表做了修改,另外一个命名空间下的查询没有任何变化,还是关联的这个表,那么使用了缓存明显存在脏数据。
所以如果表关联比较复杂的话,一般是不会使用二级缓存的。
- MyBatis 本地缓存和二级缓存使用以及源码分析 第一篇
- Mybatis源码分析之Cache二级缓存原理 (五)
- Mybatis缓存特性的使用及源码分析,避坑指南~
- 一步步学习 MyBatis:缓存的使用及源码分析
- MyBatis 源码分析 - 缓存原理
- 通过源码分析MyBatis的缓存
- 实际测试例子+源码分析的方式解剖MyBatis缓存的概念
- mybatis二级缓存分析
- 一步步学习 Mybatis:缓存的使用及源码分析
- Mybatis3源码分析(06)-加载Configuration-缓存配置加载
- Mybatis缓存特性的使用及源码分析,避坑指南
- mybatis源码分析缓存
- MyBatis从入门到放弃七:二级缓存原理分析
- 【MyBatis源码解析】MyBatis一二级缓存
- Mybatis工作机制源码分析—缓存机制及事务机制
- Mybatis 缓存特性的使用及源码分析
- Mybatis3源码分析(17)-Sql解析执行-缓存的实现