Mybaits缓存机制

标签： 学习 Mybatis 一级缓存 二级缓存 | 发表时间：2021-08-02 22:38 | 作者：
出处：https://www.sakuratears.top/

前言

我们知道 Mybatis作为常见的 Java数据库访问层的 ORM框架，其缓存分为一级缓存和二级缓存。

大多数情况下，我们使用的都是 Mybatis缓存的默认配置，但是 Mybatis缓存机制有一些不足之处，在使用中容易引起脏数据问题，形成一些潜在隐患。

今天，我们就来看下 Mybatis的缓存机制，了解其底层的一些原理，来方便我们排查、解决以后可能出现的由 Mybatis缓存引起的问题。

正文

缓存实现

我们通过 Mybatis提供的 jar包来看下缓存的整体结构，如下：

可以看到其缓存相关类位于 cache包下，其中有一个 Cache接口，有一个默认的实现类 PerpetualCache，它是用 HashMap实现的。

其他的实现类使用了装饰器模式，这些装饰器可以额外实现很多的功能，如回收策略、日志记录、定时刷新等等。使用装饰器模式的好处就是这些类可以互相组装，提供丰富的缓存操控能力。

这些缓存实现类可以总结如下表：

缓存实现类 描述 作用 装饰条件
PerpetualCache 基本缓存 默认就是 PerpetualCache，当然我们也可以自定义具备基本功能的缓存实现类，如 RedisCache、 ESCache等，来借助三方工具实现缓存 无
LruCache LRU策略的缓存 当缓存达到上限的时候，删除最近最少使用的对象（Least Recently Used）。默认上限 1024，其底层是使用的 LinkedHashMap实现的 eviction="LRU"（默认配置）
FifoCache FIFO策略的缓存 当缓存对象达到上限时，首先删除最先入队的对象。默认上限1024，底层使用 LinkedList实现。 eviction="FIFO"
SoftCache 软引用清理策略的缓存 通过软引用来实现缓存，当 JVM内存不足时，会自动清理掉这些缓存，基于 SoftReference eviction="SOFT"
WeakCache 弱引用清理策略的缓存 通过弱引用来实现缓存，当 JVM内存不足时，会自动清理掉这些缓存，基于 WeakReference eviction="WEAK"
LoggingCache 带日志功能的缓存 记录部分缓存处理情况，如：输出缓存的命中率 基本
SynchronizedCache 同步缓存 基于 synchronized关键字实现，解决并发问题 基本
BlockingCache 阻塞缓存 通过对 get/set方法里加锁，保证只有一个线程操作缓存，基于 ReentrantLock实现 blocking=true
SerializedCache 支持序列化的缓存 将对象序列化后存入缓存，取出时反序列化 readOnly=false（默认配置）
ScheduledCache 定时调度的缓存 在进行 get/set/remove/getSize等操作前，判断缓存时间是否超过了设置的最长缓存时间，默认一小时，如果是则清空缓存。 flushinterval不为空
TransactionalCache 事务缓存 在二级缓存中使用，可以一次存入多个缓存，移除多个缓存 TransactionalCacheManager中用 Map维护对应关系

对缓存实现结构有了大致了解后，我们分别来看下一级缓存和二级缓存。

一级缓存

介绍

在应用程序中，我们有可能在一次数据库会话中，执行多次查询条件完全相同的 SQL， Mybatis提供了一级缓存的方案优化此场景，如果是相同的 SQL语句，会优先命中一级缓存，避免直接对数据库进行查询，提高性能。其过程具体如下：

每个 SqlSession中持有 Executor，每个 Executor中有一个 Local Cache。当用户发起查询时， Mybaits根据当前执行的语句生成 MappedStatement，在 Local Cache中进行查询，如果缓存命中的话，直接返回结果给用户，如果缓存未命中，查询数据库，并将结果写入 Local Cache，最后返回结果给用户。

配置

如何使用 Mybatis的一级缓存呢？

我们只需在 Mybatis配置文件 mybatis-config.xml中，添加如下语句，就可以使用一级缓存了。

1     
<setting name="localCacheScope" value="SESSION"/>

对于集成 Mybaits的 springboot项目，也可以直接在 properties或者 yml 文件里直接进行配置，如下：

1     
mybatis.configuration.local-cache-scope=session

value共有两个选项， SESSION和 STATEMENT，默认是 SESSION级别，即在一个 Mybatis会话中执行的所有语句，都会共享这个缓存。另一种是 STATEMENT级别，可以理解为缓存只对当前执行的这一个 Statement有效。

测试

我们接下来通过实验来了解 Mybaits一级缓存的效果。

我们首先创建表 student，并向表中添加一些数据。

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
CREATE TABLE `student` (     
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',     
  `stu_no` varchar(20) NOT NULL COMMENT '学号',     
  `stu_sex` char(1) DEFAULT NULL COMMENT '学生性别',     
  `stu_birthday` date DEFAULT NULL COMMENT '学生生日',     
  `stu_class` char(2) DEFAULT NULL COMMENT '学生班级',     
  `stu_name` varchar(50) DEFAULT NULL COMMENT '学生姓名',     
  PRIMARY KEY (`id`)     
) ENGINE=InnoDB AUTO_INCREMENT=0 DEFAULT CHARSET=utf8;     
     
