AI专业者开发社区 1 号成员
  •  0 回帖  •  0 浏览  •  4 个月前
 

【MyBatis源码解析】MyBatis一二级缓存

MyBatis 缓存

我们知道，频繁的数据库操作是非常耗费性能的（主要是因为对于 DB 而言，数据是持久化在磁盘中的，因此查询操作需要通过 IO，IO 操作速度相比内存操作速度慢了好几个量级），尤其是对于一些相同的查询语句，完全可以把查询结果存储起来，下次查询同样的内容的时候直接从内存中获取数据即可，这样在某些场景下可以大大提升查询效率。

MyBatis 的缓存分为两种：

  1. 一级缓存，一级缓存是SqlSession 级别的缓存，对于相同的查询，会从缓存中返回结果而不是查询数据库
  2. 二级缓存，二级缓存是Mapper 级别的缓存，定义在 Mapper 文件的 <cache> 标签中并需要开启此缓存，多个 Mapper 文件可以共用一个缓存，依赖 <cache-ref> 标签配置

下面来详细看一下 MyBatis 的一二级缓存。

 

MyBatis 一级缓存工作流程

接着看一下 MyBatis 一级缓存工作流程。前面说了，MyBatis 的一级缓存是 SqlSession 级别的缓存，当 openSession() 的方法运行完毕或者主动调用了 SqlSession 的 close 方法，SqlSession 就被回收了，一级缓存与此同时也一起被回收掉了。前面的文章有说过，在 MyBatis 中，无论 selectOne 还是 selectList 方法，最终都被转换为了 selectList 方法来执行，那么看一下 SqlSession 的 selectList 方法的实现：

 1 public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
 2     try {
 3       MappedStatement ms = configuration.getMappedStatement(statement);
 4       return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
 5     } catch (Exception e) {
 6       throw ExceptionFactory.wrapException("Error querying database.  Cause:" + e, e);
 7     } finally {
 8       ErrorContext.instance().reset();
 9     }
10 }

继续跟踪第 4 行的代码，到 BaseExeccutor 的 query 方法：

1 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
2     BoundSql boundSql = ms.getBoundSql(parameter);
3     CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);
4     return query(ms, parameter, rowBounds, resultHandler, key, boundSql);
5 }

第 3 行构建缓存条件 CacheKey，这里涉及到怎么样条件算是和上一次查询是同一个条件的一个问题，因为同一个条件就可以返回上一次的结果回去，这部分代码留在下一部分分析。

接着看第 4 行的 query 方法的实现，代码位于 CachingExecutor 中：

 1 public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
 2       throws SQLException {
 3     Cache cache = ms.getCache();
 4     if (cache != null) {
 5       flushCacheIfRequired(ms);
 6       if (ms.isUseCache() && resultHandler == null) {
 7         ensureNoOutParams(ms, parameterObject, boundSql);
 8         @SuppressWarnings("unchecked")
 9         List<E> list = (List<E>)tcm.getObject(cache, key);
10         if (list == null) {
11           list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
12           tcm.putObject(cache, key, list); // issue #578 and #116
13         }
14         return list;
15       }
16     }
17     return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
18 }

第 3 行 ~ 第 16 行的代码先不管，继续跟第 17 行的 query 方法，代码位于 BaseExecutor 中：

 1 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
 2     ErrorContext.instance().resource(ms.getResource()).activity("executing a query").object(ms.getId());
 3     if (closed) {
 4       throw new ExecutorException("Executor was closed.");
 5     }
 6     if (queryStack == 0 && ms.isFlushCacheRequired()) {
 7       clearLocalCache();
 8     }
 9     List<E> list;
10     try {
11       queryStack++;
12       list = resultHandler == null ? (List<E>) localCache.getObject(key) : null;
13       if (list != null) {
14         handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
15       } else {
16         list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
17       }
18     } finally {
19       queryStack--;
20     }
21     ...
22 }

