MyBatis一级缓存机制
问题引入
今天遇到了一个非常奇怪的生产环境问题。话不多说，先上问题代码（代码经过脱敏处理）：
public Map<String, Double> queryDataFromDatabase(String id, Integer count) {
Map<String, Double> map = super.dao.selectOne(id);
if (map != null && !map.isEmpty()) {
Double weight = map.get("weight");
// 其他Map字段获取值
......
map.put("weight", weight * count);
// 其他业务处理
......
} else {
map = Maps.newHashMap();
}
return map;
}
public void handlerService() {
// 获取id，可能重复
List<String> ids = getIds();
// count从其他地方动态获取，此处简化处理
int count = 50;
for(String id : ids) {
Map<String, Double> map = queryDataFromDatabase(id, count);
// 其他需要用到map的业务逻辑
......
}
}
代码不符合规范，但看起来也不会出现啥问题，从数据库里根据id获取一个map集合，并往其中的weight更新重量。一切看起来都很正常，如果Mybatis没有一级缓存的话。
问题就出在这。当有一段业务需要用到上述代码时出现了相同的id当第一个id运行完时，一切都很正常，从数据库里拿到weight再运行map.put("weight", weight * count);，更改weight的值，返回整个哈希表，处理其他逻辑。相关数据如下：
count == 50
id == 123
----修改前weight == 30
----修改后weight == 1500
当相同的id(123)再次运行到这段逻辑时，相关数据变成了这样：
count == 50
id == 123
----修改前weight == 1500
----修改后weight == 75000
而数据库里面weight的值一直为30，从没有改变过。
直接原因
作为一名菜鸡程序员，我都还没了解过mybatis的运行机制，以前也从没遇到过这么离谱的问题。好好的数据怎么从数据库里面取出来后就变大了呢？一顿搜索，还是没有任何头绪，知道我看到了这么一张图：
CachingExecutor!缓存！不会是从缓存里面直接获取的值，然后代码又正好把新的weight赋值到缓存好的map对象里去了吧？于是我做了下面的修改
public Map<String, Double> queryDataFromDatabase(String id, Integer count) {
Map<String, Double> map = super.dao.selectOne(id);
Map<String, Double> weightMap = new HashMap<>(2);
if (map != null && !map.isEmpty()) {
Double weight = map.get("weight");
// 其他Map字段获取值
......
weightMap.put("weight", weight * count);
// 其他业务处理
......
}
return weightMap;
}
public void handlerService() {
// 获取id，可能重复
List<String> ids = getIds();
// count从其他地方动态获取，此处简化处理
int count = 50;
for(String id : ids) {
Map<String, Double> map = queryDataFromDatabase(id, count);
// 其他需要用到map的业务逻辑
......
}
}
改动不大，就是新实例化了一个weightMap 然后把修改后的weight值赋值到这个新的哈希表中去，原来从mybatis（我几乎可以确定第二次不是从数据库里取的值，而是从mybatis缓存中获取到的值）中获取到的map保持不动。再次运行代码，得到两次结果如下：
- 第一次
count == 50
id == 123
----修改前map.get("weight") == 30
----修改后weightMap.get("weight") == 1500
- 第二次
count == 50
id == 123
----修改前map.get("weight") == 30
----修改后weightMap.get("weight") == 1500
果然，只要我在新实例化出来的对象里面进行修改，那么原来的值就不会改变，所以当运行同一段sql语句时，第一次获取到结果后，mybatis会缓存一份结果，后续运行到相同的sql时会直接从缓存中获取结果，而这个结果是一个地址，指向同一个对象。
追根溯源
至此，问题是得到解决了实例化一个新的对象，在新的对象上改动原有的值就行，不会影响到缓存结果。但都查到这了，不得跟着源码找找证据？
由于我们只关注缓存，所以前面部分代码略过，debug信息取再次获取数据时的调试部分
注：此处selectList()方法会在返回集合后判断长度是否为1，为1时返回集合第0个元素，如果大于1的话会抛异常，所以实际上还是selectOne()，具体代码略去，只做简要说明
public class DefaultSqlSession implements SqlSession {
private final Executor executor;
private final Configuration configuration;
......
public DefaultSqlSession(Configuration configuration, Executor executor, boolean autoCommit) {
this.configuration = configuration;
this.executor = executor;
this.dirty = false;
this.autoCommit = autoCommit;
}
@Override
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();
}
}
}
- 此处的
executor已经在DefaultSqlSession的构造函数前就被实例化为了CachingExecutor，具体实例化过程以后再补充
- 此处的
Executor.NO_RESULT_HANDLER比较重要，会一直传递到获取数据处，值为null
executor的query方法：（此处略去了生成CacheKey key的部分，会在最后补充）
public class CachingExecutor implements Executor {
@Override
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, 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);
}
return list;
}
}
return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
}
看吧，这有个ms.getCache()方法，获取缓存的值，是不是就这样找到源头了呢？没这么简单，看debug调试吧：
null.....空！要知道，这是已经存过一次数据，再次运行相同sql的部分了
别急，这其实是mybatis的二级缓存，而二级缓存是需要手动开启的，我们项目没有配置，因此此处就为空啦。想了解二级缓存的，等我哪天再遇到相关问题了再来研究研究吧，这次先略过。
由于上面获取二级缓存为空，因此执行delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);方法，进入到BaseExecutor类中：
public abstract class BaseExecutor implements Executor {
@SuppressWarnings("unchecked")
@Override
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--;
}
if (queryStack == 0) {
for (DeferredLoad deferredLoad : deferredLoads) {
deferredLoad.load();
}
deferredLoads.clear();
if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
clearLocalCache();
}
}
return list;
}
}
list = resultHandler == null ? (List<E>) localCache.getObject(key) : null;注意这段代码
如果resultHandler为null则list从localCache.getObject(key)中获取值，否则list置为空。前面我们已经说过了，resultHandler实际只传递了一个null值过来。
可以看到我们从localCache.getObject(key)取到了第一次从数据库拿到结果后保存的缓存值，注意其地址，
这是Map<String, Double> map = super.dao.selectOne(id);我们项目业务代码中map的地址，与mybatis中获取的一致。因此，对业务代码中map的修改会影响到mybatis中的缓存。
至此，原理找到了，下次遇到这么坑的代码也不用摸不着头脑了。这点东西花了我一个多小时打断点，找原因。又花了大半个下午的时间写博客。我就想诅咒写这段代码的同事每天下班前半小时都出现新bug要他解决！！！！
参考博客：