INSERT INTO `student` (`id`, `stu_no`, `stu_sex`, `stu_birthday`, `stu_class`, `stu_name`) VALUES ('1', '1', '1', '2004-03-03', '1', '张三');     
INSERT INTO `student` (`id`, `stu_no`, `stu_sex`, `stu_birthday`, `stu_class`, `stu_name`) VALUES ('2', '2', '0', '2005-06-02', '2', '李四');     
INSERT INTO `student` (`id`, `stu_no`, `stu_sex`, `stu_birthday`, `stu_class`, `stu_name`) VALUES ('3', '3', '1', '2003-01-07', '3', '王五');

同时提供 Mapper及 pojo类，过程略。

测试一

我们通过单元测试，测试如下代码：

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
15     
@RunWith(SpringRunner.class)     
@SpringBootTest     
public class DemoApplicationTests {     
    @Autowired     
    private SqlSessionFactory sqlSessionFactory;     
     
    @Test     
    public void cacheTest() {     
        SqlSession sqlSession = sqlSessionFactory.openSession(true);     
        StudentMapper studentMapper = sqlSession.getMapper(StudentMapper.class);     
        System.out.println(studentMapper.selectByPrimaryKey(1));     
        System.out.println(studentMapper.selectByPrimaryKey(1));     
        System.out.println(studentMapper.selectByPrimaryKey(1));     
    }     
}

记得开启日志的 DEBUG级别。

可以看到三次查询，实际只有第一次真正查询了数据库，后续的查询使用的是一级缓存。

测试二

上述代码中，我们增加对数据库的修改操作，验证在一次数据库会话中，如果对数据库发生了修改操作，一级缓存是否失效。

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
@Test     
public void cacheTest1() {     
    SqlSession sqlSession = sqlSessionFactory.openSession(true);     
    StudentMapper studentMapper = sqlSession.getMapper(StudentMapper.class);     
    studentMapper.selectByPrimaryKey(1);     
    StudentModel studentModel = new StudentModel();     
    studentModel.setStuName("赵六");     
    studentModel.setStuNo("4");     
    studentModel.setStuClass("1");     
    studentModel.setStuSex("1");     
    studentMapper.insert(studentModel);     
    studentMapper.selectByPrimaryKey(1);     
}

输出如下日志：

可以看到，在修改操作后执行相同的查询， 一级缓存失效，会再次查询数据库。

测试三

开启两个 SqlSession，在 sqlSession1中查询数据，使一级缓存生效，在 sqlSession2中更新数据库，验证一级缓存只在数据库会话内部共享。

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
15     
@Test     
public void cacheTest3() {     
    SqlSession sqlSession1 = sqlSessionFactory.openSession(true);     
    SqlSession sqlSession2 = sqlSessionFactory.openSession(true);     
     
    StudentMapper studentMapper1 = sqlSession1.getMapper(StudentMapper.class);     
    StudentMapper studentMapper2 = sqlSession2.getMapper(StudentMapper.class);     
    System.out.println("studentMapper1->"+studentMapper1.selectByPrimaryKey(1));     
    System.out.println("studentMapper1->"+studentMapper1.selectByPrimaryKey(1));     
     
    studentMapper2.updateStudentName("张二",1);     
     
    System.out.println("studentMapper1->"+studentMapper1.selectByPrimaryKey(1));     
    System.out.println("studentMapper2->"+studentMapper2.selectByPrimaryKey(1));     
}

日志如下：

可以看到， sqlSession2更新了 id为1的学生的姓名，从 张三变为 张二，但在 session1之后的查询中， id为1的学生名字还是 张三，出现了脏数据，也说明了一级缓存只在数据库会话内部共享。

工作流程及源码

工作流程

一级缓存执行的时序图可以用下图来表示：

源码分析

下面我们来看下 Mybaits查询相关的核心类和一级缓存源码，这对我们后面的二级缓存学习也有帮助。

SqlSession：对外提供了用户和数据库之间交互需要的方法，隐藏了底层细节。默认实现类是 DefaultSqlSession。

Executor： SqlSession向用户提供操作数据库的方法，但和数据库操作有关的职责都会委托给 Executor。

如下图所示， Executor有若干个实现类，为 Executor赋予了不同的能力。

在一级缓存源码中，我们主要来看下 BaseExecutor的内部实现。

BaseExecutor：是一个实现了 Executor接口的抽象类，定义了若干抽象方法，在执行的时候，把具体的操作委托给子类进行执行。

1     
2     
3     
4     
5     
6     
7     
protected abstract int doUpdate(MappedStatement ms, Object parameter) throws SQLException;     
     
protected abstract List<BatchResult> doFlushStatements(boolean isRollback) throws SQLException;     
     
protected abstract <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException;     
     
protected abstract <E> Cursor<E> doQueryCursor(MappedStatement ms, Object parameter, RowBounds rowBounds, BoundSql boundSql) throws SQLException;

在 BaseExecutor中，我们可以看到 Local Cache是其内部的一个成员变量，如下：

也就到了我们最开始所说的部分， Cache接口及其实现类。

总体流程如下：

为了执行和数据库交互，首先需要初始化 SqlSession，通过 DefaultSqlSessionFactory开启 SqlSession：

可以看到会用 Configuration类创建一个全新的 Executor，作为 DefaultSqlSession 的参数。

创建 Executor的代码如下：

SqlSession创建完毕后，根据 Statement的不同类型，会进入 SqlSession的不同方法中，如果是 select语句，最后会执行到 SqlSession的 selectList方法：

SqlSession把具体的查询职责委托给了 Executor。如果只开启了一级缓存的话，会进入 BaseExecutor的 query方法。如下：