看 12 行，query 的时候会尝试从 localCache 中去获取查询结果，如果获取到的查询结果为 null，那么执行 16 行的代码从 DB 中捞数据，捞完之后会把 CacheKey 作为 key，把查询结果作为 value 放到 localCache 中。

MyBatis 一级缓存存储流程看完了，接着我们从这段代码中可以得到三个结论：

  1. MyBatis 的一级缓存是 SqlSession 级别的，但是它并不定义在 SqlSessio 接口的实现类 DefaultSqlSession 中，而是定义在 DefaultSqlSession 的成员变量 Executor 中，Executor 是在 openSession 的时候被实例化出来的，它的默认实现为 SimpleExecutor
  2. MyBatis 中的一级缓存，与有没有配置无关，只要 SqlSession 存在，MyBastis 一级缓存就存在，localCache 的类型是 PerpetualCache，它其实很简单，一个 id 属性 + 一个 HashMap 属性而已，id 是一个名为 "localCache" 的字符串，HashMap 用于存储数据，Key 为 CacheKey，Value 为查询结果
  3. MyBatis 的一级缓存查询的时候默认都是会先尝试从一级缓存中获取数据的，但是我们看第 6 行的代码做了一个判断，ms.isFlushCacheRequired()，即想每次查询都走 DB 也行，将 <select> 标签中的 flushCache 属性设置为 true 即可，这意味着每次查询的时候都会清理一遍 PerpetualCache，PerpetualCache 中没数据，自然只能走 DB

从 MyBatis 一级缓存来看，它以单纯的 HashMap 做缓存，没有容量控制，而一次 SqlSession 中通常来说并不会有大量的查询操作，因此只适用于一次 SqlSession，如果用到二级缓存的 Mapper 级别的场景，有可能缓存数据不断碰到而导致内存溢出。

还有一点，差点忘了写了，<insert>、<delete>、<update> 最终都会转换为 update 方法，看一下 BaseExecutor 的 update 方法：

1 public int update(MappedStatement ms, Object parameter) throws SQLException {
2     ErrorContext.instance().resource(ms.getResource()).activity("executing an update").object(ms.getId());
3     if (closed) {
4       throw new ExecutorException("Executor was closed.");
5     }
6     clearLocalCache();
7     return doUpdate(ms, parameter);
8 }

第 6 行 clearLocalCache() 方法，这意味着所有的增、删、改都会清空本地缓存，这和是否配置了 flushCache=true 是无关的。

这很好理解，因为增、删、改这三种操作都可能会导致查询出来的结果并不是原来的结果，如果增、删、改不清理缓存，那么可能导致读取出来的数据是脏数据。

 

一级缓存的 CacheKey

接着我们看下一个问题：怎么样的查询条件算和上一次查询是一样的查询，从而返回同样的结果回去？这个问题，得从 CacheKey 说起。

我们先看一下 CacheKey 的数据结构：

 1 public class CacheKey implements Cloneable, Serializable {
 2 
 3   private static final long serialVersionUID = 1146682552656046210L;
 4 
 5   public static final CacheKey NULL_CACHE_KEY = new NullCacheKey();
 6 
 7   private static final int DEFAULT_MULTIPLYER = 37;
 8   private static final int DEFAULT_HASHCODE = 17;
 9 
10   private int multiplier;
11   private int hashcode;
12   private long checksum;
13   private int count;
14   private List<Object> updateList;
15   ...
16 }

