mybatis缓存
我们知道，频繁的数据库操作是非常耗费性能的（主要是因为对于db而言，数据是持久化在磁盘中的，因此查询操作需要通过io，io操作速度相比内存操作速度慢了好几个量级），尤其是对于一些相同的查询语句，完全可以把查询结果存储起来，下次查询同样的内容的时候直接从内存中获取数据即可，这样在某些场景下可以大大提升查询效率。
mybatis的缓存分为两种：
一级缓存，一级缓存是sqlsession级别的缓存，对于相同的查询，会从缓存中返回结果而不是查询数据库
二级缓存，二级缓存是mapper级别的缓存，定义在mapper文件的<cache>标签中并需要开启此缓存，多个mapper文件可以共用一个缓存，依赖<cache-ref>标签配置
下面来详细看一下mybatis的一二级缓存。
mybatis一级缓存工作流程
接着看一下mybatis一级缓存工作流程。前面说了，mybatis的一级缓存是sqlsession级别的缓存，当opensession()的方法运行完毕或者主动调用了sqlsession的close方法，sqlsession就被回收了，一级缓存与此同时也一起被回收掉了。前面的文章有说过，在mybatis中，无论selectone还是selectlist方法，最终都被转换为了selectlist方法来执行，那么看一下sqlsession的selectlist方法的实现：
我要评论
public <e> list<e> selectlist(string statement, object parameter, rowbounds rowbounds) {
try {
mappedstatement ms = configuration.getmappedstatement(statement);
return executor.query(ms, wrapcollection(parameter), rowbounds, executor.no_result_handler);
} catch (exception e) {
throw exceptionfactory.wrapexception("error querying database. cause: " + e, e);
} finally {
errorcontext.instance().reset();
}
}
继续跟踪第4行的代码，到baseexeccutor的query方法：
public <e> list<e> query(mappedstatement ms, object parameter, rowbounds rowbounds, resulthandler resulthandler) throws sqlexception {
boundsql boundsql = ms.getboundsql(parameter);
cachekey key = createcachekey(ms, parameter, rowbounds, boundsql);
return query(ms, parameter, rowbounds, resulthandler, key, boundsql);
}
第3行构建缓存条件cachekey，这里涉及到怎么样条件算是和上一次查询是同一个条件的一个问题，因为同一个条件就可以返回上一次的结果回去，这部分代码留在下一部分分析。
接着看第4行的query方法的实现，代码位于cachingexecutor中：
public <e> list<e> query(mappedstatement ms, object parameterobject, rowbounds rowbounds, resulthandler resulthandler, cachekey key, boundsql boundsql)
throws sqlexception {
cache cache = ms.getcache();
if (cache != null) {
flushcacheifrequired(ms);
if (ms.isusecache() && resulthandler == null) {
ensurenooutparams(ms, parameterobject, boundsql);
@suppresswarnings("unchecked")
list<e> list = (list<e>) tcm.getobject(cache, key);
if (list == null) {
list = delegate.<e> query(ms, parameterobject, rowbounds, resulthandler, key, boundsql);
tcm.putobject(cache, key, list); // issue #578 and #116
}
return list;
}
}
return delegate.<e> query(ms, parameterobject, rowbounds, resulthandler, key, boundsql);
}
第3行~第16行的代码先不管，继续跟第17行的query方法，代码位于baseexecutor中：
public <e> list<e> query(mappedstatement ms, object parameter, rowbounds rowbounds, resulthandler resulthandler, cachekey key, boundsql boundsql) throws sqlexception {
errorcontext.instance().resource(ms.getresource()).activity("executing a query").object(ms.getid());
if (closed) {
throw new executorexception("executor was closed.");
}
if (querystack == 0 && ms.isflushcacherequired()) {
clearlocalcache();
}
list<e> list;
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--;
}
...
}
看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也行，将<select>标签中的flushcache属性设置为true即可，这意味着每次查询的时候都会清理一遍perpetualcache，perpetualcache中没数据，自然只能走db
从mybatis一级缓存来看，它以单纯的hashmap做缓存，没有容量控制，而一次sqlsession中通常来说并不会有大量的查询操作，因此只适用于一次sqlsession，如果用到二级缓存的mapper级别的场景，有可能缓存数据不断碰到而导致内存溢出。
还有一点，差点忘了写了，<insert>、<delete>、<update>最终都会转换为update方法，看一下baseexecutor的update方法：
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);
}
第6行clearlocalcache()方法，这意味着所有的增、删、改都会清空本地缓存，这和是否配置了flushcache=true是无关的。
这很好理解，因为增、删、改这三种操作都可能会导致查询出来的结果并不是原来的结果，如果增、删、改不清理缓存，那么可能导致读取出来的数据是脏数据。
一级缓存的cachekey
接着我们看下一个问题：怎么样的查询条件算和上一次查询是一样的查询，从而返回同样的结果回去？这个问题，得从cachekey说起。
我们先看一下cachekey的数据结构：
public class cachekey implements cloneable, serializable {
private static final long serialversionuid = 1146682552656046210l;
public static final cachekey null_cache_key = new nullcachekey();
private static final int default_multiplyer = 37;
private static final int default_hashcode = 17;
private int multiplier;
private int hashcode;
private long checksum;
private int count;
private list<object> updatelist;
...
}
其中最重要的是第14行的updatelist这个两个属性，为什么这么说，因为hashmap的key是cachekey，而hashmap的get方法是先判断hashcode，在hashcode冲突的情况下再进行equals判断，因此最终无论如何都会进行一次equals的判断，看下equals方法的实现：
public boolean equals(object object) {
if (this == object) {
return true;
}
if (!(object instanceof cachekey)) {
return false;
}
final cachekey cachekey = (cachekey) object;
if (hashcode != cachekey.hashcode) {
return false;
}
if (checksum != cachekey.checksum) {
return false;
}
if (count != cachekey.count) {
return false;
}
for (int i = 0; i < updatelist.size(); i++) {
object thisobject = updatelist.get(i);
object thatobject = cachekey.updatelist.get(i);
if (thisobject == null) {
if (thatobject != null) {
return false;
}
} else {
if (!thisobject.equals(thatobject)) {
return false;
}
}
}
return true;
}
看到整个方法的流程都是围绕着updatelist中的每个属性进行逐一比较，因此再进一步的，我们要看一下updatelist中到底存储了什么。
关于updatelist里面存储的数据我们可以看下哪里使用了updatelist的add方法，然后一步一步反推回去即可。updatelist中数据的添加是在doupdate方法中：
private void doupdate(object object) {
int basehashcode = object == null ? 1 : object.hashcode();
count++;
checksum += basehashcode;
basehashcode *= count;
hashcode = multiplier * hashcode + basehashcode;
updatelist.add(object);
}
它的调用方为update方法：
public void update(object object) {
if (object != null && object.getclass().isarray()) {
int length = array.getlength(object);
for (int i = 0; i < length; i++) {
object element = array.get(object, i);
doupdate(element);
}
} else {
doupdate(object);
}
}
这里主要是对输入参数是数组类型进行了一次判断，是数组就遍历逐一做doupdate，否则就直接做doupdate。再看update方法的调用方，其实update方法的调用方有挺多处，但是这里我们要看的是executor中的，看一下baseexecutor中的createcachekey方法实现：
... cachekey cachekey = new cachekey(); cachekey.update(ms.getid()); cachekey.update(rowbounds.getoffset()); cachekey.update(rowbounds.getlimit()); cachekey.update(boundsql.getsql()); ...
到了这里应当一目了然了，mybastis从三个维度判断两次查询是相同的：
<select>标签所在的mapper的namespace+<select>标签的id属性
rowbounds的offset和limit属性，rowbounds是mybatis用于处理分页的一个类，offset默认为0，limit默认为integer.max_value
<select>标签中定义的sql语句
即只要两次查询满足以上三个条件且没有定义flushcache="true"，那么第二次查询会直接从mybatis一级缓存perpetualcache中返回数据，而不会走db。
mybatis二级缓存
上面说完了mybatis，接着看一下mybatis二级缓存，还是从二级缓存工作流程开始。还是从defaultsqlsession的selectlist方法进去：
public <e> list<e> selectlist(string statement, object parameter, rowbounds rowbounds) {
try {
mappedstatement ms = configuration.getmappedstatement(statement);
return executor.query(ms, wrapcollection(parameter), rowbounds, executor.no_result_handler);
} catch (exception e) {
throw exceptionfactory.wrapexception("error querying database. cause: " + e, e);
} finally {
errorcontext.instance().reset();
}
}
执行query方法，方法位于cachingexecutor中：
public <e> list<e> query(mappedstatement ms, object parameterobject, rowbounds rowbounds, resulthandler resulthandler) throws sqlexception {
boundsql boundsql = ms.getboundsql(parameterobject);
cachekey key = createcachekey(ms, parameterobject, rowbounds, boundsql);
return query(ms, parameterobject, rowbounds, resulthandler, key, boundsql);
}
继续跟第4行的query方法，同样位于cachingexecutor中：
public <e> list<e> query(mappedstatement ms, object parameterobject, rowbounds rowbounds, resulthandler resulthandler, cachekey key, boundsql boundsql)
throws sqlexception {
cache cache = ms.getcache();
if (cache != null) {
flushcacheifrequired(ms);
if (ms.isusecache() && resulthandler == null) {
ensurenooutparams(ms, parameterobject, boundsql);
@suppresswarnings("unchecked")
list<e> list = (list<e>) tcm.getobject(cache, key);
if (list == null) {
list = delegate.<e> query(ms, parameterobject, rowbounds, resulthandler, key, boundsql);
tcm.putobject(cache, key, list); // issue #578 and #116
}
return list;
}
}
return delegate.<e> query(ms, parameterobject, rowbounds, resulthandler, key, boundsql);
}
从这里看到，执行第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>创建的cache实例
第10行~第12行，如果没有从mybatis二级缓存中拿到数据，那么就会查一次数据库，然后放到mybatis二级缓存中去
至于如何判定上次查询和这次查询是一次查询？由于这里的cachekey和mybatis一级缓存使用的是同一个cachekey，因此它的判定条件和前文写过的mybatis一级缓存三个维度的判定条件是一致的。
最后再来谈一点，"cache cache = ms.getcache()"这句代码十分重要，这意味着cache是从mappedstatement中获取到的，而mappedstatement又和每一个<insert>、<delete>、<update>、<select>绑定并在mybatis启动的时候存入configuration中：
protected final map<string, mappedstatement> mappedstatements = new strictmap<mappedstatement>("mapped statements collection");
因此mybatis二级缓存的生命周期即整个应用的生命周期，应用不结束，定义的二级缓存都会存在在内存中。
从这个角度考虑，为了避免mybatis二级缓存中数据量过大导致内存溢出，mybatis在配置文件中给我们增加了很多配置例如size（缓存大小）、flushinterval（缓存清理时间间隔）、eviction（数据淘汰算法）来保证缓存中存储的数据不至于太过庞大。
mybatis二级缓存实例化过程
接着看一下mybatis二级缓存<cache>实例化的过程，代码位于xmlmapperbuilder的cacheelement方法中：
private void cacheelement(xnode context) throws exception {
if (context != null) {
string type = context.getstringattribute("type", "perpetual");
class<? extends cache> typeclass = typealiasregistry.resolvealias(type);
string eviction = context.getstringattribute("eviction", "lru");
class<? extends cache> evictionclass = typealiasregistry.resolvealias(eviction);
long flushinterval = context.getlongattribute("flushinterval");
integer size = context.getintattribute("size");
boolean readwrite = !context.getbooleanattribute("readonly", false);
boolean blocking = context.getbooleanattribute("blocking", false);
properties props = context.getchildrenasproperties();
builderassistant.usenewcache(typeclass, evictionclass, flushinterval, size, readwrite, blocking, props);
}
}
这里分别取<cache>中配置的各个属性，关注一下两个默认值：
type表示缓存实现，默认是perpetual，根据typealiasregistry中注册的，perpetual实际对应perpetualcache，这和mybatis一级缓存是一致的
eviction表示淘汰算法，默认是lru算法
第3行~第11行拿到了所有属性，那么调用12行的usenewcache方法创建缓存：
public cache usenewcache(class<? extends cache> typeclass,
class<? extends cache> evictionclass,
long flushinterval,
integer size,
boolean readwrite,
boolean blocking,
properties props) {
cache cache = new cachebuilder(currentnamespace)
.implementation(valueordefault(typeclass, perpetualcache.class))
.adddecorator(valueordefault(evictionclass, lrucache.class))
.clearinterval(flushinterval)
.size(size)
.readwrite(readwrite)
.blocking(blocking)
.properties(props)
.build();
configuration.addcache(cache);
currentcache = cache;
return cache;
}
这里又使用了建造者模式，跟一下第16行的build()方法，在此之前该传入的参数都已经传入了cachebuilder：
public cache build() {
setdefaultimplementations();
cache cache = newbasecacheinstance(implementation, id);
setcacheproperties(cache);
// issue #352, do not apply decorators to custom caches
if (perpetualcache.class.equals(cache.getclass())) {
for (class<? extends cache> decorator : decorators) {
cache = newcachedecoratorinstance(decorator, cache);
setcacheproperties(cache);
}
cache = setstandarddecorators(cache);
} else if (!loggingcache.class.isassignablefrom(cache.getclass())) {
cache = new loggingcache(cache);
}
return cache;
}
第3行的代码，构建基础的缓存，implementation指的是type配置的值，这里是默认的perpetualcache。
第6行的代码，如果是perpetualcache，那么继续装饰（又是装饰器模式，可以数数这几篇mybatis源码解析的文章里面出现了多少次装饰器模式了），这里的装饰是根据eviction进行装饰，到这一步，给perpetualcache加上了lru的功能。
第11行的代码，继续装饰，这次mybatis将它命名为标准装饰，setstandarddecorators方法实现为：
private cache setstandarddecorators(cache cache) {
try {
metaobject metacache = systemmetaobject.forobject(cache);
if (size != null && metacache.hassetter("size")) {
metacache.setvalue("size", size);
}
if (clearinterval != null) {
cache = new scheduledcache(cache);
((scheduledcache) cache).setclearinterval(clearinterval);
}
if (readwrite) {
cache = new serializedcache(cache);
}
cache = new loggingcache(cache);
cache = new synchronizedcache(cache);
if (blocking) {
cache = new blockingcache(cache);
}
return cache;
} catch (exception e) {
throw new cacheexception("error building standard cache decorators. cause: " + e, e);
}
}
这次是根据其它的配置参数来：
cache全部装饰完毕，返回，至此mybatis二级缓存生成完毕。
最后说一下，mybatis支持三种类型的二级缓存：
从build()方法来看，后两种场景的cache，mybatis只会将其装饰为loggingcache，理由很简单，这些缓存的定期清除功能、淘汰过期数据功能开发者自己或者第三方缓存都已经实现好了，根本不需要依赖mybatis本身的装饰。
如对本文有疑问， 点击进行留言回复！！
Springboot项目因为kackson版本问题启动报错解决方案
Java多线程下的其他组件之CyclicBarrier、Callable、Future和FutureTask详解
网友评论