惊讶!!困惑我几年的MyBatis一二级缓存竟在这里懂了

惊讶!!困惑我几年的MyBatis一二级缓存竟在这里懂了_第1张图片

惊讶!!困惑我几年的MyBatis一二级缓存竟在这里懂了 【MyBatis源码解析】MyBatis一二级缓存

  • 【MyBatis源码解析】MyBatis一二级缓存
    • MyBatis缓存
    • 一级缓存的CacheKey
    • MyBatis二级缓存

【MyBatis源码解析】MyBatis一二级缓存

MyBatis缓存

我们知道,频繁的数据库操作是非常耗费性能的(主要是因为对于DB而言,数据是持久化在磁盘中的,因此查询操作需要通过IO,IO操作速度相比内存操作速度慢了好几个量级),尤其是对于一些相同的查询语句,完全可以把查询结果存储起来,下次查询同样的内容的时候直接从内存中获取数据即可,这样在某些场景下可以大大提升查询效率。

MyBatis的缓存分为两种:

一级缓存,一级缓存是SqlSession级别的缓存,对于相同的查询,会从缓存中返回结果而不是查询数据库
二级缓存,二级缓存是Mapper级别的缓存,定义在Mapper文件的标签中并需要开启此缓存,多个Mapper文件可以共用一个缓存,依赖标签配置
下面来详细看一下MyBatis的一二级缓存。

MyBatis一级缓存工作流程

接着看一下MyBatis一级缓存工作流程。前面说了,MyBatis的一级缓存是SqlSession级别的缓存,当openSession()的方法运行完毕或者主动调用了SqlSession的close方法,SqlSession就被回收了,一级缓存与此同时也一起被回收掉了。前面的文章有说过,在MyBatis中,无论selectOne还是selectList方法,最终都被转换为了selectList方法来执行,那么看一下SqlSession的selectList方法的实现:

 1 public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
 2     try {
 3       MappedStatement ms = configuration.getMappedStatement(statement);
 4       return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
 5     } catch (Exception e) {
 6       throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
 7     } finally {
 8       ErrorContext.instance().reset();
 9     }
10 }

继续跟踪第4行的代码,到BaseExeccutor的query方法:

1 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
2     BoundSql boundSql = ms.getBoundSql(parameter);
3     CacheKey key = createCacheKey(ms, parameter, rowBounds, boundSql);
4     return query(ms, parameter, rowBounds, resultHandler, key, boundSql);
5 }

第3行构建缓存条件CacheKey,这里涉及到怎么样条件算是和上一次查询是同一个条件的一个问题,因为同一个条件就可以返回上一次的结果回去,这部分代码留在下一部分分析。

接着看第4行的query方法的实现,代码位于CachingExecutor中:

 1 public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
 2       throws SQLException {
 3     Cache cache = ms.getCache();
 4     if (cache != null) {
 5       flushCacheIfRequired(ms);
 6       if (ms.isUseCache() && resultHandler == null) {
 7         ensureNoOutParams(ms, parameterObject, boundSql);
 8         @SuppressWarnings("unchecked")
 9         List<E> list = (List<E>) tcm.getObject(cache, key);
10         if (list == null) {
11           list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
12           tcm.putObject(cache, key, list); // issue #578 and #116
13         }
14         return list;
15       }
16     }
17     return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
18 }

第3行~第16行的代码先不管,继续跟第17行的query方法,代码位于BaseExecutor中:

 1 public <E> List<E> query(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
 2     ErrorContext.instance().resource(ms.getResource()).activity("executing a query").object(ms.getId());
 3     if (closed) {
 4       throw new ExecutorException("Executor was closed.");
 5     }
 6     if (queryStack == 0 && ms.isFlushCacheRequired()) {
 7       clearLocalCache();
 8     }
 9     List<E> list;
10     try {
11       queryStack++;
12       list = resultHandler == null ? (List<E>) localCache.getObject(key) : null;
13       if (list != null) {
14         handleLocallyCachedOutputParameters(ms, key, parameter, boundSql);
15       } else {
16         list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql);
17       }
18     } finally {
19       queryStack--;
20     }
21     ...
22 }

看12行,query的时候会尝试从localCache中去获取查询结果,如果获取到的查询结果为null,那么执行16行的代码从DB中捞数据,捞完之后会把CacheKey作为key,把查询结果作为value放到localCache中。

MyBatis一级缓存存储流程看完了,接着我们从这段代码中可以得到三个结论:

