Mybatis缓存使用原理探究

Mybatis缓存使用原理探究

@

目录

• Mybatis缓存使用原理探究
  • 官方定义
    • 缓存
      • 使用自定义缓存
      • cache-ref
  • 一级缓存
  • 二级缓存
  • Spring容器下的一级缓存
  • 结论

国内的开发环境下关于Mybatis还是比较广泛，因此在日常开发中有必要对Mybatis中提供的缓存机制有一个全面的了解，本文将主要从源码的角度入手，分析Mybatis的缓存机制以及在spring容器管理与非spring容器管理下，Mybatis的缓存使用情况的区别。

官方定义

首先来看一下，官网对于缓存的描述。

缓存

MyBatis 内置了一个强大的事务性查询缓存机制，它可以非常方便地配置和定制。 为了使它更加强大而且易于配置，我们对 MyBatis 3 中的缓存实现进行了许多改进。

默认情况下，只启用了本地的会话缓存（一级缓存），它仅仅对一个会话中的数据进行缓存。 要启用全局的二级缓存，只需要在你的 SQL 映射文件中添加一行：

<cache/>

基本上就是这样。这个简单语句的效果如下:

• 映射语句文件中的所有 select 语句的结果将会被缓存。
• 映射语句文件中的所有 insert、update 和 delete 语句会刷新缓存。
• 缓存会使用最近最少使用算法（LRU, Least Recently Used）算法来清除不需要的缓存。
• 缓存不会定时进行刷新（也就是说，没有刷新间隔）。
• 缓存会保存列表或对象（无论查询方法返回哪种）的 1024 个引用。
• 缓存会被视为读/写缓存，这意味着获取到的对象并不是共享的，可以安全地被调用者修改，而不干扰其他调用者或线程所做的潜在修改。

提示 缓存只作用于 cache 标签所在的映射文件中的语句。如果你混合使用 Java API 和 XML 映射文件，在共用接口中的语句将不会被默认缓存。你需要使用 @CacheNamespaceRef 注解指定缓存作用域。

这些属性可以通过 cache 元素的属性来修改。比如：

<cache
  eviction="FIFO"
  flushInterval="60000"
  size="512"
  readOnly="true"/>

这个更高级的配置创建了一个 FIFO 缓存，每隔 60 秒刷新，最多可以存储结果对象或列表的 512 个引用，而且返回的对象被认为是只读的，因此对它们进行修改可能会在不同线程中的调用者产生冲突。

可用的清除策略有：

• LRU – 最近最少使用：移除最长时间不被使用的对象。
• FIFO – 先进先出：按对象进入缓存的顺序来移除它们。
• SOFT – 软引用：基于垃圾回收器状态和软引用规则移除对象。
• WEAK – 弱引用：更积极地基于垃圾收集器状态和弱引用规则移除对象。

默认的清除策略是 LRU。

flushInterval（刷新间隔）属性可以被设置为任意的正整数，设置的值应该是一个以毫秒为单位的合理时间量。 默认情况是不设置，也就是没有刷新间隔，缓存仅仅会在调用语句时刷新。

size（引用数目）属性可以被设置为任意正整数，要注意欲缓存对象的大小和运行环境中可用的内存资源。默认值是 1024。

readOnly（只读）属性可以被设置为 true 或 false。只读的缓存会给所有调用者返回缓存对象的相同实例。 因此这些对象不能被修改。这就提供了可观的性能提升。而可读写的缓存会（通过序列化）返回缓存对象的拷贝。 速度上会慢一些，但是更安全，因此默认值是 false。

提示 二级缓存是事务性的。这意味着，当 SqlSession 完成并提交时，或是完成并回滚，但没有执行 flushCache=true 的 insert/delete/update 语句时，缓存会获得更新。

使用自定义缓存

除了上述自定义缓存的方式，你也可以通过实现你自己的缓存，或为其他第三方缓存方案创建适配器，来完全覆盖缓存行为。

<cache type="com.domain.something.MyCustomCache"/>