其中最重要的是第 14 行的 updateList 这个两个属性，为什么这么说，因为 HashMap 的 Key 是 CacheKey，而 HashMap 的 get 方法是先判断 hashCode，在 hashCode 冲突的情况下再进行 equals 判断，因此最终无论如何都会进行一次 equals 的判断，看下 equals 方法的实现：

 1 public boolean equals(Object object) {
 2     if (this == object) {
 3       return true;
 4     }
 5     if (!(object instanceof CacheKey)) {
 6       return false;
 7     }
 8 
 9     final CacheKey cacheKey = (CacheKey) object;
10 
11     if (hashcode != cacheKey.hashcode) {
12       return false;
13     }
14     if (checksum != cacheKey.checksum) {
15       return false;
16     }
17     if (count != cacheKey.count) {
18       return false;
19     }
20 
21     for (int i = 0; i < updateList.size(); i++) {
22       Object thisObject = updateList.get(i);
23       Object thatObject = cacheKey.updateList.get(i);
24       if (thisObject == null) {
25         if (thatObject != null) {
26           return false;
27         }
28       } else {
29         if (!thisObject.equals(thatObject)) {
30           return false;
31         }
32       }
33     }
34     return true;
35 }

看到整个方法的流程都是围绕着 updateList 中的每个属性进行逐一比较，因此再进一步的，我们要看一下 updateList 中到底存储了什么。

关于 updateList 里面存储的数据我们可以看下哪里使用了 updateList 的 add 方法，然后一步一步反推回去即可。updateList 中数据的添加是在 doUpdate 方法中：

 1 private void doUpdate(Object object) {
 2     int baseHashCode = object == null ? 1 : object.hashCode();
 3 
 4     count++;
 5     checksum += baseHashCode;
 6     baseHashCode *= count;
 7 
 8     hashcode = multiplier * hashcode + baseHashCode;
 9 
10     updateList.add(object);
11 }

它的调用方为 update 方法：

 1 public void update(Object object) {
 2     if (object != null && object.getClass().isArray()) {
 3       int length = Array.getLength(object);
 4       for (int i = 0; i < length; i++) {
 5         Object element = Array.get(object, i);
 6         doUpdate(element);
 7       }
 8     } else {
 9       doUpdate(object);
10     }
11 }

这里主要是对输入参数是数组类型进行了一次判断，是数组就遍历逐一做 doUpdate，否则就直接做 doUpdate。再看 update 方法的调用方，其实 update 方法的调用方有挺多处，但是这里我们要看的是 Executor 中的，看一下 BaseExecutor 中的 createCacheKey 方法实现：

 1 public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) {
 2     if (closed) {
 3       throw new ExecutorException("Executor was closed.");
 4     }
 5     CacheKey cacheKey = new CacheKey();
 6     cacheKey.update(ms.getId());
 7     cacheKey.update(rowBounds.getOffset());
 8     cacheKey.update(rowBounds.getLimit());
 9     cacheKey.update(boundSql.getSql());
10     List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
11     TypeHandlerRegistry typeHandlerRegistry = ms.getConfiguration().getTypeHandlerRegistry();
12     // mimic DefaultParameterHandler logic
13     for (ParameterMapping parameterMapping : parameterMappings) {
14       if (parameterMapping.getMode() != ParameterMode.OUT) {
15         Object value;
16         String propertyName = parameterMapping.getProperty();
17         if (boundSql.hasAdditionalParameter(propertyName)) {
18           value = boundSql.getAdditionalParameter(propertyName);
19         } else if (parameterObject == null) {
20           value = null;
21         } else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {
22           value = parameterObject;
23         } else {
24           MetaObject metaObject = configuration.newMetaObject(parameterObject);
25           value = metaObject.getValue(propertyName);
26         }
27         cacheKey.update(value);
28       }
29     }
30     if (configuration.getEnvironment() != null) {
31       // issue #176
32       cacheKey.update(configuration.getEnvironment().getId());
33     }
34     return cacheKey;
35 }

到了这里应当一目了然了，MyBastis 从四组共五个条件判断两次查询是相同的：

  1. <select> 标签所在的 Mapper 的 Namespace+<select> 标签的 id 属性
  2. RowBounds 的 offset 和 limit 属性，RowBounds 是 MyBatis 用于处理分页的一个类，offset 默认为 0，limit 默认为 Integer.MAX_VALUE
  3. <select> 标签中定义的 sql 语句
  4. 输入参数的具体参数值，一个 int 值就 update 一个 int，一个 String 值就 update 一个 String，一个 List 就轮询里面的每个元素进行 update

