1\. 写在前头
这篇帖子主要讲一级缓存,它的作用范围和源码分析
(本来想把一二级缓存合在一起,发现太长了)
2\. 准备工作
2.1 两个要用的实体类
2.2 Mapper.xml文件中要用的SQL
- DepartmentMapper.xml,两条SQL,一条根据ID匹配,一条清除缓存,注意fulshCache标签
- UserMapper.xml,简简单单的查询所有的user
3\. 一级缓存
- 一级缓存是基于SQLSession的,同一条SQL执行第二遍的时候会直接从缓存中取,测试下看看
- 可以发现控制台在第二次查询的时候,一级缓存生效,没有出现SQL
- 我们清空下一级缓存再试试
xml文件中flushCache标签 会清除所有namespace 的一级缓存 和 当前namespace 的二级缓存均会清除 默认是false
- 控制台日志很清晰,清除缓存后又重新查了一遍
3.1 一级缓存失效的情况
3.1.1 不同SQLSession下同一条SQL一级缓存不生效
- 创建一个新的sqlSession1执行相同的SQL,发现不同SQLSession下不共享一级缓存
3.1.2 两次相同查询SQL间有Insert、Delete、Update语句出现
- 因为Insert、Delete、Update的flushCache标签 默认为 true ,执行它们时,必然会导致一级缓存的清空,从而引发之前的一级缓存不能继续使用的情况(这跟我们上边清除一级缓存的SQL例子一致)
3.1.3 调用sqlSession.clearCache()方法
- 这个方***将一级缓存清除,效果是一样的
3.2 一级缓存源码:缓存被保存在了哪里?
3.2.1 该如何找打它的位置
- Mybatis顶层的缓存是接口Cache,查看它的实现类
- 发现大部分实现类的包都是decorators(装饰器),只有PerpetualCache是Impl,所以我们确定的说,它就是我们要找的缓存实现类,点进去看看,发现只是组合了HashMap...
- 那这个PerpetualCache被放在哪里呢? 我们想到了一级缓存是基于SQLSession,那我们去DefaultSQLSession,它默认的实现类里看看
- 发现并没有哇!DefaultSqlSession还有两个东西,Configuration是全局的配置,这里边儿应该是没有,那我们只能再去Executor里看看了
- 发现它是个接口,实现类有一个CachingExecutor!立马点进去!
- 发现还是没有???
- 但是Executor还有一个BaseExecutor,最后一家了,再在没有关了Idea睡觉了
- 它来了,原来在这藏着呢呀,行了,这把知道它的位置了,我们直接看SQL执行的时候是怎么存的,怎么取的吧!
3.2.2 query()方法
- BaseExecutor的query()方法,看看注释,很简单
3.2.3 写两条Sql,Debug看一下
- 哎,很对,第一次果然去数据库里查了
- 哎,更对了,第二次果然取得缓存
- 好嘛,真简单呀
3.3 注意:一级缓存的查询结果被修改后,竟然...
- 竟然会对之后取出的一级缓存有影响,测试下看看
- 第一次查询结果name为null,之后我们修改它的name,第二次查询取缓存的结果是更改name结果之后的
- 这是因为存放的数据其实是对象的引用,导致第二次从一级缓存中查询到的数据,就是我们刚刚改过的数据
3.4 文末
一级缓存到这里就要跟大家说再见了,做个总结吧
- 一级缓存是基于SQLSession的,不同SQLSession间不共享一级缓存
- 执行Insert、Delete、Update语句会使一级缓存失效
- 一级缓存在底层被存放在了BaseExecutor中,本质上就是个HashMap
- 一级缓存存放的数据其实是对象的引用,若对它进行修改,则之后取出的缓存为修改后的数据