深入浅出 MyBatis 的一级二级缓存机制

Posted 2021-09-09 老周聊架构

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了深入浅出 MyBatis 的一级二级缓存机制相关的知识，希望对你有一定的参考价值。

欢迎大家关注我的微信公众号【老周聊架构】，Java后端主流技术栈的原理、源码分析、架构以及各种互联网高并发、高性能、高可用的解决方案。

一、MyBatis 缓存

缓存就是内存中的数据，常常来自对数据库查询结果的保存。使用缓存，我们可以避免频繁与数据库进行交互，从而提高响应速度。

MyBatis 也提供了对缓存的支持，分为一级缓存和二级缓存，来看下下面这张图：

一级缓存是 SqlSession 级别的缓存。在操作数据库时需要构造 SqlSession 对象，在对象中有一个数据结构（HashMap）用于存储缓存数据。不同的是 SqlSession 之间的缓存数据区（HashMap）是互相不影响。

二级缓存是 Mapper 级别的缓存，多个 SqlSession 去操作同一个 Mapper 的 sql 语句，多个 SqlSession 可以共用二级缓存，二级缓存是跨 SqlSession 的。

相信大家看完这张图和解释心里应该有个底了吧，这对后面分析 MyBatis 的一级、二级缓存机制很有帮助，那话不多说，我们直接进入主题了。

二、一级缓存

2.1 内部结构

在我们的应用运行期间，我们可能在一次数据库会话中，执行多次查询条件相同的 SQL，要你来设计的话你会如何考虑？没错，加缓存，MyBatis 也是这样去处理的，如果是相同的 SQL 语句，会优先命中一级缓存，避免直接对数据库进行查询，造成数据库的压力，以提高性能。具体执行过程如下图所示：

SqlSession 是一个接口，提供了一些 CRUD 的方法，而 SqlSession 的默认实现类是 DefaultSqlSession，DefaultSqlSession 类持有 Executor 接口对象，而 Executor 的默认实现是 BaseExecutor 对象，每个 BaseExecutor 对象都有一个 PerpetualCache 缓存，也就是上图的 Local Cache。

当用户发起查询时，MyBatis 根据当前执行的语句生成 MappedStatement，在 Local Cache 进行查询，如果缓存命中的话，直接返回结果给用户，如果缓存没有命中的话，查询数据库，结果写入 Local Cache，最后返回结果给用户。

啊，老周，关系还是有点抽象，感觉一直在套娃，没关系，看下面这张图你立马豁然开朗。

2.2 一级缓存配置

在 MyBatis 的配置文件中添加如下语句，就可以使用一级缓存。共有两个选项，SESSION 或者 STATEMENT，默认是 SESSION 级别，即在一个 MyBatis 会话中执行的所有语句，都会共享这一个缓存。一种是 STATEMENT 级别，可以理解为缓存只对当前执行的这一个 Statement 有效。

STATEMENT 级别粒度更细，我们上面说到，每个 SqlSession 中持有了 Executor，SqlSession 的默认实现类是 DefaultSqlSession，DefaultSqlSession 类持有 Executor 接口对象，而 Executor 的默认实现是 BaseExecutor 对象，每个 BaseExecutor 对象很多方法中都有传 MappedStatement 对象。所有 STATEMENT 级别是针对 SESSION 级别粒度更细的模式。

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

三、一级缓存实验

下面老周通过几组实验来带你了解 MyBatis 一级缓存的效果，我们首先准备一张简单的表 user，如下：

CREATE TABLE `user` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `name` varchar(64) COLLATE utf8_bin DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=2 DEFAULT CHARSET=utf8 COLLATE=utf8_bin;

我们在测试类中加上带有 @Before 标注的 before 方法，省得每个单元测试方法都要重复获取 sqlSession 以及 userMapper。

@Before
public void before() throws IOException {
    InputStream resourceAsStream = Resources.getResourceAsStream("SqlMapConfig.xml");
    sqlSessionFactory = new SqlSessionFactoryBuilder().build(resourceAsStream);
    sqlSession = sqlSessionFactory.openSession(true); // 自动提交事务
    userMapper = sqlSession.getMapper(UserMapper.class);
}

3.1 实验1

开启一级缓存，范围为会话级别，调用三次 firstLevelCacheFindUserById，代码如下所示：

