Mybatis源码解析(十)：一级缓存和二级缓存

Mybatis源码系列文章

手写源码（了解源码整体流程及重要组件）

Mybatis源码解析(一)：环境搭建

Mybatis源码解析(二)：全局配置文件的解析

Mybatis源码解析(三)：映射配置文件的解析

Mybatis源码解析(四)：sql语句及#{}、${}的解析

Mybatis源码解析(五)：SqlSession会话的创建

Mybatis源码解析(六)：缓存执行器操作流程

Mybatis源码解析(七)：查询数据库主流程

Mybatis源码解析(八)：Mapper代理原理

Mybatis源码解析(九)：插件机制

Mybatis源码解析(十)：一级缓存和二级缓存

---

---

前言

• Mybatis源码解析(六)：缓存执行器操作流程-此篇讲了一级缓存和二级缓存的数据类型HashMap，key的组成部分以及一二级缓存与查询数据库的顺序
• 本篇讲解下一级缓存和二级缓存的作用范围、执行流程底层实现原理

---

一、缓存策略

• 一级缓存是SqlSession级别的缓存。在操作数据库时需要构造sqlSession对象，在对象中有一个数据结构（HashMap）用于存储缓存数据。不同的sqlSession之间的缓存数据区域（HashMap）是互相不影响的
• 二级缓存是mapper级别的缓存。多个SqlSession去操作同一个Mapper的sql语句，多个SqlSession可以共用二级缓存，二级缓存是跨SqlSession的

二、一级缓存演示

• 一级缓存默认开启

演示一

• 同一个sqlSession的相同查询，sql日志打印一次而且两次对象相等，第二次查询结果是第一次查询的缓存结果

演示二

• 同一个sqlSession的两次相同查询，中间添加一个更新操作，每次查询都要打印日志而且结果不相等，第一次查询结果缓存失效了
• 更新操作，即使没有commit，结果不变，那么失效原因就在update里面

演示三

• 不同的sqlSession的相同查询，两次sql日志打印而且对象不相等，第二次查询没有拿到第一次查询结果的缓存

三、一级缓存源码

1、作用范围

• 查询数据库方法，在此之前已经判断一级缓存中不存在查询数据
• key(Cache对象)的组成部分：statementId、分页参数、带?的sql、参数值、环境id
• 一级缓存就是PerpetualCache localCache

private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
  List<E> list;
  // 1. 首先向本地缓存中存入一个ExecutionPlaceholder的枚举类占位value
  localCache.putObject(key, EXECUTION_PLACEHOLDER);
  try {
    // 2. 执行doQuery方法
    list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
  } finally {
    // 3. 执行完成移除这个key
    localCache.removeObject(key);
  }
  // 4. 查询结果存入缓存中
  localCache.putObject(key, list);
  // 5. 如果MappedStatement的类型为CALLABLE，则向localOutputParameterCache缓存中存入value为parameter的缓存
  if (ms.getStatementType() == StatementType.CALLABLE) {
    localOutputParameterCache.putObject(key, parameter);
  }
  return list;
}

查看一级缓存对象PerpetualCache localCache

• 说到底一级缓存就是cache这个HashMap对象

public class PerpetualCache implements Cache {

  private final String id;

  private final Map<Object, Object> cache = new HashMap<>();

  @Override
  public void putObject(Object key, Object value) {
    cache.put(key, value);
  }

  @Override
  public Object getObject(Object key) {
    return cache.get(key);
  }
  ...
}

查看一级缓存对象PerpetualCache的位置

• 一级缓存对象在执行器基础抽象类下
• Mybatis源码解析(五)：SqlSession会话的创建-此篇讲了SqlSessioin的创建包含了不同执行器的创建，而BaseExecutor又是不同执行器的基类，必定需要创建
• 所以，一级缓存是跟随着SqlSession的
• 一级缓存演示一：相同的sqlSession就可以从localCache中获取以前存的value
• 一级缓存演示三：不相同的sqlSession，sqlSession1的缓存中有值，但sqlSession2需要到它的缓存中获取，所以拿不到

2、缓存失效

• 根据一级缓存的演示二可知，相同的sqlSession的update方法会导致缓存失效

进入udpate源码

• 这里有个清除缓存方法，将一级缓存localCache的Map对象clear
• 一级缓存的演示二：缓存map已被清空，所以缓存失效

@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);
}

@Override
public void clearLocalCache() {
  if (!closed) {
    localCache.clear();
    localOutputParameterCache.clear();
  }
}

四、二级缓存演示

• 二级缓存不是默认开启
• Mapper配置文件中配置标签
  
• 实体类要实现Serializable接口，因为二级缓存会将对象写进硬盘，就必须序列化，以及兼容对象在网络中的传输

演示一

