持续创作，加速成长！这是我参与「掘金日新计划 · 10 月更文挑战」的第15天，点击查看活动详情

6 MyBatis的缓存机制

博客园吴振照的博客：www.cnblogs.com/wuzhenzhao/…

前言

缓存是一般的ORM 框架都会提供的功能，目的就是提升查询的效率和减少数据库的压力。跟Hibernate 一样，MyBatis 也有一级缓存和二级缓存，并且预留了集成第三方缓存的接口。

缓存体系结构：

MyBatis 跟缓存相关的类都在cache 包里面，其中有一个Cache 接口，只有一个默认的实现类 PerpetualCache，它是用HashMap 实现的。我们可以通过以下类找到这个缓存的庐山真面目

 DefaultSqlSession
 
 　　-> BaseExecutor
 
 　　　　-> PerpetualCache localCache
 
 　　　　　　->private Map<Object, Object> cache = new HashMap<>();

除此之外，还有很多的装饰器，通过这些装饰器可以额外实现很多的功能：回收策略、日志记录、定时刷新等等。

但是无论怎么装饰，经过多少层装饰，最后使用的还是基本的实现类（默认PerpetualCache）。可以通过 CachingExecutor 类 Debug 去查看。

所有的缓存实现类总体上可分为三类：基本缓存、淘汰算法缓存、装饰器缓存。

MyBatis的一级缓存（本地缓存）

一级缓存也叫本地缓存，MyBatis 的一级缓存是在会话（SqlSession）层面进行缓存的。
- 通过同一个SqlSession查询的数据会被缓存，下次查询相同的数据，就会从缓存中直接获取，不会从数据库重新访问
MyBatis 的一级缓存是默认开启的，不需要任何的配置。

首先我们必须去弄清楚一个问题，在MyBatis 执行的流程里面，涉及到这么多的对象，那么缓存PerpetualCache 应该放在哪个对象里面去维护？如果要在同一个会话里面共享一级缓存，这个对象肯定是在SqlSession 里面创建的，作为SqlSession 的一个属性。

DefaultSqlSession 里面只有两个属性，Configuration 是全局的，所以缓存只可能放在Executor 里面维护——SimpleExecutor/ReuseExecutor/BatchExecutor 的父类BaseExecutor 的构造函数中持有了PerpetualCache。在同一个会话里面，多次执行相同的SQL 语句，会直接从内存取到缓存的结果，不会再发送SQL 到数据库。但是不同的会话里面，即使执行的SQL 一模一样（通过一个Mapper 的同一个方法的相同参数调用），也不能使用到一级缓存。

每当我们使用MyBatis开启一次和数据库的会话，MyBatis会创建出一个SqlSession对象表示一次数据库会话。

在对数据库的一次会话中，我们有可能会反复地执行完全相同的查询语句，如果不采取一些措施的话，每一次查询都会查询一次数据库,而我们在极短的时间内做了完全相同的查询，那么它们的结果极有可能完全相同，由于查询一次数据库的代价很大，这有可能造成很大的资源浪费。

为了解决这一问题，减少资源的浪费，MyBatis会在表示会话的SqlSession对象中建立一个简单的缓存，将每次查询到的结果结果缓存起来，当下次查询的时候，如果判断先前有个完全一样的查询，会直接从缓存中直接将结果取出，返回给用户，不需要再进行一次数据库查询了。

如下图所示，MyBatis会在一次会话的表示----一个SqlSession对象中创建一个本地缓存(local cache)，对于每一次查询，都会尝试根据查询的条件去本地缓存中查找是否在缓存中，如果在缓存中，就直接从缓存中取出，然后返回给用户；否则，从数据库读取数据，将查询结果存入缓存并返回给用户。

一级缓存的生命周期有多长？

MyBatis在开启一个数据库会话时，会创建一个新的SqlSession对象，SqlSession对象中会有一个新的Executor对象，Executor对象中持有一个新的PerpetualCache对象；当会话结束时，SqlSession对象及其内部的Executor对象还有PerpetualCache对象也一并释放掉。
如果SqlSession调用了close()方法，会释放掉一级缓存PerpetualCache对象，一级缓存将不可用；
如果SqlSession调用了clearCache()，会清空PerpetualCache对象中的数据，但是该对象仍可使用；
SqlSession中执行了任何一个update操作(update()、delete()、insert()) ，都会清空PerpetualCache对象的数据，但是该对象可以继续使用；