@Test
public void firstLevelCacheFindUserById() {
    // 第一次查询id为1的用户
    User user1 = userMapper.findUserById(1);
    // 第二次查询id为1的用户
    User user2 = userMapper.findUserById(1);

    System.out.println(user1);
    System.out.println(user2);

    System.out.println(user1 == user2);
}

控制台日志输出：

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

3.2 实验2

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

@Test
public void firstLevelCacheOfUpdate() {
    // 第一次查询id为1的用户
    User user1 = userMapper.findUserById(1);
    System.out.println(user1);

    // 更新用户
    User user = new User();
    user.setId(2);
    user.setUsername("tom");

    System.out.println("更新了" + userMapper.updateUser(user) + "个用户");

    // 第二次查询id为1的用户
    User user2 = userMapper.findUserById(1);
    System.out.println(user2);

    System.out.println(user1 == user2);
}

控制台日志输出：

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

3.3 实验3

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

@Test
public void firstLevelCacheOfScope() {
    SqlSession sqlSession2 = sqlSessionFactory.openSession(true);
    UserMapper userMapper2 = sqlSession2.getMapper(UserMapper.class);

    System.out.println("userMapper读取数据: " + userMapper.findUserById(1));
    System.out.println("userMapper读取数据: " + userMapper.findUserById(1));

    // 更新用户
    User user = new User();
    user.setId(1);
    user.setUsername("andy");
    System.out.println("userMapper2更新了" + userMapper2.updateUser(user) + "个用户");

    System.out.println("userMapper读取数据: " + userMapper.findUserById(1));
    System.out.println("userMapper2读取数据: " + userMapper2.findUserById(1));
}

控制台日志输出：

sqlSession2 更新了 id 为 1 的用户的姓名，从 riemann 改为了 andy，但 session1 之后的查询中，id 为 1 的学生的名字还是 riemann，出现了脏数据，也证明了之前的设想，一级缓存只在数据库会话内部共享。

四、一级缓存工作流程以及源码分析

4.1 工作流程

我们来看下一级缓存的时序图：

4.2 源码分析

看完上面的整体时序流程，我相信大家基本框架了解了，接下来针对这个框架再进行源码细化走读。

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

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

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

在一级缓存的源码分析中，主要学习 BaseExecutor 的内部实现。

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

protected abstract int doUpdate(MappedStatement var1, Object var2) throws SQLException;
protected abstract List<BatchResult> doFlushStatements(boolean var1) throws SQLException;
protected abstract <E> List<E> doQuery(MappedStatement var1, Object var2, RowBounds var3, ResultHandler var4, BoundSql var5) throws SQLException;
protected abstract <E> Cursor<E> doQueryCursor(MappedStatement var1, Object var2, RowBounds var3, BoundSql var4) throws SQLException;

在上文有提到对 Local Cache 的查询和写入是在 Executor 内部完成的。在阅读 BaseExecutor 的代码后发现 Local Cache 是 BaseExecutor 内部的一个成员变量，如下代码所示。

public abstract class BaseExecutor implements Executor {
	...
	protected ConcurrentLinkedQueue<BaseExecutor.DeferredLoad> deferredLoads;
    protected PerpetualCache localCache;
    protected PerpetualCache localOutputParameterCache;
    ...
}

Cache： MyBatis 中的 Cache 接口，提供了和缓存相关的最基本的操作，如下图所示：

有若干个实现类，使用装饰器模式互相组装，提供丰富的操控缓存的能力，部分实现类如下图所示：

BaseExecutor 成员变量之一的 PerpetualCache，是对 Cache 接口最基本的实现，其实现非常简单，内部持有 HashMap，对一级缓存的操作实则是对 HashMap 的操作。如下代码所示：

public class PerpetualCache implements Cache {
    private final String id;
    private Map<Object, Object> cache = new HashMap();
	...
}

调研了一下，画出工作流程图：

跟踪到 PerpetualCache 中的 clear() 方法。

public class PerpetualCache implements Cache {
	...
    private Map<Object, Object> cache = new HashMap();

    public void clear() {
        this.cache.clear();
    }
    ...
}

也就是说一级缓存的底层数据结构就是 HashMap。所以说 cache.clear() 其实就是 map.clear()，也就是说，缓存其实是本地存放的一个 map 对象，每一个 SqlSession 都会存放一个 map 对象的引用。

那么这个 cache 是何时创建的呢?

