MyBatis源码分析（五）：MyBatis Cache分析

一、Mybatis缓存介绍

　　在Mybatis中，它提供了一级缓存和二级缓存，默认的情况下只开启一级缓存，所以默认情况下是开启了缓存的，除非明确指定不开缓存功能。使用缓存的目的就是把数据保存在内存中，是应用能更快获取数据，避免与数据库频繁交互，特别是在查询比较多、命中率比较高的情况下，缓存就显得很重要。但是使用不得当，会产生脏数据。

二、目录

• 一级缓存介绍及相关配置。
• 一级缓存工作流程及源码分析。
• 一级缓存总结。
• 二级缓存介绍及相关配置。
• 二级缓存源码分析。
• 二级缓存总结。
• 全文总结。

三、一级缓存介绍及相关配置

　　一级缓存是有Session、Statement两种级别。Session级别，在同一个SqlSession中，执行相同的SQL查询，第一次从数据库里面找出来，然后写到缓存中，后续的查询就会从一级缓存中取出来。若是在一次数据库会话中发生了在修改操作后，再次执行的相同查询，会发现Myabtis查询了数据库，说明一级缓存失效；如果没有声明要刷新，而且缓存时间超时了，缓存会被清空。Statement级别，可以理解为支队当前执行的这个Statement有效。

　　mybatis-config中关于缓存的部分配置：

<setting name="localCacheScope" value="SESSION"/>

四、一级缓存工作流程以及源码分析

执行流程大致为下图：

在上一篇文章中的BaseExecutor的query方法中有一断代码，根据算法生成的key，从缓存中查询是否存在需要查询的的对象，若为空，则从数据库中查询结果

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

BaseExecutor成员变量之一的PerpetualCache，是对Cache接口最基本的实现，其实现非常简单，内部持有HashMap，对一级缓存的操作实则是对HashMap的操作。如下代码所示：

public class PerpetualCache implements Cache {

  private final String id;

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

SQL语句执行过程在上一篇文章中已经详细解释，BaseExecutor的query方法执行到最后会判断一级缓存级别是否是STATEMENT级别，如果是的话，就清空缓存，这也就是STATEMENT级别的一级缓存无法共享localCache的原因

if (queryStack == 0) {
      for (DeferredLoad deferredLoad : deferredLoads) {
        deferredLoad.load();
      }
      // issue #601
      deferredLoads.clear();
      if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
        // issue #482
        clearLocalCache();
      }
}

接下来看insert和delete方法，它们都是走update方法

  @Override
  public int insert(String statement) {
    return insert(statement, null);
  }

  @Override
  public int insert(String statement, Object parameter) {
    return update(statement, parameter);
  }

  @Override
  public int delete(String statement) {
    return update(statement, null);
  }

  @Override
  public int delete(String statement, Object parameter) {
    return update(statement, parameter);
  }

  @Override
  public int update(String statement, Object parameter) {
    try {
      dirty = true;
      MappedStatement ms = configuration.getMappedStatement(statement);
      return executor.update(ms, wrapCollection(parameter));
    } catch (Exception e) {
      throw ExceptionFactory.wrapException("Error updating database.  Cause: " + 
    e, e);
    } finally {
      ErrorContext.instance().reset();
    }
   }

再转到BaseExecutor看update方法，最后把doUpdate交给了继承了BaseExecutor的Executor中

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

再看到SimpleExecutor（默认）源码，清空了缓存，然后往数据库中执行更新操作，所以一级缓存发生更新操作时，会清空缓存

@Override
public int doUpdate(MappedStatement ms, Object parameter) throws SQLException {
    Statement stmt = null;
    try {
      Configuration configuration = ms.getConfiguration();
      StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);
      stmt = prepareStatement(handler, ms.getStatementLog());
      return handler.update(stmt);
    } finally {
      closeStatement(stmt);
    }
}

然后都是上一篇介绍SQL执行过程的内容了。

五、一级缓存的总结

• MyBatis一级缓存的生命周期和SqlSession一致。

• MyBatis一级缓存内部设计简单，只是一个没有容量限定的HashMap，在缓存的功能性上有所欠缺。

• MyBatis的一级缓存最大范围是SqlSession内部，有多个SqlSession或者分布式的环境下，数据库写操作会引起脏数据，建议设定缓存级别为Statement。

六、二级缓存介绍及相关配置

　　一级缓存中最大的共享范围是一个SqlSession内部，如果多个SqlSession之间需要共享缓存，则需要开启二级缓存。二级缓存开启的时候，调用Configuration的newExecutor方法，利用CachingExecutor装饰Executor，在进入一级缓存的查询前，先执行二级缓存的查询的流程。

 mybatis-config中关于开启二级缓存的部分配置：

<setting name="cacheEnabled" value="true"/>

　　在保证开启全局二级缓存的条件下，可以在Mapper.xml文件中配置二级缓存，在<mapper>节点内添加<cache/>节点（这里单单是默认的配置）

默认的二级缓存有以下效果：

• 映射语句文件中的所有 SELECT 语句将会被缓存
• 映射语句文件中的所有 SELECT、UPDATE、DELETE 语句会刷新缓存，缓存会使用 Least Recently Used（LRU，最近最少使用）的算法来收回
• 根据时间表（如 no Flush Interval，没有刷新间隔），缓存不会以任何时间顺序来刷新 缓存会存储集合或对象（无论查询方法返回什么类型的值）的 10 个引用。
• 缓存会被视为 ad/writ （可读／可写）的 意味着对象检索不是共享的，而且可以安全 地被调用者修改，而不干扰其 调用者或线程所做的潜在修改