这个示例展示了如何使用一个自定义的缓存实现。type 属性指定的类必须实现 org.apache.ibatis.cache.Cache 接口，且提供一个接受 String 参数作为 id 的构造器。 这个接口是 MyBatis 框架中许多复杂的接口之一，但是行为却非常简单。

public interface Cache {
  String getId();
  int getSize();
  void putObject(Object key, Object value);
  Object getObject(Object key);
  boolean hasKey(Object key);
  Object removeObject(Object key);
  void clear();
}

为了对你的缓存进行配置，只需要简单地在你的缓存实现中添加公有的 JavaBean 属性，然后通过 cache 元素传递属性值，例如，下面的例子将在你的缓存实现上调用一个名为 setCacheFile(String file) 的方法：

<cache type="com.domain.something.MyCustomCache">
  <property name="cacheFile" value="/tmp/my-custom-cache.tmp"/>
</cache>

你可以使用所有简单类型作为 JavaBean 属性的类型，MyBatis 会进行转换。 你也可以使用占位符（如 ${cache.file}），以便替换成在配置文件属性中定义的值。

从版本 3.4.2 开始，MyBatis 已经支持在所有属性设置完毕之后，调用一个初始化方法。 如果想要使用这个特性，请在你的自定义缓存类里实现 org.apache.ibatis.builder.InitializingObject 接口。

public interface InitializingObject {
  void initialize() throws Exception;
}

提示 上一节中对缓存的配置（如清除策略、可读或可读写等），不能应用于自定义缓存。

请注意，缓存的配置和缓存实例会被绑定到 SQL 映射文件的命名空间中。 因此，同一命名空间中的所有语句和缓存将通过命名空间绑定在一起。 每条语句可以自定义与缓存交互的方式，或将它们完全排除于缓存之外，这可以通过在每条语句上使用两个简单属性来达成。 默认情况下，语句会这样来配置：

<select ... flushCache="false" useCache="true"/>
<insert ... flushCache="true"/>
<update ... flushCache="true"/>
<delete ... flushCache="true"/>

鉴于这是默认行为，显然你永远不应该以这样的方式显式配置一条语句。但如果你想改变默认的行为，只需要设置 flushCache 和 useCache 属性。比如，某些情况下你可能希望特定 select 语句的结果排除于缓存之外，或希望一条 select 语句清空缓存。类似地，你可能希望某些 update 语句执行时不要刷新缓存。

cache-ref

回想一下上一节的内容，对某一命名空间的语句，只会使用该命名空间的缓存进行缓存或刷新。 但你可能会想要在多个命名空间中共享相同的缓存配置和实例。要实现这种需求，你可以使用 cache-ref 元素来引用另一个缓存。

<cache-ref namespace="com.someone.application.data.SomeMapper"/>

一级缓存

从上述官方的定义中得知，一级缓存是会话级别的缓存，也就是SqlSession的缓存，默认开启。带着这个定义，从SqlSession中的一条简单查询来开始探究缓存的工作原理。

private static void query(SqlSessionFactory sqlSessionFactory){
    SqlSession sqlSession = sqlSessionFactory.openSession();
    UserMapper userMapper = sqlSession.getMapper(UserMapper.class);
    User user = userMapper.findUserById(1L);
    System.out.println(user);
    System.out.println(userMapper.findUserById(1L));
    sqlSession.close();
}

以上是一个简单的查询，调用UserMapper#findUserById()。研究过Mybatis源码的应该知道，Mybatis查询是通过动态代理实现，这里的UserMapper为代理类，最终还是会调用SqlSession#selectList()。

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

往下跟踪，可以发现，最后调用到BaseExecutor#query()。

public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
  BoundSql boundSql = ms.getBoundSql(parameterObject);
    //这里是缓存的key
  CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
    //调用查询
  return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}

public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
    //.....
    //从缓存中获取返回结果，缓存为hashMap，key为hashcode + 方法path + 查询语句等组成
      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);
      }
    //.....
    return list;
  }

可以看到，查询时先从缓存中获取返回结果，如果为null，才会去查询数据库。

