Mybatis 缓存分析
其实本来不想专门的写一篇关于mybatis缓存的博客的。在之前的博客中已经大致的把mybatis的整体流程讲了一遍。只要按照步骤一步步的点进去，关于缓存的代码很容易就能发现。但是今天在看代码的时候突然对mybatis在缓存的设计上有点疑惑，花了点时间把它搞懂了，同时发现网上没有专门对这块作分析的，所以还是很有必要写出来和大家分享下。
缓存概述
mybatis的缓存分为一级缓存和二级缓存。一级缓存作用于sqlssesion，即一级缓存的生命周期只是在一个sql回话之内。二级缓存作用于namespace，生命周期可以看做是程序运行的生命周期。
mybatis默认不启用二级缓存，当启用二级缓存时，mybatis先去查询二级缓存，再查询一级缓存，最后才是数据库。
一级缓存
这里提到一个概念就是sqlsession，sqlsession就是一个sql回话，一个sql回话代表了一个sql连接数据库，执行，到最终commit的操作。下面请看一组测试代码
public Alarm test3() { Alarm alarm = new Alarm(); alarm = alarmMapper.selectList(new EntityWrapper<Alarm>().eq("levels", 0)).get(0); alarm = alarmMapper.selectList(new EntityWrapper<Alarm>().eq("levels", 0)).get(0); return alarm; }
大家觉得上述查询会用到一级缓存么
答案是不能，因为上述两个查询分别会创建两个sqlssesion。那我们怎么做才能共享sqlssesion呢？很简单，放到一个事物即可
@Transactional public Alarm test3() { Alarm alarm = new Alarm(); alarm = alarmMapper.selectList(new EntityWrapper<Alarm>().eq("levels", 0)).get(0); alarm = alarmMapper.selectList(new EntityWrapper<Alarm>().eq("levels", 0)).get(0); return alarm; }
每个Sqlsseion创建的同时会伴随创建一个executor
每个executor里面都会有localCache
每次的查询缓存步骤如下图所示
上述就是mybatis的一级缓存的流程。通过上文我们知道一级缓存是由localcache储藏的。localcache实质上就是个Hashmap， mybatis将查询的结果当做localcache的value值，那么localcache的key又是什么呢？
CacheKey
接着上文的问题，localcache的key是什么呢？换言之，怎样判断某两次查询是完全相同的查询呢。
MyBatis认为，对于两次查询，如果以下条件都完全一样，那么就认为它们是完全相同的两次查询：
1. 传入的 statementId 2. 查询时要求的结果集中的结果范围 （结果的范围通过rowBounds.offset和rowBounds.limit表示）； 3. 这次查询所产生的最终要传递给JDBC java.sql.Preparedstatement的Sql语句字符串（boundSql.getSql() ） 4. 传递给java.sql.Statement要设置的参数值
后三条都好理解，第一条的statementId是是什么呢。如下图所示
statementId就是namespace+mapperId
接下开看下mybatis对Cachekey的定义
Cachekey的构造函数：
这些参数什么意思我们等会再说。我们看下Cachekey的创建过程。
在进行真正的查询之前，先创建出cachekey
我们再看下update方法
每增加一个条件，hashcode就会变化一次。这也能保证每个Cachekey的hashcode不一样。
二级缓存
二级缓存开启后，同一个namespace下的所有操作语句，都影响着同一个Cache，即二级缓存被多个SqlSession共享，是一个全局的变量。当开启缓存后，数据的查询执行的流程就是 二级缓存 -> 一级缓存 -> 数据库。
我们先来看下每次查询时二级缓存是怎么实现的
1.创建sqlsession
2.得到CacheExecutor
这里用到了一个装饰模式
我们来看具体的查询
这里的tcm就是TransactionalCacheManager
所以实际上TransactionalCacheManager的数据结构就是一个大Map里面的value也是个map。大map的key是Cache对象，小map的key就是cachekey。
我们再仔细的看下缓存的put方法
第一步
第二步，点进去
第三步
第四步
第三步中的疑问正是我之前不解的地方。解答的关键还是在cache对象上。
首先cache是通过Mapperstatement而产生的
Mapperstatement是存储在Configuration中，二级缓存和Configuration的生命周期相同，都是一整个应用的生命周期。所以这个时候推测，二级缓存实际上存放在Mapperstatement中的Cache中
那么问题又来了，二级缓存明明是存在TransactionalCacheManager中的，是怎么存到cache里面的呢。
这里就涉及到了二级缓存的另外一个特性了
只有SqlSession commit或close之后，二级缓存才会生效
我们来看代码TransactionalCache的cmmit方法
同时在TransactionalCache还有个内部类
这时候我们往上看第四步，实际上我们往TransactionalCacheManager这个大map里面存的value值就是个Addentry，这里的cache就是由MapperStatement传进来的。在最后commit的时候会把缓存值保存到cache中。这也是为什么我们还有在commit或者close的时候，二级缓存才能生效。
为什么还有close呢，
close前需要commit啊！
以上就是对mybatis缓存的一些理解。本文并没有对mybatis做出详细的描述，只是针对二级缓存的生命周期做了些研究。
参考
https://blog.csdn.net/luanlouis/article/details/41280959
https://tech.meituan.com/mybatis_cache.html
转载请标注来源: https://www.cnblogs.com/xmzJava/p/9096722.html