SqlSession 一级缓存的工作流程：

对于某个查询，根据statementId,params,rowBounds来构建一个key值，根据这个key值去缓存Cache中取出对应的key值存储的缓存结果
判断从Cache中根据特定的key值取的数据数据是否为空，即是否命中；
如果命中，则直接将缓存结果返回；
如果没命中：
1. 去数据库中查询数据，得到查询结果；
2. 将key和查询到的结果分别作为key,value对存储到Cache中；
3. 将查询结果返回；

接下来我们来验证一下，MyBatis 的一级缓存到底是不是只能在一个会话里面共享，以及跨会话（不同session）操作相同的数据会产生什么问题。判断是否命中缓存：如果再次发送SQL 到数据库执行，说明没有命中缓存；如果直接打印对象，说明是从内存缓存中取到了结果。

1、在同一个session 中共享（不同session 不能共享）

 //同Session
 SqlSession session1 = sqlSessionFactory.openSession();
 BlogMapper mapper1 = session1.getMapper(BlogMapper.class);
 System.out.println(mapper1.selectBlogById(1002));
 System.out.println(mapper1.selectBlogById(1002));

执行以上sql我们可以看到控制台打印如下信息（需配置mybatis.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl），会发现我们两次的查询就发送了一次查询数据库的操作，这说明了缓存在发生作用：

PS：一级缓存在BaseExecutor 的query()——queryFromDatabase()中存入。在queryFromDatabase()之前会get()。

 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());
 　　　　。。。。。。try {
                 ++this.queryStack;//从缓存中获取
                 list = resultHandler == null ? (List)this.localCache.getObject(key) : null;
                 if (list != null) {
                     this.handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
                 } else {//缓存中获取不到，查询数据库
                     list = this.queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
                 }
 　　　　。。。。。。
     }

2、同一个会话中，update（包括delete）会导致一级缓存被清空

 //同Session
 SqlSession session1 = sqlSessionFactory.openSession();
 BlogMapper mapper1 = session1.getMapper(BlogMapper.class);
 System.out.println(mapper1.selectBlogById(1002));
 Blog blog3 = new Blog();
 blog3.setBid(1002);
 blog3.setName("mybatis缓存机制修改");
 mapper1.updateBlog(blog3);
 session1.commit();// 注意要提交事务，否则不会清除缓存
 System.out.println(mapper1.selectBlogById(1002));

一级缓存是在BaseExecutor 中的update()方法中调用clearLocalCache()清空的（无条件）

 public int update(MappedStatement ms, Object parameter) throws SQLException {
         ErrorContext.instance().resource(ms.getResource()).activity("executing an update").object(ms.getId());
         if (this.closed) {
             throw new ExecutorException("Executor was closed.");
         } else {　　　　　　  //清除本地缓存
             this.clearLocalCache();
             return this.doUpdate(ms, parameter);
         }
 }

3、其他会话更新了数据，导致读取到脏数据（一级缓存不能跨会话共享）

 SqlSession session1 = sqlSessionFactory.openSession();
 BlogMapper mapper1 = session1.getMapper(BlogMapper.class);
 SqlSession session2 = sqlSessionFactory.openSession();
 BlogMapper mapper2 = session2.getMapper(BlogMapper.class);
 // mapper2查询
 System.out.println(mapper2.selectBlogById(1002));
 // mapper1更新
 Blog blog3 = new Blog();
 blog3.setBid(1002);
 blog3.setName("mybatis缓存机制1");
 mapper1.updateBlog(blog3);
 
 session1.commit();
 System.out.println(mapper2.selectBlogById(1002));

一级缓存的不足：

   使用一级缓存的时候，因为缓存不能跨会话共享，不同的会话之间对于相同的数据可能有不一样的缓存。在有多个会话或者分布式环境下，会存在脏数据的问题。如果要解决这个问题，就要用到二级缓存。MyBatis 一级缓存（MyBaits 称其为 Local Cache）无法关闭，但是有两种级别可选：

session 级别的缓存，在同一个 sqlSession 内，对同样的查询将不再查询数据库，直接从缓存中。
statement 级别的缓存，避坑：为了避免这个问题，可以将一级缓存的级别设为 statement 级别的，这样每次查询结束都会清掉一级缓存。