上述代码中，会先根据传入的参数生成 CacheKey，我们来看下：

上述代码中，将 MappedStatement的 id、 SQL的 offset及 limit、 SQL本身以及 SQL中的参数传入了 CacheKey这个类。

其 update方法如下：

它重写了 equals方法，如下：

我们可以看到除去 hashcode、 checksum、 count的比较外，只要 updatelist中的元素一一对应相等，那么就认为 CacheKey相等。

也就是只要两条 SQL的下面五个值相同，即可以认为是相同 SQL。

Statement Id + Offset + Limit + Sql + Params

BaseExecutor的 query继续往下走，如下：

可以看到如果一级缓存里没有，就会去数据库查询。

在 queryFromDatabase中，会对 localCache进行写入。

在上面 query方法的最后，可以看到会判断一级缓存的级别，如果是 STATEMENT级别，就会清空缓存，也就是 STATEMENT级别无法共享一级缓存。

1     
2     
3     
4     
if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {     
        // issue #482     
        clearLocalCache();     
 }

最后，我们再来看下 insert/update/delete操作，缓存会刷新的原因。

SqlSession找到 insert/delete方法，都会走 update流程。

1     
2     
3     
4     
5     
6     
7     
8     
@Override     
public int insert(String statement, Object parameter) {     
  return update(statement, parameter);     
}     
@Override     
public int delete(String statement, Object parameter) {     
  return update(statement, parameter);     
}

我们来看下 update方法，它也是委托给了 Executor执行。

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
@Override     
public int update(String statement, Object parameter) {     
  try {     
    dirty = true;     
    MappedStatement ms = configuration.getMappedStatement(statement);     
    return executor.update(ms, wrapCollection(parameter));     
  } catch (Exception e) {     
    throw ExceptionFactory.wrapException("Error updating database.  Cause: " + e, e);     
  } finally {     
    ErrorContext.instance().reset();     
  }     
}

找到 BaseExecutor实现，我们可以看到它每次执行都会清空 Local Cache。

上面就是 Mybaits的一级缓存的工作流程原理。

总结

我们来总结下一级缓存的部分内容。

  • Mybatis一级缓存的生命周期和 SqlSession一致。
  • Mybatis一级缓存结构简单，只是个没有容量限定的 HashMap，在缓存功能上有所缺陷。
  • Mybatis的一级缓存最大范围是 SqlSession内部，有多个 SqlSession或者分布式环境下，数据库写操作可能会引起脏数据问题，建议设定缓存级别为 STATEMENT。

二级缓存

介绍

上面我们说的一级缓存，其最大共享范围就是一个 SqlSession的内部，如果多个 SqlSession需要共享缓存，则需要使用二级缓存。

开启二级缓存后，会使用 CachingExecutor 装饰 Executor，我们可以在 newExecutor方法逻辑里发现这段代码：

进入一级缓存的查询流程前，先在 CachingExecutor 进行二级缓存的查询，具体工作流程如下。

二级缓存开启后，同一个 namespace下所有操作语句，都影响着同一个 Cache，即二级缓存被多个 SqlSession共享，是一个全局变量。

当开启缓存后，数据的查询执行流程为： 二级缓存 -> 一级缓存 -> 数据库。

配置

要正确使用二级缓存，需要完成如下配置。

  • Mybatis配置文件中开启二级缓存。

    1       
    <setting name="cacheEnabled" value="true"/>

    或者如果使用的是 springboot集成，需要如下配置。

    1       
    mybatis.configuration.cache-enabled=true

  • 在 Mybatis的映射 XML中配置 cache或者 cache-ref。

    cache标签用于声明这个 namespace使用二级缓存，并且可以自定义配置。

    1       
    <cache/>
    • type： cache使用的类型，默认是 PerpetualCache。
    • eviction：定义回收的策略，常见的有 FIFO、 LRU。
    • flushInterval：配置一定时间自动刷新缓存，单位是毫秒。
    • size：最多缓存的对象个数。
    • readOnly：是否只读，若配置可读写，则需要对应的实体类能够序列化。
    • blocking：若缓存中找不到对应的 key，是否会一直 blocking，直到有对应的数据进入缓存。

    cache-ref代表引用别的命名空间的 Cache配置，两个命名空间的操作使用的是同一个 Cache。

    1       
    <cache-ref namespace="com.zwt.demo.mapper.StudentMapper"/>

测试

我们来看几个二级缓存的测试，来了解下二级缓存的一些特点。

测试一

测试二级缓存效果，不提交事务， sqlSession1查询完数据后， sqlSession2相同的查询是否会从缓存中获取数据。

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
@Test     
public void cacheTest4() {     
    SqlSession sqlSession1 = sqlSessionFactory.openSession(true);     
    SqlSession sqlSession2 = sqlSessionFactory.openSession(true);     
     
    StudentMapper studentMapper1 = sqlSession1.getMapper(StudentMapper.class);     
    StudentMapper studentMapper2 = sqlSession2.getMapper(StudentMapper.class);     
    System.out.println("studentMapper1->"+studentMapper1.selectByPrimaryKey(1));     
    System.out.println("studentMapper2->"+studentMapper2.selectByPrimaryKey(1));     
}

可以看到，当 sqlSession没有调用 commit()方法时，二级缓存并没有起到作用。

测试二

