从根上理解Mybatis的一级、二级缓存（一）

缺乏、安全感 2023-09-23 14:12 90阅读 0赞

### 1. 写在前头 ###

大家好，我是**方圆**，最近在读Mybatis的源码，之前面试被问过一、二级缓存相关的问题，想着就把这写成一篇博客记录下来吧，供回忆，供参考

这篇帖子主要讲**一级缓存，它的作用范围和源码分析**

（本来想把一二级缓存合在一起，发现太长了）

### 2. 准备工作 ###

#### 2.1 两个要用的实体类 ####

public class Department {
    
        public Department(String id) {
            this.id = id;
        }
    
        private String id;
    
        /**
         * 部门名称
         */
        private String name;
    
        /**
         * 部门电话
         */
        private String tel;
    
        /**
         * 部门成员
         */
        private Set<User> users;
    }
    复制代码

public class User {
    
        private String id;
    
        private String name;
    
        private Integer age;
    
        private LocalDateTime birthday;
    
        private Department department;
    }
    复制代码

#### 2.2 Mapper.xml文件中要用的SQL ####

*  DepartmentMapper.xml，两条SQL，一条根据ID匹配，一条清除缓存，注意**fulshCache**标签

<select id="findById" resultType="Department">
            select * from department
            where id = #{id}
        </select>
    
        
        <select id="cleanCathe" resultType="int" flushCache="true">
            select count(department.id) from department;
        </select>
    复制代码

*  UserMapper.xml，简简单单的查询所有的user

<select id="findAll" resultMap="userMap">
            select u.*, td.id, td.name as department_name
            from user u
            left join department td
            on u.department_id = td.id
        </select>
    复制代码

### 3. 一级缓存 ###

*  一级缓存是基于SQLSession的，同一条SQL执行第二遍的时候会直接从缓存中取，测试下看看

public static void main(String[] args) throws IOException {
            InputStream xml = Resources.getResourceAsStream("mybatis-config.xml");
            SqlSessionFactoryBuilder sqlSessionFactoryBuilder = new SqlSessionFactoryBuilder();
            // 开启二级缓存需要在同一个SqlSessionFactory下，二级缓存存在于 SqlSessionFactory 生命周期，如此才能命中二级缓存
            SqlSessionFactory sqlSessionFactory = sqlSessionFactoryBuilder.build(xml);
    
            SqlSession sqlSession = sqlSessionFactory.openSession();
            DepartmentMapper departmentMapper = sqlSession.getMapper(DepartmentMapper.class);
            System.out.println("----------department第一次查询 ↓------------");
            departmentMapper.findById("18ec781fbefd727923b0d35740b177ab");
            System.out.println("----------department一级缓存生效，控制台看不见SQL ↓------------");
            departmentMapper.findById("18ec781fbefd727923b0d35740b177ab");
    
        }
    复制代码

*  可以发现控制台在第二次查询的时候，一级缓存生效，没有出现SQL
    
    ![format_png][]
 *  我们清空下一级缓存再试试

> xml文件中**flushCache标签** 会清除所有namespace 的一级缓存 和 当前namespace 的二级缓存均会清除 默认是false

*  控制台日志很清晰，清除缓存后又重新查了一遍
    
    ![format_png 1][]

#### 3.1 一级缓存失效的情况 ####

3.1.1 不同SQLSession下同一条SQL一级缓存不生效

*  创建一个新的sqlSession1执行相同的SQL，发现不同SQLSession下不共享一级缓存

SqlSession sqlSession = sqlSessionFactory.openSession();
            SqlSession sqlSession1 = sqlSessionFactory.openSession();
            DepartmentMapper departmentMapper = sqlSession.getMapper(DepartmentMapper.class);
            DepartmentMapper departmentMapper1 = sqlSession1.getMapper(DepartmentMapper.class);
            System.out.println("----------department第一次查询 ↓------------");
            departmentMapper.findById("18ec781fbefd727923b0d35740b177ab");
            System.out.println("----------sqlSession1下department执行相同的SQL，控制台出现SQL ↓------------");
            departmentMapper1.findById("18ec781fbefd727923b0d35740b177ab");
    复制代码

![format_png 2][]

3.1.2 两次相同查询SQL间有Insert、Delete、Update语句出现

*  因为Insert、Delete、Update的**flushCache标签 默认为 true** ，执行它们时，必然会导致一级缓存的清空，从而引发之前的一级缓存不能继续使用的情况（这跟我们上边清除一级缓存的SQL例子一致）

3.1.3 调用sqlSession.clearCache()方法

*  这个方\*\*\*将一级缓存清除，效果是一样的

#### 3.2 一级缓存源码：缓存被保存在了哪里？ ####

3.2.1 该如何找打它的位置

*  Mybatis顶层的缓存是**接口Cache**，查看它的实现类
    
    ![format_png 3][]
    
    发现大部分实现类的包都是**decorators(装饰器)**，只有PerpetualCache是Impl，所以我们确定的说，它就是我们要找的缓存实现类，点进去看看，发现只是组合了HashMap...

public class PerpetualCache implements Cache {
    
      private final String id;
    
      // 看这里
      private final Map<Object, Object> cache = new HashMap<>();
    
      ...
    }
    复制代码

*  那这个PerpetualCache被放在哪里呢？ 我们想到了一级缓存是**基于SQLSession**，那我们去DefaultSQLSession，它默认的实现类里看看

public class DefaultSqlSession implements SqlSession {
    
      private final Configuration configuration;
      private final Executor executor;
    
      private final boolean autoCommit;
      private boolean dirty;
      private List<Cursor<?>> cursorList;
    
      ...
    }
    复制代码