private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
  List<E> list;
    //占位符(避免脏数据)
  localCache.putObject(key, EXECUTION_PLACEHOLDER);
  try {
      //执行查询
    list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
  } finally {
    localCache.removeObject(key);
  }
    //查询完成后吧结果放入缓存中
  localCache.putObject(key, list);
  return list;
}

一级缓存的逻辑并不复杂，而至于为什么说是SqlSession级别的缓存，可以从localCache变量了解到。localCache变量是属于BaseExecutor的成员，内部封装一个HashMap来存放缓存的key和对应的value，而这个executor又是属于SqlSession的成员变量。在查询时，会先获取一个SqlSession，SqlSession是每次new出来的，而Executor也是同样，因此，不同的会话间，Executor是独立的。SqlSession关闭后，缓存自然也就没了，因此一级缓存只作用于会话级别。

二级缓存

ok，简单了解了一级缓存的工作原理，二级缓存可以猜测到是缓存的存放不同，因此作用域不同。接下来探究下二级缓存的原理，看下下列这段代码。

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) {
    flushCacheIfRequired(ms);
    if (ms.isUseCache() && resultHandler == null) {
        //从缓存中获取结果集
      List<E> list = (List<E>) tcm.getObject(cache, key);
      if (list == null) {
          //没有查到则去执行查询
        list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
        tcm.putObject(cache, key, list); // issue #578 and #116
      }
      return list;
    }
  }
  return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}

可以看到，二级缓存的缓存读取是在一级缓存之前的。而主要方法是通过tcm#getObject(cache, key)。但是从方法中看，tcm实际是executor的成员，每次是new出来的。

public Object getObject(Cache cache, CacheKey key) {
    //往下探究会发现，这里只是对cache的一层包装，实际还是从cache对象中取的
  return getTransactionalCache(cache).getObject(key);
}
private TransactionalCache getTransactionalCache(Cache cache) {
    TransactionalCache txCache = transactionalCaches.get(cache);
    if (txCache == null) {
      txCache = new TransactionalCache(cache);
      transactionalCaches.put(cache, txCache);
    }
    return txCache;
  }

具体从缓存的方法就不用看了，接下来主要看一下，cache是怎么来的。回到上面的selectList方法。

@Override
public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
  try {
      //可以看到，cache是从configuration中拿到的，这里的statement是mapper + 方法id。例如：com.study.test.mapper.UserMapper.findUserById
      //get方法不复杂，内部是一个StrictMap，mybatis的内部封装，继承自HashMap，理解成HashMap就好了
    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();
  }
}

从上面的代码可以了解到，cache是从configuration中的MappedStatement中获取到的，而configuration是全局的，初始化加载，在openSession的时候将其作为SqlSession的成员赋值。因此，得出结论，二级缓存是mapper级别的（全局存在，通过statementKey区分）缓存。具体的加载可以去了解下mybatis的初始化逻辑。

Spring容器下的一级缓存

在spring的管理下，mybatis做了包装。SqlSession被包装为SqlSessionTemplate对象，通过反射调用SqlSession方法，参考如下代码：

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    //获取SqlSession
    SqlSession sqlSession = SqlSessionUtils.getSqlSession(SqlSessionTemplate.this.sqlSessionFactory, SqlSessionTemplate.this.executorType, SqlSessionTemplate.this.exceptionTranslator);
    Object unwrapped;
    try {
        //反射调用SqlSession的方法
        Object result = method.invoke(sqlSession, args);
        if (!SqlSessionUtils.isSqlSessionTransactional(sqlSession, SqlSessionTemplate.this.sqlSessionFactory)) {
            sqlSession.commit(true);
        }
        unwrapped = result;
    } catch (Throwable var11) {
        //...
    } finally {
        if (sqlSession != null) {
            SqlSessionUtils.closeSqlSession(sqlSession, SqlSessionTemplate.this.sqlSessionFactory);
        }
    }
    return unwrapped;
}

可以看到，SqlSession是从SqlSessionUtils#getSqlSession()中获取的。我们知道，一级缓存是SqlSession级别的缓存，因此，想要了解一级缓存是否生效得先看SqlSession的get过程。

