一级缓存
其实关于 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 一起使用时，就要注意这个问题。
二级缓存舍弃
看到了二级缓存，我不由自主找了一下，在我们的项目中并没有这个二级缓存的配置，这是为什么？既然可以避免重复查询，为啥不用呢?
原来不同命名空间下的表存在关联查询的话，其中一个针对某个表做了修改，另外一个命名空间下的查询没有任何变化，还是关联的这个表，那么使用了缓存明显存在脏数据。
所以如果表关联比较复杂的话，一般是不会使用二级缓存的。