• 不同的sqlSession相同的查询，sql日志只有一个，说明二级缓存生效了
• 对象不相等。内容一样，地址不一样，后面源码说
• 两次查询，只有调用commit或者close方法，二级缓存才会生效
• 记录了命中率，第一次缓存中没有，命中率0.0，第二次查询缓存中有，查询两次，缓存命中率0.5

演示二

• 两次查询之间添加更新操作，依然缓存命中0.5
• 二级缓存，只有更新操作commit以后才会缓存失效
• 一级缓存，只需要更新操作，不需要commit就会缓存失效

五、二级缓存源码

1、<cache>标签的解析

捋一下xml与对象之间的关系

• 全局配置文件会被解析成Configuration对象
• 映射配置文件会被解析成多个MappedStatement对象，每个<select><insert><update><delete>标签会被解析成一个MappedStatement对象
• MappedStatement对象集合挂在Configuration对象下面
• <cache>标签在映射配置文件的增删改查标签外，那它应该单独挂在Configuration对象下

<cache>标签解析内容

• 解析<cache>标签内的属性，通过这些属性创建Cache对象

private void cacheElement(XNode context) {
  if (context != null) {
    // 解析<cache>标签type属性的值，在这可以自定义type的值，比如redisCache,如果没有指定默认就是PERPETUAL
    String type = context.getStringAttribute("type", "PERPETUAL");
    Class<? extends Cache> typeClass = typeAliasRegistry.resolveAlias(type);
    // 获取负责过期的eviction对象，默认策略为LRU
    String eviction = context.getStringAttribute("eviction", "LRU");
    Class<? extends Cache> evictionClass = typeAliasRegistry.resolveAlias(eviction);
    // 清空缓存的频率 0代表不清空
    Long flushInterval = context.getLongAttribute("flushInterval");
    // 缓存容器的大小
    Integer size = context.getIntAttribute("size");
    // 是否只读
    boolean readWrite = !context.getBooleanAttribute("readOnly", false);
    // 是否阻塞
    boolean blocking = context.getBooleanAttribute("blocking", false);
    // 获得Properties属性
    Properties props = context.getChildrenAsProperties();
    builderAssistant.useNewCache(typeClass, evictionClass, flushInterval, size, readWrite, blocking, props);
  }
}

Cache对象创建方法

• 默认情况创建的对象和一级缓存对象一样，都是PerpetualCache
• Cache对象赋值MappedStatement对象构建器的currentCache属性，构建MappedStatement对象使用
• addCache方法：将Cache对象添加到Configuration对象

public Cache useNewCache(Class<? extends Cache> typeClass,
    Class<? extends Cache> evictionClass,
    Long flushInterval,
    Integer size,
    boolean readWrite,
    boolean blocking,
    Properties props) {
  // 1.生成cache对象
  Cache cache = new CacheBuilder(currentNamespace)
      .implementation(valueOrDefault(typeClass, PerpetualCache.class))
      .addDecorator(valueOrDefault(evictionClass, LruCache.class))
      .clearInterval(flushInterval)
      .size(size)
      .readWrite(readWrite)
      .blocking(blocking)
      .properties(props)
      .build();
  // 2.添加到configuration中
  configuration.addCache(cache);
  // 3.并赋值给MapperBuilderAssistant中的currentCache属性
  currentCache = cache;
  return cache;
}

• 装饰者模式，包了两层，最里面的引用还是PrerpetualCache

2、Cache对象存在位置

MappedStatement对象下

• 创建Cache对象时候，赋值了变量currentCache，此时创建MappedStatement使用
• 后面几乎大部分使用缓存都是从MappedStatement ms对象中获取Cache对象
• MappedStatement对象是解析映射配置文件生成的，不论创建多少SqlSession，都用的同一个MappedStatement对象，这就解释了二级缓存是跨sqlSession的
• 二级缓存map对象里的value这里还是空，后面的操作会填充

Configuration对象下

• 创建Cache对象后，调用了一个addCache方法
• 二级缓存以Map集合形式存在全局配置文件Configuration
• key：<mapper namespace=“com.xc.mapper.UserMapper”>标签的namespace值
• 这个位置的Cache几乎没啥用，知道Configuration对象下有它即可

public class Configuration {
  protected final Map<String, Cache> caches = new StrictMap<>("Caches collection");
  ...
  public void addCache(Cache cache) {
    caches.put(cache.getId(), cache);
  }
  ...
}

3、二级缓存的存和取

• ms.getCache()：从MappedStatemet对象中获取SynchronizedCache包装对象，内部引用是PerpetualCache
• tcm.getObject：从二级缓存中取值
• delegate.query：查询一级缓存，没有再查数据库，上面一级缓存中有讲
• tcm.putObject：二级缓存中存值 (注意：此处只是存到map集合中，没有真正存到二级缓存中)