MyBatis的一级缓存是SqlSession级别的,但是它并不定义在SqlSessio接口的实现类DefaultSqlSession中,而是定义在DefaultSqlSession的成员变量Executor中,Executor是在openSession的时候被实例化出来的,它的默认实现为SimpleExecutor
MyBatis中的一级缓存,与有没有配置无关,只要SqlSession存在,MyBastis一级缓存就存在,localCache的类型是PerpetualCache,它其实很简单,一个id属性+一个HashMap属性而已,id是一个名为"localCache"的字符串,HashMap用于存储数据,Key为CacheKey,Value为查询结果
MyBatis的一级缓存查询的时候默认都是会先尝试从一级缓存中获取数据的,但是我们看第6行的代码做了一个判断,ms.isFlushCacheRequired(),即想每次查询都走DB也行,将标签中的flushCache属性设置为true即可,这意味着每次查询的时候都会清理一遍PerpetualCache,PerpetualCache中没数据,自然只能走DB
从MyBatis一级缓存来看,它以单纯的HashMap做缓存,没有容量控制,而一次SqlSession中通常来说并不会有大量的查询操作,因此只适用于一次SqlSession,如果用到二级缓存的Mapper级别的场景,有可能缓存数据不断碰到而导致内存溢出。

还有一点,差点忘了写了,、、最终都会转换为update方法,看一下BaseExecutor的update方法:

1 public int update(MappedStatement ms, Object parameter) throws SQLException {
2     ErrorContext.instance().resource(ms.getResource()).activity("executing an update").object(ms.getId());
3     if (closed) {
4       throw new ExecutorException("Executor was closed.");
5     }
6     clearLocalCache();
7     return doUpdate(ms, parameter);
8 }

第6行clearLocalCache()方法,这意味着所有的增、删、改都会清空本地缓存,这和是否配置了flushCache=true是无关的。

这很好理解,因为增、删、改这三种操作都可能会导致查询出来的结果并不是原来的结果,如果增、删、改不清理缓存,那么可能导致读取出来的数据是脏数据。

一级缓存的CacheKey

接着我们看下一个问题:怎么样的查询条件算和上一次查询是一样的查询,从而返回同样的结果回去?这个问题,得从CacheKey说起。

我们先看一下CacheKey的数据结构:

 1 public class CacheKey implements Cloneable, Serializable {
 2 
 3   private static final long serialVersionUID = 1146682552656046210L;
 4 
 5   public static final CacheKey NULL_CACHE_KEY = new NullCacheKey();
 6 
 7   private static final int DEFAULT_MULTIPLYER = 37;
 8   private static final int DEFAULT_HASHCODE = 17;
 9 
10   private int multiplier;
11   private int hashcode;
12   private long checksum;
13   private int count;
14   private List<Object> updateList;
15   ...
16 }

其中最重要的是第14行的updateList这个两个属性,为什么这么说,因为HashMap的Key是CacheKey,而HashMap的get方法是先判断hashCode,在hashCode冲突的情况下再进行equals判断,因此最终无论如何都会进行一次equals的判断,看下equals方法的实现:

 1 public boolean equals(Object object) {
 2     if (this == object) {
 3       return true;
 4     }
 5     if (!(object instanceof CacheKey)) {
 6       return false;
 7     }
 8 
 9     final CacheKey cacheKey = (CacheKey) object;
10 
11     if (hashcode != cacheKey.hashcode) {
12       return false;
13     }
14     if (checksum != cacheKey.checksum) {
15       return false;
16     }
17     if (count != cacheKey.count) {
18       return false;
19     }
20 
21     for (int i = 0; i < updateList.size(); i++) {
22       Object thisObject = updateList.get(i);
23       Object thatObject = cacheKey.updateList.get(i);
24       if (thisObject == null) {
25         if (thatObject != null) {
26           return false;
27         }
28       } else {
29         if (!thisObject.equals(thatObject)) {
30           return false;
31         }
32       }
33     }
34     return true;
35 }

看到整个方法的流程都是围绕着updateList中的每个属性进行逐一比较,因此再进一步的,我们要看一下updateList中到底存储了什么。

关于updateList里面存储的数据我们可以看下哪里使用了updateList的add方法,然后一步一步反推回去即可。updateList中数据的添加是在doUpdate方法中:

 1 private void doUpdate(Object object) {
 2     int baseHashCode = object == null ? 1 : object.hashCode();
 3 
 4     count++;
 5     checksum += baseHashCode;
 6     baseHashCode *= count;
 7 
 8     hashcode = multiplier * hashcode + baseHashCode;
 9 
10     updateList.add(object);
11 }