根据上面我们画的工作流程，明显在 Executor 执行器，执行器用来执行 sql 请求，而且清除缓存的方法也在 Executor 中执行，去查看源码，果真在里面。

创建缓存 key 会经过一系列的 update 方法，update 方法由一个 cacheKey 这个对象来执行的。这个 update 方法最终由 updateList 的 list 来把六个值存进去，对照上面的代码，你应该能理解下面六个值分别是啥了吧。

这里需要关注最后一个值 this.configuration.getEnvironment().getId()，这其实就是定义在 mybatis-config.xml 中的标签。如下：

那么问题来了，创建缓存了，那具体在哪里用呢？我们一级缓存探究后，我们发现一级缓存更多的用于查询操作。我们跟踪到 query 方法：

如果查不到的话，就从数据库查，在 queryFromDatabase 中，会对 localcache 进行写入。

在 query 方法执行的最后，会判断一级缓存级别是否是 STATEMENT 级别，如果是的话，就清空缓存，这也就是 STATEMENT 级别的一级缓存无法共享 localCache 的原因。代码如下所示：

if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
	clearLocalCache();
}

在源码分析的最后，我们确认一下，如果是 insert/delete/update 方法，缓存就会刷新的原因。

SqlSession 的 insert 方法和 delete 方法，都会统一走 update 的流程，代码如下所示：

@Override
public int insert(String statement, Object parameter) {
    return update(statement, parameter);
}

@Override
public int delete(String statement) {
    return update(statement, null);
}

update 方法也是委托给了 Executor 执行。BaseExecutor 的执行方法如下所示：

@Override
public int update(MappedStatement ms, Object parameter) throws SQLException {
    ErrorContext.instance().resource(ms.getResource()).activity("executing an update").object(ms.getId());
    if (closed) {
      throw new ExecutorException("Executor was closed.");
    }
    clearLocalCache();
    return doUpdate(ms, parameter);
}

每次执行 update 前都会清空 localCache。

至此，一级缓存的工作流程讲解以及源码分析完毕。

五、一级缓存小结

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

六、二级缓存

在上文中提到的一级缓存中，其最大的共享范围就是一个 SqlSession 内部，如果多个 SqlSession 之间需要共享缓存，则需要使用到二级缓存。开启二级缓存后，会使用 CachingExecutor 装饰 Executor，进入一级缓存的查询流程前，先在 CachingExecutor 进行二级缓存的查询，具体的工作流程如下所示。

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

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

MyBatis 是默认关闭二级缓存的，因为对于增删改操作频繁的话，那么二级缓存形同虚设，每次都会被清空缓存。

6.1 二级缓存配置

和一级缓存默认开启不一样，二级缓存需要我们手动开启。

6.1.1 首先在全局配置文件 SqlMapConfig.xml 文件中加入如下代码：

<!--开启二级缓存-->
<settings>
    <setting name="cacheEnabled" value="true"/>
</settings>

6.1.2 其次在 UserMapper.xml 文件中开启二级缓存

mapper 代理模式：

<!--开启二级缓存-->
<cache />

注解开发模式：

@CacheNamespace(implementation = PerpetualCache.class) // 开启二级缓存
public interface UserMapper {
}

mapper 代理模式开启的二级缓存是一个空标签，其实这里可以配置，PerpetualCache 这个类是 mybatis 默认实现的二级缓存功能的类，我们不写 type ，用 @CacheNamespace 直接默认 PerpetualCache 这个类，也可以去实现 Cache 接口来自定义缓存。

6.2 实体类实现 Serializable 序列化接口

开启二级缓存后，还需要将要缓存的实体类去实现 Serializable 序列化接口，为了将缓存数据取出执行反序列化操作，因为二级缓存数据存储介质多种多样，不一定只存在内存中，有可能存在硬盘中，如果我们再取出这个缓存的话，就需要反序列化。所以 MyBatis 的所有 pojo 类都要去实现 Serializable 序列化接口。

七、二级缓存实验

7.1 实验1

测试二级缓存与 SqlSession 无关

@Test
public void secondLevelCache() {
    SqlSession sqlSession1 = sqlSessionFactory.openSession();
    SqlSession sqlSession2 = sqlSessionFactory.openSession();

    UserMapper userMapper1 = sqlSession1.getMapper(UserMapper.class);
    UserMapper userMapper2 = sqlSession2.getMapper(UserMapper.class);

    // 第一次查询id为1的用户
    User user1 = userMapper1.findUserById(1);
    sqlSession1.close(); // 清空一级缓存
    System.out.println(user1);

    // 第二次查询id为1的用户
    User user2 = userMapper2.findUserById(1);
    System.out.println(user2);

    System.out.println(user1 == user2);
}