这回我们测试当提交事务后，二级缓存是否可以起到作用。

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
@Test     
public void cacheTest5() {     
    SqlSession sqlSession1 = sqlSessionFactory.openSession(true);     
    SqlSession sqlSession2 = sqlSessionFactory.openSession(true);     
     
    StudentMapper studentMapper1 = sqlSession1.getMapper(StudentMapper.class);     
    StudentMapper studentMapper2 = sqlSession2.getMapper(StudentMapper.class);     
    System.out.println("studentMapper1->"+studentMapper1.selectByPrimaryKey(1));     
    sqlSession1.commit();     
    System.out.println("studentMapper2->"+studentMapper2.selectByPrimaryKey(1));     
}

可以看到只进行了一次查询， sqlSession2的查询使用了缓存，缓存命中率为0.5。

PS：为什么是0.5？ 因为进行了两次查询，第一次未命中，查询数据库，第二次命中缓存，故命中率是 1/2 = 0.5。

测试三

测试 update操作是否会刷新该 namespace下的二级缓存。

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
15     
16     
17     
@Test     
public void cacheTest6() {     
    SqlSession sqlSession1 = sqlSessionFactory.openSession(true);     
    SqlSession sqlSession2 = sqlSessionFactory.openSession(true);     
    SqlSession sqlSession3 = sqlSessionFactory.openSession(true);     
     
    StudentMapper studentMapper1 = sqlSession1.getMapper(StudentMapper.class);     
    StudentMapper studentMapper2 = sqlSession2.getMapper(StudentMapper.class);     
    StudentMapper studentMapper3 = sqlSession3.getMapper(StudentMapper.class);     
     
    System.out.println("studentMapper1->"+studentMapper1.selectByPrimaryKey(1));     
    sqlSession1.commit();     
    System.out.println("studentMapper2->"+studentMapper2.selectByPrimaryKey(1));     
    studentMapper3.updateStudentName("张二二",1);     
    sqlSession3.commit();     
    System.out.println("studentMapper2->"+studentMapper2.selectByPrimaryKey(1));     
}

可以看到， sqlSession3更新数据库，提交事务后， sqlSession2后面的查询走了数据库，没有走 Cache。

测试四

验证 Mybatis二级缓存不适用用映射文件中存在多表查询的情况。

通常我们会为每个单表创建单独的映射文件，由于 Mybatis的二级缓存是基于 namespace的，多表查询语句所在的 namespace无法感应到其他 namespace中的语句对多表查询中涉及的表进行的修改，引发脏数据问题。

这儿我们在引入一张表， score学生分数表，并创建几条数据。

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
CREATE TABLE `score` (     
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',     
  `stu_no` varchar(20) NOT NULL COMMENT '学号',     
  `cou_no` varchar(20) NOT NULL COMMENT '课程号',     
  `score` decimal(10,0) DEFAULT NULL COMMENT '分数',     
  PRIMARY KEY (`id`),     
  UNIQUE KEY `uq_stu_cou` (`stu_no`,`cou_no`) USING BTREE     
) ENGINE=InnoDB AUTO_INCREMENT=5 DEFAULT CHARSET=utf8;     
     
INSERT INTO `score` (`id`, `stu_no`, `cou_no`, `score`) VALUES ('1', '1', 'A', '80');     
INSERT INTO `score` (`id`, `stu_no`, `cou_no`, `score`) VALUES ('2', '2', 'B', '90');     
INSERT INTO `score` (`id`, `stu_no`, `cou_no`, `score`) VALUES ('3', '2', 'A', '70');     
INSERT INTO `score` (`id`, `stu_no`, `cou_no`, `score`) VALUES ('4', '3', 'A', '60');

涉及到的 ScoreMapper不再附上。

我们假设在 StudentMapper里有个根据学生 id和课程号查询学生分数的方法， ScoreMapper里有个更新学生分数的方法。

StudentMapper中获取学生分数：

1     
int selectStudentScore(@Param("stuNo") String stuNo,@Param("couNo") String couNo);     
1     
2     
3     
<select id="selectStudentScore" resultType="java.lang.Integer">     
  select c.score from student s left join score c on s.stu_no = c.stu_no where s.stu_no = #{stuNo} and c.cou_no = #{couNo};     
</select>

ScoreMapper更新分数：

1     
int updateScore(@Param("stuNo") String stuNo,@Param("couNo") String couNo,@Param("score")Integer score);     
1     
2     
3     
<update id="updateScore">     
   update score set score = #{score} where stu_no = #{stuNo} and cou_no = #{couNo}     
</update>

代码如下：

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
15     
16     
17     
@Test     
public void cacheTest7() {     
    SqlSession sqlSession1 = sqlSessionFactory.openSession(true);     
    SqlSession sqlSession2 = sqlSessionFactory.openSession(true);     
    SqlSession sqlSession3 = sqlSessionFactory.openSession(true);     
     
    StudentMapper studentMapper1 = sqlSession1.getMapper(StudentMapper.class);     
    StudentMapper studentMapper2 = sqlSession2.getMapper(StudentMapper.class);     
    ScoreMapper scoreMapper = sqlSession3.getMapper(ScoreMapper.class);     
     
    System.out.println("studentMapper1->"+studentMapper1.selectStudentScore("1","A"));     
    sqlSession1.close();     
    System.out.println("studentMapper2->"+studentMapper2.selectStudentScore("1","A"));     
    scoreMapper.updateScore("1","A",99);     
    sqlSession3.commit();     
    System.out.println("studentMapper2->"+studentMapper2.selectStudentScore("1","A"));     
}

