MyBatis一级缓存带来的麻烦

原问题

MyBatis 一级缓存与 SpringFramework 的声明式事务有冲突吗?在 Service 中开启事务,连续查询两次同样的数据,结果两次查询的结果不一致。

—— 使用 Mapper 的 selectById 查出来实体,然后修改实体的属性值,然后再 selectById 一下查出来实体,对比一下之前查出来的,发现查出来的是刚才修改过的实体,不是从数据库查出来的。

—— 如果不开启事务,则两次请求查询的结果是相同的,控制台打印了两次 SQL 。

初步分析

讲道理,看到这个问题,我一下子就猜到是 MyBatis 一级缓存重复读取的问题了。

MyBatis 的一级缓存默认开启,属于 SqlSession 作用范围。在事务开启的期间,同样的数据库查询请求只会查询一次数据库,之后重复查询会从一级缓存中获取。当不开启事务时,同样的多次数据库查询都会发送数据库请求。

上面的都属于基础知识了,不多解释。重点是,他修改的实体是 直接从 MyBatis 的一级缓存中查询出来的 。咱都知道,查询出来的这些实体肯定属于对象,拿到的是对象的引用,咱在 Service 里修改了,一级缓存中相应的也就会被影响。由此可见,这个问题的核心原因也就很容易找到了。

问题复现

为了展示这个问题,咱还是简单复现一下场景吧。

工程搭建

咱使用 SpringBoot + mybatis-spring-boot-starter 快速构建出工程,此处 SpringBoot 版本为 2.2.8 , mybatis-spring-boot-starter 的版本为 2.1.2 。

pom

核心的 pom 依赖有 3 个:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>2.1.2</version>
</dependency>

<dependency>
    <groupId>com.h2database</groupId>
    <artifactId>h2</artifactId>
    <version>1.4.199</version>
</dependency>
复制代码
数据库配置

数据库咱们依然选用 h2 作为快速问题复现的数据库,只需要在 application.properties 中添加如下配置,即可初始化一个 h2 数据库。顺便的,咱把 MyBatis 的配置也简单配置好:

spring.datasource.driver-class-name=org.h2.Driver
spring.datasource.url=jdbc:h2:mem:mybatis-transaction-cache
spring.datasource.username=sa
spring.datasource.password=sa
spring.datasource.platform=h2

spring.datasource.schema=classpath:sql/schema.sql
spring.datasource.data=classpath:sql/data.sql

spring.h2.console.settings.web-allow-others=true
spring.h2.console.path=/h2
spring.h2.console.enabled=true