使一级缓存失效的四种情况：

不同的SqlSession对应不同的一级缓存
同一个SqlSession但是查询条件不同
同一个SqlSession两次查询期间执行了任何一次增删改操作
同一个SqlSession两次查询期间手动清空了缓存

MyBatis的二级缓存

二级缓存是用来解决一级缓存不能跨会话共享的问题的，范围是namespace 级别的，可以被多个SqlSession 共享（只要是同一个接口里面的相同方法，都可以共享），生命周期和应用同步。

如果你的MyBatis使用了二级缓存，并且你的Mapper和select语句也配置使用了二级缓存，那么在执行select查询的时候，MyBatis会先从二级缓存中取数据，其次才是一级缓存，即MyBatis查询数据的顺序是：二级缓存 —> 一级缓存 —> 数据库。

作为一个作用范围更广的缓存，它肯定是在SqlSession 的外层，否则不可能被多个SqlSession 共享。而一级缓存是在SqlSession 内部的，所以第一个问题，肯定是工作在一级缓存之前，也就是只有取不到二级缓存的情况下才到一个会话中去取一级缓存。第二个问题，二级缓存放在哪个对象中维护呢？要跨会话共享的话，SqlSession 本身和它里面的BaseExecutor 已经满足不了需求了，那我们应该在BaseExecutor 之外创建一个对象。

实际上MyBatis 用了一个装饰器的类来维护，就是CachingExecutor。如果启用了二级缓存，MyBatis 在创建Executor 对象的时候会对Executor 进行装饰。CachingExecutor 对于查询请求，会判断二级缓存是否有缓存结果，如果有就直接返回，如果没有委派交给真正的查询器Executor 实现类，比如SimpleExecutor 来执行查询，再走到一级缓存的流程。最后会把结果缓存起来，并且返回给用户。

二级缓存开启的条件：

配置 mybatis.configuration.cache-enabled=true，只要没有显式地设置cacheEnabled=false，都会用CachingExecutor 装饰基本的执行器。默认为true，不需要设置。
在映射文件中设置标签

 <cache type="org.apache.ibatis.cache.impl.PerpetualCache"
     size="1024"
 eviction="LRU"
 flushInterval="120000"
 readOnly="false"/>

基本上就是这样。这个简单语句的效果如下:

映射语句文件中的所有 select 语句的结果将会被缓存。
映射语句文件中的所有 insert、update 和 delete 语句会刷新缓存。
缓存会使用最近最少使用算法（LRU, Least Recently Used）算法来清除不需要的缓存。
缓存不会定时进行刷新（也就是说，没有刷新间隔）。
缓存会保存列表或对象（无论查询方法返回哪种）的 1024 个引用。
缓存会被视为读/写缓存，这意味着获取到的对象并不是共享的，可以安全地被调用者修改，而不干扰其他调用者或线程所做的潜在修改。

这个更高级的配置创建了一个 FIFO 缓存，每隔 60 秒刷新，最多可以存储结果对象或列表的 512 个引用，而且返回的对象被认为是只读的，因此对它们进行修改可能会在不同线程中的调用者产生冲突。可用的清除策略有：

LRU – 最近最少使用：移除最长时间不被使用的对象。
FIFO – 先进先出：按对象进入缓存的顺序来移除它们。
SOFT – 软引用：基于垃圾回收器状态和软引用规则移除对象。
WEAK – 弱引用：更积极地基于垃圾收集器状态和弱引用规则移除对象。

默认的清除策略是 LRU。

Mapper.xml 配置了之后，select()会被缓存。update()、delete()、insert()会刷新缓存。

如果cacheEnabled=true，Mapper.xml 没有配置标签，还有二级缓存吗？（没有）还会出现CachingExecutor 包装对象吗？（会）

只要cacheEnabled=true 基本执行器就会被装饰。有没有配置，决定了在启动的时候会不会创建这个mapper 的Cache 对象，只是最终会影响到CachingExecutorquery 方法里面的判断。如果某些查询方法对数据的实时性要求很高，不需要二级缓存，怎么办？ 我们可以在单个Statement ID 上显式关闭二级缓存（默认是true）：

 <select id="selectBlog" resultMap="BaseResultMap" useCache="false">