所有的这些属性都可以通过修改<cache/>

七、二级缓存源码分析

 　　二级缓存开启，在一个SqlSession查询了对象，用另外一个SqlSession中查同样的数据，首先CachingExecutor先从二级缓存中查询

　　在CachingExecutor的query方法里，首先从MappedStatement中获取配置初始化时赋予的Cache，本质上是装饰器模式的使用，具体的装饰链是：SynchronizedCache -> LoggingCache -> SerializedCache -> LruCache -> PerpetualCache。

@Override
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
      throws SQLException {
    Cache cache = ms.getCache(); //获取配置初始化时的cache 5     if (cache != null) {
      flushCacheIfRequired(ms); //判断是否刷新
      if (ms.isUseCache() && resultHandler == null) {
        ensureNoOutParams(ms, boundSql); //主要是用来处理存储过程的
        @SuppressWarnings("unchecked")
        List<E> list = (List<E>) tcm.getObject(cache, key); //从tcm中获取缓存的列表,把获取值的职责一路传递,最终到perpetualCache
        if (list == null) {
          list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
          tcm.putObject(cache, key, list); //如果查询到数据，则调用tcm.putObject方法，往缓存中放入值;不是直接操作缓存，只是在把这次的数据和key放入待提交的Map中
        }
        return list;
      }
    }
    return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}

以下是具体这些Cache实现类的介绍，他们的组合为Cache赋予了不同的能力。

• SynchronizedCache：同步Cache，实现比较简单，直接使用synchronized修饰方法。
• LoggingCache：日志功能，装饰类，用于记录缓存的命中率，如果开启了DEBUG模式，则会输出命中率日志。
• SerializedCache：序列化功能，将值序列化后存到缓存中。该功能用于缓存返回一份实例的Copy，用于保存线程安全。
• LruCache：采用了Lru算法的Cache实现，移除最近最少使用的Key/Value。
• PerpetualCache： 作为为最基础的缓存类，底层实现比较简单，直接使用了HashMap。

看到Lru算法，再来说说缓存的收回策略 eviction ：

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

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

flushinterval （刷新间隔）：可以被设置为任意的正整数，而且它们代表一个合理的毫秒形式的时间段。默认情况不设置，即没有刷新间隔，缓存仅仅在调用语句时刷新。

size （引用数目）：可以被设置为任意正整数，要记住缓存的对象数目和运行环境的可用内存资源数目。默认值是 1024。

readOnly （只读）：属性可以被设置为 true false 。只读的缓存会给所有调用者 返回缓存对象的相同实例，因此这些对象不能被修改 这提供了很重要的性能优势。可读写的缓存会通过序列化返回缓存对象的拷贝，这种方式会慢一些，但是安全。因此默认是 false。

MyBatis的CachingExecutor持有了TransactionalCacheManager，上面的tcm，它里面有一个Map,这个Map保存了Cache和TransactionalCache包装后的clear方法


private Map<Cache, TransactionalCache> transactionalCaches = new HashMap<Cache, TransactionalCache>();

TransactionalCache实现了Cache接口，CachingExecutor会默认使用他包装初始生成的Cache，作用是如果事务提交，对缓存的操作才会生效，如果事务回滚或者不提交事务，则不对缓存产生影响。TransactionalCache里面有一个clear方法

@Override
public void clear() {
    clearOnCommit = true;
    entriesToAddOnCommit.clear();
}

CachingExecutor里面的commit方法

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

TransactionalCachingManager的commit方法

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

TransactionalCache的commit方法

public void commit() {
    if (clearOnCommit) {
      delegate.clear();
    }
    flushPendingEntries();
    reset();
}

TransactionalCache的flushPendingEntries方法，在flushPendingEntries中，将待提交的Map进行循环处理，委托给包装的Cache类，进行putObject的操作。

private void flushPendingEntries() {
    for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) {
      delegate.putObject(entry.getKey(), entry.getValue());
    }
    ......
}

 后续的查询操作会重复执行这套流程。如果是 insert | update | delete 的话，会统一进入CachingExecutor的update方法

private void flushCacheIfRequired(MappedStatement ms) 

二级缓存执行后会执行一级缓存操作。

八、二级缓存总结

• MyBatis的二级缓存相对于一级缓存来说，实现了SqlSession之间缓存数据的共享，同时粒度更加的细，能够到namespace级别，通过Cache接口实现类不同的组合，对Cache的可控性也更强。

• MyBatis在多表查询时，极大可能会出现脏数据，有设计上的缺陷，安全使用二级缓存的条件比较苛刻。

• 在分布式环境下，由于默认的MyBatis Cache实现都是基于本地的，分布式环境下必然会出现读取到脏数据，需要使用集中式缓存将MyBatis的Cache接口实现，有一定的开发成本，直接使用Redis、Memcached等分布式缓存可能成本更低，安全性也更高。

九、总结

本文对介绍了MyBatis一二级缓存的基本概念，并从应用及源码的角度对MyBatis的缓存机制进行了分析。最后对MyBatis缓存机制做了一定的总结，个人建议MyBatis缓存特性在生产环境中进行关闭，单纯作为一个ORM框架使用可能更为合适。

参考：聊聊MyBatis缓存机制