mybatis.type-aliases-package=com.linkedbear.demo.entity
mybatis.mapper-locations=classpath:mapper/*.xml
复制代码
初始化数据库

上面咱使用了 datasource 的 schema 和 data 初始化数据库,那自然的就应该有这两个 .sql 文件。

schema.sql

create table if not exists sys_department (
   id varchar(32) not null primary key,
   name varchar(32) not null
);
复制代码

data.sql

insert into sys_department (id, name) values ('idaaa', 'testaaa');
insert into sys_department (id, name) values ('idbbb', 'testbbb');
insert into sys_department (id, name) values ('idccc', 'testccc');
insert into sys_department (id, name) values ('idddd', 'testddd');
复制代码

编写测试代码

咱使用一个最简单的单表模型,快速复现场景。

entity

新建一个 Department 类,并声明 id 和 name 属性:

public class Department {
    
    private String id;
    private String name;
    
    // getter setter toString ......
}
复制代码
mapper

MyBatis 的接口动态代理方式可以快速声明查询的 statement ,咱只需要声明一个 findById 即可:

@Mapper
public interface DepartmentMapper {
    Department findById(String id);
}
复制代码
mapper.xml

对应的,接口需要 xml 作为照应:(此处并没有使用注解式 Mapper )

<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE mapper
        PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN"
        "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.linkedbear.demo.mapper.DepartmentMapper">
    <select id="findById" parameterType="string" resultType="department">
        select * from sys_department where id = #{id}
    </select>
</mapper>
复制代码
service

Service 中注入 Mapper ,并编写一个需要事务的 update 方法,模拟更新动作:

@Service
public class DepartmentService {
    
    @Autowired
    DepartmentMapper departmentMapper;
    
    @Transactional(rollbackFor = Exception.class)
    public Department update(Department department) {
        Department temp = departmentMapper.findById(department.getId());
        temp.setName(department.getName());
        Department temp2 = departmentMapper.findById(department.getId());
        System.out.println("两次查询的结果是否是同一个对象:" + temp == temp2);
        return temp;
    }
}
复制代码
controller

Controller 中注入 Service ,并调用 Service 的 update 方法来触发测试:

@RestController
public class DepartmentController {
    
    @Autowired
    DepartmentService departmentService;
    
    @GetMapping("/department/{id}")
    public Department findById(@PathVariable("id") String id) {
        Department department = new Department();
        department.setId(id);
        department.setName(UUID.randomUUID().toString().replaceAll("-", ""));
        return departmentService.update(department);
    }
}
复制代码
主启动类

主启动类中不需要什么特别的内容,只需要记得开启事务就好:

@EnableTransactionManagement
@SpringBootApplication
public class MyBatisTransactionCacheApplication {
    
    public static void main(String[] args) {
        SpringApplication.run(MyBatisTransactionCacheApplication.class, args);
    }
}
复制代码

运行测试

以 Debug 方式运行 SpringBoot 的主启动类,在浏览器中输入 http://localhost:8080/h2 输入刚才在 application.properties 中声明的配置,即可打开 h2 数据库的管理台。

执行 SELECT * FROM SYS_DEPARTMENT ,可以发现数据已经成功初始化了:

image
下面测试效果,在浏览器中输入 http://localhost:8080/department/idaaa ,控制台中打印的结果为 true ,证明 MyBatis 的一级缓存生效,两次查询最终得到的实体类对象一致。

解决方案

对于这个问题的解决方案,其实说白了,就是关闭一级缓存。最常见的几种方案列举一下:

  • 全局关闭:设置 mybatis.configuration.local-cache-scope=statement
  • 指定 mapper 关闭:在 mapper.xml 的指定 statement 上标注 flushCache="true"
  • 另类的办法:在 statement 的 SQL 上添加一串随机数(过于非主流。。。)

select * from sys_department where #{random} = #{random}

原理扩展

其实到这里,问题就已经解决了,但先不要着急,思考一个问题:为什么声明了 local-cache-scopestatement ,或者mapper 的 statement 标签中设置 flushCache=true ,一级缓存就被禁用了呢?下面咱来了解下这背后的原理。

一级缓存失效的原理

DepartmentService 中,执行 mapper.findById 的动作,最终会进入到 DefaultSqlSessionselectOne 中:

public <T> T selectOne(String statement) {
    return this.selectOne(statement, null);
}

@Override
public <T> T selectOne(String statement, Object parameter) {
    // Popular vote was to return null on 0 results and throw exception on too many.
    List<T> list = this.selectList(statement, parameter);
    if (list.size() == 1) {
        return list.get(0);
    } else if (list.size() > 1) {
        throw new TooManyResultsException("Expected one result (or null) to be returned by selectOne(), but found: " + list.size());
    } else {
        return null;
    }
}
复制代码

可见 selectOne 的底层是调用的 selectList ,之后 get(0) 取出第一条数据返回。

selectList 的底层会有两个步骤: 获取 MappedStatement → 执行查询 ,如下代码中的 try 部分:

public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
    try {
        MappedStatement ms = configuration.getMappedStatement(statement);
        return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
    } catch (Exception e) {
        throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
    } finally {
        ErrorContext.instance().reset();
    }
}
复制代码

执行 query 方法,来到 BaseExecutor 中,它会执行三个步骤: 获取预编译的 SQL → 创建缓存键 → 真正查询

public <E> List<E> query(MappedStatement ms, Object parameter, 
                         RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
    BoundSql boundSql = ms.getBoundSql(parameter);
    CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);
    return query(ms, parameter, rowBounds, resultHandler, key, boundSql);
}
复制代码

这里面的缓存键是有一定设计的,它的结构可以简单的看成 “ statementId + SQL + 参数 ” 的形式,根据这三个要素,就可以唯一的确定出一个查询结果。

到了这里面的 query 方法,它就带着这个缓存键,执行真正的查询动作了,如下面的这段长源码:(注意看源码中的注释)

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());
    if (closed) {
        throw new ExecutorException("Executor was closed.");
    }
    // 如果statement有设置flushCache="true",则查询之前先清理一级缓存
    if (queryStack == 0 && ms.isFlushCacheRequired()) {
        clearLocalCache();
    }
    List<E> list;
    try {
        queryStack++;
        // 先检查一级缓存
        list = resultHandler == null ? (List<E>) localCache.getObject(key) : null;
        if (list != null) {
            // 如果一级缓存中有,则直接取出
            handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
        } else {
            // 一级缓存没有,则查询数据库
            list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
        }
    } finally {
        queryStack--;
    }
    if (queryStack == 0) {
        for (DeferredLoad deferredLoad : deferredLoads) {
            deferredLoad.load();
        }
        // issue #601
        deferredLoads.clear();
        // 如果全局配置中有设置local-cache-scope=statement,则清除一级缓存
        if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
            // issue #482
            clearLocalCache();
        }
    }
    return list;
}
复制代码

上面的注释中,可以发现,只要上面的三个解决方案,任选一个配置,则一级缓存就会失效,分别分析下:

  • 全局设置 local-cache-scope=statement ,则查询之后即便放入了一级缓存,但存放完立马就给清了,下一次还是要查数据库;
  • statement 设置 flushCache="true" ,则查询之前先清空一级缓存,还是得查数据库;
  • 设置随机数,如果随机数的上限足够大,那随机到相同数的概率就足够低,也能类似的看成不同的数据库请求,那缓存的 key 都不一样,自然就不会匹配到缓存。

本文涉及到的所有源码可以从 GitHub 中找到:github.com/LinkedBear/…


作者:LinkedBear
原文:https://juejin.im/post/6844904201244377095