标签：command equals ifreq att warning java column 现在 赋值
老规矩，先说结论。给各位大兄弟来点总结。
mybatis有两级缓存，分别是：
想必大家都对这个结论不陌生，但是有许多人其实并不明白具体原因。所以今天就和各位大兄弟一起来探讨一下具体代码。
这个缓存就得从创建执行器开始，org.apache.ibatis.session.Configuration#newExecutor(org.apache.ibatis.transaction.Transaction, org.apache.ibatis.session.ExecutorType)，创建执行器是从创建SqlSession开始的， 这个看过上一篇文章的大兄弟应有了解，就不一一说啦。先上代码。
public Executor newExecutor(Transaction transaction, ExecutorType executorType) {
executorType = executorType == null ? defaultExecutorType : executorType;
executorType = executorType == null ? ExecutorType.SIMPLE : executorType;
Executor executor;
if (ExecutorType.BATCH == executorType) {
executor = new BatchExecutor(this, transaction);
} else if (ExecutorType.REUSE == executorType) {
executor = new ReuseExecutor(this, transaction);
} else {
executor = new SimpleExecutor(this, transaction);
}
if (cacheEnabled) { // 是否开启二级缓存，这个属性是从配置文件中解析出来的。二级缓存默认是true.
executor = new CachingExecutor(executor);
}
executor = (Executor) interceptorChain.pluginAll(executor);
return executor;
}
这段代码，我们可以看出，如果在配置文件中，没有开启二级缓存，则会直接创建一个Executor， 如果开启了二级缓存，则会把创建的执行器进行包装。 那我们就从没有开启二级缓存查看。（为什么要直接分析SimpleExecutor先不说，卖个关子）
直接点进SimpleExecutor，发现没啥东西，直接点进父类构造函数。（BaseExecutor有三个默认实现，分别是：BatchExecutor，ReuseExecutor，SimpleExecutor。所以小伙伴不要纠结为什么选择SimpleExecutor了）代码如下。
protected BaseExecutor(Configuration configuration, Transaction transaction) {
this.transaction = transaction;
this.deferredLoads = new ConcurrentLinkedQueue<DeferredLoad>();
this.localCache = new PerpetualCache("LocalCache");
this.localOutputParameterCache = new PerpetualCache("LocalOutputParameterCache");
this.closed = false;
this.configuration = configuration;
this.wrapper = this;
}
点进父类的构造函数，我们大概也看出来了，在父类的构造函数中，的确存在名字叫localCache。 那不行，我们只看到了Cahce，得找到使用的地方。缓存一般都是用来缓存查询内容的，那我们就去找select，query方法咯。
private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
List<E> list;
// 用来延迟加载，表示当前key已经被缓存
localCache.putObject(key, EXECUTION_PLACEHOLDER);
try {
list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
} finally {
localCache.removeObject(key);
}
// 放入缓存中
localCache.putObject(key, list);
if (ms.getStatementType() == StatementType.CALLABLE) {
localOutputParameterCache.putObject(key, parameter);
}
return list;
}
从一个query方法中，点到最后。我们不用关注其中细节，在最终query方法中，的确是放入缓存中。我们看一下localCache的具体类型。代码如下。
public class PerpetualCache implements Cache {
private final String id;
private Map<Object, Object> cache = new HashMap<Object, Object>();
public PerpetualCache(String id) {
this.id = id;
}
}
很简单，就是一个id 和 一个map。 ，这也就是说明了，mybatis是用map来缓存数据的。
我们看到现在，算是明白了，mybatis中的一级缓存是自动开启的，不需要什么配置文件，也只是用map来缓存的。
从上面代码看，CacheExecutor是对SimpleExecutor进行了包装。那就进代码看看。
public CachingExecutor(Executor delegate) {
this.delegate = delegate;
// 进行包装， 从实现类字面理解，就是延迟加载
delegate.setExecutorWrapper(this);
}
我们不关注这么多， 我们就一个目的，搞清楚这个cache。 老规矩，查缓存从select或query方法找起来。
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
throws SQLException {
// 从mappedStatement中获取缓存。
Cache cache = ms.getCache();
if (cache != null) {
flushCacheIfRequired(ms);
if (ms.isUseCache() && resultHandler == null) {
ensureNoOutParams(ms, boundSql);
@SuppressWarnings("unchecked")
// 把cache和key传递进去，查看是否有缓存数据
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);
}
我们基本看出来，这个ms.getCache()是至关重要的，因为在代码中，接下来的操作都和这个cache有关系。 那么唯一的一件事就是搞清楚这个cache是从哪来的。我们就从MappedStatement的方方法开始看，这个cache是如何生成的。
public final class MappedStatement {
....
public Builder cache(Cache cache) {
mappedStatement.cache = cache;
return this;
}
...
}
我们不难看出来，这个Cache通过传递进来，然后直接赋值给了MappedStatement的变量。 那么我们就点击一下这个方法，看被哪调用。
org.apache.ibatis.builder.MapperBuilderAssistant#addMappedStatement(...){
MappedStatement.Builder statementBuilder = new MappedStatement.Builder(configuration, id, sqlSource, sqlCommandType)
...
.useCache(valueOrDefault(useCache, isSelect))
// 传入cache
.cache(currentCache);
}
我们发现被这个方法，这个方法有点熟悉，就是我们前一篇文章讲到的，在解析mapper，构建MappedStatement的方法。这个传入的currentCache不是当期方法的，是当前类的，那我们就要看当那类是怎么构建出来的。我们直接看这个方法被哪调用，然后顺藤摸瓜，找到创建的地方。
public void parseStatementNode() {
String id = context.getStringAttribute("id");
String databaseId = context.getStringAttribute("databaseId");
...
// 通过使用builderAssistant添加mapper. 我们要接着看builderAssistant是如何构建的
builderAssistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType,
fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass,
resultSetTypeEnum, flushCache, useCache, resultOrdered,
keyGenerator, keyProperty, keyColumn, databaseId, langDriver, resultSets);
}
note: 看到这些代码并不陌生，我们现在反着推断了。 有的小伙伴肯定好奇，我是如何找到这些方法的， 如何你有这个疑问，就需要看一下前一篇mybatis的文章啦！！
因为builderAssistant是类成员变量，那我们接着看parseStatementNode()方法被哪调用，然后找到构建builderAssistant的地方
private void buildStatementFromContext(List<XNode> list, String requiredDatabaseId) {
for (XNode context : list) {
final XMLStatementBuilder statementParser = new XMLStatementBuilder(configuration, builderAssistant, context, requiredDatabaseId);
try {
statementParser.parseStatementNode();
} catch (IncompleteElementException e) {
configuration.addIncompleteStatement(statementParser);
}
}
}
到这仍发现builderAssistant是传递过来的，那我们就接着往上翻代码。找到当前类是如何构建的。
....
一直往上翻，有很多代码，道理相同，我们最后找到了如下代码。
private void configurationElement(XNode context) {
try {
String namespace = context.getStringAttribute("namespace");
if (namespace == null || namespace.equals("")) {
throw new BuilderException("Mapper‘s namespace cannot be empty");
}
// 设置namespace
builderAssistant.setCurrentNamespace(namespace);
cacheRefElement(context.evalNode("cache-ref"));
// 构建cache
cacheElement(context.evalNode("cache"));
parameterMapElement(context.evalNodes("/mapper/parameterMap"));
resultMapElements(context.evalNodes("/mapper/resultMap"));
sqlElement(context.evalNodes("/mapper/sql"));
// 解析mappedStatement
buildStatementFromContext(context.evalNodes("select|insert|update|delete"));
} catch (Exception e) {
...
}
}
这个熟悉的感觉。 我们看大了给builderAssistant设置namespace。并且有关于cache的代码，这个时候就不要点走啦，得进去看看了，因为已经到了我们关心的点。点进cacheElement(context.evalNode("cache"));一探究竟。
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;
}
发现最终调用了org.apache.ibatis.builder.MapperBuilderAssistant#useNewCache的方法，我们也如愿看到了cache的产生，并且是以namespace为单位的。
自此，我们搞清楚了一条大概的逻辑。
现在大体逻辑是搞懂了，但是代码可能各位大兄弟看着有些糊涂，建议在电脑自己看看，加深一下印象。 毕竟看别人千遍，不如自己来实现一遍。
标签：command equals ifreq att warning java column 现在 赋值
原文地址：https://www.cnblogs.com/lifacheng/p/13245990.html