public static SqlSession getSqlSession(SqlSessionFactory sessionFactory, ExecutorType executorType, PersistenceExceptionTranslator exceptionTranslator) {
   //...从holder中获取SqlSession
    SqlSessionHolder holder = (SqlSessionHolder)TransactionSynchronizationManager.getResource(sessionFactory);
    SqlSession session = sessionHolder(executorType, holder);
    if (session != null) {
        return session;
    } else {
        //...否则就跟单独使用mybatis一样，通过openSession拿到
        session = sessionFactory.openSession(executorType);
        registerSessionHolder(sessionFactory, executorType, exceptionTranslator, session);
        return session;
    }
}
private static SqlSession sessionHolder(ExecutorType executorType, SqlSessionHolder holder) {
        SqlSession session = null;
        if (holder != null && holder.isSynchronizedWithTransaction()) {
            if (holder.getExecutorType() != executorType) {
                throw new TransientDataAccessResourceException("Cannot change the ExecutorType when there is an existing transaction");
            }
            holder.requested();
            if (LOGGER.isDebugEnabled()) {
                LOGGER.debug("Fetched SqlSession [" + holder.getSqlSession() + "] from current transaction");
            }
            session = holder.getSqlSession();
        }
        return session;
    }

SqlSession是从一个SqlSessionHolder中获取的，如果没有获取到就调用openSession。但是实际在debug的时候可以看到，sessionHolder中每次返回的都是null，因此每次都是openSession。回到之前的方法。

public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
    //获取SqlSession
    SqlSession sqlSession = SqlSessionUtils.getSqlSession(SqlSessionTemplate.this.sqlSessionFactory, SqlSessionTemplate.this.executorType, SqlSessionTemplate.this.exceptionTranslator);
    Object unwrapped;
    try {
        //反射调用SqlSession的方法
        Object result = method.invoke(sqlSession, args);
        if (!SqlSessionUtils.isSqlSessionTransactional(sqlSession, SqlSessionTemplate.this.sqlSessionFactory)) {
            sqlSession.commit(true);
        }
        unwrapped = result;
    } catch (Throwable var11) {
        //...
    } finally {
        if (sqlSession != null) {
            //关闭SqlSession
            SqlSessionUtils.closeSqlSession(sqlSession, SqlSessionTemplate.this.sqlSessionFactory);
        }
    }
    return unwrapped;
}

每次执行完成后，在finally中又将SqlSession关闭掉了，因此能发现，在spring容器管理下的mybatis一级缓存根本就没生效。在看下SqlSessionHolder。

//...从holder中获取SqlSession
    SqlSessionHolder holder = (SqlSessionHolder)TransactionSynchronizationManager.getResource(sessionFactory);
    SqlSession session = sessionHolder(executorType, holder);

private static void registerSessionHolder(SqlSessionFactory sessionFactory, ExecutorType executorType, PersistenceExceptionTranslator exceptionTranslator, SqlSession session) {
    //这里是判断是否存在活动的事务，如果存在事务则将SqlSession注册进holder中
        if (TransactionSynchronizationManager.isSynchronizationActive()) {
            Environment environment = sessionFactory.getConfiguration().getEnvironment();
                SqlSessionHolder holder = new SqlSessionHolder(session, executorType, exceptionTranslator);
                TransactionSynchronizationManager.bindResource(sessionFactory, holder);
                TransactionSynchronizationManager.registerSynchronization(new SqlSessionUtils.SqlSessionSynchronization(holder, sessionFactory));
                holder.setSynchronizedWithTransaction(true);
                holder.requested();
            } 
    }

从上面的逻辑看出，在spring容器管理下，SqlSession是受事务控制的，事务开启后，在这个方法中，SqlSession不会重新open。

结论

mybatis的缓存，分为一级和二级缓存。

一级缓存是属于SqlSession（会话）级别的缓存，随着SqlSession的关闭而消亡

二级缓存是属于Mapper级别的缓存，二级缓存默认关闭，需要主动开启，随着容器销毁而消亡，或者可以通过指定刷新方式。

在spring下使用mybatis，一级缓存只有在事务控制下才会生效，非事务控制的情况下每次都会open一个SqlSession。