二级缓存必须在SqlSession关闭或提交之后有效
查询的数据所转换的实体类类型必须实现序列化的接口

二级缓存验证（验证二级缓存需要先开启二级缓存）

1、事务不提交，二级缓存不存在

 System.out.println(mapper1.selectBlogById(1002));
 // 事务不提交的情况下，二级缓存不会写入
 // session1.commit();
 System.out.println(mapper2.selectBlogById(1002));

2、使用不同的session 和mapper，验证二级缓存可以跨session 存在（取消以上commit()的注释）

3、在其他的session 中执行增删改操作，验证缓存会被刷新

 System.out.println(mapper1.selectBlogById(1002));
 //主键自增返回测试
 Blog blog3 = new Blog();
 blog3.setBid(1002);
 blog3.setName("mybatis缓存机制");
 mapper1.updateBlog(blog3);
 session1.commit();
 System.out.println(mapper2.selectBlogById(1002));

什么时候开启二级缓存？

一级缓存默认是打开的，二级缓存需要配置才可以开启。那么我们必须思考一个问题，在什么情况下才有必要去开启二级缓存？

因为所有的增删改都会刷新二级缓存，导致二级缓存失效，所以适合在查询为主的应用中使用，比如历史交易、历史订单的查询。否则缓存就失去了意义。
如果多个namespace 中有针对于同一个表的操作，比如Blog 表，如果在一个namespace 中刷新了缓存，另一个namespace 中没有刷新，就会出现读到脏数据的情况。所以，推荐在一个Mapper 里面只操作单表的情况使用。

如果要让多个namespace 共享一个二级缓存，应该怎么做？跨namespace 的缓存共享的问题，可以使用来解决：

 <cache-ref namespace="com.wuzz.crud.dao.DepartmentMapper" />

cache-ref 代表引用别的命名空间的Cache 配置，两个命名空间的操作使用的是同一个Cache。在关联的表比较少，或者按照业务可以对表进行分组的时候可以使用。

注意：在这种情况下，多个Mapper 的操作都会引起缓存刷新，缓存的意义已经不大了。

第三方缓存做二级缓存

除了MyBatis 自带的二级缓存之外，我们也可以通过实现Cache 接口来自定义二级缓存。MyBatis 官方提供了一些第三方缓存集成方式，比如ehcache 和redis：github.com/mybatis/red… ,这里就不过多介绍了。当然，我们也可以使用独立的缓存服务，不使用MyBatis 自带的二级缓存。

使二级缓存失效的情况：两次查询之间执行了任意的增删改，会使一级和二级缓存同时失效

二级缓存的相关配置

在mapper配置文件中添加的cache标签可以设置一些属性：

eviction属性：缓存回收策略
- LRU（Least Recently Used） – 最近最少使用的：移除最长时间不被使用的对象。
- FIFO（First in First out） – 先进先出：按对象进入缓存的顺序来移除它们。
- SOFT – 软引用：移除基于垃圾回收器状态和软引用规则的对象。
- WEAK – 弱引用：更积极地移除基于垃圾收集器状态和弱引用规则的对象。
- 默认的是 LRU
flushInterval属性：刷新间隔，单位毫秒
- 默认情况是不设置，也就是没有刷新间隔，缓存仅仅调用语句（增删改）时刷新
size属性：引用数目，正整数
- 代表缓存最多可以存储多少个对象，太大容易导致内存溢出
readOnly属性：只读，true/false
- true：只读缓存；会给所有调用者返回缓存对象的相同实例。因此这些对象不能被修改。这提供了很重要的性能优势。
- false：读写缓存；会返回缓存对象的拷贝（通过序列化）。这会慢一些，但是安全，因此默认是false

MyBatis缓存查询的顺序

先查询二级缓存，因为二级缓存中可能会有其他程序已经查出来的数据，可以拿来直接使用
如果二级缓存没有命中，再查询一级缓存
如果一级缓存也没有命中，则查询数据库
SqlSession关闭之后，一级缓存中的数据会写入二级缓存

整合第三方缓存EHCache（了解）

