深入浅出 MyBatis 的一级、二级缓存机制2

那么问题来了，创建缓存了，那具体在哪里用呢？我们一级缓存探究后，我们发现一级缓存更多的用于查询操作。我们跟踪到 query 方法：

如果查不到的话，就从数据库查，在 queryFromDatabase 中，会对 localcache 进行写入。

在 query 方法执行的最后，会判断一级缓存级别是否是 STATEMENT 级别，如果是的话，就清空缓存，这也就是 STATEMENT 级别的一级缓存无法共享 localCache 的原因。代码如下所示：

if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {  
    clearLocalCache();  
}  

在源码分析的最后，我们确认一下，如果是 insert/delete/update 方法，缓存就会刷新的原因。

SqlSession 的 insert 方法和 delete 方法，都会统一走 update 的流程，代码如下所示：

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

update 方法也是委托给了 Executor 执行。BaseExecutor 的执行方法如下所示：

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

每次执行 update 前都会清空 localCache。

至此，一级缓存的工作流程讲解以及源码分析完毕。

五、一级缓存小结

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

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

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

六、二级缓存

在上文中提到的一级缓存中，其最大的共享范围就是一个 SqlSession 内部，如果多个 SqlSession 之间需要共享缓存，则需要使用到二级缓存。开启二级缓存后，会使用 CachingExecutor 装饰 Executor，进入一级缓存的查询流程前，先在 CachingExecutor 进行二级缓存的查询，具体的工作流程如下所示。

二级缓存开启后，同一个 namespace 下的所有操作语句，都影响着同一个 Cache，即二级缓存被多个 SqlSession 共享，是一个全局的变量。

当开启缓存后，数据的查询执行的流程就是 二级缓存 -> 一级缓存 -> 数据库。

MyBatis 是默认关闭二级缓存的，因为对于增删改操作频繁的话，那么二级缓存形同虚设，每次都会被清空缓存。

6.1 二级缓存配置

和一级缓存默认开启不一样，二级缓存需要我们手动开启。

6.1.1 首先在全局配置文件 SqlMapConfig.xml 文件中加入如下代码：

<!--开启二级缓存-->  
<settings>  
    <setting name="cacheEnabled" value="true"/>  
</settings>  

6.1.2 其次在 UserMapper.xml 文件中开启二级缓存

mapper 代理模式：

<!--开启二级缓存-->  
<cache />

注解开发模式：

@CacheNamespace(implementation = PerpetualCache.class) // 开启二级缓存  
public interface UserMapper {  
}

mapper 代理模式开启的二级缓存是一个空标签，其实这里可以配置，PerpetualCache 这个类是 mybatis 默认实现的二级缓存功能的类，我们不写 type ，用 @CacheNamespace 直接默认 PerpetualCache 这个类，也可以去实现 Cache 接口来自定义缓存。

6.2 实体类实现 Serializable 序列化接口

开启二级缓存后，还需要将要缓存的实体类去实现 Serializable 序列化接口，为了将缓存数据取出执行反序列化操作，因为二级缓存数据存储介质多种多样，不一定只存在内存中，有可能存在硬盘中，如果我们再取出这个缓存的话，就需要反序列化。所以 MyBatis 的所有 pojo 类都要去实现 Serializable 序列化接口。

七、二级缓存实验

7.1 实验1

测试二级缓存与 SqlSession 无关

@Test  
public void secondLevelCache() {  
    SqlSession sqlSession1 = sqlSessionFactory.openSession();  
    SqlSession sqlSession2 = sqlSessionFactory.openSession();  
    UserMapper userMapper1 = sqlSession1.getMapper(UserMapper.class);  
    UserMapper userMapper2 = sqlSession2.getMapper(UserMapper.class);  
    // 第一次查询id为1的用户  
    User user1 = userMapper1.findUserById(1);  
    sqlSession1.close(); // 清空一级缓存  
    System.out.println(user1);  
    // 第二次查询id为1的用户  
    User user2 = userMapper2.findUserById(1);  
    System.out.println(user2);  
    System.out.println(user1 == user2);  
}  

