Mybatis学习笔记（五）- mybatis二级缓存原理

在前边的学习中我们大概得了解了mybatis扫描和注入原理和sql的执行过程，还有mybatis插件的原理，在后边我们学习了mybatis的一级缓存的原理。那么今天我们主要学习一下mybatis二级缓存吧！

@Override
  public Listquery(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
      throws SQLException {
只有是select类型的查询才有缓存可言
    Cache cache = ms.getCache();
    if (cache != null) {
//如果需要就删除当前缓存
      flushCacheIfRequired(ms);
      if (ms.isUseCache() && resultHandler == null) {
        ensureNoOutParams(ms, boundSql);
        @SuppressWarnings("unchecked")
从缓存中获取，获取不到的话就先填入一个值
        List list = (List) tcm.getObject(cache, key);
        if (list == null) {
          list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
将结果添加到缓存
          tcm.putObject(cache, key, list); // issue #578 and #116
        }
        return list;
      }
    }
    return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
  }

清空当前缓存

 

private void flushCacheIfRequired(MappedStatement ms) {
    Cache cache = ms.getCache();
    if (cache != null && ms.isFlushCacheRequired()) {
      tcm.clear(cache);
    }
  }
  
    public Object getObject(Cache cache, CacheKey key) {
    return getTransactionalCache(cache).getObject(key);
  }

如果二级缓存没有那么就添加进去

private TransactionalCache getTransactionalCache(Cache cache) {
    return transactionalCaches.computeIfAbsent(cache, TransactionalCache::new);
  }

同样我们也发现在执行非select查询的时候，二级缓存会清理

同样的如果我们使用事务，那么缓存也会在执行结束之后进行释放。

当发生事务回滚的时候也会将之前加入的缓存key给清理掉

 public void rollback() {
    unlockMissedEntries();
    reset();
  }


  private void unlockMissedEntries() {
    for (Object entry : entriesMissedInCache) {
      try {
        delegate.removeObject(entry);
      } catch (Exception e) {
        log.warn("Unexpected exception while notifiying a rollback to the cache adapter."
            + "Consider upgrading your cache adapter to the latest version.  Cause: " + e);
      }
    }
  }

分析到这里可能有人就问了，这个sqlsession会回收的时候，这里的cache会不会被回收掉。答案是肯定得，因为executor是sqlsession的私有变量，cachemanager是executor的私有变量。所以二级缓存其实也会在事务提交的时候进行释放。据此我们做一些相关的测试。

1.关闭一级缓存，开启二级缓存，使用事务。预期会走缓存查询，但是第二次请求会重新建立缓存不会使用第一次请求产生的缓存。

2.关闭一级缓存，开启二级缓存，不使用事务，预期走缓存，但是第二次请求不会使用缓存。

但是作者通过实验发现springboot中并没有提供二级缓存相关的开关，也就是说springboot可能已经抛弃了mybatis的二级缓存。毕竟这里边和业务以及项目整合会有脏数据产生。

通过上述分析，作者并没有发现二级缓存与项目同生共死的作用。反而觉得二级缓存的可用性更低。为什么这么说的原因是每次查询sql，其实都是存sqlsesion池中获取sqlsession，而sqlsession的创建的参数就是executor，executor就是根据我们配置新建的，所以我们的缓存作为executor的私有变量显然也是新的。当然我们还发现cacheexecutor中对事务相关的接口，显然事务操作也会使得二级缓存无效。所以根据作者的分析，二级缓存且不说可能有多么厉害，就这些点个人觉得还没有一级缓存好用。但可能作者的反编译器不够出色，不能看到真相。以后有机会再回过头细细品味吧，就目前来说springboot已经没有二级缓存相关的开启配置了！