本节内容主要分析一级缓存,首先看一下一级缓存命中的条件有哪些
命中一级缓存需同时满足下面四个条件:
正例:如要命中一级缓存需同时满足上述4个条件方可,如下面所示可以命中一级缓存。
public void test1(){
SqlSession sqlSession = mybatisUtil.getSqlSession();
UserDao userDao = sqlSession.getMapper(UserDao.class);
User user1 = userDao.selectOne(2);
User user2 = userDao.selectOne(2);
System.out.println(user1 == user2); //输出true
}
反例:尽管SQL相同,但参数不同不可命中缓存,如下案例所示
public void test1(){
SqlSession sqlSession = mybatisUtil.getSqlSession();
UserDao userDao = sqlSession.getMapper(UserDao.class);
User user1 = userDao.selectOne(2);
User user2 = userDao.selectOne(3);
System.out.println(user1 == user2); //输出false
}
如果不是同一个会话同样不可以命中一级缓存,入戏所示构建两个sqlsession
public void test1(){
SqlSession sqlSession = mybatisUtil.getSqlSession();
UserDao userDao = sqlSession.getMapper(UserDao.class);
User user1 = userDao.selectOne(2);
SqlSession sqlSession2 = mybatisUtil.getFactory().openSession(true);
UserDao userDao2 = sqlSession2.getMapper(UserDao.class);
User user2 = userDao2.selectOne(2);
System.out.println(user1 == user2); //输出false
}
尽管SQL和参数相同,如果MapperStatement ID不同也不可以命中缓存,MapperStatement ID为书写mapper文件对应的每个SQL前的id。
public void test1(){
SqlSession sqlSession = mybatisUtil.getSqlSession();
UserDao userDao = sqlSession.getMapper(UserDao.class);
User user1 = userDao.selectOne(2);
User user2 = userDao.selectById(2);
System.out.println(user1 == user2); //输出false
}
<select id="selectOne" parameterType="int" resultType="com.lzj.bean.User">
select * from user where id=#{id}
</select>
<select id="selectById" parameterType="int" resultType="com.lzj.bean.User">
select * from user where id=#{id}
</select>
如果分页条件不同也不可以命中一级缓存,比如下面案例,第一次未设置分页条件即默认RowBounds.DEFAULT,第二次分页0,2,从第0条开始,获取2条数据,显然分页条件不一样,因此不可以命中缓存。
public void test1(){
SqlSession sqlSession = mybatisUtil.getSqlSession();
UserDao userDao = sqlSession.getMapper(UserDao.class);
User user1 = userDao.selectOne(2);
List<Object> users2 = sqlSession.selectList("com.lzj.dao.UserDao.selectOne", 2, new RowBounds(0, 2));
System.out.println(user1 == users2.get(0)); //输出false
}
正案例,sqlSession.getMapper底层也是调用的RowBounds.DEFAULT。
public void test1(){
SqlSession sqlSession = mybatisUtil.getSqlSession();
UserDao userDao = sqlSession.getMapper(UserDao.class);
User user1 = userDao.selectOne(2);
List<Object> users2 = sqlSession.selectList("com.lzj.dao.UserDao.selectOne", 2, RowBounds.DEFAULT);
System.out.println(user1 == users2.get(0)); //输出true
}
分析源码最好根据一个案例进行代码跟踪,下面以一个简单案例为例
public void test1(){
SqlSession sqlSession = mybatisUtil.getSqlSession();
List<Object> users2 = sqlSession.selectList("com.lzj.dao.UserDao.selectOne", 2, RowBounds.DEFAULT);
}
在分析一级缓存源码时主要分析一级缓存部分,下面会过滤掉二级缓存部分以及嵌套查询部分。
首先这个地方的sqlSession指的默认的DefalultSqlSession,因此就可以断点到DefaultSqlSession中的selectList方法,如下所示

通过断点可以看到首先执行的是二级缓存CachingExecutor,然后把断点打到二级缓存中的query方法中,如下所示当list为null时表示未命中二级缓存,再继续去执行delegate中的query方法。在前面一章节介绍到了CachingExecutor二级缓存执行器实际是对简单执行器、复用执行器、批量执行器的装饰,所以内部的delegeta还是指的这三种执行器,如没有特别指定,默认就是对SimpleExecutor执行器的装饰。

下面把断点放到BaseExecutor中的query方法上,因为三大执行器都是继承了BaseExecutor,三大执行器的query方法都是利用的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.");
}
/*queryStack非嵌套查询或者对于嵌套查询的最外层,如果mapper中配置了清空缓存,此时会首先清空一级缓存的*/
if (queryStack == 0 && ms.isFlushCacheRequired()) {
clearLocalCache();
}
List<E> list;
try {
queryStack++;
/*对于查询SQL语句要先从一级缓存中获取*/
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();
/*LocalCacheScope包含SESSION和STATEMENT级别
1.SESSION级别表示在一次会话请求中命中不了二级缓存的会首先从一级缓存缓存中获取结果。
2.STATEMENT级别表示SQL语句级别的,每次查询SQL后都会清空缓存,就会导致即使在同一个session中即使相同的SQL也不会命中缓存,
只有一种例外,对于嵌套查询,子查询完不会清空一级缓存,而是等到最外层的查询结束后才会清空缓存,也就是说外层查询还是有可能会用到子查询后的一级缓存的
*/
if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
// issue #482
clearLocalCache();
}
}
return list;
}
在BaseExecutor中清空一级缓存的方法为clearLocalCache,在idea中可以通过查看调用该方法的场景就可以确定一级缓存都是在哪些场景情况下时效的,通过方法调用追踪可以发现调用清空一级缓存的方法如下所示

虽然一级缓存可以在一个session中提升查询效率,但一级缓存也有其弊端,就是会导致脏读。
比如在sessionA中查询了同一条SQL:select name, age from user where name=‘tom’,查出来的name=tom,age=20;
然后在sessionB中执行了update user set age=25 where name=‘tom’,并commit;
最后继续在sessionA中执行一遍select name, age from user where name=‘tom’,发现还是输出的name=tom,age=20,出现了脏读问题。
那么如何关闭一级缓存呢,mybatis可以配置如下localCacheScope=STATEMENT,一级缓存只对当前语句执行有效,一旦该SQL执行完后,即使在同一个session中执行了相同的SQL也是重新查数据库了;默认配置是localCacheScope=SESSION,表示一级缓存在整个session中是有效的。
<settings>
<setting name="localCacheScope" value="STATEMENT"/>
settings>