控制台日志输出：

第一次查询时，将查询结果放入缓存中，第二次查询，即使 sqlSession1.close(); 清空了一级缓存，第二次查询依然不发出 sql 语句。

这里的你可能有个疑问，这里不是二级缓存了吗？怎么 user1 与 user2 不相等？

这是因为二级缓存的是数据，并不是对象。而 user1 与 user2 是两个对象，所以地址值当然也不想等。

7.2 实验2

测试执行 commit()，二级缓存数据清空。

@Test  
public void secondLevelCacheOfUpdate() {  
    SqlSession sqlSession1 = sqlSessionFactory.openSession();  
    SqlSession sqlSession2 = sqlSessionFactory.openSession();  
    SqlSession sqlSession3 = sqlSessionFactory.openSession();  
    UserMapper userMapper1 = sqlSession1.getMapper(UserMapper.class);  
    UserMapper userMapper2 = sqlSession2.getMapper(UserMapper.class);  
    UserMapper userMapper3 = sqlSession3.getMapper(UserMapper.class);  
    // 第一次查询id为1的用户  
    User user1 = userMapper1.findUserById(1);  
    sqlSession1.close(); // 清空一级缓存  
    User user = new User();  
    user.setId(3);  
    user.setUsername("edgar");  
    userMapper3.updateUser(user);  
    sqlSession3.commit();  
    // 第二次查询id为1的用户  
    User user2 = userMapper2.findUserById(1);  
    sqlSession2.close();  
    System.out.println(user1 == user2);  
}  

控制台日志输出：

我们可以看到，在 sqlSession3 更新数据库，并提交事务后，sqlsession2 的 UserMapper namespace 下的查询走了数据库，没有走 Cache。

7.3 实验3

验证 MyBatis 的二级缓存不适应用于映射文件中存在多表查询的情况。

通常我们会为每个单表创建单独的映射文件，由于 MyBatis 的二级缓存是基于 namespace 的，多表查询语句所在的 namspace 无法感应到其他 namespace 中的语句对多表查询中涉及的表进行的修改，引发脏数据问题。

为了解决实验3的问题呢，可以使用 Cache ref，让 OrderMapper 引用 UserMapper 命名空间，这样两个映射文件对应的 SQL 操作都使用的是同一块缓存了。

不过这样做的后果是，缓存的粒度变粗了，多个 Mapper namespace 下的所有操作都会对缓存使用造成影响。

这里老周就不代码演示了，有没有感觉很鸡肋，而且不熟用二级缓存的话，像这种多表查询的，很容易造成脏读数据不一致，这在线上的话是致命的。

7.4 useCache 和 flushCache

useCache 是用来设置是否禁用二级缓存的，在 statement 中设置 useCache=“false”，可以禁用当前 select 语句的二级缓存，即每次都会去数据库查询。如下：

<select id="findAll" resultMap="userMap" useCache="false">  
    select * from user u left join orders o on u.id = o.uid  
</select>  

设置 statement 配置中的 flushCache=“true” 属性，默认情况下为 true，即刷新缓存，一般执行完 commit 操作都需要刷新缓存，flushCache=“true” 表示刷新缓存，这样可以避免增删改操作而导致的脏读问题。默认不要配置，如下：

<select id="findAll" resultMap="userMap" useCache="false" flushCache="true">  
    select * from user u left join orders o on u.id = o.uid  
</select>  

八、二级缓存源码分析

MyBatis 二级缓存的工作流程和前文提到的一级缓存类似，只是在一级缓存处理前，用 CachingExecutor 装饰了 BaseExecutor 的子类，在委托具体职责给 delegate 之前，实现了二级缓存的查询和写入功能，具体类关系图如下图所示。

