一、MyBatis的工作原理和源码解析
一 构造篇
今天会给大家分享我们常用的持久层框架——MyBatis的工作原理和源码解析，后续会围绕Mybatis框架做一些比较深入的讲解.对于MyBatis，给我个人的感受，其工作流程实际上分为两部分：第一，构建，也就是解析我们写的xml配置，将其变成它所需要的对象。第二，就是执行，在构建完成的基础上，去执行我们的SQL，完成与Jdbc的交互。而这篇的重点会先放在构建上。
1.1 Xml配置文件
<!-- mybatis-config.xml -->
<?xml version="1.0" encoding="UTF-8" ?>
<!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-config.dtd">
<configuration>
<properties resource="jdbcConfig.properties">
<property name="dialect" value="mysql" />
</properties>
<settings>
<!-- 这个配置使全局的映射器启用或禁用缓存 -->
<setting name="cacheEnabled" value="true" />
<!-- 对于未知的SQL查询，允许返回不同的结果集以达到通用的效果 -->
<setting name="multipleResultSetsEnabled" value="true" />
<!-- 配置默认的执行器。SIMPLE 执行器没有什么特别之处。REUSE 执行器重用预处理语句。BATCH 执行器重用语句和批量更新 -->
<setting name="defaultExecutorType" value="REUSE" />
<!-- 全局启用或禁用延迟加载。当禁用时，所有关联对象都会即时加载。 -->
<setting name="lazyLoadingEnabled" value="false" />
<setting name="aggressiveLazyLoading" value="true" />
<!-- <setting name="enhancementEnabled" value="true"/> -->
<!-- 设置超时时间，它决定驱动等待一个数据库响应的时间。 -->
<setting name="defaultStatementTimeout" value="25000" />
<!-- 使用驼峰命名法转换字段。 -->
<setting name="mapUnderscoreToCamelCase" value="true"/>
</settings>
<typeAliases>
<typeAlias alias="Integer" type="java.lang.Integer"/>
<typeAlias alias="Long" type="java.lang.Long"/>
<typeAlias alias="HashMap" type="java.util.HashMap"/>
<typeAlias alias="LinkedHashMap" type="java.util.LinkedHashMap"/>
<typeAlias alias="ArrayList" type="java.util.ArrayList"/>
<typeAlias alias="LinkedList" type="java.util.LinkedList"/>
</typeAliases>
<!--配置环境-->
<environments default="mysql">
<!-- 配置mysql的环境-->
<environment id="mysql">
<!-- 配置事务 -->
<transactionManager type="JDBC"></transactionManager>
<!--配置连接池-->
<dataSource type="POOLED">
<property name="driver" value="${jdbc.driver}"></property>
<property name="url" value="${jdbc.url}"></property>
<property name="username" value="${jdbc.username}"></property>
<property name="password" value="${jdbc.password}"></property>
</dataSource>
</environment>
</environments>
<!-- 配置映射文件的位置 -->
<mappers>
<mapper resource="mapper/SysZdlxMapper.xml"/>
</mappers>
</configuration>
<!-- jdbcConfig.properties -->
jdbc.driver=com.mysql.jdbc.Driver
jdbc.url=jdbc:mysql://192.168.146.180:3306/yun?useUnicode=true&characterEncoding=utf8&allowMultiQueries=true&serverTimezone=Asia/Shanghai&zeroDateTimeBehavior=convertToNull&autoReconnect=true
jdbc.username=XXX
jdbc.password=XXX
<!-- SysZdlxMapper.xml -->
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE mapper PUBLIC "-//mybatis.org//DTD Mapper 3.0//EN" "http://mybatis.org/dtd/mybatis-3-mapper.dtd">
<mapper namespace="com.xx.SysZdlxDao">
<cache/>
<resultMap id="BaseResultMap" type="com.xx.pojo.po.SysZdlx">
<!--
WARNING - @mbg.generated
-->
<id column="ZDLX_ID" jdbcType="BIGINT" property="zdlxId" />
<result column="ZDLXMC" jdbcType="VARCHAR" property="zdlxmc" />
<result column="ZDLXDM" jdbcType="VARCHAR" property="zdlxdm" />
</resultMap>
<sql id="Base_Column_List">
<!--
WARNING - @mbg.generated
-->
ZDLX_ID, ZDLXMC, ZDLXDM
</sql>
<select id="selectDictionaryTypeList" parameterType="java.lang.Long" resultMap="BaseResultMap" >
select
<include refid="Base_Column_List" />
from sys_zdlx
</select>
</mapper>
<!-- SysZdlxDao -->
public interface SysZdlxDao{
/**
* 查询所有自动类型
*/
List<SysZdlx> selectDictionaryTypeList();
}
我们不难看出，在mybatis-config.xml这个文件主要是用于配置数据源、配置别名、加载mapper.xml，并且我们可以看到这个文件的节点中包含了一个，而这个mapper所指向的路径就是另外一个xml文件：SysZdlxMapper.xml，而这个文件中写了我们查询数据库所用的SQL。 MyBatis实际上就是将这两个xml文件，解析成配置对象，在执行中去使用它。
1.2 环境搭建
public static void main(String[] args) throws IOException {
InputStream inputStream = null;
try {
inputStream = Resources.getResourceAsStream("config/mybatis-config.xml");
} catch (IOException e) {
e.printStackTrace();
}
SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(inputStream);
SqlSession sqlSession = factory.openSession();
SysZdlxDao mapper = sqlSession.getMapper(SysZdlxDao.class);
List<SysZdlx> sysZdlxes = mapper.selectDictionaryTypeList();
System.out.println(sysZdlxes.size()+JsonUtil.toJson(sysZdlxes));
sqlSession.commit();
sqlSession.close();
}
看源码重要的一点就是要找到源码的入口，而我们可以从这几行程序出发，来看看构建究竟是在哪开始的。 首先不难看出，这段程序显示通过字节流读取了mybatis-config.xml文件，然后通过SqlSessionFactoryBuilder.build()方法，创建了一个SqlSessionFactory（这里用到了工厂模式和构建者模式），前面说过，MyBatis就是通过我们写的xml配置文件，来构建配置对象的，那么配置文件所在的地方，就一定是构建开始的地方，也就是build方法。
1.3 源码构建开始
进入build方法，我们可以看到这里的确有解析的意思,这个方法返回了一个SqlSessionFactory，而这个对象也是使用构造者模式创建的，不妨继续往下走。
public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) {
try {
//解析mybatis-config.xml
//XMLConfigBuilder 构造者
XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties);
//parse(): 解析mybatis-config.xml里面的节点
return build(parser.parse());
} catch (Exception e) {
throw ExceptionFactory.wrapException("Error building SqlSession.", e);
} finally {
ErrorContext.instance().reset();
try {
inputStream.close();
} catch (IOException e) {
// Intentionally ignore. Prefer previous error.
}
}
}
进入parse():
public Configuration parse() {
//查看该文件是否已经解析过
if (parsed) {
throw new BuilderException("Each XMLConfigBuilder can only be used once.");
}
//如果没有解析过，则继续往下解析，并且将标识符置为true
parsed = true;
//解析<configuration>节点
parseConfiguration(parser.evalNode("/configuration"));
return configuration;
}
注意parse的返回值，Configuration，这个似曾相识的单词好像在哪见过，是否与mybatis-config.xml中的节点有所关联呢？
答案是肯定的，我们可以接着往下看。
看到这里，虽然代码量还不是特别多，但是至少现在我们可以在大脑中得到一个大致的主线图，也如下图所示：
沿着这条主线，我们进入parseConfiguration(XNode)方法，接着往下看。
private void parseConfiguration(XNode root) {
try {
//解析<Configuration>下的节点
//issue #117 read properties first
//<properties>
propertiesElement(root.evalNode("properties"));
//<settings>
Properties settings = settingsAsProperties(root.evalNode("settings"));
loadCustomVfs(settings);
loadCustomLogImpl(settings);
//别名<typeAliases>解析
// 所谓别名 其实就是把你指定的别名对应的class存储在一个Map当中
typeAliasesElement(root.evalNode("typeAliases"));
//插件 <plugins>
pluginElement(root.evalNode("plugins"));
//自定义实例化对象的行为<objectFactory>
objectFactoryElement(root.evalNode("objectFactory"));
//MateObject 方便反射操作实体类的对象
objectWrapperFactoryElement(root.evalNode("objectWrapperFactory"));
reflectorFactoryElement(root.evalNode("reflectorFactory"));
settingsElement(settings);
// read it after objectFactory and objectWrapperFactory issue #631
//<environments>
environmentsElement(root.evalNode("environments"));
databaseIdProviderElement(root.evalNode("databaseIdProvider"));
// typeHandlers
typeHandlerElement(root.evalNode("typeHandlers"));
//主要 <mappers> 指向我们存放SQL的xxxxMapper.xml文件
mapperElement(root.evalNode("mappers"));
} catch (Exception e) {
throw new BuilderException("Error parsing SQL Mapper Configuration. Cause: " + e, e);
}
}
可以看到这个方法已经在解析configuration下的节点了，例如settings,typeAliases,environments和mappers。 这里主要使用了分步构建，每个解析不同标签的方法内部都对Configuration对象进行了set或者其它类似的操作，经过这些操作之后，一个Configuration对象就构建完毕了，这里由于代码量比较大，而且大多数构建都是些细节，大概知道怎么用就可以了，就不在文章中说明了，我会挑一个主要的说，当然有兴趣的可以自己去pull MyBatis的源码看看。
1.3.1 Mappers解析
上文中提到，mybatis-config.xml文件中我们一定会写一个叫做mappers的标签，这个标签中的mapper节点存放了我们对数据库进行操作的SQL语句，所以这个标签的构建会作为今天分析的重点。 首先在看源码之前，我们先回忆一下我们在mapper标签内通常会怎样进行配置，通常有如下几种配置方式。<mappers>
<!-- 通过配置文件路径 -->
<mapper resource="mapper/xxxMapper.xml" ></mapper>
<!-- 通过Java全限定类名 -->
<mapper class="com.xxx.TestMapper"/>
<!-- 通过url 通常是mapper不在本地时用 -->
<mapper url=""/>
<!-- 通过包名 -->
<package name="com.xxx"/>
<!-- 注意 mapper节点中，可以使用resource/url/class三种方式获取mapper-->
</mappers>
这是mappers标签的几种配置方式，通过这几种配置方式，可以帮助我们更容易理解mappers的解析。
private void mapperElement(XNode parent) throws Exception {
if (parent != null) {
//遍历解析mappers下的节点
for (XNode child : parent.getChildren()) {
//首先解析package节点
if ("package".equals(child.getName())) {
//获取包名
String mapperPackage = child.getStringAttribute("name");
configuration.addMappers(mapperPackage);
} else {
//如果不存在package节点，那么扫描mapper节点
//resource/url/mapperClass三个值只能有一个值是有值的
String resource = child.getStringAttribute("resource");
String url = child.getStringAttribute("url");
String mapperClass = child.getStringAttribute("class");
//优先级 resource>url>mapperClass
if (resource != null && url == null && mapperClass == null) {
//如果mapper节点中的resource不为空
ErrorContext.instance().resource(resource);
//那么直接加载resource指向的XXXMapper.xml文件为字节流
InputStream inputStream = Resources.getResourceAsStream(resource);
//通过XMLMapperBuilder解析XXXMapper.xml，可以看到这里构建的XMLMapperBuilde还传入了configuration,所以之后肯定是会将mapper封装到configuration对象中去的。
XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, resource, configuration.getSqlFragments());
//解析
mapperParser.parse();
} else if (resource == null && url != null && mapperClass == null) {
//如果url!=null，那么通过url解析
ErrorContext.instance().resource(url);
InputStream inputStream = Resources.getUrlAsStream(url);
XMLMapperBuilder mapperParser = new XMLMapperBuilder(inputStream, configuration, url, configuration.getSqlFragments());
mapperParser.parse();
} else if (resource == null && url == null && mapperClass != null) {
//如果mapperClass!=null，那么通过加载类构造Configuration
Class<?> mapperInterface = Resources.classForName(mapperClass);
configuration.addMapper(mapperInterface);
} else {
//如果都不满足 则直接抛异常 如果配置了两个或三个 直接抛异常
throw new BuilderException("A mapper element may only specify a url, resource or class, but not more than one.");
}
}
}
}
}
我们的配置文件中写的是通过resource来加载mapper.xml的，所以会通过XMLMapperBuilder来进行解析，我们可以进去他的parse方法中看一下:
public void parse() {
//判断文件是否之前解析过
if (!configuration.isResourceLoaded(resource)) {
//解析mapper文件节点（主要）(下面贴了代码)
configurationElement(parser.evalNode("/mapper"));
configuration.addLoadedResource(resource);
//绑定Namespace里面的Class对象
bindMapperForNamespace();
}
//重新解析之前解析不了的节点，先不看，最后填坑。
parsePendingResultMaps();
parsePendingCacheRefs();
parsePendingStatements();
}
//解析mapper文件里面的节点
// 拿到里面配置的配置项 最终封装成一个MapperedStatemanet
private void configurationElement(XNode context) {
try {
//获取命名空间 namespace，这个很重要，后期mybatis会通过这个动态代理我们的Mapper接口
String namespace = context.getStringAttribute("namespace");
if (namespace == null || namespace.equals("")) {
//如果namespace为空则抛一个异常
throw new BuilderException("Mapper's namespace cannot be empty");
}
builderAssistant.setCurrentNamespace(namespace);
//解析缓存节点
cacheRefElement(context.evalNode("cache-ref"));
cacheElement(context.evalNode("cache"));
//解析parameterMap（过时）和resultMap <resultMap></resultMap>
parameterMapElement(context.evalNodes("/mapper/parameterMap"));
resultMapElements(context.evalNodes("/mapper/resultMap"));
//解析<sql>节点
//<sql id="staticSql">select * from test</sql> （可重用的代码段）
//<select> <include refid="staticSql"></select>
sqlElement(context.evalNodes("/mapper/sql"));
//解析增删改查节点<select> <insert> <update> <delete>
buildStatementFromContext(context.evalNodes("select|insert|update|delete"));
} catch (Exception e) {
throw new BuilderException("Error parsing Mapper XML. The XML location is '" + resource + "'. Cause: " + e, e);
}
}
在这个parse()方法中，调用了一个configuationElement代码，用于解析XXXMapper.xml文件中的各种节点，包括cache、cache-ref、paramaterMap（已过时）、resultMap、sql、还有增删改查节点，和上面相同的是，我们也挑一个主要的来说，因为解析过程都大同小异。 毋庸置疑的是，我们在XXXMapper.xml中必不可少的就是编写SQL，与数据库交互主要靠的也就是这个，所以着重说说解析增删改查节点的方法——buildStatementFromContext()。 在没贴代码之前，根据这个名字就可以略知一二了，这个方法会根据我们的增删改查节点，来构造一个Statement，而用过原生Jdbc的都知道，Statement就是我们操作数据库的对象。
private void buildStatementFromContext(List<XNode> list) {
if (configuration.getDatabaseId() != null) {
buildStatementFromContext(list, configuration.getDatabaseId());
}
//解析xml
buildStatementFromContext(list, null);
}
private void buildStatementFromContext(List<XNode> list, String requiredDatabaseId) {
for (XNode context : list) {
final XMLStatementBuilder statementParser = new XMLStatementBuilder(configuration, builderAssistant, context, requiredDatabaseId);
try {
//解析xml节点
statementParser.parseStatementNode();
} catch (IncompleteElementException e) {
//xml语句有问题时 存储到集合中 等解析完能解析的再重新解析
configuration.addIncompleteStatement(statementParser);
}
}
}
public void parseStatementNode() {
//获取<select id="xxx">中的id
String id = context.getStringAttribute("id");
//获取databaseId 用于多数据库，这里为null
String databaseId = context.getStringAttribute("databaseId");
if (!databaseIdMatchesCurrent(id, databaseId, this.requiredDatabaseId)) {
return;
}
//获取节点名 select update delete insert
String nodeName = context.getNode().getNodeName();
//根据节点名，得到SQL操作的类型
SqlCommandType sqlCommandType = SqlCommandType.valueOf(nodeName.toUpperCase(Locale.ENGLISH));
//判断是否是查询
boolean isSelect = sqlCommandType == SqlCommandType.SELECT;
//是否刷新缓存 默认:增删改刷新 查询不刷新
boolean flushCache = context.getBooleanAttribute("flushCache", !isSelect);
//是否使用二级缓存 默认值:查询使用 增删改不使用
boolean useCache = context.getBooleanAttribute("useCache", isSelect);
//是否需要处理嵌套查询结果 group by
// 三组数据 分成一个嵌套的查询结果
boolean resultOrdered = context.getBooleanAttribute("resultOrdered", false);
// Include Fragments before parsing
XMLIncludeTransformer includeParser = new XMLIncludeTransformer(configuration, builderAssistant);
//替换Includes标签为对应的sql标签里面的值
includeParser.applyIncludes(context.getNode());
//获取parameterType名
String parameterType = context.getStringAttribute("parameterType");
//获取parameterType的Class
Class<?> parameterTypeClass = resolveClass(parameterType);
//解析配置的自定义脚本语言驱动 这里为null
String lang = context.getStringAttribute("lang");
LanguageDriver langDriver = getLanguageDriver(lang);
// Parse selectKey after includes and remove them.
//解析selectKey
processSelectKeyNodes(id, parameterTypeClass, langDriver);
// Parse the SQL (pre: <selectKey> and <include> were parsed and removed)
//设置主键自增规则
KeyGenerator keyGenerator;
String keyStatementId = id + SelectKeyGenerator.SELECT_KEY_SUFFIX;
keyStatementId = builderAssistant.applyCurrentNamespace(keyStatementId, true);
if (configuration.hasKeyGenerator(keyStatementId)) {
keyGenerator = configuration.getKeyGenerator(keyStatementId);
} else {
keyGenerator = context.getBooleanAttribute("useGeneratedKeys",
configuration.isUseGeneratedKeys() && SqlCommandType.INSERT.equals(sqlCommandType))
? Jdbc3KeyGenerator.INSTANCE : NoKeyGenerator.INSTANCE;
}
/************************************************************************************/
//解析Sql（重要） 根据sql文本来判断是否需要动态解析 如果没有动态sql语句且 只有#{}的时候 直接静态解析使用?占位 当有 ${} 不解析
SqlSource sqlSource = langDriver.createSqlSource(configuration, context, parameterTypeClass);
//获取StatementType，可以理解为Statement和PreparedStatement
StatementType statementType = StatementType.valueOf(context.getStringAttribute("statementType", StatementType.PREPARED.toString()));
//没用过
Integer fetchSize = context.getIntAttribute("fetchSize");
//超时时间
Integer timeout = context.getIntAttribute("timeout");
//已过时
String parameterMap = context.getStringAttribute("parameterMap");
//获取返回值类型名
String resultType = context.getStringAttribute("resultType");
//获取返回值烈性的Class
Class<?> resultTypeClass = resolveClass(resultType);
//获取resultMap的id
String resultMap = context.getStringAttribute("resultMap");
//获取结果集类型
String resultSetType = context.getStringAttribute("resultSetType");
ResultSetType resultSetTypeEnum = resolveResultSetType(resultSetType);
if (resultSetTypeEnum == null) {
resultSetTypeEnum = configuration.getDefaultResultSetType();
}
String keyProperty = context.getStringAttribute("keyProperty");
String keyColumn = context.getStringAttribute("keyColumn");
String resultSets = context.getStringAttribute("resultSets");
//将刚才获取到的属性，封装成MappedStatement对象（代码贴在下面）
builderAssistant.addMappedStatement(id, sqlSource, statementType, sqlCommandType,
fetchSize, timeout, parameterMap, parameterTypeClass, resultMap, resultTypeClass,
resultSetTypeEnum, flushCache, useCache, resultOrdered,
keyGenerator, keyProperty, keyColumn, databaseId, langDriver, resultSets);
}
//将刚才获取到的属性，封装成MappedStatement对象
public MappedStatement addMappedStatement(
String id,
SqlSource sqlSource,
StatementType statementType,
SqlCommandType sqlCommandType,
Integer fetchSize,
Integer timeout,
String parameterMap,
Class<?> parameterType,
String resultMap,
Class<?> resultType,
ResultSetType resultSetType,
boolean flushCache,
boolean useCache,
boolean resultOrdered,
KeyGenerator keyGenerator,
String keyProperty,
String keyColumn,
String databaseId,
LanguageDriver lang,
String resultSets) {
if (unresolvedCacheRef) {
throw new IncompleteElementException("Cache-ref not yet resolved");
}
//id = namespace
id = applyCurrentNamespace(id, false);
boolean isSelect = sqlCommandType == SqlCommandType.SELECT;
//通过构造者模式+链式变成，构造一个MappedStatement的构造者
MappedStatement.Builder statementBuilder = new MappedStatement.Builder(configuration, id, sqlSource, sqlCommandType)
.resource(resource)
.fetchSize(fetchSize)
.timeout(timeout)
.statementType(statementType)
.keyGenerator(keyGenerator)
.keyProperty(keyProperty)
.keyColumn(keyColumn)
.databaseId(databaseId)
.lang(lang)
.resultOrdered(resultOrdered)
.resultSets(resultSets)
.resultMaps(getStatementResultMaps(resultMap, resultType, id))
.resultSetType(resultSetType)
.flushCacheRequired(valueOrDefault(flushCache, !isSelect))
.useCache(valueOrDefault(useCache, isSelect))
.cache(currentCache);
ParameterMap statementParameterMap = getStatementParameterMap(parameterMap, parameterType, id);
if (statementParameterMap != null) {
statementBuilder.parameterMap(statementParameterMap);
}
//通过构造者构造MappedStatement
MappedStatement statement = statementBuilder.build();
//将MappedStatement对象封装到Configuration对象中
configuration.addMappedStatement(statement);
return statement;
}
这个代码段虽然很长，但是一句话形容它就是繁琐但不复杂，里面主要也就是对xml的节点进行解析。举个比上面简单的例子吧，假设我们有这样一段配置：
<select id="selectDemo" parameterType="java.lang.Integer" resultType='Map'>
SELECT * FROM test
</select>
MyBatis需要做的就是，先判断这个节点是用来干什么的，然后再获取这个节点的id、parameterType、resultType等属性，封装成一个MappedStatement对象，由于这个对象很复杂，所以MyBatis使用了构造者模式来构造这个对象，最后当MappedStatement对象构造完成后，将其封装到Configuration对象中。
代码执行至此，基本就结束了对Configuration对象的构建，MyBatis的第一阶段：构造，也就到这里结束了，现在再来回答我们在文章开头提出的那两个问题：MyBatis需要构造什么对象？以及是否两个配置文件对应着两个对象？，似乎就已经有了答案，这里做一个总结:
MyBatis需要对配置文件进行解析，最终会解析成一个Configuration对象，但是要说两个配置文件对应了两个对象实际上也没有错：
- Configuration对象，保存了mybatis-config.xml的配置信息。
- MappedStatement，保存了XXXMapper.xml的配置信息。
但是最终MappedStatement对象会封装到Configuration对象中，合二为一，成为一个单独的对象，也就是Configuration。
最后给大家画一个构建过程的流程图：
填坑: SQL语句在哪解析？
细心的同学可能已经发现了，上文中只说了去节点中获取一些属性从而构建配置对象，但是最重要的SQL语句并没有提到，这是因为这部分我想要和属性区分开单独说，由于MyBatis支持动态SQL和${}、#{}的多样的SQL，所以这里单独提出来说会比较合适。 首先可以确认的是，刚才我们走完的那一整个流程中，包含了SQL语句的生成，下面贴代码（这一段代码相当绕，不好读）。
//解析Sql（重要） 根据sql文本来判断是否需要动态解析 如果没有动态sql语句且 只有#{}的时候 直接静态解析使用?占位 当有 ${} 不解析
SqlSource sqlSource = langDriver.createSqlSource(configuration, context, parameterTypeClass);
这里就是生成Sql的入口，以单步调试的角度接着往下看。
/*进入createSqlSource方法*/
@Override
public SqlSource createSqlSource(Configuration configuration, XNode script, Class<?> parameterType) {
//进入这个构造
XMLScriptBuilder builder = new XMLScriptBuilder(configuration, script, parameterType);
//进入parseScriptNode
return builder.parseScriptNode();
}
/**
进入这个方法
*/
public SqlSource parseScriptNode() {
//#
//会先解析一遍
MixedSqlNode rootSqlNode = parseDynamicTags(context);
SqlSource sqlSource;
if (isDynamic) {
//如果是${}会直接不解析，等待执行的时候直接赋值
sqlSource = new DynamicSqlSource(configuration, rootSqlNode);
} else {
//用占位符方式来解析 #{} --> ?
sqlSource = new RawSqlSource(configuration, rootSqlNode, parameterType);
}
return sqlSource;
}
protected MixedSqlNode parseDynamicTags(XNode node) {
List<SqlNode> contents = new ArrayList<>();
//获取select标签下的子标签
NodeList children = node.getNode().getChildNodes();
for (int i = 0; i < children.getLength(); i++) {
XNode child = node.newXNode(children.item(i));
if (child.getNode().getNodeType() == Node.CDATA_SECTION_NODE || child.getNode().getNodeType() == Node.TEXT_NODE) {
//如果是查询
//获取原生SQL语句 这里是 select * from test where id = #{id}
String data = child.getStringBody("");
TextSqlNode textSqlNode = new TextSqlNode(data);
//检查sql是否是${}
if (textSqlNode.isDynamic()) {
//如果是${}那么直接不解析
contents.add(textSqlNode);
isDynamic = true;
} else {
//如果不是，则直接生成静态SQL
//#{} -> ?
contents.add(new StaticTextSqlNode(data));
}
} else if (child.getNode().getNodeType() == Node.ELEMENT_NODE) { // issue #628
//如果是增删改
String nodeName = child.getNode().getNodeName();
NodeHandler handler = nodeHandlerMap.get(nodeName);
if (handler == null) {
throw new BuilderException("Unknown element <" + nodeName + "> in SQL statement.");
}
handler.handleNode(child, contents);
isDynamic = true;
}
}
return new MixedSqlNode(contents);
}
#########################
/*从上面的代码段到这一段中间需要经过很多代码，就不一段一段贴了*/
public SqlSource parse(String originalSql, Class<?> parameterType, Map<String, Object> additionalParameters) {
ParameterMappingTokenHandler handler = new ParameterMappingTokenHandler(configuration, parameterType, additionalParameters);
//这里会生成一个GenericTokenParser，传入#{}作为开始和结束，然后调用其parse方法，即可将#{}换为 ?
GenericTokenParser parser = new GenericTokenParser("#{", "}", handler);
//这里可以解析#{} 将其替换为?
String sql = parser.parse(originalSql);
return new StaticSqlSource(configuration, sql, handler.getParameterMappings());
}
//经过一段复杂的解析过程
public String parse(String text) {
if (text == null || text.isEmpty()) {
return "";
}
// search open token
int start = text.indexOf(openToken);
if (start == -1) {
return text;
}
char[] src = text.toCharArray();
int offset = 0;
final StringBuilder builder = new StringBuilder();
StringBuilder expression = null;
//遍历里面所有的#{} select ? ,#{id1} ${}
while (start > -1) {
if (start > 0 && src[start - 1] == '\') {
// this open token is escaped. remove the backslash and continue.
builder.append(src, offset, start - offset - 1).append(openToken);
offset = start + openToken.length();
} else {
// found open token. let's search close token.
if (expression == null) {
expression = new StringBuilder();
} else {
expression.setLength(0);
}
builder.append(src, offset, start - offset);
offset = start + openToken.length();
int end = text.indexOf(closeToken, offset);
while (end > -1) {
if (end > offset && src[end - 1] == '\') {
// this close token is escaped. remove the backslash and continue.
expression.append(src, offset, end - offset - 1).append(closeToken);
offset = end + closeToken.length();
end = text.indexOf(closeToken, offset);
} else {
expression.append(src, offset, end - offset);
break;
}
}
if (end == -1) {
// close token was not found.
builder.append(src, start, src.length - start);
offset = src.length;
} else {
//使用占位符 ?
//注意handler.handleToken()方法，这个方法是核心
builder.append(handler.handleToken(expression.toString()));
offset = end + closeToken.length();
}
}
start = text.indexOf(openToken, offset);
}
if (offset < src.length) {
builder.append(src, offset, src.length - offset);
}
return builder.toString();
}
//BindingTokenParser 的handleToken
//当扫描到${}的时候调用此方法 其实就是不解析 在运行时候在替换成具体的值
@Override
public String handleToken(String content) {
this.isDynamic = true;
return null;
}
//ParameterMappingTokenHandler的handleToken
//全局扫描#{id} 字符串之后 会把里面所有 #{} 调用handleToken 替换为?
@Override
public String handleToken(String content) {
parameterMappings.add(buildParameterMapping(content));
return "?";
}
这段代码相当绕，我们应该站在一个宏观的角度去看待它。所以我直接在这里概括一下： 首先这里会通过节点获取到我们的SQL语句，假设SQL语句中只有${}，那么直接就什么都不做，在运行的时候直接进行赋值。 而如果扫描到了#{}字符串之后，会进行替换，将#{}替换为 ?。 那么他是怎么进行判断的呢？ 这里会生成一个GenericTokenParser，这个对象可以传入一个openToken和closeToken，如果是#{}，那么openToken就是#{，closeToken就是 }，然后通过parse方法中的handler.handleToken()方法进行替换。 在这之前由于已经进行过SQL是否含有#{}的判断了，所以在这里如果是只有${}，那么handler就是BindingTokenParser的实例化对象，如果存在#{}，那么handler就是ParameterMappingTokenHandler的实例化对象。 分别进行处理。
上文中提到的解析不了的节点是什么意思？
根据上文的代码我们可知，解析Mapper.xml文件中的每个节点是有顺序的。那么假设我写了这么一个几个节点:
<select id="demoselect" paramterType='java.lang.Integer' resultMap='demoResultMap'>
</select>
<resultMap id="demoResultMap" type="demo">
<id column property>
<result coulmn property>
</resultMap>
select节点是需要获取resultMap的，但是此时resultMap并没有被解析到，所以解析到这个节点的时候是无法获取到resultMap的信息的。
我们来看看MyBatis是怎么做的：
private void buildStatementFromContext(List<XNode> list, String requiredDatabaseId) {
for (XNode context : list) {
final XMLStatementBuilder statementParser = new XMLStatementBuilder(configuration, builderAssistant, context, requiredDatabaseId);
try {
//解析xml节点
statementParser.parseStatementNode();
} catch (IncompleteElementException e) {
//xml语句有问题时 存储到集合中 等解析完能解析的再重新解析
configuration.addIncompleteStatement(statementParser);
}
}
}
当解析到某个节点出现问题的时候，会抛一个异常，然后会调用configuration的addIncompleteStatement方法，将这个解析对象先暂存到这个集合中，等到所有的节点都解析完毕之后，在对这个集合内的解析对象继续解析:
public void parse() {
//判断文件是否之前解析过
if (!configuration.isResourceLoaded(resource)) {
//解析mapper文件
configurationElement(parser.evalNode("/mapper"));
configuration.addLoadedResource(resource);
//绑定Namespace里面的Class对象
bindMapperForNamespace();
}
//重新解析之前解析不了的节点
parsePendingResultMaps();
parsePendingCacheRefs();
parsePendingStatements();
}
private void parsePendingResultMaps() {
Collection<ResultMapResolver> incompleteResultMaps = configuration.getIncompleteResultMaps();
synchronized (incompleteResultMaps) {
Iterator<ResultMapResolver> iter = incompleteResultMaps.iterator();
while (iter.hasNext()) {
try {
//添加resultMap
iter.next().resolve();
iter.remove();
} catch (IncompleteElementException e) {
// ResultMap is still missing a resource...
}
}
}
}
public ResultMap resolve() {
//添加resultMap
return assistant.addResultMap(this.id, this.type, this.extend, this.discriminator, this.resultMappings, this.autoMapping);
}
1.3 解析小结
至此整个MyBatis的查询前构建的过程就基本说完了，简单地总结就是，MyBatis会在执行查询之前，对配置文件进行解析成配置对象：Configuration，以便在后面执行的时候去使用，而存放SQL的xml又会解析成MappedStatement对象，但是最终这个对象也会加入Configuration中。
二 执行篇
2.1 入口（代理对象的生成)
public static void main(String[] args) throws IOException {
InputStream inputStream = null;
try {
inputStream = Resources.getResourceAsStream("config/mybatis-config.xml");
} catch (IOException e) {
e.printStackTrace();
}
SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(inputStream);
SqlSession sqlSession = factory.openSession();
SysZdlxDao mapper = sqlSession.getMapper(SysZdlxDao.class);
List<SysZdlx> sysZdlxes = mapper.selectDictionaryTypeList();
System.out.println(sysZdlxes.size()+JsonUtil.toJson(sysZdlxes));
sqlSession.commit();
sqlSession.close();
}
首先在没看源码之前希望大家可以回忆起来，我们在使用原生MyBatis的时候（不与Spring进行整合），操作SQL的只需要一个对象，那就是SqlSession对象，这个对象就是专门与数据库进行交互的。
我们在构造篇有提到，Configuration对象是在SqlSessionFactoryBuilder中的build方法中调用了XMLConfigBuilder的parse方法进行解析的，但是我们没有提到这个Configuration最终的去向。讲这个之前我们可以思考一下，这个Configuration生成之后，会在哪个环节被使用？毋庸置疑，它作为一个配置文件的整合，里面包含了数据库连接相关的信息，SQL语句相关信息等，在查询的整个流程中必不可少，而刚才我们又说过，SqlSession实际上是我们操作数据库的一个真实对象，所以可以得出这个结论：Configuration必然和SqlSession有所联系。
源码:
public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) {
try {
//解析config.xml(mybatis解析xml是用的 java dom) dom4j sax...
XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties);
//parse(): 解析config.xml里面的节点
return build(parser.parse());
} catch (Exception e) {
throw ExceptionFactory.wrapException("Error building SqlSession.", e);
} finally {
ErrorContext.instance().reset();
try {
inputStream.close();
} catch (IOException e) {
// Intentionally ignore. Prefer previous error.
}
}
}
public SqlSessionFactory build(Configuration config) {
//注入到SqlSessionFactory
return new DefaultSqlSessionFactory(config);
}
public DefaultSqlSessionFactory(Configuration configuration) {
this.configuration = configuration;
}
实际上我们从源码中可以看到，Configuration是SqlSessionFactory的一个属性，而SqlSessionFactoryBuilder在build方法中实际上就是调用XMLConfigBuilder对xml文件进行解析，然后注入到SqlSessionFactory中。
明确了这一点我们就接着往下看。
根据主线我们现在得到了一个SqlSessionFactory对象，下一步就是要去获取SqlSession对象，这里会调用SqlSessionFactory.openSession()方法来获取，而openSession中实际上就是对SqlSession做了进一步的加工封装，包括增加了事务、执行器等
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
Transaction tx = null;
try {
//对SqlSession对象进行进一步加工封装
final Environment environment = configuration.getEnvironment();
final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);
tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);
final Executor executor = configuration.newExecutor(tx, execType);
//构建SqlSession对象
return new DefaultSqlSession(configuration, executor, autoCommit);
} catch (Exception e) {
closeTransaction(tx); // may have fetched a connection so lets call close()
throw ExceptionFactory.wrapException("Error opening session. Cause: " + e, e);
} finally {
ErrorContext.instance().reset();
}
}
到这里可以得出的小结论是，SqlSessionFactory对象中由于存在Configuration对象，所以它保存了全局配置信息，以及初始化环境和DataSource，而DataSource的作用就是用来开辟链接，当我们调用openSession方法时，就会开辟一个连接对象并传给SqlSession对象，交给SqlSession来对数据库做相关操作。
接着往下，现在我们获取到了一个SqlSession对象，而执行过程就是从这里开始的。
我们可以开始回忆了，平时我们使用MyBatis的时候，我们写的DAO层应该长这样：
public interface DemoMapper {
public List<Map<String,Object>> selectAll(Map<String,Object> map);
}
实际上它是一个接口，而且并没有实现类，而我们却可以直接对它进行调用，如下：
DemoMapper mapper = sqlSession.getMapper(DemoMapper.class);
Map<String,Object> map = new HashMap();
map.put("id","123");
System.out.println(mapper.selectAll(map));
可以猜测了，MyBatis底层一定使用了动态代理，来对这个接口进行代理，我们实际上调用的是MyBatis为我们生成的代理对象。
我们在获取Mapper的时候，需要调用SqlSession的getMapper()方法，那么就从这里深入。
//getMapper方法最终会调用到这里，这个是MapperRegistry的getMapper方法
@SuppressWarnings("unchecked")
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
//MapperProxyFactory 在解析的时候会生成一个map map中会有我们的DemoMapper的Class
final MapperProxyFactory<T> mapperProxyFactory = (MapperProxyFactory<T>) knownMappers.get(type);
if (mapperProxyFactory == null) {
throw new BindingException("Type " + type + " is not known to the MapperRegistry.");
}
try {
return mapperProxyFactory.newInstance(sqlSession);
} catch (Exception e) {
throw new BindingException("Error getting mapper instance. Cause: " + e, e);
}
}
可以看到这里mapperProxyFactory对象会从一个叫做knownMappers的对象中以type为key取出值，这个knownMappers是一个HashMap，存放了我们的DemoMapper对象，而这里的type，就是我们上面写的Mapper接口。那么就有人会问了，这个knownMappers是在什么时候生成的呢？实际上这是我上一篇漏讲的一个地方，在解析的时候，会调用parse()方法,相信大家都还记得，这个方法内部有一个bindMapperForNamespace方法，而就是这个方法帮我们完成了knownMappers的生成，并且将我们的Mapper接口put进去。
public void parse() {
//判断文件是否之前解析过
if (!configuration.isResourceLoaded(resource)) {
//解析mapper文件
configurationElement(parser.evalNode("/mapper"));
configuration.addLoadedResource(resource);
//这里：绑定Namespace里面的Class对象*
bindMapperForNamespace();
}
//重新解析之前解析不了的节点
parsePendingResultMaps();
parsePendingCacheRefs();
parsePendingStatements();
}
private void bindMapperForNamespace() {
String namespace = builderAssistant.getCurrentNamespace();
if (namespace != null) {
Class<?> boundType = null;
try {
boundType = Resources.classForName(namespace);
} catch (ClassNotFoundException e) {
}
if (boundType != null) {
if (!configuration.hasMapper(boundType)) {
configuration.addLoadedResource("namespace:" + namespace);
//这里将接口class传入
configuration.addMapper(boundType);
}
}
}
}
public <T> void addMapper(Class<T> type) {
if (type.isInterface()) {
if (hasMapper(type)) {
throw new BindingException("Type " + type + " is already known to the MapperRegistry.");
}
boolean loadCompleted = false;
try {
//这里将接口信息put进konwMappers。
knownMappers.put(type, new MapperProxyFactory<>(type));
MapperAnnotationBuilder parser = new MapperAnnotationBuilder(config, type);
parser.parse();
loadCompleted = true;
} finally {
if (!loadCompleted) {
knownMappers.remove(type);
}
}
}
}
所以我们在getMapper之后，获取到的是一个Class，之后的代码就简单了，就是生成标准的代理类了，调用newInstance()方法。
public T newInstance(SqlSession sqlSession) {
//首先会调用这个newInstance方法
//动态代理逻辑在MapperProxy里面
final MapperProxy<T> mapperProxy = new MapperProxy<>(sqlSession, mapperInterface, methodCache);
//通过这里调用下面的newInstance方法
return newInstance(mapperProxy);
}
@SuppressWarnings("unchecked")
protected T newInstance(MapperProxy<T> mapperProxy) {
//jdk自带的动态代理
return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy);
}
到这里，就完成了代理对象（MapperProxy）的创建，很明显的，MyBatis的底层就是对我们的接口进行代理类的实例化，从而操作数据库。
但是，我们好像就得到了一个空荡荡的对象，调用方法的逻辑呢？好像根本就没有看到，所以这也是比较考验Java功底的地方。
我们知道，一个类如果要称为代理对象，那么一定需要实现InvocationHandler接口，并且实现其中的invoke方法，进行一波推测，逻辑一定在invoke方法中。
于是就可以点进MapperProxy类，发现其的确实现了InvocationHandler接口，这里我将一些用不到的代码先删除了，只留下有用的代码，便于分析
/**
* @author Clinton Begin
* @author Eduardo Macarron
*/
public class MapperProxy<T> implements InvocationHandler, Serializable {
public MapperProxy(SqlSession sqlSession, Class<T> mapperInterface, Map<Method, MapperMethod> methodCache) {
//构造
this.sqlSession = sqlSession;
this.mapperInterface = mapperInterface;
this.methodCache = methodCache;
}
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
//这就是一个很标准的JDK动态代理了
//执行的时候会调用invoke方法
try {
if (Object.class.equals(method.getDeclaringClass())) {
//判断方法所属的类
//是不是调用的Object默认的方法
//如果是 则不代理，不改变原先方法的行为
return method.invoke(this, args);
} else if (method.isDefault()) {
//对于默认方法的处理
//判断是否为default方法，即接口中定义的默认方法。
//如果是接口中的默认方法则把方法绑定到代理对象中然后调用。
//这里不详细说
if (privateLookupInMethod == null) {
return invokeDefaultMethodJava8(proxy, method, args);
} else {
return invokeDefaultMethodJava9(proxy, method, args);
}
}
} catch (Throwable t) {
throw ExceptionUtil.unwrapThrowable(t);
}
//如果不是默认方法，则真正开始执行MyBatis代理逻辑。
//获取MapperMethod代理对象
final MapperMethod mapperMethod = cachedMapperMethod(method);
//执行
return mapperMethod.execute(sqlSession, args);
}
private MapperMethod cachedMapperMethod(Method method) {
//动态代理会有缓存，computeIfAbsent 如果缓存中有则直接从缓存中拿
//如果缓存中没有，则new一个然后放入缓存中
//因为动态代理是很耗资源的
return methodCache.computeIfAbsent(method,
k -> new MapperMethod(mapperInterface, method, sqlSession.getConfiguration()));
}
}
在方法开始代理之前，首先会先判断是否调用了Object类的方法，如果是，那么MyBatis不会去改变其行为，直接返回，如果是默认方法，则绑定到代理对象中然后调用（不是本文的重点），如果都不是，那么就是我们定义的mapper接口方法了，那么就开始执行。
执行方法需要一个MapperMethod对象，这个对象是MyBatis执行方法逻辑使用的，MyBatis这里获取MapperMethod对象的方式是，首先去方法缓存中看看是否已经存在了，如果不存在则new一个然后存入缓存中，因为创建代理对象是十分消耗资源的操作。总而言之，这里会得到一个MapperMethod对象，然后通过MapperMethod的excute()方法，来真正地执行逻辑。
2.2 执行逻辑
2.2.1 语句类型判断
这里首先会判断SQL的类型：SELECT|DELETE|UPDATE|INSERT，我们这里举的例子是SELECT，其它的其实都差不多，感兴趣的同学可以自己去看看。判断SQL类型为SELECT之后，就开始判断返回值类型，根据不同的情况做不同的操作。然后开始获取参数 -> 执行SQL。
//execute() 这里是真正执行SQL的地方
public Object execute(SqlSession sqlSession, Object[] args) {
//判断是哪一种SQL语句
Object result;
switch (command.getType()) {
case INSERT: {
Object param = method.convertArgsToSqlCommandParam(args);
result = rowCountResult(sqlSession.insert(command.getName(), param));
break;
}
case UPDATE: {
Object param = method.convertArgsToSqlCommandParam(args);
result = rowCountResult(sqlSession.update(command.getName(), param));
break;
}
case DELETE: {
Object param = method.convertArgsToSqlCommandParam(args);
result = rowCountResult(sqlSession.delete(command.getName(), param));
break;
}
case SELECT:
//我们的例子是查询
//判断是否有返回值
if (method.returnsVoid() && method.hasResultHandler()) {
//无返回值
executeWithResultHandler(sqlSession, args);
result = null;
} else if (method.returnsMany()) {
//返回值多行 这里调用这个方法
result = executeForMany(sqlSession, args);
} else if (method.returnsMap()) {
//返回Map
result = executeForMap(sqlSession, args);
} else if (method.returnsCursor()) {
//返回Cursor
result = executeForCursor(sqlSession, args);
} else {
Object param = method.convertArgsToSqlCommandParam(args);
result = sqlSession.selectOne(command.getName(), param);
if (method.returnsOptional()
&& (result == null || !method.getReturnType().equals(result.getClass()))) {
result = Optional.ofNullable(result);
}
}
break;
case FLUSH:
result = sqlSession.flushStatements();
break;
default:
throw new BindingException("Unknown execution method for: " + command.getName());
}
if (result == null && method.getReturnType().isPrimitive() && !method.returnsVoid()) {
throw new BindingException("Mapper method '" + command.getName()
+ " attempted to return null from a method with a primitive return type (" + method.getReturnType() + ").");
}
return result;
}
//返回值多行 这里调用这个方法
private <E> Object executeForMany(SqlSession sqlSession, Object[] args) {
//返回值多行时执行的方法
List<E> result;
//param是我们传入的参数，如果传入的是Map，那么这个实际上就是Map对象
Object param = method.convertArgsToSqlCommandParam(args);
if (method.hasRowBounds()) {
//如果有分页
RowBounds rowBounds = method.extractRowBounds(args);
//执行SQL的位置
result = sqlSession.selectList(command.getName(), param, rowBounds);
} else {
//如果没有
//执行SQL的位置
result = sqlSession.selectList(command.getName(), param);
}
// issue #510 Collections & arrays support
if (!method.getReturnType().isAssignableFrom(result.getClass())) {
if (method.getReturnType().isArray()) {
return convertToArray(result);
} else {
return convertToDeclaredCollection(sqlSession.getConfiguration(), result);
}
}
return result;
}
/**
* 获取参数名的方法
*/
public Object getNamedParams(Object[] args) {
final int paramCount = names.size();
if (args == null || paramCount == 0) {
//如果传过来的参数是空
return null;
} else if (!hasParamAnnotation && paramCount == 1) {
//如果参数上没有加注解例如@Param，且参数只有一个，则直接返回参数
return args[names.firstKey()];
} else {
//如果参数上加了注解，或者参数有多个。
//那么MyBatis会封装参数为一个Map，但是要注意，由于jdk的原因，我们只能获取到参数下标和参数名，但是参数名会变成arg0,arg1.
//所以传入多个参数的时候，最好加@Param，否则假设传入多个String，会造成#{}获取不到值的情况
final Map<String, Object> param = new ParamMap<>();
int i = 0;
for (Map.Entry<Integer, String> entry : names.entrySet()) {
//entry.getValue 就是参数名称
param.put(entry.getValue(), args[entry.getKey()]);
//如果传很多个String，也可以使用param1，param2.。。
// add generic param names (param1, param2, ...)
final String genericParamName = GENERIC_NAME_PREFIX + String.valueOf(i + 1);
// ensure not to overwrite parameter named with @Param
if (!names.containsValue(genericParamName)) {
param.put(genericParamName, args[entry.getKey()]);
}
i++;
}
return param;
}
}
2.2.2 SQL执行（二级缓存）
执行SQL的核心方法就是selectList，即使是selectOne，底层实际上也是调用了selectList方法，然后取第一个而已。
@Override
public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
try {
//MappedStatement:解析XML时生成的对象， 解析某一个SQL 会封装成MappedStatement，里面存放了我们所有执行SQL所需要的信息
MappedStatement ms = configuration.getMappedStatement(statement);
//查询,通过executor
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();
}
}
在这里我们又看到了上一篇构造的时候提到的，MappedStatement对象，这个对象是解析Mapper.xml配置而产生的，用于存储SQL信息，执行SQL需要这个对象中保存的关于SQL的信息，而selectList内部调用了Executor对象执行SQL语句，这个对象作为MyBatis四大对象之一，一会会说。
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
//获取sql语句
BoundSql boundSql = ms.getBoundSql(parameterObject);
//生成一个缓存的key
//这里是-1181735286:4652640444:com.DemoMapper.selectAll:0:2147483647:select * from test WHERE id =?:2121:development
CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
@Override
//二级缓存查询
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
throws SQLException {
//二级缓存的Cache
Cache cache = ms.getCache();
if (cache != null) {
//如果Cache不为空则进入
//如果有需要的话，就刷新缓存（有些缓存是定时刷新的，需要用到这个）
flushCacheIfRequired(ms);
//如果这个statement用到了缓存（二级缓存的作用域是namespace，也可以理解为这里的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.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
//查询完毕后将数据放入二级缓存
tcm.putObject(cache, key, list); // issue #578 and #116
}
//返回
return list;
}
}
//如果cache根本就不存在，那么直接查询一级缓存
return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
首先MyBatis在查询时，不会直接查询数据库，而是会进行二级缓存的查询，由于二级缓存的作用域是namespace，也可以理解为一个mapper，所以还会判断一下这个mapper是否开启了二级缓存，如果没有开启，则进入一级缓存继续查询。
2.2.3 SQL执行（一级缓存）
//一级缓存查询
@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 {
//查询栈+1
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 {
//查询栈-1
queryStack--;
}
if (queryStack == 0) {
for (DeferredLoad deferredLoad : deferredLoads) {
deferredLoad.load();
}
// issue #601
deferredLoads.clear();
if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
// issue #482
clearLocalCache();
}
}
//结果返回
return list;
}
如果一级缓存查到了，那么直接就返回结果了，如果一级缓存没有查到结果，那么最终会进入数据库进行查询。
2.2.4 SQL执行（数据库查询）
//数据库查询
private <E> List<E> queryFromDatabase(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql) throws SQLException {
List<E> list;
//先往一级缓存中put一个占位符
localCache.putObject(key, EXECUTION_PLACEHOLDER);
try {
//调用doQuery方法查询数据库
list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
} finally {
localCache.removeObject(key);
}
//往缓存中put真实数据
localCache.putObject(key, list);
if (ms.getStatementType() == StatementType.CALLABLE) {
localOutputParameterCache.putObject(key, parameter);
}
return list;
}
//真实数据库查询
@Override
public <E> List<E> doQuery(MappedStatement ms, Object parameter, RowBounds rowBounds, ResultHandler resultHandler, BoundSql boundSql) throws SQLException {
Statement stmt = null;
try {
Configuration configuration = ms.getConfiguration();
//封装，StatementHandler也是MyBatis四大对象之一
StatementHandler handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
//#{} -> ? 的SQL在这里初始化
stmt = prepareStatement(handler, ms.getStatementLog());
//参数赋值完毕之后，才会真正地查询。
return handler.query(stmt, resultHandler);
} finally {
closeStatement(stmt);
}
}
在真正的数据库查询之前，我们的语句还是这样的：select * from test where id = ?，所以要先将占位符换成真实的参数值，所以接下来会进行参数的赋值。
参数赋值
因为MyBatis底层封装的就是java最基本的jdbc，所以赋值一定也是调用jdbc的putString()方法。
/********************************参数赋值部分*******************************/
//由于是#{}，所以使用的是prepareStatement，预编译SQL
private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException {
Statement stmt;
//拿连接对象
Connection connection = getConnection(statementLog);
//初始化prepareStatement
stmt = handler.prepare(connection, transaction.getTimeout());
//获取了PrepareStatement之后，这里给#{}赋值
handler.parameterize(stmt);
return stmt;
}
/**
* 预编译SQL进行put值
*/
@Override
public void setParameters(PreparedStatement ps) {
ErrorContext.instance().activity("setting parameters").object(mappedStatement.getParameterMap().getId());
//参数列表
List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();
if (parameterMappings != null) {
for (int i = 0; i < parameterMappings.size(); i++) {
ParameterMapping parameterMapping = parameterMappings.get(i);
if (parameterMapping.getMode() != ParameterMode.OUT) {
Object value;
//拿到xml中#{} 参数的名字 例如 #{id} propertyName==id
String propertyName = parameterMapping.getProperty();
if (boundSql.hasAdditionalParameter(propertyName)) { // issue #448 ask first for additional params
value = boundSql.getAdditionalParameter(propertyName);
} else if (parameterObject == null) {
value = null;
} else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {
value = parameterObject;
} else {
//metaObject存储了参数名和参数值的对应关系
MetaObject metaObject = configuration.newMetaObject(parameterObject);
value = metaObject.getValue(propertyName);
}
TypeHandler typeHandler = parameterMapping.getTypeHandler();
JdbcType jdbcType = parameterMapping.getJdbcType();
if (value == null && jdbcType == null) {
jdbcType = configuration.getJdbcTypeForNull();
}
try {
//在这里给preparedStatement赋值，通过typeHandler，setParameter最终会调用一个叫做setNonNullParameter的方法。代码贴在下面了。
typeHandler.setParameter(ps, i + 1, value, jdbcType);
} catch (TypeException | SQLException e) {
throw new TypeException("Could not set parameters for mapping: " + parameterMapping + ". Cause: " + e, e);
}
}
}
}
}
//jdbc赋值
public void setNonNullParameter(PreparedStatement ps, int i, String parameter, JdbcType jdbcType)
throws SQLException {
//这里就是最最原生的jdbc的赋值了
ps.setString(i, parameter);
}
/********************************参数赋值部分*******************************/
正式执行
当参数赋值完毕后，SQL就可以执行了，在上文中的代码可以看到当参数赋值完毕后，直接通过hanler.query()方法进行数据库查询 @Override
public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
//通过jdbc进行数据库查询。
PreparedStatement ps = (PreparedStatement) statement;
ps.execute();
//处理结果集 resultSetHandler 也是MyBatis的四大对象之一
return resultSetHandler.handleResultSets(ps);
}
可以很明显看到，这里实际上也就是调用我们熟悉的原生jdbc对数据库进行查询。
2.3 执行阶段总结
到这里，MyBatis的执行阶段从宏观角度看，一共完成了两件事：
- 代理对象的生成
- SQL的执行
而SQL的执行用了大量的篇幅来进行分析，虽然是根据一条查询语句的主线来进行分析的，但是这么看下来一定很乱，所以这里我会话一个流程图来帮助大家理解：
结果集处理
在SQL执行阶段，MyBatis已经完成了对数据的查询，那么现在还存在最后一个问题，那就是结果集处理，换句话来说，就是将结果集封装成对象。在不用框架的时候我们是使用循环获取结果集，然后通过getXXXX()方法一列一列地获取，这种方法劳动强度太大，看看MyBatis是如何解决的。
@Override
public List<Object> handleResultSets(Statement stmt) throws SQLException {
ErrorContext.instance().activity("handling results").object(mappedStatement.getId());
//resultMap可以通过多个标签指定多个值，所以存在多个结果集
final List<Object> multipleResults = new ArrayList<>();
int resultSetCount = 0;
//拿到当前第一个结果集
ResultSetWrapper rsw = getFirstResultSet(stmt);
//拿到所有的resultMap
List<ResultMap> resultMaps = mappedStatement.getResultMaps();
//resultMap的数量
int resultMapCount = resultMaps.size();
validateResultMapsCount(rsw, resultMapCount);
//循环处理每一个结果集
while (rsw != null && resultMapCount > resultSetCount) {
//开始封装结果集 list.get(index) 获取结果集
ResultMap resultMap = resultMaps.get(resultSetCount);
//传入resultMap处理结果集 rsw 当前结果集（主线）
handleResultSet(rsw, resultMap, multipleResults, null);
rsw = getNextResultSet(stmt);
cleanUpAfterHandlingResultSet();
resultSetCount++;
}
String[] resultSets = mappedStatement.getResultSets();
if (resultSets != null) {
while (rsw != null && resultSetCount < resultSets.length) {
ResultMapping parentMapping = nextResultMaps.get(resultSets[resultSetCount]);
if (parentMapping != null) {
String nestedResultMapId = parentMapping.getNestedResultMapId();
ResultMap resultMap = configuration.getResultMap(nestedResultMapId);
handleResultSet(rsw, resultMap, null, parentMapping);
}
rsw = getNextResultSet(stmt);
cleanUpAfterHandlingResultSet();
resultSetCount++;
}
}
//如果只有一个结果集，那么从多结果集中取出第一个
return collapseSingleResultList(multipleResults);
}
//处理结果集
private void handleResultSet(ResultSetWrapper rsw, ResultMap resultMap, List<Object> multipleResults, ResultMapping parentMapping) throws SQLException {
//处理结果集
try {
if (parentMapping != null) {
handleRowValues(rsw, resultMap, null, RowBounds.DEFAULT, parentMapping);
} else {
if (resultHandler == null) {
//判断resultHandler是否为空，如果为空建立一个默认的。
//结果集处理器
DefaultResultHandler defaultResultHandler = new DefaultResultHandler(objectFactory);
//处理行数据
handleRowValues(rsw, resultMap, defaultResultHandler, rowBounds, null);
multipleResults.add(defaultResultHandler.getResultList());
} else {
handleRowValues(rsw, resultMap, resultHandler, rowBounds, null);
}
}
} finally {
// issue #228 (close resultsets)
//关闭结果集
closeResultSet(rsw.getResultSet());
}
}
上文的代码，会创建一个处理结果集的对象，最终调用handleRwoValues()方法进行行数据的处理。
//处理行数据
public void handleRowValues(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping) throws SQLException {
//是否存在内嵌的结果集
if (resultMap.hasNestedResultMaps()) {
ensureNoRowBounds();
checkResultHandler();
handleRowValuesForNestedResultMap(rsw, resultMap, resultHandler, rowBounds, parentMapping);
} else {
//不存在内嵌的结果集
handleRowValuesForSimpleResultMap(rsw, resultMap, resultHandler, rowBounds, parentMapping);
}
}
//没有内嵌结果集时调用
private void handleRowValuesForSimpleResultMap(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping)
throws SQLException {
DefaultResultContext<Object> resultContext = new DefaultResultContext<>();
//获取当前结果集
ResultSet resultSet = rsw.getResultSet();
skipRows(resultSet, rowBounds);
while (shouldProcessMoreRows(resultContext, rowBounds) && !resultSet.isClosed() && resultSet.next()) {
//遍历结果集
ResultMap discriminatedResultMap = resolveDiscriminatedResultMap(resultSet, resultMap, null);
//拿到行数据，将行数据包装成一个Object
Object rowValue = getRowValue(rsw, discriminatedResultMap, null);
storeObject(resultHandler, resultContext, rowValue, parentMapping, resultSet);
}
}
这里的代码主要是通过每行的结果集，然后将其直接封装成一个Object对象，那么关键就是在于getRowValue()方法，如何让行数据变为Object对象的。
private Object getRowValue(ResultSetWrapper rsw, ResultMap resultMap, String columnPrefix) throws SQLException {
//创建一个空的Map存值
final ResultLoaderMap lazyLoader = new ResultLoaderMap();
//创建一个空对象装行数据
Object rowValue = createResultObject(rsw, resultMap, lazyLoader, columnPrefix);
if (rowValue != null && !hasTypeHandlerForResultObject(rsw, resultMap.getType())){
//通过反射操作返回值
//此时metaObject.originalObject = rowValue
final MetaObject metaObject = configuration.newMetaObject(rowValue);
boolean foundValues = this.useConstructorMappings;
if (shouldApplyAutomaticMappings(resultMap, false)) {
//判断是否需要自动映射，默认自动映射，也可以通过resultMap节点上的autoMapping配置是否自动映射
//这里是自动映射的操作。
foundValues = applyAutomaticMappings(rsw, resultMap, metaObject, columnPrefix) || foundValues;
}
foundValues = applyPropertyMappings(rsw, resultMap, metaObject, lazyLoader, columnPrefix) || foundValues;
foundValues = lazyLoader.size() > 0 || foundValues;
rowValue = foundValues || configuration.isReturnInstanceForEmptyRow() ? rowValue : null;
}
return rowValue;
}
在getRowValue中会判断是否是自动映射的，我们这里没有使用ResultMap，所以是自动映射（默认），那么就进入applyAutomaticMappings()方法，而这个方法就会完成对象的封装。
private boolean applyAutomaticMappings(ResultSetWrapper rsw, ResultMap resultMap, MetaObject metaObject, String columnPrefix) throws SQLException {
//自动映射参数列表
List<UnMappedColumnAutoMapping> autoMapping = createAutomaticMappings(rsw, resultMap, metaObject, columnPrefix);
//是否找到了该列
boolean foundValues = false;
if (!autoMapping.isEmpty()) {
//遍历
for (UnMappedColumnAutoMapping mapping : autoMapping) {
//通过列名获取值
final Object value = mapping.typeHandler.getResult(rsw.getResultSet(), mapping.column);
if (value != null) {
//如果值不为空，说明找到了该列
foundValues = true;
}
if (value != null || (configuration.isCallSettersOnNulls() && !mapping.primitive)) {
// gcode issue #377, call setter on nulls (value is not 'found')
//在这里赋值
metaObject.setValue(mapping.property, value);
}
}
}
return foundValues;
}
我们可以看到这个方法会通过遍历参数列表从而通过metaObject.setValue(mapping.property, value);对返回对象进行赋值，但是返回对象有可能是Map，有可能是我们自定义的对象，会有什么区别呢？
实际上，所有的赋值操作在内部都是通过一个叫ObjectWrapper的对象完成的，我们可以进去看看它对于Map和自定义对象赋值的实现有什么区别，问题就迎刃而解了。
先看看上文中代码的metaObject.setValue()方法
public void setValue(String name, Object value) {
PropertyTokenizer prop = new PropertyTokenizer(name);
if (prop.hasNext()) {
MetaObject metaValue = metaObjectForProperty(prop.getIndexedName());
if (metaValue == SystemMetaObject.NULL_META_OBJECT) {
if (value == null) {
// don't instantiate child path if value is null
return;
} else {
metaValue = objectWrapper.instantiatePropertyValue(name, prop, objectFactory);
}
}
metaValue.setValue(prop.getChildren(), value);
} else {
//这个方法最终会调用objectWrapper.set()对结果进行赋值
objectWrapper.set(prop, value);
}
}
我们可以看看objectWrapper的实现类：
而我们今天举的例子，DemoMapper的返回值是Map，所以objectWrapper会调用MapWrapper的set方法，如果是自定义类型，那么就会调用BeanWrapper的set方法，下面看看两个类中的set方法有什么区别:
//MapWrapper的set方法
public void set(PropertyTokenizer prop, Object value) {
if (prop.getIndex() != null) {
Object collection = resolveCollection(prop, map);
setCollectionValue(prop, collection, value);
} else {
//实际上就是调用了Map的put方法将属性名和属性值放入map中
map.put(prop.getName(), value);
}
}
//BeanWrapper的set方法
public void set(PropertyTokenizer prop, Object value) {
if (prop.getIndex() != null) {
Object collection = resolveCollection(prop, object);
setCollectionValue(prop, collection, value);
} else {
//在这里赋值，通过反射赋值，调用setXX()方法赋值
setBeanProperty(prop, object, value);
}
}
private void setBeanProperty(PropertyTokenizer prop, Object object, Object value) {
try {
Invoker method = metaClass.getSetInvoker(prop.getName());
Object[] params = {value};
try {
method.invoke(object, params);
} catch (Throwable t) {
throw ExceptionUtil.unwrapThrowable(t);
}
} catch (Throwable t) {
throw new ReflectionException("Could not set property '" + prop.getName() + "' of '" + object.getClass() + "' with value '" + value + "' Cause: " + t.toString(), t);
}
}
上面两个set方法分别是MapWrapper和BeanWrapper的不同实现，MapWrapper的set方法实际上就是将属性名和属性值放到map的key和value中，而BeanWrapper则是使用了反射，调用了Bean的set方法，将值注入。
2.4 执行阶段结语
至此，MyBatis的执行流程就为止了，本篇主要聊了从构建配置对象后，MyBatis是如何执行一条查询语句的，一级查询语句结束后是如何进行对结果集进行处理，映射为我们定义的数据类型的。 由于是源码分析文章，所以如果只是粗略的看，会显得有些乱，所以我还是再提供一张流程图，会比较好理解一些。
关于MyBatis的一级缓存、二级缓存相关的内容，我会在下面源码解析中阐述。
三 缓存篇
大家好，这一篇文章是MyBatis系列的最后一篇文章，前面两篇文章：带你阅读Mybatis源码（一）构造篇 和 带你阅读Mybatis源码（二）执行篇，主要说明了MyBatis是如何将我们的xml配置文件构建为其内部的Configuration对象和MappedStatement对象的，然后在第二篇我们说了构建完成后MyBatis是如何一步一步地执行我们的SQL语句并且对结果集进行封装的。
那么这篇作为MyBatis系列的最后一篇，自然是要来聊聊MyBatis中的一个不可忽视的功能，一级缓存和二级缓存。
3.1 何谓缓存
虽然这篇说的是MyBatis的缓存，但是我希望正在学习计算机的小伙伴即使还没有使用过MyBatis框架也能看明白今天这篇文章。缓存是什么？我来说说个人的理解，最后再上比较官方的概念。
缓存（Cache），顾名思义，有临时存储的意思。计算机中的缓存，我们可以直接理解为，存储在内存中的数据的容器，这与物理存储是有差别的，由于内存的读写速度比物理存储高出几个数量级，所以程序直接从内存中取数据和从物理硬盘中取数据的效率是不同的，所以有一些经常需要读取的数据，设计师们通常会将其放在缓存中，以便于程序对其进行读取。
但是，缓存是有代价的，刚才我们说过，缓存就是在内存中的数据的容器，一条64G的内存条，通常可以买3-4块1T-2T的机械硬盘了，所以缓存不能无节制地使用，这样成本会剧增，所以一般缓存中的数据都是需要频繁查询，但是又不常修改的数据。
而在一般业务中，查询通常会经过如下步骤。
- 读操作 --> 查询缓存中已经存在数据 -->如果不存在则查询数据库，如果存在则直接查询缓存-->数据库查询返回数据的同时，写入缓存中。
- 写操作 --> 清空缓存数据 -->写入数据库
比较官方的概念：
- ☞ 缓存就是数据交换的缓冲区（称作：Cache），当某一硬件要读取数据时，会首先从缓存汇总查询数据，有则直接执行，不存在时从内存中获取。由于缓存的数据比内存快的多，所以缓存的作用就是帮助硬件更快的运行。
- ☞ 缓存往往使用的是RAM（断电既掉的非永久存储），所以在用完后还是会把文件送到硬盘等存储器中永久存储。电脑中最大缓存就是内存条，硬盘上也有16M或者32M的缓存。
- ☞ 高速缓存是用来协调CPU与主存之间存取速度的差异而设置的。一般CPU工作速度高，但内存的工作速度相对较低，为了解决这个问题，通常使用高速缓存，高速缓存的存取速度介于CPU与主存之间。系统将一些CPU在最近几个时间段经常访问的内容存在高速缓存，这样就在一定程度上缓解了由于主存速度低造成的CPU“停工待料”的情况。
- ☞ 缓存就是把一些外存上的数据保存在内存上而已，为什么保存在内存上，我们运行的所有程序里面的变量都是存放在内存中的，所以如果想将值放入内存上，可以通过变量的方式存储。在JAVA中一些缓存一般都是通过Map集合来实现的。
3.2 MyBatis的缓存
在说MyBatis的缓存之前，先了解一下Java中的缓存一般都是怎么实现的，我们通常会使用Java中的Map，来实现缓存，所以在之后的缓存这个概念，就可以把它直接理解为一个Map，存的就是键值对。
一级缓存简介
MyBatis中的一级缓存，是默认开启且无法关闭的，一级缓存默认的作用域是一个SqlSession，解释一下，就是当SqlSession被构建了之后，缓存就存在了，只要这个SqlSession不关闭，这个缓存就会一直存在，换言之，只要SqlSession不关闭，那么这个SqlSession处理的同一条SQL就不会被调用两次，只有当会话结束了之后，这个缓存才会一并被释放。
虽说我们不能关闭一级缓存，但是作用域是可以修改的，比如可以修改为某个Mapper。
一级缓存的生命周期：
- 1、如果SqlSession调用了close()方法，会释放掉一级缓存PerpetualCache对象，一级缓存将不可用。
- 2、如果SqlSession调用了clearCache()，会清空PerpetualCache对象中的数据，但是该对象仍可使用。
- 3、SqlSession中执行了任何一个update操作(update()、delete()、insert()) ，都会清空PerpetualCache对象的数据，但是该对象可以继续使用。 节选自：https://www.cnblogs.com/happyflyingpig/p/7739749.html
二级缓存简介
MyBatis的二级缓存是默认关闭的，如果要开启有两种方式：
- 1.在mybatis-config.xml中加入如下配置片段
<!-- 全局配置参数，需要时再设置 -->
<settings>
<!-- 开启二级缓存 默认值为true -->
<setting name="cacheEnabled" value="true"/>
</settings>
- 2.在mapper.xml中开启
<!--开启本mapper的namespace下的二级缓存-->
<!--
eviction:代表的是缓存回收策略，目前MyBatis提供以下策略。
(1) LRU,最近最少使用的，一处最长时间不用的对象
(2) FIFO,先进先出，按对象进入缓存的顺序来移除他们
(3) SOFT,软引用，移除基于垃圾回收器状态和软引用规则的对象
(4) WEAK,弱引用，更积极的移除基于垃圾收集器状态和弱引用规则的对象。
这里采用的是LRU， 移除最长时间不用的对形象
flushInterval:刷新间隔时间，单位为毫秒，如果你不配置它，那么当
SQL被执行的时候才会去刷新缓存。
size:引用数目，一个正整数，代表缓存最多可以存储多少个对象，不宜设置过大。设置过大会导致内存溢出。
这里配置的是1024个对象
readOnly:只读，意味着缓存数据只能读取而不能修改，这样设置的好处是我们可以快速读取缓存，缺点是我们没有
办法修改缓存，他的默认值是false，不允许我们修改
-->
<cache eviction="回收策略" type="缓存类"/>
二级缓存的作用域与一级缓存不同，一级缓存的作用域是一个SqlSession，但是二级缓存的作用域是一个namespace，什么意思呢，你可以把它理解为一个mapper，在这个mapper中操作的所有SqlSession都可以共享这个二级缓存。但是假设有两条相同的SQL，写在不同的namespace下，那这个SQL就会被执行两次，并且产生两份value相同的缓存。
3.3 MyBatis缓存的执行流程
依旧是用前两篇的main方法，我们从源码的角度看看缓存是如何执行的。
public static void main(String[] args) throws IOException {
InputStream inputStream = null;
try {
inputStream = Resources.getResourceAsStream("config/mybatis-config.xml");
} catch (IOException e) {
e.printStackTrace();
}
SqlSessionFactory factory = new SqlSessionFactoryBuilder().build(inputStream);
SqlSession sqlSession = factory.openSession();
SysZdlxDao mapper = sqlSession.getMapper(SysZdlxDao.class);
List<SysZdlx> sysZdlxes = mapper.selectDictionaryTypeList();
System.out.println(sysZdlxes.size()+JsonUtil.toJson(sysZdlxes));
sqlSession.commit();
sqlSession.close();
}
这里会执行到query()方法：
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
throws SQLException {
//二级缓存的Cache,通过MappedStatement获取
Cache cache = ms.getCache();
if (cache != null) {
//是否需要刷新缓存
//在<select>标签中也可以配置flushCache属性来设置是否查询前要刷新缓存，默认增删改刷新缓存查询不刷新
flushCacheIfRequired(ms);
//判断这个mapper是否开启了二级缓存
if (ms.isUseCache() && resultHandler == null) {
//不管
ensureNoOutParams(ms, boundSql);
@SuppressWarnings("unchecked")
//先从缓存拿
List<E> list = (List<E>) tcm.getObject(cache, key);
if (list == null) {
//如果缓存等于空，那么查询一级缓存
list = delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
//查询完毕后将数据放入二级缓存
tcm.putObject(cache, key, list); // issue #578 and #116
}
//返回
return list;
}
}
//如果二级缓存为null，那么直接查询一级缓存
return delegate.query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
可以看到首先MyBatis在查询数据时会先看看这个mapper是否开启了二级缓存，如果开启了，会先查询二级缓存，如果缓存中存在我们需要的数据，那么直接就从缓存返回数据，如果不存在，则继续往下走查询逻辑。
接着往下走，如果二级缓存不存在，那么就直接查询数据了吗？答案是否定的，二级缓存如果不存在，MyBatis会再查询一次一级缓存，接着往下看。
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++;
//查询一级缓存（localCache）
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);
/**这个是queryFromDatabase的逻辑
* //先往缓存中put一个占位符
localCache.putObject(key, EXECUTION_PLACEHOLDER);
try {
list = doQuery(ms, parameter, rowBounds, resultHandler, boundSql);
} finally {
localCache.removeObject(key);
}
//往一级缓存中put真实数据
localCache.putObject(key, list);
if (ms.getStatementType() == StatementType.CALLABLE) {
localOutputParameterCache.putObject(key, parameter);
}
return list;
*/
}
} finally {
queryStack--;
}
if (queryStack == 0) {
for (DeferredLoad deferredLoad : deferredLoads) {
deferredLoad.load();
}
// issue #601
deferredLoads.clear();
if (configuration.getLocalCacheScope() == LocalCacheScope.STATEMENT) {
// issue #482
clearLocalCache();
}
}
return list;
}
一级缓存和二级缓存的查询逻辑其实差不多，都是先查询缓存，如果没有则进行下一步查询，只不过一级缓存中如果没有结果，那么就直接查询数据库，然后回写一级缓存。
讲到这里其实一级缓存和二级缓存的执行流程就说完了，缓存的逻辑其实都差不多，MyBatis的缓存是先查询一级缓存再查询二级缓存。
但是文章到这里并没有结束，还有一些缓存相关的问题可以聊。
缓存事务问题 不知道这个问题大家有没有想过，假设有这么一个场景，这里用二级缓存举例，因为二级缓存是跨事务的。
假设我们在查询之前开启了事务，并且进行数据库操作：
- 1.往数据库中插入一条数据（INSERT）
- 2.在同一个事务内查询数据（SELECT）
- 3.提交事务(COMMIT)
- 4.提交事务失败(ROLLBACK)
我们来分析一下这个场景，首先SqlSession先执行了一个INSERT操作，很显然，在我们刚才分析的逻辑基础上，此时缓存一定会被清空，然后在同一个事务下查询数据，数据又从数据库中被加载到了缓存中，此时提交事务，然后事务提交失败了。
考虑一下此时会出现什么情况，相信已经有人想到了，事务提交失败之后，事务会进行回滚，那么执行INSERT插入的这条数据就被回滚了，但是我们在插入之后进行了一次查询，这个数据已经放到了缓存中，下一次查询必然是直接查询缓存而不会再去查询数据库了，可是此时缓存和数据库之间已经存在了数据不一致的问题。
问题的根本原因就在于，数据库提交事务失败了可以进行回滚，但是缓存不能进行回滚。
我们来看看MyBatis是如何解决这个问题的。
TransactionalCacheManager
这个类是MyBatis用于缓存事务管理的类，我们可以看看其数据结构。
public class TransactionalCacheManager {
//事务缓存
private final Map<Cache, TransactionalCache> transactionalCaches = new HashMap<>();
public void clear(Cache cache) {
getTransactionalCache(cache).clear();
}
public Object getObject(Cache cache, CacheKey key) {
return getTransactionalCache(cache).getObject(key);
}
public void putObject(Cache cache, CacheKey key, Object value) {
getTransactionalCache(cache).putObject(key, value);
}
public void commit() {
for (TransactionalCache txCache : transactionalCaches.values()) {
txCache.commit();
}
}
public void rollback() {
for (TransactionalCache txCache : transactionalCaches.values()) {
txCache.rollback();
}
}
private TransactionalCache getTransactionalCache(Cache cache) {
return transactionalCaches.computeIfAbsent(cache, TransactionalCache::new);
}
}
TransactionalCacheManager中封装了一个Map，用于将事务缓存对象缓存起来，这个Map的Key是我们的二级缓存对象，而Value是一个叫做TransactionalCache，顾名思义，这个缓存就是事务缓存，我们来看看其内部的实现。
public class TransactionalCache implements Cache {
private static final Log log = LogFactory.getLog(TransactionalCache.class);
//真实缓存对象
private final Cache delegate;
//是否需要清空提交空间的标识
private boolean clearOnCommit;
//所有待提交的缓存
private final Map<Object, Object> entriesToAddOnCommit;
//未命中的缓存集合，防止击穿缓存，并且如果查询到的数据为null，说明要通过数据库查询，有可能存在数据不一致，都记录到这个地方
private final Set<Object> entriesMissedInCache;
public TransactionalCache(Cache delegate) {
this.delegate = delegate;
this.clearOnCommit = false;
this.entriesToAddOnCommit = new HashMap<>();
this.entriesMissedInCache = new HashSet<>();
}
@Override
public String getId() {
return delegate.getId();
}
@Override
public int getSize() {
return delegate.getSize();
}
@Override
public Object getObject(Object key) {
// issue #116
Object object = delegate.getObject(key);
if (object == null) {
//如果取出的是空，那么放到未命中缓存，并且在查询数据库之后putObject中将本应该放到真实缓存中的键值对放到待提交事务缓存
entriesMissedInCache.add(key);
}
//如果不为空
// issue #146
//查看缓存清空标识是否为false，如果事务提交了就为true，事务提交了会更新缓存，所以返回null。
if (clearOnCommit) {
return null;
} else {
//如果事务没有提交，那么返回原先缓存中的数据，
return object;
}
}
@Override
public void putObject(Object key, Object object) {
//如果返回的数据为null，那么有可能到数据库查询，查询到的数据先放置到待提交事务的缓存中
//本来应该put到缓存中，现在put到待提交事务的缓存中去。
entriesToAddOnCommit.put(key, object);
}
@Override
public Object removeObject(Object key) {
return null;
}
@Override
public void clear() {
//如果事务提交了，那么将清空缓存提交标识设置为true
clearOnCommit = true;
//清空entriesToAddOnCommit
entriesToAddOnCommit.clear();
}
public void commit() {
if (clearOnCommit) {
//如果为true，那么就清空缓存。
delegate.clear();
}
//把本地缓存刷新到真实缓存。
flushPendingEntries();
//然后将所有值复位。
reset();
}
public void rollback() {
//事务回滚
unlockMissedEntries();
reset();
}
private void reset() {
//复位操作。
clearOnCommit = false;
entriesToAddOnCommit.clear();
entriesMissedInCache.clear();
}
private void flushPendingEntries() {
//遍历事务管理器中待提交的缓存
for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) {
//写入到真实的缓存中。
delegate.putObject(entry.getKey(), entry.getValue());
}
for (Object entry : entriesMissedInCache) {
//把未命中的一起put
if (!entriesToAddOnCommit.containsKey(entry)) {
delegate.putObject(entry, null);
}
}
}
private void unlockMissedEntries() {
for (Object entry : entriesMissedInCache) {
//清空真实缓存区中未命中的缓存。
try {
delegate.removeObject(entry);
} catch (Exception e) {
log.warn("Unexpected exception while notifiying a rollback to the cache adapter."
+ "Consider upgrading your cache adapter to the latest version. Cause: " + e);
}
}
}
}
在TransactionalCache中有一个真实缓存对象Cache，这个真实缓存对象就是我们真正的二级缓存，还有一个 entriesToAddOnCommit，这个Map对象中存放的是所有待提交事务的缓存。
我们在二级缓存执行的代码中，看到在缓存中get或者put结果时，都是叫tcm的对象调用了getObject()方法和putObject()方法，这个对象实际上就是TransactionalCacheManager的实体对象，而这个对象实际上是调用了TransactionalCache的方法，我们来看看这两个方法是如何实现的。
@Override
public Object getObject(Object key) {
// issue #116
Object object = delegate.getObject(key);
if (object == null) {
//如果取出的是空，那么放到未命中缓存，并且在查询数据库之后putObject中将本应该放到真实缓存中的键值对放到待提交事务缓存
entriesMissedInCache.add(key);
}
//如果不为空
// issue #146
//查看缓存清空标识是否为false，如果事务提交了就为true，事务提交了会更新缓存，所以返回null。
if (clearOnCommit) {
return null;
} else {
//如果事务没有提交，那么返回原先缓存中的数据，
return object;
}
}
@Override
public void putObject(Object key, Object object) {
//如果返回的数据为null，那么有可能到数据库查询，查询到的数据先放置到待提交事务的缓存中
//本来应该put到缓存中，现在put到待提交事务的缓存中去。
entriesToAddOnCommit.put(key, object);
}
在getObject()方法中存在两个分支：
如果发现缓存中取出的数据为null，那么会把这个key放到entriesMissedInCache中，这个对象的主要作用就是将我们未命中的key全都保存下来，防止缓存被击穿，并且当我们在缓存中无法查询到数据，那么就有可能到一级缓存和数据库中查询，那么查询过后会调用putObject()方法，这个方法本应该将我们查询到的数据put到真是缓存中，但是现在由于存在事务，所以暂时先放到entriesToAddOnCommit中。
如果发现缓存中取出的数据不为null，那么会查看事务提交标识(clearOnCommit)是否为true，如果为true，代表事务已经提交了，之后缓存会被清空，所以返回null，如果为false，那么由于事务还没有被提交，所以返回当前缓存中存的数据。
那么当事务提交成功或提交失败，又会是什么状况呢？不妨看看commit和rollback方法。
public void commit() {
if (clearOnCommit) {
//如果为true，那么就清空缓存。
delegate.clear();
}
//把本地缓存刷新到真实缓存。
flushPendingEntries();
//然后将所有值复位。
reset();
}
public void rollback() {
//事务回滚
unlockMissedEntries();
reset();
}
先分析事务提交成功的情况，如果事务正常提交了，那么会有这么几步操作：
- 清空真实缓存。
- 将本地缓存（未提交的事务缓存 entriesToAddOnCommit）刷新到真实缓存。
- 将所有值复位。
我们来看看代码是如何实现的：
private void flushPendingEntries() {
//遍历事务管理器中待提交的缓存
for (Map.Entry<Object, Object> entry : entriesToAddOnCommit.entrySet()) {
//写入到真实的缓存中。
delegate.putObject(entry.getKey(), entry.getValue());
}
for (Object entry : entriesMissedInCache) {
//把未命中的一起put
if (!entriesToAddOnCommit.containsKey(entry)) {
delegate.putObject(entry, null);
}
}
}
private void reset() {
//复位操作。
clearOnCommit = false;
entriesToAddOnCommit.clear();
entriesMissedInCache.clear();
}
public void clear() {
//如果事务提交了，那么将清空缓存提交标识设置为true
clearOnCommit = true;
//清空事务提交缓存
entriesToAddOnCommit.clear();
}
清空真实缓存就不说了，就是Map调用clear方法，清空所有的键值对。
将未提交事务缓存刷新到真实缓存，首先会遍历entriesToAddOnCommit，然后调用真实缓存的putObject方法，将entriesToAddOnCommit中的键值对put到真实缓存中，这步完成后，还会将未命中缓存中的数据一起put进去，值设置为null。
最后进行复位，将提交事务标识设为false，未命中缓存、未提交事务缓存中的所有数据全都清空。
如果事务没有正常提交，那么就会发生回滚，再来看看回滚是什么流程：
- 清空真实缓存中未命中的缓存。
- 将所有值复位
public void rollback() {
//事务回滚
unlockMissedEntries();
reset();
}
private void unlockMissedEntries() {
for (Object entry : entriesMissedInCache) {
//清空真实缓存区中未命中的缓存。
try {
delegate.removeObject(entry);
} catch (Exception e) {
log.warn("Unexpected exception while notifiying a rollback to the cache adapter."
+ "Consider upgrading your cache adapter to the latest version. Cause: " + e);
}
}
}
由于凡是在缓存中未命中的key，都会被记录到entriesMissedInCache这个缓存中，所以这个缓存中包含了所有查询数据库的key，所以最终只需要在真实缓存中把这部分key和对应的value给删除即可。
缓存事务总结
简而言之，缓存事务的控制主要是通过TransactionalCacheManager控制TransactionCache完成的，关键就在于TransactionCache中的entriesToAddCommit和entriesMissedInCache这两个对象，entriesToAddCommit在事务开启到提交期间作为真实缓存的替代品，将从数据库中查询到的数据先放到这个Map中，待事务提交后，再将这个对象中的数据刷新到真实缓存中，如果事务提交失败了，则清空这个缓存中的数据即可，并不会影响到真实的缓存。
entriesMissedInCache主要是用来保存在查询过程中在缓存中没有命中的key，由于没有命中，说明需要到数据库中查询，那么查询过后会保存到entriesToAddCommit中，那么假设在事务提交过程中失败了，而此时entriesToAddCommit的数据又都刷新到缓存中了，那么此时调用rollback就会通过entriesMissedInCache中保存的key，来清理真实缓存，这样就可以保证在事务中缓存数据与数据库的数据保持一致。
一些使用缓存的经验
二级缓存不能存在一直增多的数据
由于二级缓存的影响范围不是SqlSession而是namespace，所以二级缓存会在你的应用启动时一直存在直到应用关闭，所以二级缓存中不能存在随着时间数据量越来越大的数据，这样有可能会造成内存空间被占满。
二级缓存有可能存在脏读的问题（可避免）
由于二级缓存的作用域为namespace，那么就可以假设这么一个场景，有两个namespace操作一张表，第一个namespace查询该表并回写到内存中，第二个namespace往表中插一条数据，那么第一个namespace的二级缓存是不会清空这个缓存的内容的，在下一次查询中，还会通过缓存去查询，这样会造成数据的不一致。
所以当项目里有多个命名空间操作同一张表的时候，最好不要用二级缓存，或者使用二级缓存时避免用两个namespace操作一张表。
Spring整合MyBatis缓存失效问题
一级缓存的作用域是SqlSession，而使用者可以自定义SqlSession什么时候出现什么时候销毁，在这段期间一级缓存都是存在的。
当使用者调用close()方法之后，就会销毁一级缓存。
但是，我们在和Spring整合之后，Spring帮我们跳过了SqlSessionFactory这一步，我们可以直接调用Mapper，导致在操作完数据库之后，Spring就将SqlSession就销毁了，一级缓存就随之销毁了，所以一级缓存就失效了。
那么怎么能让缓存生效呢？
- 1.开启事务，因为一旦开启事务，Spring就不会在执行完SQL之后就销毁SqlSession，因为SqlSession一旦关闭，事务就没了，一旦我们开启事务，在事务期间内，缓存会一直存在。
- 2.使用二级缓存。
End
393
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