@Override
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
    throws SQLException {
  // 获取二级缓存
  Cache cache = ms.getCache();
  if (cache != null) {
    // 刷新二级缓存 （存在缓存且flushCache为true时）
    flushCacheIfRequired(ms);
    if (ms.isUseCache() && resultHandler == null) {
      ensureNoOutParams(ms, boundSql);
      @SuppressWarnings("unchecked")
      // 从二级缓存中查询数据
      List<E> list = (List<E>) tcm.getObject(cache, key);
      // 如果二级缓存中没有查询到数据，则查询一级缓存及数据库
      if (list == null) {
        // 委托给BaseExecutor执行
        list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
        // 将查询结果 要存到二级缓存中（注意：此处只是存到map集合中，没有真正存到二级缓存中）
        tcm.putObject(cache, key, list); // issue #578 and #116
      }
      return list;
    }
  }
  // 委托给BaseExecutor执行
  return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}

• tcm里面层层包裹，但都是同一个二级缓存对象SynchronizedCache@2695

tcm对象

• tcm即TransactionalCacheManager：事务缓存管理器

public class CachingExecutor implements Executor {

  private final Executor delegate;
  private final TransactionalCacheManager tcm = new TransactionalCacheManager();
  ...
}

• TransactionalCacheManager里主要维护着一个transactionalCaches的Map集合
  • Cache：SynchronizedCache类，内部引用delegate还是PerpetualCache
  • TransactionalCache：事务缓存类，内部引用是SynchronizedCache
• tcm的存值和取值就是对应的putObject和getObject方法

public class TransactionalCacheManager {

  // Cache 与 TransactionalCache 的映射关系表
  private final Map<Cache, TransactionalCache> transactionalCaches = new HashMap<>();

  public void clear(Cache cache) {
    // 获取 TransactionalCache 对象，并调用该对象的 clear 方法，下同
    getTransactionalCache(cache).clear();
  }

  public Object getObject(Cache cache, CacheKey key) {
    // 直接从TransactionalCache中获取缓存
    return getTransactionalCache(cache).getObject(key);
  }

  public void putObject(Cache cache, CacheKey key, Object value) {
    // 直接存入TransactionalCache的缓存中
    getTransactionalCache(cache).putObject(key, value);
  }
...
}

1）tcm.putObject：二级缓存中存值

• 如果上面所说二级缓存存值和取值没问题，那么二级缓存的演示一，不需要commit就能实现二级缓存
• 原因这里的二级缓存中存值只是存到map集合，没有存到二级缓存
• 猜想那就是commit操作把这个map集合数据转移到二级缓存

进入tcm.putObject方法

public void putObject(Cache cache, CacheKey key, Object value) {
  // 直接存入TransactionalCache的缓存中
  getTransactionalCache(cache).putObject(key, value);
}

进入getTransactionalCache方法

• 从transactionalCaches这个Map集合的找有没有key=Cache对象
  • 有，则将transactionalCaches集合中的事务缓存返回
  • 没有，则根据cache(SynchronizedCache)创建事务缓存返回且添加transactionalCaches集合中

private TransactionalCache getTransactionalCache(Cache cache) {
  // 从映射表中获取 TransactionalCache
  return MapUtil.computeIfAbsent(transactionalCaches, cache, TransactionalCache::new);
}

进入putObject方法

• 将key=CacheKey，value=查询结果放入entriesToAddOnCommit集合
• 这里不是二级缓存位置，只是临时位置，commit以后才会将此处值转移到二级缓存位置

public class TransactionalCache implements Cache {
  ...
  /**
   *  // 在事务被提交前，所有从数据库中查询的结果将缓存在此集合中
   */
  private final Map<Object, Object> entriesToAddOnCommit;

  @Override
  public void putObject(Object key, Object object) {
    // 将键值对存入到 entriesToAddOnCommit 这个Map中中，而非真实的缓存对象 delegate 中
    entriesToAddOnCommit.put(key, object);
  }
  ...
}

2） tcm.getObject：二级缓存中取值

• 与存值一样，先通过getTransactionalCache方法，获取事务缓存

public Object getObject(Cache cache, CacheKey key) {
  // 直接从TransactionalCache中获取缓存
  return getTransactionalCache(cache).getObject(key);
}

进入getObject方法

• delegate：SynchronizedCache对象，内部实际引用是PerpetualCache，二级缓存

public class TransactionalCache implements Cache {
  /**
   * 委托的 Cache 对象。
   *
   * 实际上，就是二级缓存 Cache 对象。
   */
  private final Cache delegate;
  /**
   * 提交时，清空 {@link #delegate}
   *
   * 初始时，该值为 false
   * 清理后{@link #clear()} 时，该值为 true ，表示持续处于清空状态
   */
  private boolean clearOnCommit;
  /**
   *   在事务被提交前，当缓存未命中时，CacheKey 将会被存储在此集合中
   */
  private final Set<Object> entriesMissedInCache;