它的调用方为update方法:

 1 public void update(Object object) {
 2     if (object != null && object.getClass().isArray()) {
 3       int length = Array.getLength(object);
 4       for (int i = 0; i < length; i++) {
 5         Object element = Array.get(object, i);
 6         doUpdate(element);
 7       }
 8     } else {
 9       doUpdate(object);
10     }
11 }

这里主要是对输入参数是数组类型进行了一次判断,是数组就遍历逐一做doUpdate,否则就直接做doUpdate。再看update方法的调用方,其实update方法的调用方有挺多处,但是这里我们要看的是Executor中的,看一下BaseExecutor中的createCacheKey方法实现:

 1 public CacheKey createCacheKey(MappedStatement ms, Object parameterObject, RowBounds rowBounds, BoundSql boundSql) {
 2     if (closed) {
 3       throw new ExecutorException("Executor was closed.");
 4     }
 5     CacheKey cacheKey = new CacheKey();
 6     cacheKey.update(ms.getId());
 7     cacheKey.update(rowBounds.getOffset());
 8     cacheKey.update(rowBounds.getLimit());
 9     cacheKey.update(boundSql.getSql());
10     List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
11     TypeHandlerRegistry typeHandlerRegistry = ms.getConfiguration().getTypeHandlerRegistry();
12     // mimic DefaultParameterHandler logic
13     for (ParameterMapping parameterMapping : parameterMappings) {
14       if (parameterMapping.getMode() != ParameterMode.OUT) {
15         Object value;
16         String propertyName = parameterMapping.getProperty();
17         if (boundSql.hasAdditionalParameter(propertyName)) {
18           value = boundSql.getAdditionalParameter(propertyName);
19         } else if (parameterObject == null) {
20           value = null;
21         } else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {
22           value = parameterObject;
23         } else {
24           MetaObject metaObject = configuration.newMetaObject(parameterObject);
25           value = metaObject.getValue(propertyName);
26         }
27         cacheKey.update(value);
28       }
29     }
30     if (configuration.getEnvironment() != null) {
31       // issue #176
32       cacheKey.update(configuration.getEnvironment().getId());
33     }
34     return cacheKey;
35 }

到了这里应当一目了然了,MyBastis从四组共五个条件判断两次查询是相同的:

标签所在的Mapper的Namespace+标签的id属性
RowBounds的offset和limit属性,RowBounds是MyBatis用于处理分页的一个类,offset默认为0,limit默认为Integer.MAX_VALUE
标签中定义的sql语句
输入参数的具体参数值,一个int值就update一个int,一个String值就update一个String,一个List就轮询里面的每个元素进行update
即只要两次查询满足以上三个条件且没有定义flushCache=“true”,那么第二次查询会直接从MyBatis一级缓存PerpetualCache中返回数据,而不会走DB。

MyBatis二级缓存

上面说完了MyBatis,接着看一下MyBatis二级缓存,还是从二级缓存工作流程开始。还是从DefaultSqlSession的selectList方法进去:

 1 public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
 2     try {
 3       MappedStatement ms = configuration.getMappedStatement(statement);
 4       return executor.query(ms, wrapCollection(parameter), rowBounds, Executor.NO_RESULT_HANDLER);
 5     } catch (Exception e) {
 6       throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
 7     } finally {
 8       ErrorContext.instance().reset();
 9     }
10 }

执行query方法,方法位于CachingExecutor中:

1 public List query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
2 BoundSql boundSql = ms.getBoundSql(parameterObject);
3 CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
4 return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
5 }
继续跟第4行的query方法,同样位于CachingExecutor中:

 1 public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
 2       throws SQLException {
 3     Cache cache = ms.getCache();
 4     if (cache != null) {
 5       flushCacheIfRequired(ms);
 6       if (ms.isUseCache() && resultHandler == null) {
 7         ensureNoOutParams(ms, parameterObject, boundSql);
 8         @SuppressWarnings("unchecked")
 9         List<E> list = (List<E>) tcm.getObject(cache, key);
10         if (list == null) {
11           list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
12           tcm.putObject(cache, key, list); // issue #578 and #116
13         }
14         return list;
15       }
16     }
17     return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
18 }

从这里看到,执行第17行的BaseExecutor的query方法之前,会先拿Mybatis二级缓存,而BaseExecutor的query方法会优先读取MyBatis一级缓存,由此可以得出一个重要结论:假如定义了MyBatis二级缓存,那么MyBatis二级缓存读取优先级高于MyBatis一级缓存。

而第3行~第16行的逻辑:

第5行的方法很好理解,根据flushCache=true或者flushCache=false判断是否要清理二级缓存
第7行的方法是保证MyBatis二级缓存不会存储存储过程的结果
第9行的方法先尝试从tcm中获取查询结果,这个tcm解释一下,这又是一个装饰器模式(数数MyBatis用到了多少装饰器模式了),创建一个事物缓存TranactionalCache,持有Cache接口,Cache接口的实现类就是根据我们在Mapper文件中配置的创建的Cache实例
第10行~第12行,如果没有从MyBatis二级缓存中拿到数据,那么就会查一次数据库,然后放到MyBatis二级缓存中去
至于如何判定上次查询和这次查询是一次查询?由于这里的CacheKey和MyBatis一级缓存使用的是同一个CacheKey,因此它的判定条件和前文写过的MyBatis一级缓存三个维度的判定条件是一致的。

最后再来谈一点,"Cache cache = ms.getCache()"这句代码十分重要,这意味着Cache是从MappedStatement中获取到的,而MappedStatement又和每一个、、、绑定并在MyBatis启动的时候存入Configuration中:

protected final Map<String, MappedStatement> mappedStatements = new StrictMap<MappedStatement>("Mapped Statements collection");

因此MyBatis二级缓存的生命周期即整个应用的生命周期,应用不结束,定义的二级缓存都会存在在内存中。

从这个角度考虑,为了避免MyBatis二级缓存中数据量过大导致内存溢出,MyBatis在配置文件中给我们增加了很多配置例如size(缓存大小)、flushInterval(缓存清理时间间隔)、eviction(数据淘汰算法)来保证缓存中存储的数据不至于太过庞大。

MyBatis二级缓存实例化过程

接着看一下MyBatis二级缓存实例化的过程,代码位于XmlMapperBuilder的cacheElement方法中:

 1 private void cacheElement(XNode context) throws Exception {
 2     if (context != null) {
 3       String type = context.getStringAttribute("type", "PERPETUAL");
 4       Class<? extends Cache> typeClass = typeAliasRegistry.resolveAlias(type);
 5       String eviction = context.getStringAttribute("eviction", "LRU");
 6       Class<? extends Cache> evictionClass = typeAliasRegistry.resolveAlias(eviction);
 7       Long flushInterval = context.getLongAttribute("flushInterval");
 8       Integer size = context.getIntAttribute("size");
 9       boolean readWrite = !context.getBooleanAttribute("readOnly", false);
10       boolean blocking = context.getBooleanAttribute("blocking", false);
11       Properties props = context.getChildrenAsProperties();
12       builderAssistant.useNewCache(typeClass, evictionClass, flushInterval, size, readWrite, blocking, props);
13     }
14 }

这里分别取中配置的各个属性,关注一下两个默认值:

type表示缓存实现,默认是PERPETUAL,根据typeAliasRegistry中注册的,PERPETUAL实际对应PerpetualCache,这和MyBatis一级缓存是一致的
eviction表示淘汰算法,默认是LRU算法
第3行~第11行拿到了所有属性,那么调用12行的useNewCache方法创建缓存:

 1 public Cache useNewCache(Class<? extends Cache> typeClass,
 2       Class<? extends Cache> evictionClass,
 3       Long flushInterval,
 4       Integer size,
 5       boolean readWrite,
 6       boolean blocking,
 7       Properties props) {
 8     Cache cache = new CacheBuilder(currentNamespace)
 9         .implementation(valueOrDefault(typeClass, PerpetualCache.class))
10         .addDecorator(valueOrDefault(evictionClass, LruCache.class))
11         .clearInterval(flushInterval)
12         .size(size)
13         .readWrite(readWrite)
14         .blocking(blocking)
15         .properties(props)
16         .build();
17     configuration.addCache(cache);
18     currentCache = cache;
19     return cache;
20 }

这里又使用了建造者模式,跟一下第16行的build()方法,在此之前该传入的参数都已经传入了CacheBuilder:

 1 public Cache build() {
 2     setDefaultImplementations();
 3     Cache cache = newBaseCacheInstance(implementation, id);
 4     setCacheProperties(cache);
 5     // issue #352, do not apply decorators to custom caches
 6     if (PerpetualCache.class.equals(cache.getClass())) {
 7       for (Class<? extends Cache> decorator : decorators) {
 8         cache = newCacheDecoratorInstance(decorator, cache);
 9         setCacheProperties(cache);
10       }
11       cache = setStandardDecorators(cache);
12     } else if (!LoggingCache.class.isAssignableFrom(cache.getClass())) {
13       cache = new LoggingCache(cache);
14     }
15     return cache;
16 }

第3行的代码,构建基础的缓存,implementation指的是type配置的值,这里是默认的PerpetualCache。