可以看到， sqlSession1 的 studentMapper1 查询数据库后，二级缓存生效。其保存在 StudentMapper 的 namespace的 cache中。当 sqlSession3的 scoreMapper更新数据时，其方法不属于 StudentMapper 的 namespace，无法感应到缓存变化，因此读取了脏数据。

测试五

为了解决测试四出现的问题，我们可以使用 cache-ref，让 ScoreMapper引用 StudentMapper的命名空间，这样两个映射文件对应的 SQL操作就会使用同一块缓存。

1     
2     
3     
4     
5     
......     
<mapper namespace="com.zwt.demo.mapper.ScoreMapper" >     
......     
    <cache-ref namespace="com.zwt.demo.mapper.StudentMapper"></cache-ref>     
</mapper>

继续执行测试四代码：

可以看到，更新后，会重新进行查询，得到99的结果。

PS：不过这样做的后果是，缓存的粒度变粗了，多个 Mapper namespace下的所有操作都会对缓存的使用造成影响。

源码分析

Mybatis二级缓存的工作流程和上面提到的一级缓存类似，只是在一级缓存处理前，用 CachingExecutor装饰了 BaseExecutor的子类，在委托具体职责给 delegate之前，实现了二级缓存的查询和写入功能。

我们从 CachingExecutor的 query方法看起，来了解下二级缓存的一些内容。

CachingExecutor的 query方法，首先会从 MappedStatement中获得在配置初始化时赋予的 Cache。

1     
Cache cache = ms.getCache();

其也是装饰器模式的使用，装饰链如下：

1      
SynchronizedCache -> LoggingCache -> SerializedCache -> LruCache -> PerpetualCache

这些缓存的具体能力我们上面都有讲到。

然后判断是否需要刷新缓存。

1     
flushCacheIfRequired(ms);

默认设置中 SELECT语句不会刷新， INSERT/UPDATE/DELETE语句会刷新缓存。

1     
2     
3     
4     
5     
6     
private void flushCacheIfRequired(MappedStatement ms) {     
    Cache cache = ms.getCache();     
    if (cache != null && ms.isFlushCacheRequired()) {           
      tcm.clear(cache);     
    }     
  }

上述代码中我们可以看到 tcm，它是 TransactionalCacheManager。

底层是由 TransactionalCache 实现的，作用就是如果事务提交，对缓存的操作才会生效，如果事务回滚或者不提交事务，则不会对缓存产生影响。

在 TransactionalCache中的 clear方法，清空了需要在提交时加入缓存的列表，同时设定提交时清空缓存。有以下代码。

1     
2     
3     
4     
5     
@Override     
public void clear() {     
  clearOnCommit = true;     
  entriesToAddOnCommit.clear();     
}

返回到 CachingExecutor，我们继续向下看， ensureNoOutParams 方法用来处理存储过程的，暂时不用考虑。

之后会尝试从 tcm中获取缓存列表。

1     
List<E> list = (List<E>) tcm.getObject(cache, key);

getObject方法中，可以看到未命中会把 key加入Miss集合，这个主要是为了统计命中率。

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
@Override     
public Object getObject(Object key) {     
    // issue #116     
    Object object = delegate.getObject(key);     
    if (object == null) {     
        entriesMissedInCache.add(key);     
    }     
    // issue #146     
    if (clearOnCommit) {     
        return null;     
    } else {     
        return object;     
    }     
}

返回到 CachingExecutor，我们继续向下看，如果查询到数据，则调用 putObject方法，向缓存中放入值。

1     
2     
3     
4     
if (list == null) {     
    list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);     
    tcm.putObject(cache, key, list); // issue #578 and #116     
 }

putObject方法最终调用 tcm.put方法。

1     
2     
3     
4     
@Override     
public void putObject(Object key, Object object) {     
  entriesToAddOnCommit.put(key, object);     
}

这儿是将数据放入待提交的 Map中，而不是直接操作缓存。

上面代码我们可以看到，如果不调用 commit方法的话，由于 TransactionalCache 的作用，不会对二级缓存造成直接影响。因此我们来看看 SqlSession的 commit方法中做了什么。

因为我们使用的是 CachingExecutor，因此我们来看下其 commit方法。

1     
2     
3     
4     
5     
@Override     
public void commit(boolean required) throws SQLException {     
  delegate.commit(required);     
  tcm.commit();     
}

会把具体 commit的职责委托给包装的 Executor。而后 tcm.commit方法如下：

1     
2     
3     
4     
5     
public void commit() {     
    for (TransactionalCache txCache : transactionalCaches.values()) {     
        txCache.commit();     
    }     
}

最终调用了 TransactionalCache。

1     
2     
3     
4     
5     
6     
7     
public void commit() {     
    if (clearOnCommit) {     
        delegate.clear();     
    }     
    flushPendingEntries();     
    reset();     
}

可以看到真正的清理 Cache实在这里进行的。具体的清理职责委托给了包装的 Cache类。

之后进入到 flushPendingEntries()方法，代码如下：

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
private void flushPendingEntries() {     
    for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) {     
        delegate.putObject(entry.getKey(), entry.getValue());     
    }     
    for (Object entry : entriesMissedInCache) {     
        if (!entriesToAddOnCommit.containsKey(entry)) {     
            delegate.putObject(entry, null);     
        }     
    }     
}

可以看到在 flushPendingEntries中，会将待提交的 Map进行循环处理，委托给包装的 Cache类，进行 putObject操作。