即只要两次查询满足以上三个条件且没有定义 flushCache="true"，那么第二次查询会直接从 MyBatis 一级缓存 PerpetualCache 中返回数据，而不会走 DB。

 

MyBatis 二级缓存

上面说完了 MyBatis，接着看一下 MyBatis 二级缓存，还是从二级缓存工作流程开始。还是从 DefaultSqlSession 的 selectList 方法进去：

 1 public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
 2     try {
 3       MappedStatement ms = configuration.getMappedStatement(statement);
 4       return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
 5     } catch (Exception e) {
 6       throw ExceptionFactory.wrapException("Error querying database.  Cause:" + e, e);
 7     } finally {
 8       ErrorContext.instance().reset();
 9     }
10 }

执行 query 方法，方法位于 CachingExecutor 中：

1 public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
2     BoundSql boundSql = ms.getBoundSql(parameterObject);
3     CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
4     return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
5 }

继续跟第 4 行的 query 方法，同样位于 CachingExecutor 中：

 1 public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
 2       throws SQLException {
 3     Cache cache = ms.getCache();
 4     if (cache != null) {
 5       flushCacheIfRequired(ms);
 6       if (ms.isUseCache() && resultHandler == null) {
 7         ensureNoOutParams(ms, parameterObject, boundSql);
 8         @SuppressWarnings("unchecked")
 9         List<E> list = (List<E>)tcm.getObject(cache, key);
10         if (list == null) {
11           list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
12           tcm.putObject(cache, key, list); // issue #578 and #116
13         }
14         return list;
15       }
16     }
17     return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
18 }

从这里看到，执行第 17 行的 BaseExecutor 的 query 方法之前，会先拿 Mybatis 二级缓存，而 BaseExecutor 的 query 方法会优先读取 MyBatis 一级缓存，由此可以得出一个重要结论：假如定义了 MyBatis 二级缓存，那么 MyBatis 二级缓存读取优先级高于 MyBatis 一级缓存。

而第 3 行 ~ 第 16 行的逻辑：

  • 第 5 行的方法很好理解，根据 flushCache=true 或者 flushCache=false 判断是否要清理二级缓存
  • 第 7 行的方法是保证 MyBatis 二级缓存不会存储存储过程的结果
  • 第 9 行的方法先尝试从 tcm 中获取查询结果，这个 tcm 解释一下，这又是一个装饰器模式（数数 MyBatis 用到了多少装饰器模式了），创建一个事物缓存 TranactionalCache，持有 Cache 接口，Cache 接口的实现类就是根据我们在 Mapper 文件中配置的 <cache> 创建的 Cache 实例
  • 第 10 行 ~ 第 12 行，如果没有从 MyBatis 二级缓存中拿到数据，那么就会查一次数据库，然后放到 MyBatis 二级缓存中去

至于如何判定上次查询和这次查询是一次查询？由于这里的 CacheKey 和 MyBatis 一级缓存使用的是同一个 CacheKey，因此它的判定条件和前文写过的 MyBatis 一级缓存三个维度的判定条件是一致的。

最后再来谈一点，"Cache cache = ms.getCache()" 这句代码十分重要，这意味着 Cache 是从 MappedStatement 中获取到的，而 MappedStatement 又和每一个 <insert>、<delete>、<update>、<select> 绑定并在 MyBatis 启动的时候存入 Configuration 中：

protected final Map<String, MappedStatement> mappedStatements = new StrictMap<MappedStatement>("Mapped Statements collection");

因此MyBatis 二级缓存的生命周期即整个应用的生命周期，应用不结束，定义的二级缓存都会存在在内存中。