第6行的代码,如果是PerpetualCache,那么继续装饰(又是装饰器模式,可以数数这几篇MyBatis源码解析的文章里面出现了多少次装饰器模式了),这里的装饰是根据eviction进行装饰,到这一步,给PerpetualCache加上了LRU的功能。

第11行的代码,继续装饰,这次MyBatis将它命名为标准装饰,setStandardDecorators方法实现为:

 1 private Cache setStandardDecorators(Cache cache) {
 2     try {
 3       MetaObject metaCache = SystemMetaObject.forObject(cache);
 4       if (size != null && metaCache.hasSetter("size")) {
 5         metaCache.setValue("size", size);
 6       }
 7       if (clearInterval != null) {
 8         cache = new ScheduledCache(cache);
 9         ((ScheduledCache) cache).setClearInterval(clearInterval);
10       }
11       if (readWrite) {
12         cache = new SerializedCache(cache);
13       }
14       cache = new LoggingCache(cache);
15       cache = new SynchronizedCache(cache);
16       if (blocking) {
17         cache = new BlockingCache(cache);
18       }
19       return cache;
20     } catch (Exception e) {
21       throw new CacheException("Error building standard cache decorators.  Cause: " + e, e);
22     }
23 }

这次是根据其它的配置参数来:

如果配置了flushInterval,那么继续装饰为ScheduledCache,这意味着在调用Cache的getSize、putObject、getObject、removeObject四个方法的时候都会进行一次时间判断,如果到了指定的清理缓存时间间隔,那么就会将当前缓存清空
如果readWrite=true,那么继续装饰为SerializedCache,这意味着缓存中所有存储的内存都必须实现Serializable接口
跟配置无关,将之前装饰好的Cache继续装饰为LoggingCache与SynchronizedCache,前者在getObject的时候会打印缓存命中率,后者将Cache接口中所有的方法都加了Synchronized关键字进行了同步处理
如果blocking=true,那么继续装饰为BlockingCache,这意味着针对同一个CacheKey,拿数据与放数据、删数据是互斥的,即拿数据的时候必须没有在放数据、删数据
Cache全部装饰完毕,返回,至此MyBatis二级缓存生成完毕。

最后说一下,MyBatis支持三种类型的二级缓存:

MyBatis默认的缓存,type为空,Cache为PerpetualCache
自定义缓存
第三方缓存
从build()方法来看,后两种场景的Cache,MyBatis只会将其装饰为LoggingCache,理由很简单,这些缓存的定期清除功能、淘汰过期数据功能开发者自己或者第三方缓存都已经实现好了,根本不需要依赖MyBatis本身的装饰。

MyBatis二级缓存带来的问题

补充一个内容,MyBatis二级缓存使用的在某些场景下会出问题,来看一下为什么这么说。

假设我有一条select语句(开启了二级缓存):

select a.col1, a.col2, a.col3, b.col1, b.col2, b.col3 from tableA a, tableB b where a.id = b.id;
对于tableA与tableB的操作定义在两个Mapper中,分别叫做MapperA与MapperB,即它们属于两个命名空间,如果此时启用缓存:

MapperA中执行上述sql语句查询这6个字段
tableB更新了col1与col2两个字段
MapperA再次执行上述sql语句查询这6个字段(前提是没有执行过任何insert、delete、update操作)
此时问题就来了,即使第(2)步tableB更新了col1与col2两个字段,第(3)步MapperA走二级缓存查询到的这6个字段依然是原来的这6个字段的值,因为我们从CacheKey的3组条件来看:

标签所在的Mapper的Namespace+标签的id属性
RowBounds的offset和limit属性,RowBounds是MyBatis用于处理分页的一个类,offset默认为0,limit默认为Integer.MAX_VALUE
标签中定义的sql语句
对于MapperA来说,其中的任何一个条件都没有变化,自然会将原结果返回。

这个问题对于MyBatis的二级缓存来说是一个无解的问题,因此使用MyBatis二级缓存有一个前提:必须保证所有的增删改查都在同一个命名空间下才行。

==================================================================================

我不能保证写的每个地方都是对的,但是至少能保证不复制、不黏贴,保证每一句话、每一行代码都经过了认真的推敲、仔细的斟酌。每一篇文章的背后,希望都能看到自己对于技术、对于生活的态度。

我相信乔布斯说的,只有那些疯狂到认为自己可以改变世界的人才能真正地改变世界。面对压力,我可以挑灯夜战、不眠不休;面对困难,我愿意迎难而上、永不退缩。

参考文献

你可能感兴趣的:(后端)