控制台日志输出：

第一次查询时，将查询结果放入缓存中，第二次查询，即使 sqlSession1.close(); 清空了一级缓存，第二次查询依然不发出 sql 语句。

这里的你可能有个疑问，这里不是二级缓存了吗？怎么 user1 与 user2 不相等？

这是因为二级缓存的是数据，并不是对象。而 user1 与 user2 是两个对象，所以地址值当然也不想等。

7.2 实验2

测试执行 commit()，二级缓存数据清空。

@Test
public void secondLevelCacheOfUpdate() {
    SqlSession sqlSession1 = sqlSessionFactory.openSession();
    SqlSession sqlSession2 = sqlSessionFactory.openSession();
    SqlSession sqlSession3 = sqlSessionFactory.openSession();

    UserMapper userMapper1 = sqlSession1.getMapper(UserMapper.class);
    UserMapper userMapper2 = sqlSession2.getMapper(UserMapper.class);
    UserMapper userMapper3 = sqlSession3.getMapper(UserMapper.class);

    // 第一次查询id为1的用户
    User user1 = userMapper1.findUserById(1);
    sqlSession1.close(); // 清空一级缓存

    User user = new User();
    user.setId(3);
    user.setUsername("edgar");
    userMapper3.updateUser(user);
    sqlSession3.commit();

    // 第二次查询id为1的用户
    User user2 = userMapper2.findUserById(1);
    sqlSession2.close();

    System.out.println(user1 == user2);
}

控制台日志输出：

我们可以看到，在 sqlSession3 更新数据库，并提交事务后，sqlsession2 的 UserMapper namespace 下的查询走了数据库，没有走 Cache。

7.3 实验3

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

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

为了解决实验3的问题呢，可以使用 Cache ref，让 OrderMapper 引用 UserMapper 命名空间，这样两个映射文件对应的 SQL 操作都使用的是同一块缓存了。

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

这里老周就不代码演示了，有没有感觉很鸡肋，而且不熟用二级缓存的话，像这种多表查询的，很容易造成脏读数据不一致，这在线上的话是致命的。

7.4 useCache 和 flushCache

useCache 是用来设置是否禁用二级缓存的，在 statement 中设置 useCache=“false”，可以禁用当前 select 语句的二级缓存，即每次都会去数据库查询。如下：

<select id="findAll" resultMap="userMap" useCache="false">
    select * from user u left join orders o on u.id = o.uid
</select>

设置 statement 配置中的 flushCache=“true” 属性，默认情况下为 true，即刷新缓存，一般执行完 commit 操作都需要刷新缓存，flushCache=“true” 表示刷新缓存，这样可以避免增删改操作而导致的脏读问题。默认不要配置，如下：

<select id="findAll" resultMap="userMap" useCache="false" flushCache="true">
    select * from user u left join orders o on u.id = o.uid
</select>

八、二级缓存源码分析

MyBatis 二级缓存的工作流程和前文提到的一级缓存类似，只是在一级缓存处理前，用 CachingExecutor 装饰了 BaseExecutor 的子类，在委托具体职责给 delegate 之前，实现了二级缓存的查询和写入功能，具体类关系图如下图所示。

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

public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
    Cache cache = ms.getCache(); // 首先会从 MappedStatement 中获得在配置初始化时赋予的 Cache
    if (cache != null) {
        this.flushCacheIfRequired(ms);
        if (ms.isUseCache() && resultHandler == null) {
            this.ensureNoOutParams(ms, parameterObject, boundSql);
            List<E> list = (List)this.tcm.getObject(cache, key);
            if (list == null) {
                list = this.delegate.query(ms, parameterObject, rowBounds, resultHandler, key《深入理解mybatis原理6》 MyBatis的一级缓存实现详解 及使用注意事项
 《深入理解mybatis原理4》 MyBatis缓存机制的设计与实现
 MyBatis缓存机制
 [mybatis]缓存机制介绍_一级缓存&二级缓存
 MyBatis的缓存机制
 MyBatis加强~缓存机制(一级缓存二级缓存第三方缓存技术redisehcache)