从这个角度考虑，为了避免 MyBatis 二级缓存中数据量过大导致内存溢出，MyBatis 在配置文件中给我们增加了很多配置例如 size（缓存大小）、flushInterval（缓存清理时间间隔）、eviction（数据淘汰算法）来保证缓存中存储的数据不至于太过庞大。

 

MyBatis 二级缓存实例化过程

接着看一下 MyBatis 二级缓存 <cache> 实例化的过程，代码位于 XmlMapperBuilder 的 cacheElement 方法中：

 1 private void cacheElement(XNode context) throws Exception {
 2     if (context != null) {
 3       String type = context.getStringAttribute("type", "PERPETUAL");
 4       Class<? extends Cache> typeClass = typeAliasRegistry.resolveAlias(type);
 5       String eviction = context.getStringAttribute("eviction", "LRU");
 6       Class<? extends Cache> evictionClass = typeAliasRegistry.resolveAlias(eviction);
 7       Long flushInterval = context.getLongAttribute("flushInterval");
 8       Integer size = context.getIntAttribute("size");
 9       boolean readWrite = !context.getBooleanAttribute("readOnly", false);
10       boolean blocking = context.getBooleanAttribute("blocking", false);
11       Properties props = context.getChildrenAsProperties();
12       builderAssistant.useNewCache(typeClass, evictionClass, flushInterval, size, readWrite, blocking, props);
13     }
14 }

这里分别取 <cache> 中配置的各个属性，关注一下两个默认值：

  1. type 表示缓存实现，默认是 PERPETUAL，根据 typeAliasRegistry 中注册的，PERPETUAL 实际对应 PerpetualCache，这和 MyBatis 一级缓存是一致的
  2. eviction 表示淘汰算法，默认是 LRU 算法

第 3 行 ~ 第 11 行拿到了所有属性，那么调用 12 行的 useNewCache 方法创建缓存：

 1 public Cache useNewCache(Class<? extends Cache> typeClass,
 2       Class<? extends Cache> evictionClass,
 3       Long flushInterval,
 4       Integer size,
 5       boolean readWrite,
 6       boolean blocking,
 7       Properties props) {
 8     Cache cache = new CacheBuilder(currentNamespace)
 9         .implementation(valueOrDefault(typeClass, PerpetualCache.class))
10         .addDecorator(valueOrDefault(evictionClass, LruCache.class))
11         .clearInterval(flushInterval)
12         .size(size)
13         .readWrite(readWrite)
14         .blocking(blocking)
15         .properties(props)
16         .build();
17     configuration.addCache(cache);
18     currentCache = cache;
19     return cache;
20 }

这里又使用了建造者模式，跟一下第 16 行的 build() 方法，在此之前该传入的参数都已经传入了 CacheBuilder：

 1 public Cache build() {
 2     setDefaultImplementations();
 3     Cache cache = newBaseCacheInstance(implementation, id);
 4     setCacheProperties(cache);
 5     // issue #352, do not apply decorators to custom caches
 6     if (PerpetualCache.class.equals(cache.getClass())) {
 7       for (Class<? extends Cache> decorator : decorators) {
 8         cache = newCacheDecoratorInstance(decorator, cache);
 9         setCacheProperties(cache);
10       }
11       cache = setStandardDecorators(cache);
12     } else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) {
13       cache = new LoggingCache(cache);
14     }
15     return cache;
16 }

第 3 行的代码，构建基础的缓存，implementation 指的是 type 配置的值，这里是默认的 PerpetualCache。

第 6 行的代码，如果是 PerpetualCache，那么继续装饰（又是装饰器模式，可以数数这几篇 MyBatis 源码解析的文章里面出现了多少次装饰器模式了），这里的装饰是根据 eviction 进行装饰，到这一步，给 PerpetualCache 加上了 LRU 的功能。