后续的查询操作会重复这套流程。

如果是 INSERT/UPDATE/DELETE语句的话，会统一进入 CachingExecutor的 update方法。

1     
2     
3     
4     
5     
@Override     
public int update(MappedStatement ms, Object parameterObject) throws SQLException {     
    flushCacheIfRequired(ms);     
    return delegate.update(ms, parameterObject);     
}

flushCacheIfRequired我们上面有提到过。

在二级缓存执行流程后就会进入一级缓存的执行流程，这儿我们就不过多介绍了。

总结

  • Mybatis的二级缓存相对于一级缓存来说，实现了 SqlSession之间缓存数据的共享，同时粒度更加细致，能够到 namespace级别，通过 Cache接口实现不同的组合，对 Cache的可控性也更强。
  • 二级缓存开启状态下， Mybatis在多表查询时，很有可能会出现脏数据，有设计上的缺陷，安全使用二级缓存条件比较苛刻。
  • 在分布式环境下，由于默认的 Mybatis Cache实现都是基于本地的，因此也很可能出现脏数据问题，此时可以使用集中式缓存将 Mybaits的 Cache接口实现，但会有一定的开发成本，直接使用 Redis等分布式缓存成本可能更低，安全性也更好。

自定义缓存实现

我们在正文的缓存实现里说到，我们可以借助一些缓存工具来实现 Mybatis的自定义缓存，这儿我们使用 Redis来举例。

首先需要引入 Redis，我的项目配置如下：

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
15     
16     
17     
18     
spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver     
spring.datasource.url=jdbc:mysql://localhost:3306/test1?characterEncoding=utf8&useSSL=false&serverTimezone=GMT%2B8     
spring.datasource.username=root     
spring.datasource.password=123456     
     
