title: 关于MyBatis_缓存
tags:
- MyBatis
- 缓存
cover: ‘https://cdn.jsdelivr.net/gh/yang-sir-one/yangimg/MyBatis缓存.png’
abbrlink: 32284
date: 2022-04-12 15:56:25
关于MyBatis_缓存
一、MyBatis缓存简介
MyBatis是常见的Java数据库访问层框架，MyBatis中允许使用缓存，缓存一般都放置在可高速读/写的存储器上，比如服务器的内存，它能够有效提高系统的性能。因为数据库在大部分场景下是把存储在磁盘上的数据索引出来。从硬件的角度分析，索引磁盘是一个较为缓慢的过程，读取内存或者高速缓存处理器的速度要比读取磁盘快得多，其速度是读取硬盘的几十倍到上百倍,但是内存和高速缓存处理器的空间有限，所以一般只会把那些常用且命中率高的数据缓存起来，以便将来使用，而不缓存那些不常用且命中率低的数据缓存。因为命中率低，最后还是要在磁盘内查找,并不能有效提高性能。
MyBatis分为一级缓存和二级缓存，一级缓存是在SqlSession上的缓存，二级缓存是在SqlSessionFactory上的缓存，同时也可以配置关于缓存的设置。
二、一级缓存
在程序运行过程中，我们可能会在一次数据库会话中执行完全相同的SQL语句，如果不停的访问数据库会影响运行效率，MyBatis提供的一级缓存优化了这一场景。
MyBatis一级缓存的生命周期和SqlSession一致。
MyBatis一级缓存内部设计简单，只是一个没有容量限定的HashMap，在缓存的功能性上欠缺。
MyBatis的一级缓存最大范围是SqlSession内部，有多个SqlSession或者分布式的环境下，数据库写操作会引起脏数据，建议设定缓存级别为Statement。
如果是相同的SQL语句，会优先命中一级缓存中的数据，而不会去访问数据库，执行过程如下：
每个SqlSession中持有了Executor，每个Executor中有一个LocalCache。当用户发起查询时，MyBatis根据当前执行的语句生成MappedStatement，在Local Cache进行查询，如果缓存命中的话，直接返回结果给用户，如果缓存没有命中的话，查询数据库，结果写入Local Cache，最后返回结果给用户。
1、测试：一级缓存有效查询数据库次数
一级缓存的作用范围是会话级别，代码如下：
public static void main(String[] args) {
SqlSession session1 = MybatisUtils.getSqlSession();
// SqlSession session2 = MybatisUtils.getSqlSession();
// SqlSession session3 = MybatisUtils.getSqlSession();
try {
UserMapper mapper1 = session1.getMapper(UserMapper.class);
// UserMapper mapper2 = session2.getMapper(UserMapper.class);
// ApartMapper mapper3 = session3.getMapper(ApartMapper.class);
System.out.println("第一次读取" + mapper1.findBid(1));
System.out.println("第二次读取" + mapper1.findBid(1));
System.out.println("第三次读取" + mapper1.findBid(1));
执行结果：
DEBUG 2022-04-13 10:57:13,302 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 10:57:13,332 demo.dao.UserMapper.findBid: ==> Parameters: 1(Integer)
DEBUG 2022-04-13 10:57:13,351 demo.dao.ApartMapper: Cache Hit Ratio [demo.dao.ApartMapper]: 0.0
DEBUG 2022-04-13 10:57:13,351 demo.dao.ApartMapper.findByAid: ====> Preparing: select did,dname from t_dep where did = ?
DEBUG 2022-04-13 10:57:13,351 demo.dao.ApartMapper.findByAid: ====> Parameters: 1(Integer)
DEBUG 2022-04-13 10:57:13,351 demo.dao.ApartMapper.findByAid: <==== Total: 1
DEBUG 2022-04-13 10:57:13,351 demo.dao.UserMapper.findBid: <== Total: 1
第一次读取Emp{eid=1, ename='李四', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 10:57:13,351 demo.dao.UserMapper: Cache Hit Ratio [demo.dao.UserMapper]: 0.0
第二次读取Emp{eid=1, ename='李四', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 10:57:13,351 demo.dao.UserMapper: Cache Hit Ratio [demo.dao.UserMapper]: 0.0
第三次读取Emp{eid=1, ename='李四', gender='人事部', apart=Apart{did=1, dname='人事部'}}
只有第一次执行了SQL语句查询数据库，其他两次都是从一级缓存中获取。
2、测试：在会话中修改数据库是否会对一级缓存造成影响
我们增加对数据的修改操作，看是否会使得一级缓存失效。
public static void main(String[] args) {
SqlSession session3 = MybatisUtils.getSqlSession();
try {
ApartMapper mapper3 = session3.getMapper(ApartMapper.class);
System.out.println(mapper3.findByAid(1));
System.out.println(mapper3.update("物业部",1));
System.out.println(mapper3.findByAid(1));
session3.commit();
执行结果：
DEBUG 2022-04-13 11:04:01,039 demo.dao.ApartMapper.findByAid: ==> Preparing: select did,dname from t_dep where did = ?
DEBUG 2022-04-13 11:04:01,089 demo.dao.ApartMapper.findByAid: <== Total: 1
Apart{did=1, dname='人事部'}
DEBUG 2022-04-13 11:04:01,090 demo.dao.ApartMapper.update: ==> Preparing: update t_dep set dname = ? where did = ?
DEBUG 2022-04-13 11:04:01,090 demo.dao.ApartMapper.update: ==> Parameters: 物业部(String), 1(Integer)
DEBUG 2022-04-13 11:04:01,090 demo.dao.ApartMapper.update: <== Updates: 1
DEBUG 2022-04-13 11:04:01,090 demo.dao.ApartMapper: Cache Hit Ratio [demo.dao.ApartMapper]: 0.0
DEBUG 2022-04-13 11:04:01,090 demo.dao.ApartMapper.findByAid: ==> Preparing: select did,dname from t_dep where did = ?
DEBUG 2022-04-13 11:04:01,090 demo.dao.ApartMapper.findByAid: ==> Parameters: 1(Integer)
DEBUG 2022-04-13 11:04:01,090 demo.dao.ApartMapper.findByAid: <== Total: 1
Apart{did=1, dname='物业部'}
可以看到，在执行修改操作之后，再次查询了数据库，一级缓存失效
3、测试：验证一级缓存作用范围
开启两个SqlSession，对同一个命名空间进行操作，判断两个对象是否相等。
public static void main(String[] args) {
SqlSession session1 = MybatisUtils.getSqlSession();
SqlSession session2 = MybatisUtils.getSqlSession();
try {
UserMapper mapper1 = session1.getMapper(UserMapper.class);
UserMapper mapper2 = session2.getMapper(UserMapper.class);
Emp emp1 = mapper1.findBid(1);
System.out.println("SqlSession1读取：" + emp1);
Emp emp2 = mapper2.findBid(1);
System.out.println("SqlSession2读取：" + emp2);
System.out.println(emp1 == emp2);
运行结果：
DEBUG 2022-04-13 11:21:26,730 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 11:21:26,779 demo.dao.ApartMapper.findByAid: ====> Preparing: select did,dname from t_dep where did = ?
SqlSession1读取：Emp{eid=1, ename='李四', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 11:21:26,781 org.apache.ibatis.transaction.jdbc.JdbcTransaction:
DEBUG 2022-04-13 11:21:26,787 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 11:21:26,788 demo.dao.ApartMapper.findByAid: ====> Preparing: select did,dname from t_dep where did = ?
DEBUG 2022-04-13 11:21:26,789 demo.dao.ApartMapper.findByAid: ====> Parameters: 1(Integer)
DEBUG 2022-04-13 11:21:26,789 demo.dao.ApartMapper.findByAid: <==== Total: 1
DEBUG 2022-04-13 11:21:26,789 demo.dao.UserMapper.findBid: <== Total: 1
SqlSession2读取：Emp{eid=1, ename='李四', gender='人事部', apart=Apart{did=1, dname='人事部'}}
两个对象不相同false
可以看到，程序运行后，SQL语句执行了两次，对数据库进行了两次访问操作，最后两个结果对象对比也是为false，证明一级缓存无效，一级缓存只能在SqlSession会话内部共享。
4、源码分析
SqlSession： 对外提供了用户和数据库之间交互需要的所有方法，隐藏了底层的细节。默认实现类是DefaultSqlSession。
Executor： SqlSession向用户提供操作数据库的方法，但和数据库操作有关的职责都会委托给Executor。
如下图所示，Executor有若干个实现类，为Executor赋予了不同的能力
BaseExecutor： BaseExecutor是一个实现了Executor接口的抽象类，定义若干抽象方法，在执行的时候，把具体的操作委托给子类进行执行。
protected abstract int doUpdate(MappedStatement ms, Object parameter) throws SQLException;
protected abstract List<BatchResult> doFlushStatements(boolean isRollback) throws SQLException;
protected abstract <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException;
protected abstract <E> Cursor<E> doQueryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds, BoundSql boundSql) throws SQLException;
在一级缓存的介绍中提到对Local Cache的查询和写入是在Executor内部完成的。在阅读BaseExecutor的代码后发现Local Cache是BaseExecutor内部的一个成员变量，如下代码所示。
public abstract class BaseExecutor implements Executor {
protected ConcurrentLinkedQueue<DeferredLoad> deferredLoads;
protected PerpetualCache localCache;
Cache： MyBatis中的Cache接口，提供了和缓存相关的最基本的操作，如下图所示：
有若干个实现类，使用装饰器模式互相组装，提供丰富的操控缓存的能力，部分实现类如下图所示：
BaseExecutor成员变量之一的PerpetualCache，是对Cache接口最基本的实现，其实现非常简单，内部持有HashMap，对一级缓存的操作实则是对HashMap的操作。如下代码所示：
public class PerpetualCache implements Cache {
private String id;
private Map<Object, Object> cache = new HashMap<Object, Object>();
为执行和数据库的交互，首先需要初始化SqlSession，通过DefaultSqlSessionFactory开启SqlSession：
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
............
final Executor executor = configuration.newExecutor(tx, execType);
return new DefaultSqlSession(configuration, executor, autoCommit);
}
在初始化SqlSesion时，会使用Configuration类创建一个全新的Executor，作为DefaultSqlSession构造函数的参数，创建Executor代码如下所示：
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) {
executor = new ReuseExecutor(this, transaction);
} else {
executor = new SimpleExecutor(this, transaction);
}
if (cacheEnabled) {
// 二级缓存开启，使用CahingExecutor装饰BaseExecutor的子类
executor = new CachingExecutor(executor);
}
executor = (Executor) interceptorChain.pluginAll(executor);
return executor;
}
SqlSession创建完毕后，根据Statment的不同类型，会进入SqlSession的不同方法中，如果是Select语句的话，最后会执行到SqlSession的selectList，代码如下所示：
@Override
public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
MappedStatement ms = configuration.getMappedStatement(statement);
return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
}
SqlSession把具体的查询职责委托给了Executor。如果只开启了一级缓存的话，首先会进入BaseExecutor的query方法。代码如下所示：
@Override
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);
}
在上述代码中，会先根据传入的参数生成CacheKey，进入该方法查看CacheKey是如何生成的，代码如下所示：
CacheKey cacheKey = new CacheKey();
cacheKey.update(ms.getId());
cacheKey.update(rowBounds.getOffset());
cacheKey.update(rowBounds.getLimit());
cacheKey.update(boundSql.getSql());
cacheKey.update(value);
//value是update的sql中带的参数
在上述的代码中，将MappedStatement的Id、SQL的offset、SQL的limit、SQL本身以及SQL中的参数传入了CacheKey这个类，最终构成CacheKey。以下是这个类的内部结构：
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;
public CacheKey() {
this.hashcode = DEFAULT_HASHCODE;
this.multiplier = DEFAULT_MULTIPLYER;
this.count = 0;
this.updateList = new ArrayList<Object>();
}
首先是成员变量和构造函数，有一个初始的hachcode和乘数，同时维护了一个内部的updatelist。在CacheKey的update方法中，会进行一个hashcode和checksum的计算，同时把传入的参数添加进updatelist中。如下代码所示：
public void update(Object object) {
int baseHashCode = object == null ? 1 : ArrayUtil.hashCode(object);
count++;
checksum += baseHashCode;
baseHashCode *= count;
hashcode = multiplier * hashcode + baseHashCode;
updateList.add(object);
}
同时重写了CacheKey的equals方法，代码如下所示：
@Override
public boolean equals(Object object) {
.............
for (int i = 0; i < updateList.size(); i++) {
Object thisObject = updateList.get(i);
Object thatObject = cacheKey.updateList.get(i);
if (!ArrayUtil.equals(thisObject, thatObject)) {
return false;
}
}
return true;
}
除去hashcode、checksum和count的比较外，只要updatelist中的元素一一对应相等，那么就可以认为是CacheKey相等。只要两条SQL的下列五个值相同，即可以认为是相同的SQL。
Statement Id + Offset + Limmit + Sql + Params
BaseExecutor的query方法继续往下走，代码如下所示：
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);
}
如果查不到的话，就从数据库查，在queryFromDatabase中，会对localcache进行写入。
在query方法执行的最后，会判断一级缓存级别是否是STATEMENT级别，如果是的话，就清空缓存，这也就是STATEMENT级别的一级缓存无法共享localCache的原因。代码如下所示：
if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
clearLocalCache();
}
在源码分析的最后，我们确认一下，如果是insert/delete/update方法，缓存就会刷新的原因。
SqlSession的insert方法和delete方法，都会统一走update的流程，代码如下所示：
@Override
public int insert(String statement, Object parameter) {
return update(statement, parameter);
}
@Override
public int delete(String statement) {
return update(statement, null);
}
update方法也是委托给了Executor执行。BaseExecutor的执行方法如下所示：
@Override
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);
}
每次执行update前都会清空localCache。
三、二级缓存
MyBatis的二级缓存相对于一级缓存来说，实现了SqlSession之间缓存数据的共享，同时粒度更加的细，能够到namespace级别，通过Cache接口实现类不同的组合，对Cache的可控性也更强。
MyBatis在多表查询时，极大可能会出现脏数据，有设计上的缺陷，安全使用二级缓存的条件比较苛刻。
在分布式环境下，由于默认的MyBatis Cache实现都是基于本地的，分布式环境下必然会出现读取到脏数据，需要使用集中式缓存将MyBatis的Cache接口实现，有一定的开发成本，直接使用Redis、Memcached等分布式缓存可能成本更低，安全性也更高。
1、配置
在MyBatis主配置文件中开启二级缓存 cacheEnabled，默认为true。
记得实体类pojo要实现序列化接口，implements Serializable。
<setting name="cacheEnabled" value="true"/>
在映射器XML文件中声明这个命名空间使用二级缓存。
<cache/>
<!--
参数详解：
type：cache使用的类型，默认是PerpetualCache，这在一级缓存中提到过。
eviction： 定义回收的策略，常见的有FIFO，LRU。
flushInterval： 配置一定时间自动刷新缓存，单位是毫秒。
size： 最多缓存对象的个数。
readOnly： 是否只读，若配置可读写，则需要对应的实体类能够序列化。
blocking： 若缓存中找不到对应的key，是否会一直blocking，直到有对应的数据进入缓存。
-->
<cache-ref namespace="mapper.StudentMapper"/>
<!--cache-ref代表引用别的命名空间的Cache配置，两个命名空间的操作使用的是同一个Cache。-->
2、测试：当事务操作未提交时，二级缓存是否有效
开启两个SqlSession，运行但不进行commit()提交操作。
public static void main(String[] args) {
SqlSession session1 = MybatisUtils.getSqlSession();
SqlSession session2 = MybatisUtils.getSqlSession();
try {
UserMapper mapper1 = session1.getMapper(UserMapper.class);
UserMapper mapper2 = session2.getMapper(UserMapper.class);
System.out.println(mapper1.findBid(1));
System.out.println(mapper2.findBid(1));
运行结果：
DEBUG 2022-04-13 11:43:03,514 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 11:43:03,545 demo.dao.UserMapper.findBid: ==> Parameters: 1(Integer)
DEBUG 2022-04-13 11:43:03,564 demo.dao.ApartMapper: Cache Hit Ratio [demo.dao.ApartMapper]: 0.0
DEBUG 2022-04-13 11:43:03,564 demo.dao.ApartMapper.findByAid: ====> Preparing: select did,dname from t_dep where did = ?
DEBUG 2022-04-13 11:43:03,564 demo.dao.ApartMapper.findByAid: ====> Parameters: 1(Integer)
DEBUG 2022-04-13 11:43:03,567 demo.dao.ApartMapper.findByAid: <==== Total: 1
DEBUG 2022-04-13 11:43:03,567 demo.dao.UserMapper.findBid: <== Total: 1
Emp{eid=1, ename='李四', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 11:43:03,573 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 11:43:03,573 demo.dao.UserMapper.findBid: ==> Parameters: 1(Integer)
DEBUG 2022-04-13 11:43:03,575 demo.dao.ApartMapper: Cache Hit Ratio [demo.dao.ApartMapper]: 0.0
DEBUG 2022-04-13 11:43:03,575 demo.dao.ApartMapper.findByAid: ====> Preparing: select did,dname from t_dep where did = ?
DEBUG 2022-04-13 11:43:03,575 demo.dao.ApartMapper.findByAid: ====> Parameters: 1(Integer)
DEBUG 2022-04-13 11:43:03,576 demo.dao.ApartMapper.findByAid: <==== Total: 1
DEBUG 2022-04-13 11:43:03,576 demo.dao.UserMapper.findBid: <== Total: 1
Emp{eid=1, ename='李四', gender='人事部', apart=Apart{did=1, dname='人事部'}}
可以看到，执行了两次SQL语句，对数据库进行了两次访问，证明当不进行commit()提交操作时二级缓存无效，所以请大家注意，在二级缓存中需要commit()提交事务才能生效。
3、测试：更新数据操作是否刷新所在 namespace 的二级缓存
创建三个SqlSession，先查询两次，证明二级缓存有效，然后定义修改方法，对表进行更新，测试第三次查询是走数据库还是二级缓存：
public static void main(String[] args) {
SqlSession session1 = MybatisUtils.getSqlSession();
SqlSession session2 = MybatisUtils.getSqlSession();
SqlSession session3 = MybatisUtils.getSqlSession();
try {
UserMapper mapper1 = session1.getMapper(UserMapper.class);
UserMapper mapper2 = session2.getMapper(UserMapper.class);
UserMapper mapper3 = session3.getMapper(UserMapper.class);
System.out.println("emp1读取内容：" + mapper1.findBid(1));
session1.commit();
System.out.println("emp2读取内容：" + mapper2.findBid(1));
mapper3.update("王麻子",1);
session3.commit();
System.out.println("emp2读取内容：" + mapper2.findBid(1));
运行结果：
DEBUG 2022-04-13 12:33:39,919 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 12:33:39,979 demo.dao.ApartMapper.findByAid: ====> Preparing: select did,dname from t_dep where did = ?
emp1读取内容：Emp{eid=1, ename='李四', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 12:33:40,040 demo.dao.UserMapper: Cache Hit Ratio [demo.dao.UserMapper]: 0.5
emp2读取内容：Emp{eid=1, ename='李四', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 12:33:40,040 demo.dao.UserMapper.update: ==> Preparing: update t_emp set ename = ? where eid = ?
DEBUG 2022-04-13 12:33:40,040 demo.dao.UserMapper.update: ==> Parameters: 王麻子(String), 1(Integer)
DEBUG 2022-04-13 12:33:40,040 demo.dao.UserMapper.update: <== Updates: 1
DEBUG 2022-04-13 12:33:40,040 org.apache.ibatis.transaction.jdbc.JdbcTransaction: Committing JDBC Connection [com.mysql.jdbc.JDBC4Connection@2db7a79b]
DEBUG 2022-04-13 12:33:40,060 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 12:33:40,060 demo.dao.UserMapper.findBid: ==> Parameters: 1(Integer)
DEBUG 2022-04-13 12:33:40,060 demo.dao.ApartMapper: Cache Hit Ratio [demo.dao.ApartMapper]: 0.5
DEBUG 2022-04-13 12:33:40,060 demo.dao.UserMapper.findBid: <== Total: 1
emp2读取内容：Emp{eid=1, ename='王麻子', gender='人事部', apart=Apart{did=1, dname='人事部'}}
从此可以看出，前两次查询二级缓存有效，进行更新操作之后，第三次查询再次执行了SQL语句访问数据库，证明更新操作使得二级缓存进行了刷新。
4、测试：二级缓存对映射器中多表查询时是否有效
在我们进行级联查询的时候，涉及到了另一个namespace ，此时二级缓存是否有效呢？是否会引发脏数据问题呢？
public static void main(String[] args) {
SqlSession session1 = MybatisUtils.getSqlSession();
SqlSession session2 = MybatisUtils.getSqlSession();
SqlSession session3 = MybatisUtils.getSqlSession();
try {
UserMapper mapper1 = session1.getMapper(UserMapper.class);
UserMapper mapper2 = session2.getMapper(UserMapper.class);
ApartMapper mapper3 = session3.getMapper(ApartMapper.class);
System.out.println("emp1读取内容：" + mapper1.findBid(1));
session1.commit();
System.out.println("emp2读取内容：" + mapper2.findBid(1));
int i = mapper3.update("物业部", 1);
session3.commit();
System.out.println("emp2读取内容：" + mapper2.findBid(1));
System.out.println(i);
运行结果：
DEBUG 2022-04-13 12:47:38,840 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 12:47:38,889 demo.dao.ApartMapper.findByAid: ====> Preparing: select did,dname from t_dep where did = ?
emp1读取内容：Emp{eid=1, ename='王麻子', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 12:47:38,942 demo.dao.UserMapper: Cache Hit Ratio [demo.dao.UserMapper]: 0.5
emp2读取内容：Emp{eid=1, ename='王麻子', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 12:47:38,945 org.apache.ibatis.transaction.jdbc.JdbcTransaction: Opening JDBC Connection
DEBUG 2022-04-13 12:47:38,948 demo.dao.ApartMapper.update: ==> Preparing: update t_dep set dname = ? where did = ?
DEBUG 2022-04-13 12:47:38,948 demo.dao.ApartMapper.update: ==> Parameters: 物业部(String), 1(Integer)
DEBUG 2022-04-13 12:47:38,950 demo.dao.UserMapper: Cache Hit Ratio [demo.dao.UserMapper]: 0.6666666666666666
emp2读取内容：Emp{eid=1, ename='王麻子', gender='人事部', apart=Apart{did=1, dname='人事部'}}
由此可见，二级缓存有效，但是存在脏数据。 当sqlsession1的mapper1查询数据后，二级缓存生效。保存在StudentMapper的namespace下的cache中。当sqlSession3的mapper3的update方法对class表进行更新时，update不属于Mapper2的namespace，所以Mapper2下的cache没有感应到变化，没有刷新缓存。当Mapper2中同样的查询再次发起时，从缓存中读取了脏数据。
5、测试：解决二级缓存脏数据问题
在测试4的时候脏数据问题，经过多方查找资料，最终在美团大佬的文章中找到了我想要的答案， 可以使用Cache ref，让主查询引用子查询的命名空间，这样两个映射文件对应的SQL操作都使用的是同一块缓存了。
在被级联进行子查询的命名空间加入以下代码，让两个映射器对应的SQL操作都使用同一个缓存就ok了，此时进行更新操作就会强制刷新啦。
<cache-ref namespace="这里是进行查询的那个命名空间接口的全限定类名"/>
结果如下：
DEBUG 2022-04-13 19:17:57,721 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 19:17:57,774 demo.dao.ApartMapper.findByAid: ====> Preparing: select did,dname from t_dep where did = ?
DEBUG 2022-04-13 19:17:57,776 demo.dao.UserMapper.findBid: <== Total: 1
emp1读取内容：Emp{eid=1, ename='王麻子', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 19:17:57,832 demo.dao.UserMapper: Cache Hit Ratio [demo.dao.UserMapper]: 0.3333333333333333
emp2读取内容：Emp{eid=1, ename='王麻子', gender='人事部', apart=Apart{did=1, dname='人事部'}}
DEBUG 2022-04-13 19:17:57,840 demo.dao.ApartMapper.update: ==> Preparing: update t_dep set dname = ? where did = ?
DEBUG 2022-04-13 19:17:57,841 demo.dao.ApartMapper.update: ==> Parameters: 物业部(String), 1(Integer)
DEBUG 2022-04-13 19:17:57,856 demo.dao.UserMapper.findBid: ==> Preparing: select eid,ename,gender,did from t_emp where eid = ?
DEBUG 2022-04-13 19:17:57,858 demo.dao.ApartMapper.findByAid: ====> Preparing: select did,dname from t_dep where did = ?
DEBUG 2022-04-13 19:17:57,862 demo.dao.UserMapper.findBid: <== Total: 1
emp2读取内容：Emp{eid=1, ename='王麻子', gender='人事部', apart=Apart{did=1, dname='物业部'}}
但是当然有得必有失，这样多个命名空间的操作会对缓存造成相应的影响。
二级缓存的源码相对感觉比较复杂，后续还需要深度理解后再补上吧，当然我们在实际开发中MyBatis的缓存特性用的不是很多，大多使用第三方如Redis、 Memcached 等分布式缓存比较多，当然深度理解了MyBatis缓存特性后第三方缓存工具会更加的顺手，最后感谢美团后端大姥，让我对MyBatis缓存有更加深入的了解。
扫一扫
748
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