第 11 行的代码，继续装饰，这次 MyBatis 将它命名为标准装饰，setStandardDecorators 方法实现为：

 1 private Cache setStandardDecorators(Cache cache) {
 2     try {
 3       MetaObject metaCache = SystemMetaObject.forObject(cache);
 4       if (size != null && metaCache.hasSetter("size")) {
 5         metaCache.setValue("size", size);
 6       }
 7       if (clearInterval != null) {
 8         cache = new ScheduledCache(cache);
 9         ((ScheduledCache) cache).setClearInterval(clearInterval);
10       }
11       if (readWrite) {
12         cache = new SerializedCache(cache);
13       }
14       cache = new LoggingCache(cache);
15       cache = new SynchronizedCache(cache);
16       if (blocking) {
17         cache = new BlockingCache(cache);
18       }
19       return cache;
20     } catch (Exception e) {
21       throw new CacheException("Error building standard cache decorators.  Cause:" + e, e);
22     }
23 }

这次是根据其它的配置参数来：

  • 如果配置了 flushInterval，那么继续装饰为 ScheduledCache，这意味着在调用 Cache 的 getSize、putObject、getObject、removeObject 四个方法的时候都会进行一次时间判断，如果到了指定的清理缓存时间间隔，那么就会将当前缓存清空
  • 如果 readWrite=true，那么继续装饰为 SerializedCache，这意味着缓存中所有存储的内存都必须实现 Serializable 接口
  • 跟配置无关，将之前装饰好的 Cache 继续装饰为 LoggingCache 与 SynchronizedCache，前者在 getObject 的时候会打印缓存命中率，后者将 Cache 接口中所有的方法都加了 Synchronized 关键字进行了同步处理
  • 如果 blocking=true，那么继续装饰为 BlockingCache，这意味着针对同一个 CacheKey，拿数据与放数据、删数据是互斥的，即拿数据的时候必须没有在放数据、删数据

Cache 全部装饰完毕，返回，至此 MyBatis 二级缓存生成完毕。

最后说一下，MyBatis 支持三种类型的二级缓存：

  • MyBatis 默认的缓存，type 为空，Cache 为 PerpetualCache
  • 自定义缓存
  • 第三方缓存

从 build() 方法来看，后两种场景的 Cache，MyBatis 只会将其装饰为 LoggingCache，理由很简单，这些缓存的定期清除功能、淘汰过期数据功能开发者自己或者第三方缓存都已经实现好了，根本不需要依赖 MyBatis 本身的装饰。

 

MyBatis 二级缓存带来的问题

补充一个内容，MyBatis 二级缓存使用的在某些场景下会出问题，来看一下为什么这么说。

假设我有一条 select 语句（开启了二级缓存）：

select a.col1, a.col2, a.col3, b.col1, b.col2, b.col3 from tableA a, tableB b where a.id = b.id;

对于 tableA 与 tableB 的操作定义在两个 Mapper 中，分别叫做 MapperA 与 MapperB，即它们属于两个命名空间，如果此时启用缓存：

  1. MapperA 中执行上述 sql 语句查询这 6 个字段
  2. tableB 更新了 col1 与 col2 两个字段
  3. MapperA 再次执行上述 sql 语句查询这 6 个字段（前提是没有执行过任何 insert、delete、update 操作）

此时问题就来了，即使第（2）步 tableB 更新了 col1 与 col2 两个字段，第（3）步 MapperA 走二级缓存查询到的这 6 个字段依然是原来的这 6 个字段的值，因为我们从 CacheKey 的 3 组条件来看：

  1. <select> 标签所在的 Mapper 的 Namespace+<select> 标签的 id 属性
  2. RowBounds 的 offset 和 limit 属性，RowBounds 是 MyBatis 用于处理分页的一个类，offset 默认为 0，limit 默认为 Integer.MAX_VALUE
  3. <select> 标签中定义的 sql 语句

对于 MapperA 来说，其中的任何一个条件都没有变化，自然会将原结果返回。

这个问题对于 MyBatis 的二级缓存来说是一个无解的问题，因此使用 MyBatis 二级缓存有一个前提：必须保证所有的增删改查都在同一个命名空间下才行。