mybatis.mapper-locations=classpath:sqlmap/mapper/*.xml     
mybatis.type-aliases-package=com.zwt.demo.model     
mybatis.configuration.local-cache-scope=session     
mybatis.configuration.cache-enabled=true     
     
spring.redis.host=127.0.0.1     
spring.redis.database=0     
spring.redis.port=6379     
spring.redis.timeout=3600ms     
spring.redis.jedis.pool.max-active=8     
spring.redis.jedis.pool.max-wait=-1ms     
spring.redis.jedis.pool.max-idle=8     
spring.redis.jedis.pool.min-idle=0

其项目结构如下：

可以看到在 cache包下的内容就是我对于 Mybatis二级缓存的自定义实现。

主要有两个类： RedisCache和 RedisCacheHelp， RedisCache1是 RedisCache的另一种实现。

我们来看下，首先看下 RedisCache，代码如下：

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
15     
16     
17     
18     
19     
20     
21     
22     
23     
24     
25     
26     
27     
28     
29     
30     
31     
32     
33     
34     
35     
36     
37     
38     
39     
40     
41     
42     
43     
44     
45     
46     
47     
48     
49     
50     
51     
52     
53     
54     
55     
56     
57     
58     
59     
60     
61     
62     
63     
64     
65     
66     
67     
68     
69     
70     
71     
72     
public class RedisCache implements Cache{     
     
    private static final Logger logger = LoggerFactory.getLogger(RedisCache.class);     
     
    private static RedisTemplate<String,Object> redisTemplate;     
     
    private final String id;     
     
    private final String HASH_KEY = "mybatis_redis_cache";     
     
    private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock();     
     
    @Override     
    public ReadWriteLock getReadWriteLock(){     
        return this.readWriteLock;     
    }     
     
    public static void setRedisTemplate(RedisTemplate redisTemplate){     
        RedisCache.redisTemplate = redisTemplate;     
    }     
     
    public RedisCache(final String id){     
        if (id == null) {     
            throw new IllegalArgumentException("需要指定id");     
        }     
        this.id = id;     
    }     
     
    @Override     
    public String getId(){     
        return this.id;     
    }     
     
    @Override     
    public void putObject(Object key, Object value){     
        logger.info("MybatisRedisCache -> putObject: key=" + key + ",value=" + value);     
        if(null!=value) {     
            redisTemplate.opsForHash().put(HASH_KEY,key.toString(),value);     
        }     
    }     
     
    @Override     
    public Object getObject(Object key) {     
        logger.info("MybatisRedisCache -> getObject: key="+key);     
        if(null != key) {     
            return redisTemplate.opsForHash().get(HASH_KEY,key.toString());     
        }     
        return null;     
    }     
     
    @Override     
    public Object removeObject(Object key){     
        logger.info("MybatisRedisCache -> removeObject: key="+key);     
        if(null != key) {     
            return redisTemplate.opsForHash().delete(HASH_KEY,key);     
        }     
        return null;     
    }     
     
    @Override     
    public void clear() {     
        Long size = redisTemplate.opsForHash().size(HASH_KEY);     
        redisTemplate.delete(HASH_KEY);     
        logger.info("MybatisRedisCache -> clear: 清除了" + size + "个对象");     
    }     
     
    @Override     
    public int getSize() {     
        Long size = redisTemplate.opsForHash().size(HASH_KEY);     
        return size == null ? 0 : size.intValue();     
    }     
}

代码非常好理解，就是实现 org.apache.ibatis.cache.Cache 接口，通过 Redis操作实现缓存的操作，这儿我们使用到了 Hash表。

关于如何是上述代码中的 redisTemplate生效，就要用到了 RedisCacheHelp类，这个类代码如下，主要是实现 redisTemplate的注入。

1     
2     
3     
4     
5     
6     
7     
8     
@Component     
public class RedisCacheHelp {     
    @Autowired     
    public void setRedisTemplate(RedisTemplate redisTemplate) {     
        RedisCache.setRedisTemplate(redisTemplate);     
        //RedisCache1.setRedisTemplate(redisTemplate);     
    }     
}

上述代码弄好后，我们还需要在具体的 xml（如StudentMapper.xml）指定缓存类型为我们的 RedisCache，如下：

1     
<cache type="com.zwt.demo.cache.RedisCache"></cache>

以上配置完成，我们就可以使用我们自定义的二级缓存了。

我们运行一下测试代码，比如上面的这一个测试类：

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
15     
16     
17     
@Test     
public void cacheTest6() {     
    SqlSession sqlSession1 = sqlSessionFactory.openSession(true);     
    SqlSession sqlSession2 = sqlSessionFactory.openSession(true);     
    SqlSession sqlSession3 = sqlSessionFactory.openSession(true);     
     
    StudentMapper studentMapper1 = sqlSession1.getMapper(StudentMapper.class);     
    StudentMapper studentMapper2 = sqlSession2.getMapper(StudentMapper.class);     
    StudentMapper studentMapper3 = sqlSession3.getMapper(StudentMapper.class);     
     
    System.out.println("studentMapper1->"+studentMapper1.selectByPrimaryKey(1));     
    sqlSession1.commit();     
    System.out.println("studentMapper2->"+studentMapper2.selectByPrimaryKey(1));     
    studentMapper3.updateStudentName("张二二",1);     
    sqlSession3.commit();     
    System.out.println("studentMapper2->"+studentMapper2.selectByPrimaryKey(1));     
}

可以看到如下输出：

说明已经使用了我们自定义的缓存策略。

大家可以看到我写了 RedisCache和 RedisCache1两个类，是这样的，我们可以看到 RedisCache使用的是 Redis Hash表结构来实现的二级缓存，其增加、删除、获取、统计数量、清空等操作十分方便，但有一个问题，就是 Hash表没有办法设置其内部的单个 key的过期时间，只能指定 Hash表过期时间。

如果我们使用不当，可能会出现一些问题。

RedisCache1的代码如下：

1     
2     
3     
4     
5     
6     
7     
8     
9     
10     
11     
12     
13     
14     
15     
16     
17     
18     
19     
20     
21     
22     
23     
24     
25     
26     
27     
28     
29     
30     
31     
32     
33     
34     
35     
36     
37     
38     
39     
40     
41     
42     
43     
44     
45     
46     
47     
48     
49     
50     
51     
52     
53     
54     
55     
56     
57     
58     
59     
60     
61     
62     
63     
64     
65     
66     
67     
68     
69     
70     
71     
72     
public class RedisCache1 implements Cache{     
     
    private static final Logger logger = LoggerFactory.getLogger(RedisCache1.class);     
     
    private static RedisTemplate<String,Object> redisTemplate;     
     
    private final String id;     
     
    private final String KEY_ALL_PREFIX = "mybatis_redis_cache_%s";     
     
    private final ReadWriteLock readWriteLock = new ReentrantReadWriteLock();     
     
    @Override     
    public ReadWriteLock getReadWriteLock(){     
        return this.readWriteLock;     
    }     
     
    public static void setRedisTemplate(RedisTemplate redisTemplate){     
        RedisCache1.redisTemplate = redisTemplate;     
    }     
     
    public RedisCache1(final String id){     
        if (id == null) {     
            throw new IllegalArgumentException("需要指定id");     
        }     
        this.id = id;     
    }     
     
    @Override     
    public String getId(){     
        return this.id;     
    }     
     
    @Override     
    public void putObject(Object key, Object value){     
        logger.info("MybatisRedisCache -> putObject: key=" + key + ",value=" + value);     
        if(null!=value) {     
            redisTemplate.opsForValue().set(String.format(KEY_ALL_PREFIX,key.toString()),value,60, TimeUnit.SECONDS);     
        }     
    }     
     
    @Override     
    public Object getObject(Object key) {     
        logger.info("MybatisRedisCache -> getObject: key="+key);     
        if(null != key) {     
            return redisTemplate.opsForValue().get(String.format(KEY_ALL_PREFIX,key.toString()));     
        }     
        return null;     
    }     
     
    @Override     
    public Object removeObject(Object key){     
        logger.info("MybatisRedisCache -> removeObject: key="+key);     
        if(null != key) {     
            return redisTemplate.delete(String.format(KEY_ALL_PREFIX,key.toString()));     
        }     
        return null;     
    }     
     
    @Override     
    public void clear() {     
        Set<String> keys = redisTemplate.keys(String.format(KEY_ALL_PREFIX,"*"));     
        redisTemplate.delete(keys);     
        logger.info("MybatisRedisCache -> clear: 清除了" + keys.size() + "个对象");     
    }     
     
    @Override     
    public int getSize() {     
        Set<String> keys = redisTemplate.keys(String.format(KEY_ALL_PREFIX,"*"));     
        return keys.size();     
    }     
}

可以看到这个类主要是利用 Redis key前缀来处理缓存内容，其 K,V都是单个存储的，其增加、删除、获取是非常方便的，而且可以指定 key的过期时间，防止出现问题，但其清空、统计数量操作需要查出全部前缀数据的 Set集合，在进行处理。

以上就是我们关于实现自定义 Mybatis缓存的一些代码。

这儿需要说的一点是：我们上述这种使用Redis实现 Mybatis二级缓存的方式，在分布式环境下，可以将各个单机缓存归一，避免了一些查库操作，但实际上我们不使用二级缓存，只使用Redis也是可以解决的。

另外这种形式的二级缓存，出现（测试四）映射文件中存在多表查询的情况，如果不使用cache-ref，也会有脏数据问题。

总结

本文通过对 Mybaits一二级缓存的介绍，并从实验及源码角度分析了 Mybaits缓存的特点、机制及可能产生的问题，并对缓存机制做了一定的总结。

而后我们又借助 Redis实现了一个自定义的二级缓存处理器，加深对 Mybatis缓存的理解。

在实际生产中，我们一般建议关闭 Mybatis缓存特性，单纯将其作为一个 ORM框架来使用。

参考资料

相关 [mybaits 缓存] 推荐：

Mybaits缓存机制

- - SakuraTears的博客
我们知道 Mybatis作为常见的 Java数据库访问层的 ORM框架，其缓存分为一级缓存和二级缓存. 大多数情况下，我们使用的都是 Mybatis缓存的默认配置，但是 Mybatis缓存机制有一些不足之处，在使用中容易引起脏数据问题，形成一些潜在隐患. 今天，我们就来看下 Mybatis的缓存机制，了解其底层的一些原理，来方便我们排查、解决以后可能出现的由 Mybatis缓存引起的问题.

缓存算法

- lostsnow - 小彰
没有人能说清哪种缓存算法由于其他的缓存算法. （以下的几种缓存算法，有的我也理解不好，如果感兴趣，你可以Google一下  ）. 大家好，我是 LFU，我会计算为每个缓存对象计算他们被使用的频率. 我是LRU缓存算法，我把最近最少使用的缓存对象给踢走. 我总是需要去了解在什么时候，用了哪个缓存对象.

Hibernate 缓存

- - ITeye博客
1数据缓存:(date caching) 是一种将数据暂时存于内存缓存去中的技术,缓存通常是影响系统性能的关键因素. 2.ORM的数据缓存策略有3中.   1.事务级缓存:  分为 数据库事务和 应用级事务,是基于Session的生命周期的实现,每个session都会在内部维持一个数据缓存, 随session的创建和消亡.

hibernate缓存，一级缓存，二级缓存，查询缓存

- - CSDN博客推荐文章
1、缓存是数据库数据在内存中的临时容器，它包含了库表数据在内存中的临时拷贝，位于数据库和访问层之间. 2、ORM在进行数据读取时，会根据缓存管理策略，首先在缓冲中查询，如果发现，则直接使用，避免数据库调用的开销. 事务级缓存：当前事务范围内的数据缓存. 应用级缓存：某个应用中的数据缓存. 分布式缓存：多个应用，多个JVM之间共享缓存.

缓存相关——缓存穿透、缓存并发、缓存失效、缓存预热、缓存雪崩、缓存算法

- - 编程语言 - ITeye博客
我们在项目中使用缓存通常都是先检查缓存中是否存在，如果存在直接返回缓存内容，如果不存在就直接查询数据库然后再缓存查询结果返回. 这个时候如果我们查询的某一个数据在缓存中一直不存在，就会造成每一次请求都查询DB，这样缓存就失去了意义，在流量大时，可能DB就挂掉了. 要是有人利用不存在的key频繁攻击我们的应用，这就是漏洞.

Hibernate 二级缓存

- - CSDN博客推荐文章
很多人对二级缓存都不太了解，或者是有错误的认识，我一直想写一篇文章介绍一下hibernate的二级缓存的，今天终于忍不住了. 我的经验主要来自hibernate2.1版本，基本原理和3.0、3.1是一样的，请原谅我的顽固不化. hibernate的session提供了一级缓存，每个session，对同一个id进行两次load，不会发送两条sql给数据库，但是session关闭的时候，一级缓存就失效了.

App缓存管理

- - ITeye博客
无论大型或小型应用，灵活的缓存可以说不仅大大减轻了服务器的压力，而且因为更快速的用户体验而方便了用户. Android的apk可以说是作为小型应用，其中99%的应用并不是需要实时更新的，而且诟病于蜗牛般的移动网速，与服务器的数据交互是能少则少，这样用户体验才更好，这也是我们有时舍弃webview而采用json传输数据的原因之一.

关于缓存（上）

- - 搜索技术博客－淘宝
商业世界中常说的一句话是“现金为王”. 在技术世界里，与之相近的一个说法是“缓存为王”. 缓存在构建高性能web站点中有着举足轻重的作用， sql优化， 算法优化所带来的效果可能远远不如缓存带来的优化效果. 但是缓存的使用并不是零成本的，首先的一个问题是，任何缓存的增加，都会带来两大问题：. 解决这两个问题需要以下一些方法，首先是去掉缓存.

HTTP缓存算法

- - PHP源码阅读，PHP设计模式，PHP学习笔记，项目管理-胖胖的空间
HTTP协议缓存的目标是去除许多情况下对于发送请求的需求和去除许多情况下发送完整请求的需求. 以不发送请求或减少请求传输的数据量来优化整个HTTP架构，此目标的实现可以产生如下好处：. 降低对原始服务器的请求量. 减少了传送距离，降低了因为距离而产生的时延. 缓存基本处理过程包括七个步骤. 接收 – 缓存从网络中读取抵达的请求报文.