a. 添加依赖

 <!-- Mybatis EHCache整合包 -->
 <dependency>
   <groupId>org.mybatis.caches</groupId>
   <artifactId>mybatis-ehcache</artifactId>
   <version>1.2.1</version>
 </dependency>
 <!-- slf4j日志门面的一个具体实现 -->
 <dependency>
   <groupId>ch.qos.logback</groupId>
   <artifactId>logback-classic</artifactId>
   <version>1.2.3</version>
 </dependency>

b. 各个jar包的功能

jar包名称	作用
mybatis-ehcache	Mybatis和EHCache的整合包
ehcache	EHCache核心包
slf4j-api	SLF4J日志门面包
logback-classic	支持SLF4J门面接口的一个具体实现

c. 创建EHCache的配置文件ehcache.xml

名字必须叫ehcache.xml

 <?xml version="1.0" encoding="utf-8" ?>
 <ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
          xsi:noNamespaceSchemaLocation="../config/ehcache.xsd">
     <!-- 磁盘保存路径 -->
     <diskStore path="D:\atguigu\ehcache"/>
     <defaultCache
             maxElementsInMemory="1000"
             maxElementsOnDisk="10000000"
             eternal="false"
             overflowToDisk="true"
             timeToIdleSeconds="120"
             timeToLiveSeconds="120"
             diskExpiryThreadIntervalSeconds="120"
             memoryStoreEvictionPolicy="LRU">
     </defaultCache>
 </ehcache>

d. 设置二级缓存的类型

在xxxMapper.xml文件中设置二级缓存类型

 <cache type="org.mybatis.caches.ehcache.EhcacheCache"/>

e. 加入logback日志

存在SLF4J时，作为简易日志的log4j将失效，此时我们需要借助SLF4J的具体实现logback来打印日志。

创建logback的配置文件logback.xml，名字固定，不可改变

 <?xml version="1.0" encoding="UTF-8"?>
 <configuration debug="true">
     <!-- 指定日志输出的位置 -->
     <appender name="STDOUT"
               class="ch.qos.logback.core.ConsoleAppender">
         <encoder>
             <!-- 日志输出的格式 -->
             <!-- 按照顺序分别是：时间、日志级别、线程名称、打印日志的类、日志主体内容、换行 -->
             <pattern>[%d{HH:mm:ss.SSS}] [%-5level] [%thread] [%logger] [%msg]%n</pattern>
         </encoder>
     </appender>
     <!-- 设置全局日志级别。日志级别按顺序分别是：DEBUG、INFO、WARN、ERROR -->
     <!-- 指定任何一个日志级别都只打印当前级别和后面级别的日志。 -->
     <root level="DEBUG">
         <!-- 指定打印日志的appender，这里通过“STDOUT”引用了前面配置的appender -->
         <appender-ref ref="STDOUT" />
     </root>
     <!-- 根据特殊需求指定局部日志级别 -->
     <logger name="com.atguigu.crowd.mapper" level="DEBUG"/>
 </configuration>

f. EHCache配置文件说明

属性名	是否必须	作用
maxElementsInMemory	是	在内存中缓存的element的最大数目
maxElementsOnDisk	是	在磁盘上缓存的element的最大数目，若是0表示无穷大
eternal	是	设定缓存的elements是否永远不过期。如果为true，则缓存的数据始终有效，如果为false那么还要根据timeToIdleSeconds、timeToLiveSeconds判断
overflowToDisk	是	设定当内存缓存溢出的时候是否将过期的element缓存到磁盘上
timeToIdleSeconds	否	当缓存在EhCache中的数据前后两次访问的时间超过timeToIdleSeconds的属性取值时，这些数据便会删除，默认值是0,也就是可闲置时间无穷大
timeToLiveSeconds	否	缓存element的有效生命期，默认是0.,也就是element存活时间无穷大
diskSpoolBufferSizeMB	否	DiskStore(磁盘缓存)的缓存区大小。默认是30MB。每个Cache都应该有自己的一个缓冲区
diskPersistent	否	在VM重启的时候是否启用磁盘保存EhCache中的数据，默认是false
diskExpiryThreadIntervalSeconds	否	磁盘缓存的清理线程运行间隔，默认是120秒。每个120s，相应的线程会进行一次EhCache中数据的清理工作
memoryStoreEvictionPolicy	否	当内存缓存达到最大，有新的element加入的时候，移除缓存中element的策略。默认是LRU（最近最少使用），可选的有LFU（最不常使用）和FIFO（先进先出