源码分析从 CachingExecutor 的 query 方法展开，首先会从 MappedStatement 中获得在配置初始化时赋予的 Cache。

public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {  
    Cache cache = ms.getCache(); // 首先会从 MappedStatement 中获得在配置初始化时赋予的 Cache  
    if (cache != null) {  
        this.flushCacheIfRequired(ms);  
        if (ms.isUseCache() && resultHandler == null) {  
            this.ensureNoOutParams(ms, parameterObject, boundSql);  
            List<E> list = (List)this.tcm.getObject(cache, key);  
            if (list == null) {  
                list = this.delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);  
                this.tcm.putObject(cache, key, list);  
            }  
            return list;  
        }  
    }  
    return this.delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);  
}  

本质上是装饰器模式的使用，具体的装饰链是：

SynchronizedCache -> LoggingCache -> SerializedCache -> LruCache -> PerpetualCache。

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

SynchronizedCache：同步 Cache，实现比较简单，直接使用 synchronized 修饰方法。

LoggingCache：日志功能，装饰类，用于记录缓存的命中率，如果开启了 DEBUG 模式，则会输出命中率日志。

SerializedCache：序列化功能，将值序列化后存到缓存中。该功能用于缓存返回一份实例的 Copy，用于保存线程安全。

LruCache：采用了 LRU 算法的 Cache 实现，移除最近最少使用的 Key/Value。

PerpetualCache：作为为最基础的缓存类，底层实现比较简单，直接使用了 HashMap。

然后是判断是否需要刷新缓存，也就是上面代码中的：

this.flushCacheIfRequired(ms);

在默认的设置中 SELECT 语句不会刷新缓存，insert/update/delte 会刷新缓存。进入该方法。代码如下所示：

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

MyBatis 的 CachingExecutor 持有了 TransactionalCacheManager，即上述代码中的 tcm。

TransactionalCacheManager 中持有了一个 Map，代码如下所示：

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

这个 Map 保存了 Cache 和用 TransactionalCache 包装后的 Cache 的映射关系。

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

在 TransactionalCache 的 clear，有以下两句。清空了需要在提交时加入缓存的列表，同时设定提交时清空缓存，代码如下所示：

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

CachingExecutor#query 继续往下走，ensureNoOutParams 主要是用来处理存储过程的，暂时不用考虑。

if (ms.isUseCache() && resultHandler == null) {  
    ensureNoOutParams(ms, parameterObject, boundSql);  
    ...  
}  

之后会尝试从tcm中获取缓存的列表。

List<E> list = (List<E>) tcm.getObject(cache, key);

在 getObject 方法中，会把获取值的职责一路传递，最终到 PerpetualCache。如果没有查到，会把 key 加入 Miss 集合，这个主要是为了统计命中率。

// TransactionalCache#getObject  
public Object getObject(Object key) {  
    Object object = this.delegate.getObject(key);  
    if (object == null) {  
        this.entriesMissedInCache.add(key);  
    }  
    return this.clearOnCommit ? null : object;  
}  

CachingExecutor 继续往下走，如果查询到数据，则调用 tcm.putObject 方法，往缓存中放入值。

if (list == null) {  
    list = this.delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);  
    this.tcm.putObject(cache, key, list); // issue #578 and #116  
}  

tcm 的 put 方法也不是直接操作缓存，只是在把这次的数据和 key 放入待提交的 Map 中。

public void putObject(Cache cache, CacheKey key, Object value) {  
    this.getTransactionalCache(cache).putObject(key, value);  
}  
public void putObject(Object key, Object object) {  
    entriesToAddOnCommit.put(key, object);  
}  

从以上的代码分析中，我们可以明白，如果不调用 commit 方法的话，由于 TranscationalCache 的作用，并不会对二级缓存造成直接的影响。我们来看下 CachingExecutor#commit 方法：

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

会把具体 commit 的职责委托给包装的 Executor。主要是看下tcm.commit()，tcm 最终又会调用到TrancationalCache。

