MyBatis功能点一：二级缓存cache

　　对于Mybatis缓存分作用域等维度区别一、二级缓存特点如下图：

　　　　

　　分析缓存源码首先得找到缓存操作的入口：前面已经分析，sqlsesion.close()仅对一级缓存有影响，而update等对一/二级缓存均有影响。那从session为入口分析一级缓存，从mapper分析二级缓存。

　　对于缓存的作用域，之前文章五、MyBatis缓存初体验 - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com)中已经验证，下面主要从底层数据结构这个维度理解一二级缓存。既然都是基于Perpetualcache的HashMap本地缓存，那么通过调试跟踪到其源码所在位置分析：

　　PerpetualCache是对JUC中Cache接口的实现，其核心结构为命名为cache的Map<Object, Object>；所以缓存实际就是一个附带id的HashMap。实际上是不是只要实现了JUC中Cache接口均可以作为Mybatis备用缓存？？？当然可以，可参考MyBatis缓存Cache包 - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com)。

　　一级缓存

　　跟踪调试仅使用一级缓存的代码，调试信息发现，

　　　　　，

　　即可知SimpleExectutor或其上级父类中对一级缓存进行处理，跟踪调试信息，可得如下调用链(查看MyBatis中执行器Executor框架 - 池塘里洗澡的鸭子 - 博客园 (cnblogs.com))：

　　一级缓存功能由BaseExecutor类实现，即意味着每个实际执行器都具有这一级的功能。

　　那么其具体应用逻辑为何？查看源码如下：

　　从源码分析可得：如果设置了每次查询都清缓存，那么每次查询清缓存。同时查询之前判断localCache中是否有当前查询statement.id的相应数据，如果有则直接从一级缓存中获取结果，否则进行查询数据库的操作。

　　二级缓存

　　二级缓存的作用范围是一个命名空间(即一个映射文件或多个mapper文件同一个命名空间)，而且可以实现多个命名空间共享一个缓存。跟踪二级缓存，其建立在mapper配置文件解析过程中即建立，而不是在opensession中。

　　二级缓存默认开启，如取消采用如下配置：

　　<settings>
   　　 <setting name="cacheEnabled" value="false"/>
　　</settings>
　　注解方式在mapper接口中使用如下注解，二级缓存生效，否则开启亦不生效。同理在mapper.xml文件中也需配置<cache></cache>表示二级缓存生效

　　通过注解开启二级缓存，查看注解源码

　　可知默认使用PerpetualCache的实现，通过implementation属性，说明二级缓存是可配置的。可以配置用户需要使用的第三方或自定义缓存，比如redis。

　　那二级缓存是如何工作的？我们开启二级缓存通过调试查看源码，如下：

　　可知CachingExecutor中首先查询二级缓存，如果查询结果为空则业务逻辑有simpleExecutor处理即一级缓存的使用逻辑。

　　开篇提到，sqlSession.close仅对一级缓存清空二级缓存无影响，以及update等操作对一二级缓存均清空，那么通过close和update源码分别来证实：

　　分析CachingExecutor中close的业务逻辑：

　　首先处理二级缓存rollback或者commit，再处理一级缓存赋值null。所以close操作会清空一级缓存，二级缓存强制回退或者提交数据。

　　分析CachingExecutor中update的业务逻辑，显然与close方法不同，如下：

　　在上面分析过程中都遇到了CachingExecutor的一个属性，tcm——啥玩意？TransactionalCacheManager

　　MyBatis将Cache,TransactionalCache做了映射，而不是和一级缓存保存一致，直接使用，这是为什么呢？下面附源码两张：

　　第一张图说明一级缓存直接在executor中活动，即作用范围为session；第二张图说明二级缓存在MappedStatement中活动，作用范围跨session了。同样证实了开篇提到的cache作用范围。也因为二级缓存的作用范围跨session，可以同时被多个session同时获取就出现了线程安全的问题，导致脏读问题。为了解决这一问题，就有了TransactionalCache及其Manager——就是tcm对应类。

　　从其类图中，可以直观的发现其增加了读写锁相关的功能。