  @Override
  public Object getObject(Object key) {
    // issue #116
    // 查询的时候是直接从delegate中去查询的，也就是从真正的缓存对象中查询
    Object object = delegate.getObject(key);
    // 如果不存在，则添加到 entriesMissedInCache 中
    if (object == null) {
      // 缓存未命中，则将 key 存入到 entriesMissedInCache 中
      entriesMissedInCache.add(key);
    }
    // issue #146
    // 如果 clearOnCommit 为 true ，表示处于持续清空状态，则返回 null
    if (clearOnCommit) {
      return null;
    } else {
      // 返回 value
      return object;
    }
  }
  ...
}

3）commit操作

• 查看tcm即TransactionalCacheManager的提交

@Override
public void commit(boolean required) throws SQLException {
  delegate.commit(required);
  tcm.commit();
}

• 遍历事务缓存集合

public void commit() {
  for (TransactionalCache txCache : transactionalCaches.values()) {
    txCache.commit();
  }
}

• flushPendingEntries方法：将entriesToAddOnCommit转移到二级缓存
• reset重置方法 将entriesToAddOnCommit集合清空

public void commit() {
  // 如果 clearOnCommit 为 true ，则清空 delegate 缓存
  if (clearOnCommit) {
    delegate.clear();
  }
  // 将 entriesToAddOnCommit、entriesMissedInCache 刷入 delegate(cache) 中
  flushPendingEntries();
  // 重置
  reset();
}

flushPendingEntries真正存入二级缓存方法

• 这里的putObject是将对象序列化成二进制对象，获取时候反序列化，所以第一次的查询结果与第二次获取的缓存结果不相等，因为他两不是同一个对象，只是内容相同

private void flushPendingEntries() {
  // 将 entriesToAddOnCommit 中的内容转存到 delegate 中
  for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) {
    // 在这里真正的将entriesToAddOnCommit的对象逐个添加到delegate中，只有这时，二级缓存才真正的生效
    delegate.putObject(entry.getKey(), entry.getValue());
  }
}

二级缓存存取总结：

• 二级缓存存值，放到了事务缓存TransactionalCache对象的entriesToAddOnCommit的map集合中
• 二级缓存取值，从事务缓存TransactionalCache对象的delegate(内部引用PerpetualCache)中获取
• 存和取不在一个地方，commit操作会将entriesToAddOnCommit集合数据序列化二进制数据转移到delegate
• 这样也就能解释二级缓存的演示一了

4、缓存失效

• 查看更新方法

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

• 查询方法flushCacheRequired属性为false，更新方法为true

private void flushCacheIfRequired(MappedStatement ms) {
  Cache cache = ms.getCache();
  if (cache != null && ms.isFlushCacheRequired()) {
    tcm.clear(cache);
  }
}

• 通过Cache对象获取事务缓存对象，再调用clear方法

public void clear(Cache cache) {
  // 获取 TransactionalCache 对象，并调用该对象的 clear 方法，下同
  getTransactionalCache(cache).clear();
}

进入clear方法

• clearOnCommit：清理标志设置为true
• entriesToAddOnCommit：临时存放二级缓存的集合清空，真正的二级缓存没有清空
• 所以，更新方法没有失效，接下来要看commit

@Override
public void clear() {
  // 标记 clearOnCommit 为 true
  clearOnCommit = true;
  // 清空 entriesToAddOnCommit
  entriesToAddOnCommit.clear();
}

进入commit方法

• 此时clearOnCommit标志已经被设置为true，delegate则是真正的二级缓存，被清除了
• 这样，二级缓存的演示二也就能解释清楚了

public void commit() {
  // 如果 clearOnCommit 为 true ，则清空 delegate 缓存
  if (clearOnCommit) {
    delegate.clear();
  }
  // 将 entriesToAddOnCommit、entriesMissedInCache 刷入 delegate(cache) 中
  flushPendingEntries();
  // 重置
  reset();
}

---

总结

• 作用范围
  • 一级缓存放在执行器里，每次创建sqlSession都会创建执行器，所以一级缓存的作用范围在sqlSession里
  • 二级缓存放在MappedStatement里，解析映射配置文件创建而成，不论创建多少sqlSession都只用这一个MappedStatemt对象，所以二级缓存的作用范围在多个sqlSession(也就是namespace)
• 一级缓存
  • 默认开启，就是简单得存取值
  • update操作无commit会使缓存失效
• 二级缓存
  • 手动开启，缓存结果通过序列化传递，所以地址不同，内容相同
  • 查询流程缓存是数据只是放入临时map集合，commit以后才将数据转移到二级缓存，故查询操作后commit以后二级缓存才生效
  • update操作commit以后才会使缓存失效