MyBatis源码分析(五):MyBatis Cache分析
一、Mybatis缓存介绍
在Mybatis中,它提供了一级缓存和二级缓存,默认的情况下只开启一级缓存,所以默认情况下是开启了缓存的,除非明确指定不开缓存功能。使用缓存的目的就是把数据保存在内存中,是应用能更快获取数据,避免与数据库频繁交互,特别是在查询比较多、命中率比较高的情况下,缓存就显得很重要。但是使用不得当,会产生脏数据。
二、目录
- 一级缓存介绍及相关配置。
- 一级缓存工作流程及源码分析。
- 一级缓存总结。
- 二级缓存介绍及相关配置。
- 二级缓存源码分析。
- 二级缓存总结。
- 全文总结。
三、一级缓存介绍及相关配置
一级缓存是有Session、Statement两种级别。Session级别,在同一个SqlSession中,执行相同的SQL查询,第一次从数据库里面找出来,然后写到缓存中,后续的查询就会从一级缓存中取出来。若是在一次数据库会话中发生了在修改操作后,再次执行的相同查询,会发现Myabtis查询了数据库,说明一级缓存失效;如果没有声明要刷新,而且缓存时间超时了,缓存会被清空。Statement级别,可以理解为支队当前执行的这个Statement有效。
mybatis-config中关于缓存的部分配置:
1 <setting name="localCacheScope" value="SESSION"/>
四、一级缓存工作流程以及源码分析
执行流程大致为下图:
在上一篇文章中的BaseExecutor的query方法中有一断代码,根据算法生成的key,从缓存中查询是否存在需要查询的的对象,若为空,则从数据库中查询结果
1 try { 2 queryStack++; 3 list = resultHandler == null ? (List<E>) localCache.getObject(key) : null; //从缓存中查询 4 if (list != null) { 5 handleLocallyCachedOutputParameters(ms, key, parameter, boundSql); 6 } else { 7 list = queryFromDatabase(ms, parameter, rowBounds, resultHandler, key, boundSql); //从数据库中查询 8 } 9 } finally { 10 queryStack--; 11 }
BaseExecutor成员变量之一的PerpetualCache,是对Cache接口最基本的实现,其实现非常简单,内部持有HashMap,对一级缓存的操作实则是对HashMap的操作。如下代码所示:
1 public class PerpetualCache implements Cache { 2 3 private final String id; 4 5 private Map<Object, Object> cache = new HashMap<>(); 6 7 ... ... 8 }
SQL语句执行过程在上一篇文章中已经详细解释,BaseExecutor的query方法执行到最后会判断一级缓存级别是否是STATEMENT
级别,如果是的话,就清空缓存,这也就是STATEMENT
级别的一级缓存无法共享localCache的原因
1 if (queryStack == 0) { 2 for (DeferredLoad deferredLoad : deferredLoads) { 3 deferredLoad.load(); 4 } 5 // issue #601 6 deferredLoads.clear(); 7 if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) { 8 // issue #482 9 clearLocalCache(); 10 } 11 }
接下来看insert和delete方法,它们都是走update方法
1 @Override 2 public int insert(String statement) { 3 return insert(statement, null); 4 } 5 6 @Override 7 public int insert(String statement, Object parameter) { 8 return update(statement, parameter); 9 } 10 11 @Override 12 public int delete(String statement) { 13 return update(statement, null); 14 } 15 16 @Override 17 public int delete(String statement, Object parameter) { 18 return update(statement, parameter); 19 }
1 @Override 2 public int update(String statement, Object parameter) { 3 try { 4 dirty = true; 5 MappedStatement ms = configuration.getMappedStatement(statement); 6 return executor.update(ms, wrapCollection(parameter)); 7 } catch (Exception e) { 8 throw ExceptionFactory.wrapException("Error updating database. Cause: " + 9 e, e); 10 } finally { 11 ErrorContext.instance().reset(); 12 } 13 }
再转到BaseExecutor看update方法,最后把doUpdate交给了继承了BaseExecutor的Executor中
1 @Override 2 public int update(MappedStatement ms, Object parameter) throws SQLException { 3 ErrorContext.instance().resource(ms.getResource()).activity("executing an update").object(ms.getId()); 4 if (closed) { 5 throw new ExecutorException("Executor was closed."); 6 } 7 clearLocalCache(); //清空了缓存 8 return doUpdate(ms, parameter); 9 }
再看到SimpleExecutor(默认)源码,清空了缓存,然后往数据库中执行更新操作,所以一级缓存发生更新操作时,会清空缓存
1 @Override 2 public int doUpdate(MappedStatement ms, Object parameter) throws SQLException { 3 Statement stmt = null; 4 try { 5 Configuration configuration = ms.getConfiguration(); 6 StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null); 7 stmt = prepareStatement(handler, ms.getStatementLog()); 8 return handler.update(stmt); 9 } finally { 10 closeStatement(stmt); 11 } 12 }
然后都是上一篇介绍SQL执行过程的内容了。
五、一级缓存的总结
-
MyBatis一级缓存的生命周期和SqlSession一致。
-
MyBatis一级缓存内部设计简单,只是一个没有容量限定的HashMap,在缓存的功能性上有所欠缺。
-
MyBatis的一级缓存最大范围是SqlSession内部,有多个SqlSession或者分布式的环境下,数据库写操作会引起脏数据,建议设定缓存级别为Statement。
六、二级缓存介绍及相关配置
一级缓存中最大的共享范围是一个SqlSession内部,如果多个SqlSession之间需要共享缓存,则需要开启二级缓存。二级缓存开启的时候,调用Configuration的newExecutor方法,利用CachingExecutor装饰Executor,在进入一级缓存的查询前,先执行二级缓存的查询的流程。
mybatis-config中关于开启二级缓存的部分配置:
1 <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。
1 @Override 2 public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) 3 throws SQLException { 4 Cache cache = ms.getCache(); //获取配置初始化时的cache 5 if (cache != null) { 6 flushCacheIfRequired(ms); //判断是否刷新 7 if (ms.isUseCache() && resultHandler == null) { 8 ensureNoOutParams(ms, boundSql); //主要是用来处理存储过程的 9 @SuppressWarnings("unchecked") 10 List<E> list = (List<E>) tcm.getObject(cache, key); //从tcm中获取缓存的列表,把获取值的职责一路传递,最终到perpetualCache
11 if (list == null) {
12 list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
13 tcm.putObject(cache, key, list); //如果查询到数据,则调用tcm.putObject
方法,往缓存中放入值;不是直接操作缓存,只是在把这次的数据和key放入待提交的Map中
14 }
15 return list;
16 }
17 }
18 return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
19 }
以下是具体这些Cache实现类的介绍,他们的组合为Cache赋予了不同的能力。
- SynchronizedCache:同步Cache,实现比较简单,直接使用synchronized修饰方法。
- LoggingCache:日志功能,装饰类,用于记录缓存的命中率,如果开启了DEBUG模式,则会输出命中率日志。
- SerializedCache:序列化功能,将值序列化后存到缓存中。该功能用于缓存返回一份实例的Copy,用于保存线程安全。
- LruCache:采用了Lru算法的Cache实现,移除最近最少使用的Key/Value。
- PerpetualCache: 作为为最基础的缓存类,底层实现比较简单,直接使用了HashMap。
看到Lru算法,再来说说缓存的收回策略 eviction :
- LRU(最近最少使用的):移除最长时间不被使用的对象,这是默认值
- FIFO(先进先出): 按对象进入缓存的顺序来移除它们
- SOFT(软引用):移除基于垃圾回收器状态和软引用规则的对象
- WEAK(弱引用):更积极地移除基于垃圾收集器状态和弱引用规则的对象
1 <cache 2 eviction = "FIFO" 3 flushlnterval = "60000" 4 size = "512" 5 readOnly = "true" \ />
flushinterval (刷新间隔):可以被设置为任意的正整数,而且它们代表一个合理的毫秒形式的时间段。默认情况不设置,即没有刷新间隔,缓存仅仅在调用语句时刷新。
size (引用数目):可以被设置为任意正整数,要记住缓存的对象数目和运行环境的可用内存资源数目。默认值是 1024。
readOnly (只读):属性可以被设置为 true false 。只读的缓存会给所有调用者 返回缓存对象的相同实例,因此这些对象不能被修改 这提供了很重要的性能优势。可读写的缓存会通过序列化返回缓存对象的拷贝,这种方式会慢一些,但是安全。因此默认是 false。
MyBatis的CachingExecutor持有了TransactionalCacheManager,上面的tcm,它里面有一个Map,这个Map保存了Cache和TransactionalCache包装后的clear方法
1 private Map<Cache, TransactionalCache> transactionalCaches = new HashMap<Cache, TransactionalCache>();
TransactionalCache实现了Cache接口,CachingExecutor会默认使用他包装初始生成的Cache,作用是如果事务提交,对缓存的操作才会生效,如果事务回滚或者不提交事务,则不对缓存产生影响。TransactionalCache里面有一个clear方法
1 @Override 2 public void clear() { 3 clearOnCommit = true; 4 entriesToAddOnCommit.clear(); 5 }
CachingExecutor里面的commit方法
1 @Override 2 public void commit(boolean required) throws SQLException { 3 delegate.commit(required); 4 tcm.commit(); 5 }
TransactionalCachingManager的commit方法
1 public void commit() { 2 for (TransactionalCache txCache : transactionalCaches.values()) { 3 txCache.commit(); 4 } 5 }
TransactionalCache的commit方法
1 public void commit() { 2 if (clearOnCommit) { 3 delegate.clear(); 4 } 5 flushPendingEntries(); 6 reset(); 7 }
TransactionalCache的flushPendingEntries方法,在flushPendingEntries中,将待提交的Map进行循环处理,委托给包装的Cache类,进行putObject的操作。
1 private void flushPendingEntries() { 2 for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) { 3 delegate.putObject(entry.getKey(), entry.getValue()); 4 } 5 ...... 6 }
后续的查询操作会重复执行这套流程。如果是 insert | update | delete 的话,会统一进入CachingExecutor的update方法
1 private void flushCacheIfRequired(MappedStatement ms)
二级缓存执行后会执行一级缓存操作。
八、二级缓存总结
-
MyBatis的二级缓存相对于一级缓存来说,实现了SqlSession之间缓存数据的共享,同时粒度更加的细,能够到namespace级别,通过Cache接口实现类不同的组合,对Cache的可控性也更强。
-
MyBatis在多表查询时,极大可能会出现脏数据,有设计上的缺陷,安全使用二级缓存的条件比较苛刻。
-
在分布式环境下,由于默认的MyBatis Cache实现都是基于本地的,分布式环境下必然会出现读取到脏数据,需要使用集中式缓存将MyBatis的Cache接口实现,有一定的开发成本,直接使用Redis、Memcached等分布式缓存可能成本更低,安全性也更高。
九、总结
本文对介绍了MyBatis一二级缓存的基本概念,并从应用及源码的角度对MyBatis的缓存机制进行了分析。最后对MyBatis缓存机制做了一定的总结,个人建议MyBatis缓存特性在生产环境中进行关闭,单纯作为一个ORM框架使用可能更为合适。
参考:聊聊MyBatis缓存机制