共计 23712 个字符，预计需要花费 60 分钟才能阅读完成。
缓存就是内存中的数据，经常来自对数据库查问后果的保留。应用缓存，咱们能够防止频繁的与数据库进行交互，进而进步响应速度 MyBatis 也提供了对缓存的反对，分为一级缓存和二级缓存，能够通过下图来了解：
①、一级缓存是 SqlSession 级别的缓存。在操作数据库时须要结构 sqlSession 对象，在对象中有一个数据结构（HashMap）用于存储缓存数据。不同的 sqlSession 之间的缓存数据区域（HashMap）是相互不影响的。
②、二级缓存是 mapper 级别的缓存，多个 SqlSession 去操作同一个 Mapper 的 sql 语句，多个 SqlSession 能够共用二级缓存，二级缓存是跨 SqlSession 的
一级缓存
默认是开启的
①、咱们应用同一个 sqlSession，对 User 表依据雷同 id 进行两次查问，查看他们收回 sql 语句的状况
@Test
public void firstLevelCacheTest() throws IOException {
// 1. 通过类加载器对配置文件进行加载，加载成了字节输出流，存到内存中 留神：配置文件并没有被解析
InputStream resourceAsStream = Resources.getResourceAsStream("sqlMapConfig.xml");
// 2. (1)解析了配置文件，封装 configuration 对象（2）创立了 DefaultSqlSessionFactory 工厂对象
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(resourceAsStream);
// 3. 问题：openSession()执行逻辑是什么？// 3. (1)创立事务对象（2）创立了执行器对象 cachingExecutor (3)创立了 DefaultSqlSession 对象
SqlSession sqlSession = sqlSessionFactory.openSession();
// 4. 委派给 Executor 来执行，Executor 执行时又会调用很多其余组件（参数设置、解析 sql 的获取，sql 的执行、后果集的封装）User user = sqlSession.selectOne("com.itheima.mapper.UserMapper.findByCondition", 1);
User user2 = sqlSession.selectOne("com.itheima.mapper.UserMapper.findByCondition", 1);
System.out.println(user == user2);
sqlSession.close();}查看控制台打印状况：
② 同样是对 user 表进行两次查问，只不过两次查问之间进行了一次 update 操作。
@Test
public void test3() throws IOException {
// 1. 通过类加载器对配置文件进行加载，加载成了字节输出流，存到内存中 留神：配置文件并没有被解析
InputStream resourceAsStream = Resources.getResourceAsStream("sqlMapConfig.xml");
// 2. (1)解析了配置文件，封装 configuration 对象（2）创立了 DefaultSqlSessionFactory 工厂对象
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(resourceAsStream);
// 3. 问题：openSession()执行逻辑是什么？// 3. (1)创立事务对象（2）创立了执行器对象 cachingExecutor (3)创立了 DefaultSqlSession 对象
SqlSession sqlSession = sqlSessionFactory.openSession();
// 4. 委派给 Executor 来执行，Executor 执行时又会调用很多其余组件（参数设置、解析 sql 的获取，sql 的执行、后果集的封装）User user = sqlSession.selectOne("com.itheima.mapper.UserMapper.findByCondition", 1);
User user1 = new User();
user1.setId(1);
user1.setUsername("zimu");
sqlSession.update("com.itheima.mapper.UserMapper.updateUser",user1);
sqlSession.commit();
User user2 = sqlSession.selectOne("com.itheima.mapper.UserMapper.findByCondition", 1);
System.out.println(user == user2);
System.out.println(user);
System.out.println(user2);
System.out.println("MyBatis 源码环境搭建胜利....");
sqlSession.close();}查看控制台打印状况：
③、总结
1、第一次发动查问用户 id 为 1 的用户信息，先去找缓存中是否有 id 为 1 的用户信息，如果没有，从 数据库查问用户信息。失去用户信息，将用户信息存储到一级缓存中。
2、如果两头 sqlSession 去执行 commit 操作（执行插入、更新、删除），则会清空 SqlSession 中的 一级缓存，这样做的目标为了让缓存中存储的是最新的信息，防止脏读。
3、第二次发动查问用户 id 为 1 的用户信息，先去找缓存中是否有 id 为 1 的用户信息，缓存中有，直 接从缓存中获取用户信息
一级缓存原理探索与源码剖析
问题 1：一级缓存 底层数据结构到底是什么？
问题 2：一级缓存的工作流程是怎么的？
一级缓存 底层数据结构到底是什么？
之前说 不同 SqlSession 的一级缓存互不影响, 所以我从 SqlSession 这个类动手
能够看到，org.apache.ibatis.session.SqlSession中有一个和缓存无关的办法——clearCache()刷新缓存的办法，点进去，找到它的实现类DefaultSqlSession
@Override
public void clearCache() {executor.clearLocalCache();
}再次点进去executor.clearLocalCache(), 再次点进去并找到其实现类BaseExecutor，
@Override
public void clearLocalCache() {if (!closed) {localCache.clear();
localOutputParameterCache.clear();}
进入 localCache.clear() 办法。进入到了 org.apache.ibatis.cache.impl.PerpetualCache 类中
package org.apache.ibatis.cache.impl;
import java.util.HashMap;
import java.util.Map;
import java.util.concurrent.locks.ReadWriteLock;
import org.apache.ibatis.cache.Cache;
import org.apache.ibatis.cache.CacheException;
/**
* @author Clinton Begin
*/
public class PerpetualCache implements Cache {
private final String id;
private Map<Object, Object> cache = new HashMap<Object, Object>();
public PerpetualCache(String id) {this.id = id;}
// 省略局部...
@Override
public void clear() {cache.clear();
}
// 省略局部...
}
咱们看到了 PerpetualCache 类中有一个属性 private Map<Object, Object> cache = new HashMap<Object, Object>()，很显著它是一个 HashMap，咱们所调用的.clear() 办法，实际上就是调用的 Map 的 clear 办法
得出结论：
一级缓存的数据结构的确是 HashMap
一级缓存的执行流程
咱们进入到 org.apache.ibatis.executor.Executor 中
看到一个办法 CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql)，见名思意是一个创立 CacheKey 的办法
找到它的实现类和办法org.apache.ibatis.executor.BaseExecuto.createCacheKey
咱们剖析一下创立 CacheKey 的这块代码：
public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) {if (closed) {throw new ExecutorException("Executor was closed.");
}
// 初始化 CacheKey
CacheKey cacheKey = new CacheKey();
// 存入 statementId
cacheKey.update(ms.getId());
// 别离存入分页须要的 Offset 和 Limit
cacheKey.update(rowBounds.getOffset());
cacheKey.update(rowBounds.getLimit());
// 把从 BoundSql 中封装的 sql 取出并存入到 cacheKey 对象中
cacheKey.update(boundSql.getSql());
// 上面这一块就是封装参数
List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
TypeHandlerRegistry typeHandlerRegistry = ms.getConfiguration().getTypeHandlerRegistry();
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);
}
}
// 从 configuration 对象中（也就是载入配置文件后寄存的对象）把 EnvironmentId 存入
/**
* <environments default="development">
* <environment id="development"> // 就是这个 id
* <!-- 以后事务交由 JDBC 进行治理 -->
* <transactionManager type="JDBC"></transactionManager>
* <!-- 以后应用 mybatis 提供的连接池 -->
* <dataSource type="POOLED">
* <property name="driver" value="${jdbc.driver}"/>
* <property name="url" value="${jdbc.url}"/>
* <property name="username" value="${jdbc.username}"/>
* <property name="password" value="${jdbc.password}"/>
* </dataSource>
* </environment>
* </environments>
*/
if (configuration.getEnvironment() != null) {
// issue #176
cacheKey.update(configuration.getEnvironment().getId());
}
// 返回
return cacheKey;
}咱们再点进去 cacheKey.update() 办法看一看
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 final int multiplier;
private int hashcode;
private long checksum;
private int count;
// 值存入的中央
private transient List<Object> updateList;
// 省略局部办法......
// 省略局部办法......
public void update(Object object) {int baseHashCode = object == null ? 1 : ArrayUtil.hashCode(object);
count++;
checksum += baseHashCode;
baseHashCode *= count;
hashcode = multiplier * hashcode + baseHashCode;
// 看到把值传入到了一个 list 中
updateList.add(object);
}
// 省略局部办法......
}咱们晓得了那些数据是在 CacheKey 对象中如何存储的了。上面咱们返回 createCacheKey() 办法。
咱们进入 BaseExecutor，能够看到一个query() 办法：
这里咱们很分明的看到，在执行 query() 办法前，CacheKey办法被创立了
咱们能够看到，创立 CacheKey 后调用了 query()办法，咱们再次点进去：
在执行 SQL 前如何在一级缓存中找不到 Key，那么将会执行 sql，咱们来看一下执行 sql 前后会做些什么，进入list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
剖析一下：
private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
List<E> list;
//1. 把 key 存入缓存，value 放一个占位符
localCache.putObject(key, EXECUTION_PLACEHOLDER);
try {
//2. 与数据库交互
list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
} finally {
//3. 如果第 2 步出了什么异样，把第 1 步存入的 key 删除
localCache.removeObject(key);
}
//4. 把后果存入缓存
localCache.putObject(key, list);
if (ms.getStatementType() == StatementType.CALLABLE) {localOutputParameterCache.putObject(key, parameter);
}
return list;
}一级缓存源码剖析论断：
- 一级缓存的数据结构是一个
HashMap<Object,Object>，它的 value 就是查问后果，它的 key 是CacheKey，CacheKey中有一个 list 属性，statementId,params,rowbounds,sql等参数都存入到了这个 list 中 - 先创立
CacheKey，会首先依据CacheKey查问缓存中有没有，如果有，就解决缓存中的参数，如果没有，就执行 sql，执行 sql 后执行 sql 后把后果存入缓存
二级缓存
留神：Mybatis 的二级缓存不是默认开启的，是须要通过配置能力应用的
启用二级缓存
分为三步走：
1）开启映射器配置文件中的缓存配置：
<settings>
<setting name="cacheEnabled" value="true"/>
</settings>2) 在须要应用二级缓存的 Mapper 配置文件中配置 <cache> 标签
<!--type：cache 应用的类型，默认是 PerpetualCache，这在一级缓存中提到过。eviction：定义回收的策略，常见的有 FIFO，LRU。flushInterval：配置肯定工夫主动刷新缓存，单位是毫秒。size：最多缓存对象的个数。readOnly：是否只读，若配置可读写，则须要对应的实体类可能序列化。blocking：若缓存中找不到对应的 key，是否会始终 blocking，直到有对应的数据进入缓存。-->
<cache></cache>3）在具体 CURD 标签上配置 useCache=true
<select id="findById" resultType="com.itheima.pojo.User" useCache="true">
select * from user where id = #{id}
</select>** 留神：实体类要实现 Serializable 接口，因为二级缓存会将对象写进硬盘，就必须序列化，以及兼容对象在网络中的传输
具体实现
/**
* 测试一级缓存
*/
@Test
public void secondLevelCacheTest() throws IOException {InputStream resourceAsStream = Resources.getResourceAsStream("sqlMapConfig.xml");
// 2. (1)解析了配置文件，封装 configuration 对象（2）创立了 DefaultSqlSessionFactory 工厂对象
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(resourceAsStream);
// 3. 问题：openSession()执行逻辑是什么？// 3. (1)创立事务对象（2）创立了执行器对象 cachingExecutor (3)创立了 DefaultSqlSession 对象
SqlSession sqlSession1 = sqlSessionFactory.openSession();
// 发动第一次查问，查问 ID 为 1 的用户
User user1 = sqlSession1.selectOne("com.itheima.mapper.UserMapper.findByCondition", 1);
// *** 必须调用 sqlSession1.commit()或者 close(), 一级缓存中的内容才会刷新到二级缓存中
sqlSession1.commit();// close();
// 发动第二次查问，查问 ID 为 1 的用户
SqlSession sqlSession2 = sqlSessionFactory.openSession();
User user2 = sqlSession2.selectOne("com.itheima.mapper.UserMapper.findByCondition", 1);
System.out.println(user1 == user2);
System.out.println(user1);
System.out.println(user2);
sqlSession1.close();
sqlSession2.close();}二级缓存源码剖析
问题：
① cache 标签如何被解析的（二级缓存的底层数据结构是什么？）？
② 同时开启一级缓存二级缓存，优先级？
③ 为什么只有执行 sqlSession.commit 或者 sqlSession.close 二级缓存才会失效
④ 更新办法为什么不会清空二级缓存？
标签 < cache/> 的解析
二级缓存和具体的命名空间绑定，一个 Mapper 中有一个 Cache, 雷同 Mapper 中的 MappedStatement 共用同一个 Cache
依据之前的 mybatis 源码分析，xml 的解析工作次要交给 XMLConfigBuilder.parse()办法来实现
// XMLConfigBuilder.parse()
public Configuration parse() {if (parsed) {throw new BuilderException("Each XMLConfigBuilder can only be used once.");
}
parsed = true;
parseConfiguration(parser.evalNode("/configuration"));// 在这里
return configuration;
}
// parseConfiguration()
// 既然是在 xml 中增加的，那么咱们就间接看对于 mappers 标签的解析
private void parseConfiguration(XNode root) {
try {Properties settings = settingsAsPropertiess(root.evalNode("settings"));
propertiesElement(root.evalNode("properties"));
loadCustomVfs(settings);
typeAliasesElement(root.evalNode("typeAliases"));
pluginElement(root.evalNode("plugins"));
objectFactoryElement(root.evalNode("objectFactory"));
objectWrapperFactoryElement(root.evalNode("objectWrapperFactory"));
reflectionFactoryElement(root.evalNode("reflectionFactory"));
settingsElement(settings);
// read it after objectFactory and objectWrapperFactory issue #631
environmentsElement(root.evalNode("environments"));
databaseIdProviderElement(root.evalNode("databaseIdProvider"));
typeHandlerElement(root.evalNode("typeHandlers"));
// 就是这里
mapperElement(root.evalNode("mappers"));
} catch (Exception e) {throw new BuilderException("Error parsing SQL Mapper Configuration. Cause:" + e, e);
}
}
// mapperElement()
private void mapperElement(XNode parent) throws Exception {if (parent != null) {for (XNode child : parent.getChildren()) {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 判断
if (resource != null && url == null && mapperClass == null) {ErrorContext.instance().resource(resource);
InputStream inputStream = Resources.getResourceAsStream(resource);
XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, resource, configuration.getSqlFragments());
// 生成 XMLMapperBuilder，并执行其 parse 办法
mapperParser.parse();} else if (resource == null && url != null && mapperClass == null) {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<?> 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.");
}
}
}
}
} 咱们来看看解析 Mapper.xml
// XMLMapperBuilder.parse()
public void parse() {if (!configuration.isResourceLoaded(resource)) {
// 解析 mapper 属性
configurationElement(parser.evalNode("/mapper"));
configuration.addLoadedResource(resource);
bindMapperForNamespace();}
parsePendingResultMaps();
parsePendingChacheRefs();
parsePendingStatements();}
// configurationElement()
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"));
parameterMapElement(context.evalNodes("/mapper/parameterMap"));
resultMapElements(context.evalNodes("/mapper/resultMap"));
sqlElement(context.evalNodes("/mapper/sql"));
// 这里会将生成的 Cache 包装到对应的 MappedStatement
buildStatementFromContext(context.evalNodes("select|insert|update|delete"));
} catch (Exception e) {throw new BuilderException("Error parsing Mapper XML. Cause:" + e, e);
}
}
// cacheElement()
private void cacheElement(XNode context) throws Exception {if (context != null) {
// 解析 <cache/> 标签的 type 属性，这里咱们能够自定义 cache 的实现类，比方 redisCache，如果没有自定义，这里应用和一级缓存雷同的 PERPETUAL
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();
// 构建 Cache 对象
builderAssistant.useNewCache(typeClass, evictionClass, flushInterval, size, readWrite, blocking, props);
}
}先来看看是如何构建 Cache 对象的
MapperBuilderAssistant.useNewCache()
public Cache useNewCache(Class<? extends Cache> typeClass,
Class<? extends Cache> evictionClass,
Long flushInterval,
Integer size,
boolean readWrite,
boolean blocking,
Properties props) {
// 1. 生成 Cache 对象
Cache cache = new CacheBuilder(currentNamespace)
// 这里如果咱们定义了 <cache/> 中的 type，就应用自定义的 Cache, 否则应用和一级缓存雷同的 PerpetualCache
.implementation(valueOrDefault(typeClass, PerpetualCache.class))
.addDecorator(valueOrDefault(evictionClass, LruCache.class))
.clearInterval(flushInterval)
.size(size)
.readWrite(readWrite)
.blocking(blocking)
.properties(props)
.build();
// 2. 增加到 Configuration 中
configuration.addCache(cache);
// 3. 并将 cache 赋值给 MapperBuilderAssistant.currentCache
currentCache = cache;
return cache;
}咱们看到一个 Mapper.xml 只会解析一次 <cache/> 标签，也就是只创立一次 Cache 对象，放进 configuration 中，并将 cache 赋值给 MapperBuilderAssistant.currentCache
buildStatementFromContext(context.evalNodes(“select|insert|update|delete”)); 将 Cache 包装到 MappedStatement
// buildStatementFromContext()
private void buildStatementFromContext(List<XNode> list) {if (configuration.getDatabaseId() != null) {buildStatementFromContext(list, configuration.getDatabaseId());
}
buildStatementFromContext(list, null);
}
//buildStatementFromContext()
private void buildStatementFromContext(List<XNode> list, String requiredDatabaseId) {for (XNode context : list) {final XMLStatementBuilder statementParser = new XMLStatementBuilder(configuration, builderAssistant, context, requiredDatabaseId);
try {
// 每一条执行语句转换成一个 MappedStatement
statementParser.parseStatementNode();} catch (IncompleteElementException e) {configuration.addIncompleteStatement(statementParser);
}
}
}
// XMLStatementBuilder.parseStatementNode();
public void parseStatementNode() {String id = context.getStringAttribute("id");
String databaseId = context.getStringAttribute("databaseId");
...
Integer fetchSize = context.getIntAttribute("fetchSize");
Integer timeout = context.getIntAttribute("timeout");
String parameterMap = context.getStringAttribute("parameterMap");
String parameterType = context.getStringAttribute("parameterType");
Class<?> parameterTypeClass = resolveClass(parameterType);
String resultMap = context.getStringAttribute("resultMap");
String resultType = context.getStringAttribute("resultType");
String lang = context.getStringAttribute("lang");
LanguageDriver langDriver = getLanguageDriver(lang);
...
// 创立 MappedStatement 对象
builderAssistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType,
fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass,
resultSetTypeEnum, flushCache, useCache, resultOrdered,
keyGenerator, keyProperty, keyColumn, databaseId, langDriver, resultSets);
}
// builderAssistant.addMappedStatement()
public MappedStatement addMappedStatement(
String id,
...) {if (unresolvedCacheRef) {throw new IncompleteElementException("Cache-ref not yet resolved");
}
id = applyCurrentNamespace(id, false);
boolean isSelect = sqlCommandType == SqlCommandType.SELECT;
// 创立 MappedStatement 对象
MappedStatement.Builder statementBuilder = new MappedStatement.Builder(configuration, id, sqlSource, sqlCommandType)
...
.flushCacheRequired(valueOrDefault(flushCache, !isSelect))
.useCache(valueOrDefault(useCache, isSelect))
.cache(currentCache);// 在这里将之前生成的 Cache 封装到 MappedStatement
ParameterMap statementParameterMap = getStatementParameterMap(parameterMap, parameterType, id);
if (statementParameterMap != null) {statementBuilder.parameterMap(statementParameterMap);
}
MappedStatement statement = statementBuilder.build();
configuration.addMappedStatement(statement);
return statement;
}咱们看到将 Mapper 中创立的 Cache 对象，退出到了每个 MappedStatement 对象中，也就是同一个 Mapper 中所有的 MappedStatement 中的 cache 属性援用的是同一个
有对于 <cache/> 标签的解析就到这了。
查问源码剖析
CachingExecutor
// CachingExecutor
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {BoundSql boundSql = ms.getBoundSql(parameterObject);
// 创立 CacheKey
CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
throws SQLException {
// 从 MappedStatement 中获取 Cache，留神这里的 Cache 是从 MappedStatement 中获取的
// 也就是咱们下面解析 Mapper 中 <cache/> 标签中创立的，它保留在 Configration 中
// 咱们在下面解析 blog.xml 时剖析过每一个 MappedStatement 都有一个 Cache 对象，就是这里
Cache cache = ms.getCache();
// 如果配置文件中没有配置 <cache>，则 cache 为空
if (cache != null) {
// 如果须要刷新缓存的话就刷新：flushCache="true"
flushCacheIfRequired(ms);
if (ms.isUseCache() && resultHandler == null) {ensureNoOutParams(ms, boundSql);
// 拜访二级缓存
List<E> list = (List<E>) tcm.getObject(cache, key);
// 缓存未命中
if (list == null) {
// 如果没有值，则执行查问，这个查问理论也是先走一级缓存查问，一级缓存也没有的话，则进行 DB 查问
list = delegate.<E>query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
// 缓存查问后果
tcm.putObject(cache, key, list);
}
return list;
}
}
return delegate.<E>query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}如果设置了flushCache=”true”，则每次查问都会刷新缓存
<!-- 执行此语句清空缓存 -->
<select id="findbyId" resultType="com.itheima.pojo.user" useCache="true" flushCache="true" >
select * from t_demo
</select>如上，留神二级缓存是从 MappedStatement 中获取的。因为 MappedStatement 存在于全局配置中，能够多个 CachingExecutor 获取到，这样就会呈现线程平安问题。除此之外，若不加以控制，多个事务共用一个缓存实例，会导致脏读问题。至于脏读问题，须要借助其余类来解决，也就是下面代码中 tcm 变量对应的类型。上面剖析一下。
TransactionalCacheManager
/** 事务缓存管理器 */
public class TransactionalCacheManager {
// Cache 与 TransactionalCache 的映射关系表
private final Map<Cache, TransactionalCache> transactionalCaches = new HashMap<Cache, TransactionalCache>();
public void clear(Cache cache) {
// 获取 TransactionalCache 对象，并调用该对象的 clear 办法，下同
getTransactionalCache(cache).clear();}
public Object getObject(Cache cache, CacheKey key) {
// 间接从 TransactionalCache 中获取缓存
return getTransactionalCache(cache).getObject(key);
}
public void putObject(Cache cache, CacheKey key, Object value) {
// 间接存入 TransactionalCache 的缓存中
getTransactionalCache(cache).putObject(key, value);
}
public void commit() {for (TransactionalCache txCache : transactionalCaches.values()) {txCache.commit();
}
}
public void rollback() {for (TransactionalCache txCache : transactionalCaches.values()) {txCache.rollback();
}
}
private TransactionalCache getTransactionalCache(Cache cache) {
// 从映射表中获取 TransactionalCache
TransactionalCache txCache = transactionalCaches.get(cache);
if (txCache == null) {
// TransactionalCache 也是一种装璜类，为 Cache 减少事务性能
// 创立一个新的 TransactionalCache，并将真正的 Cache 对象存进去
txCache = new TransactionalCache(cache);
transactionalCaches.put(cache, txCache);
}
return txCache;
}
}TransactionalCacheManager 外部保护了 Cache 实例与 TransactionalCache 实例间的映射关系，该类也仅负责保护两者的映射关系，真正做事的还是 TransactionalCache。TransactionalCache 是一种缓存装璜器，能够为 Cache 实例减少事务性能。上面剖析一下该类的逻辑。
TransactionalCache
public class TransactionalCache implements Cache {
// 真正的缓存对象，和下面的 Map<Cache, TransactionalCache> 中的 Cache 是同一个
private final Cache delegate;
private boolean clearOnCommit;
// 在事务被提交前，所有从数据库中查问的后果将缓存在此汇合中
private final Map<Object, Object> entriesToAddOnCommit;
// 在事务被提交前，当缓存未命中时，CacheKey 将会被存储在此汇合中
private final Set<Object> entriesMissedInCache;
@Override
public Object getObject(Object key) {
// 查问的时候是间接从 delegate 中去查问的，也就是从真正的缓存对象中查问
Object object = delegate.getObject(key);
if (object == null) {
// 缓存未命中，则将 key 存入到 entriesMissedInCache 中
entriesMissedInCache.add(key);
}
if (clearOnCommit) {return null;} else {return object;}
}
@Override
public void putObject(Object key, Object object) {
// 将键值对存入到 entriesToAddOnCommit 这个 Map 中中，而非实在的缓存对象 delegate 中
entriesToAddOnCommit.put(key, object);
}
@Override
public Object removeObject(Object key) {return null;}
@Override
public void clear() {
clearOnCommit = true;
// 清空 entriesToAddOnCommit，但不清空 delegate 缓存
entriesToAddOnCommit.clear();}
public void commit() {
// 依据 clearOnCommit 的值决定是否清空 delegate
if (clearOnCommit) {delegate.clear();
}
// 刷新未缓存的后果到 delegate 缓存中
flushPendingEntries();
// 重置 entriesToAddOnCommit 和 entriesMissedInCache
reset();}
public void rollback() {unlockMissedEntries();
reset();}
private void reset() {
clearOnCommit = false;
// 清空集合
entriesToAddOnCommit.clear();
entriesMissedInCache.clear();}
private void flushPendingEntries() {for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) {
// 将 entriesToAddOnCommit 中的内容转存到 delegate 中
delegate.putObject(entry.getKey(), entry.getValue());
}
for (Object entry : entriesMissedInCache) {if (!entriesToAddOnCommit.containsKey(entry)) {
// 存入空值
delegate.putObject(entry, null);
}
}
}
private void unlockMissedEntries() {for (Object entry : entriesMissedInCache) {
try {
// 调用 removeObject 进行解锁
delegate.removeObject(entry);
} catch (Exception e) {log.warn("...");
}
}
}
}存储二级缓存对象的时候是放到了 TransactionalCache.entriesToAddOnCommit 这个 map 中，然而每次查问的时候是间接从 TransactionalCache.delegate 中去查问的，所以这个二级缓存查询数据库后，设置缓存值是没有立即失效的，次要是因为间接存到 delegate 会导致脏数据问题
为何只有 SqlSession 提交或敞开之后？
那咱们来看下 SqlSession.commit()办法做了什么
SqlSession
@Override
public void commit(boolean force) {
try {
// 次要是这句
executor.commit(isCommitOrRollbackRequired(force));
dirty = false;
} catch (Exception e) {throw ExceptionFactory.wrapException("Error committing transaction. Cause:" + e, e);
} finally {ErrorContext.instance().reset();}
}
// CachingExecutor.commit()
@Override
public void commit(boolean required) throws SQLException {delegate.commit(required);
tcm.commit();// 在这里}
// TransactionalCacheManager.commit()
public void commit() {for (TransactionalCache txCache : transactionalCaches.values()) {txCache.commit();// 在这里
}
}
// TransactionalCache.commit()
public void commit() {if (clearOnCommit) {delegate.clear();
}
flushPendingEntries();// 这一句
reset();}
// TransactionalCache.flushPendingEntries()
private void flushPendingEntries() {for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) {
// 在这里真正的将 entriesToAddOnCommit 的对象一一增加到 delegate 中，只有这时，二级缓存才真正的失效
delegate.putObject(entry.getKey(), entry.getValue());
}
for (Object entry : entriesMissedInCache) {if (!entriesToAddOnCommit.containsKey(entry)) {delegate.putObject(entry, null);
}
}
}二级缓存的刷新
咱们来看看 SqlSession 的更新操作
public int update(String statement, Object parameter) {
int var4;
try {
this.dirty = true;
MappedStatement ms = this.configuration.getMappedStatement(statement);
var4 = this.executor.update(ms, this.wrapCollection(parameter));
} catch (Exception var8) {throw ExceptionFactory.wrapException("Error updating database. Cause:" + var8, var8);
} finally {ErrorContext.instance().reset();}
return var4;
}
public int update(MappedStatement ms, Object parameterObject) throws SQLException {this.flushCacheIfRequired(ms);
return this.delegate.update(ms, parameterObject);
}
private void flushCacheIfRequired(MappedStatement ms) {
// 获取 MappedStatement 对应的 Cache，进行清空
Cache cache = ms.getCache();
//SQL 需设置 flushCache="true" 才会执行清空
if (cache != null && ms.isFlushCacheRequired()) {this.tcm.clear(cache);
}
}MyBatis 二级缓存只实用于不常进行增、删、改的数据，比方国家行政区省市区街道数据。一但数据变更，MyBatis 会清空缓存。因而二级缓存不适用于常常进行更新的数据。
总结：
在二级缓存的设计上，MyBatis 大量地使用了装璜者模式，如 CachingExecutor, 以及各种 Cache 接口的装璜器。
- 二级缓存实现了 Sqlsession 之间的缓存数据共享，属于 namespace 级别
- 二级缓存具备丰盛的缓存策略。
- 二级缓存可由多个装璜器，与根底缓存组合而成
- 二级缓存工作由 一个缓存装璜执行器 CachingExecutor 和 一个事务型预缓存 TransactionalCache 实现
如果本文对您有帮忙，欢送
关注和点赞`，您的反对是我保持创作的能源。转载请注明出处！
正文完