*  发现并没有哇！DefaultSqlSession还有两个东西，Configuration是全局的配置，这里边儿应该是没有，那我们只能**再去Executor里**看看了
    
    ![format_png 4][]
 *  发现它是个接口，实现类有一个**CachingExecutor**！立马点进去！

public class CachingExecutor implements Executor {
    
      private final Executor delegate;
      private final TransactionalCacheManager tcm = new TransactionalCacheManager();
    
      ...
    }
    复制代码

*  发现还是没有？？？
    
    ![format_png 5][]
 *  但是Executor还有一个**BaseExecutor**，最后一家了，再在没有关了Idea睡觉了

public abstract class BaseExecutor implements Executor {
    
      private static final Log log = LogFactory.getLog(BaseExecutor.class);
    
      protected Transaction transaction;
      protected Executor wrapper;
    
      protected ConcurrentLinkedQueue<DeferredLoad> deferredLoads;
      // o??!! 不就在这呢嘛，小老弟
      protected PerpetualCache localCache;
      protected PerpetualCache localOutputParameterCache;
      protected Configuration configuration;
    
      ...
    }
    复制代码

*  它来了，原来在这藏着呢呀，行了，这把知道它的位置了，我们直接看SQL执行的时候是怎么存的，怎么取的吧！

3.2.2 query()方法

*  BaseExecutor的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.");
        }
        // 是否需要清除一级缓存
        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();
          }
          deferredLoads.clear();
          // 全局localCacheScope设置为statement，则清空一级缓存
          if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
            clearLocalCache();
          }
        }
        return list;
      }
    复制代码

3.2.3 写两条Sql，Debug看一下

System.out.println("----------department第一次查询 ↓------------");
            departmentMapper.findById("18ec781fbefd727923b0d35740b177ab");
            System.out.println("----------department一级缓存生效，控制台看不见SQL ↓------------");
            departmentMapper.findById("18ec781fbefd727923b0d35740b177ab");
    复制代码

*  哎，很对，第一次果然去数据库里查了
    
    ![format_png 6][]
 *  哎，更对了，第二次果然取得缓存
    
    ![format_png 7][]
 *  好嘛，真简单呀

#### 3.3 注意：一级缓存的查询结果被修改后，竟然... ####

*  竟然会对之后取出的一级缓存有影响，测试下看看

System.out.println("----------department第一次查询 ↓------------");
            Department department = departmentMapper.findById("18ec781fbefd727923b0d35740b177ab");
            System.out.println(department);
            department.setName("方圆把名字改了");
    
            System.out.println("----------department一级缓存生效，控制台看不见SQL ↓------------");
            System.out.println(departmentMapper.findById("18ec781fbefd727923b0d35740b177ab"));
    复制代码

*  第一次查询结果name为null，之后我们修改它的name，第二次查询取缓存的结果**是更改name结果之后的**
    
    ![format_png 8][]
 *  这是因为**存放的数据其实是对象的引用**，导致第二次从一级缓存中查询到的数据，就是我们刚刚改过的数据

#### 3.4 文末 ####

一级缓存到这里就要跟大家说再见了，做个总结吧

*  一级缓存是基于SQLSession的，不同SQLSession间不共享一级缓存
 *  执行Insert、Delete、Update语句会使一级缓存失效
 *  一级缓存在底层被存放在了BaseExecutor中，本质上就是个HashMap
 *  一级缓存存放的数据其实是对象的引用，若对它进行修改，则之后取出的缓存为修改后的数据

### 巨人的肩膀 ###

*  [为什么要实现序列化：MyBatis的一级缓存、二级缓存演示以及讲解，序列化异常的处理][MyBatis]
 *  [为什么MyBatis二级缓存Cache Hit Ratio始终等于0：二级缓存的生命周期在同一个SqlSessionFactory中][MyBatis_Cache Hit Ratio_0_SqlSessionFactory]
 *  《玩转 MyBatis：深度解析与定制》第十四章
 *  [原文收录：GitHub-Java-Enthusiasm][GitHub-Java-Enthusiasm]

[format_png]: https://img-blog.csdnimg.cn/img_convert/b357d8d200b71f81a9f99984fc1678eb.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/78779c85b2538451444aeae187792524.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/c74d1c79fa1fc98b9effeb7d22383583.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/a3fb12ff04dec2cdf1fe0039b170835b.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/38a84c90dffeea84427f3b3251148c66.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/691d648a53bf1bf8a8ec4eab53c7f2ad.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/16caca72d05bf61f56cf53c93423da37.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/9015ef51e1bd2d454528c318ec3578f1.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/638b8ec9345589ef7a74a8eec5314ebf.webp?x-oss-process=image/format,png
[MyBatis]: https://link.juejin.cn?target=https%3A%2F%2Fwww.cnblogs.com%2Fncl-960301-success%2Fp%2F10976255.html
[MyBatis_Cache Hit Ratio_0_SqlSessionFactory]: https://link.juejin.cn?target=https%3A%2F%2Fwww.it610.com%2Farticle%2F1304085366302609408.htm
[GitHub-Java-Enthusiasm]: https://link.juejin.cn?target=https%3A%2F%2Fgithub.com%2FFangYuan33%2FJava-Enthusiasm%2Fblob%2Fmain%2Fsrc%2Fmain%2Fjava%2Farticle2021%2Fmonth12%2F%25E4%25BB%258E%25E6%25A0%25B9%25E4%25B8%258A%25E7%2590%2586%25E8%25A7%25A3Mybatis%25E7%259A%2584%25E4%25B8%2580%25E7%25BA%25A7%25E3%2580%2581%25E4%25BA%258C%25E7%25BA%25A7%25E7%25BC%2593%25E5%25AD%2598%25EF%25BC%2588%25E4%25B8%2580%25EF%25BC%2589.md