// TransactionalCacheManager#commit  
public void commit() {  
    Iterator var1 = this.transactionalCaches.values().iterator();  
    while(var1.hasNext()) {  
        TransactionalCache txCache = (TransactionalCache)var1.next();  
        txCache.commit();  
    }  
}  
// TransactionalCache#commit  
public void commit() {  
    if (this.clearOnCommit) {  
        this.delegate.clear();  
    }  
    this.flushPendingEntries();  
    this.reset();  
}  

看到这里的 clearOnCommit 就想起刚才 TrancationalCache 的 clear 方法设置的标志位，真正的清理 Cache 是放到这里来进行的。具体清理的职责委托给了包装的 Cache 类。之后进入 flushPendingEntries 方法。代码如下所示：

private void flushPendingEntries() {  
    Iterator var1 = this.entriesToAddOnCommit.entrySet().iterator();  
    while(var1.hasNext()) {  
        Entry<Object, Object> entry = (Entry)var1.next();  
        this.delegate.putObject(entry.getKey(), entry.getValue());  
    }  
    var1 = this.entriesMissedInCache.iterator();  
    while(var1.hasNext()) {  
        Object entry = var1.next();  
        if (!this.entriesToAddOnCommit.containsKey(entry)) {  
            this.delegate.putObject(entry, (Object)null);  
        }  
    }  
}  

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

后续的查询操作会重复执行这套流程。如果是 insert|update|delete 的话，会统一进入 CachingExecutor 的 update 方法，其中调用了这个函数，代码如下所示：

private void flushCacheIfRequired(MappedStatement ms) 

在二级缓存执行流程后就会进入一级缓存的执行流程，因此不再赘述 。

九、二级缓存小结

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

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

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

十、总结

本文先是介绍了 MyBatis 的缓存，MyBatis 的缓存分为一、二级缓存，一级缓存是 SqlSession 级别的缓存，二级缓存是 Mapper 级别的缓存；然后从工作流程、应用试验以及源码层面分析了 MyBatis 的一、二级缓存机制；最后对 MyBatis 的一、二级缓存做了相应的小结。

老周建议 MyBatis 的一级、二级缓存只作为 ORM 框架使用就行了，线上环境得关闭 MyBatis 的缓存机制。通过全文分析，不知道你有没有觉得 MyBatis 的缓存机制很鸡肋？

一级缓存来说对于有多个 SqlSession 或者分布式的环境下，数据库写操作会引起脏数据以及对于增删改多的操作来说，清除一级缓存会很频繁，这会导致一级缓存形同虚设。

二级缓存来说实现了 SqlSession 之间缓存数据的共享，除了跟一级缓存一样对于增删改多的操作来说，清除二级缓存会很频繁，这会导致二级缓存形同虚设；MyBatis 的二级缓存不适应用于映射文件中存在多表查询的情况，由于 MyBatis 的二级缓存是基于 namespace 的，多表查询语句所在的 namspace 无法感应到其他 namespace 中的语句对多表查询中涉及的表进行的修改，引发脏数据问题。虽然可以通过 Cache ref 来解决多表的问题，但这样做的后果是，缓存的粒度变粗了，多个 Mapper namespace 下的所有操作都会对缓存使用造成影响。

综上，生产环境要关闭 MyBatis 的缓存机制。你可能会问，老周，你说生产环境不推荐用，那为啥很多面试官很喜欢问 MyBatis 的一级、二级缓存机制呢？那你把老周这篇丢给他就好了，最后你再反问面试官，你们生产环境有用 MyBatis 的一级、二级缓存机制吗？大多数的答案要么是没用或者它自己也不知道用没用就随便那几道题来面你。如果面试官回答生产环境用了的话，那你就把这些用的弊端跟面试官交流交流。

好了深入浅出 MyBatis 的一级、二级缓存机制就到这了，我们下期再见。