MyBatis3源码解析-执行SQL流程
获取SQL
思考：Mybatis是如何获取SQL的？即是如何获取到我们写的mapper文件的？
其实我们有在XML配置文件中配置标签来加载我们的mapper文件。
Mybatis加载mapper文件有几种方式？
官网文档给了答案：总共有四种方式()。
源码
前文了解了XML 配置解析器XMLConfigBuilder的parse()方法便是加载配置文件生成一个Configuration对象的入口方法；
上篇了解了通过扫描environments标签如何获取数据源，下面会执行一个mapperElement方法来解析mappers标签,root.evalNode("mappers")返回的是一个value是mappers标签中内容的XNode对象；
mapperElement(root.evalNode("mappers"));
进入方法，会有限判断有没有package标签，如何没有则会去获取该子node的三个属性，然后3个if分别处理。
无论是哪种方式最后都会执行MapperBuilderAssistant类中的addMappedStatement方法,之后会将解析的sql信息后封装成的MappedStatement对象放在全局配置类的一个Map属性mappedStatements中。
configuration.addMappedStatement(statement);
protected final Map mappedStatements = new StrictMap("Mapped Statements collection")
.conflictMessageProducer((savedValue, targetValue) ->
". please check " + savedValue.getResource() + " and " + targetValue.getResource());
执行sql
再贴一下我们的测试demo：
@Test
public void test() throws IOException {
InputStream input = Resources.getResourceAsStream("SqlSessionConfig.xml");
SqlSessionFactory sessionFactory = new SqlSessionFactoryBuilder().build(input);
SqlSession sqlSession = sessionFactory.openSession();
LevelDao dao = sqlSession.getMapper(LevelDao.class);
List all = dao.findAll();
}
在生成SqlSessionFactory对象后，会调用openSession()。已知在前面执行build方法时把数据源和sql都存储在了全局配置类Configuration中，在该方法中则会从配置类中获取Environment(其中包含数据源信息)、TransactionFactory(事务)、Executor（执行器）来生成一个默认的DefaultSqlSession对象返回。
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
Transaction tx = null;
try {
final Environment environment = configuration.getEnvironment();
final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);
tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);
final Executor executor = configuration.newExecutor(tx, execType);
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();
}
}
Executor（执行器）一共分为三种：简单、复用、批量，默认SimpleExecutor。CachingExecutor也实现了Executor接口，严格来说CachingExecutor不是一个真正的实现，它会委托给BaseExecutor去实现。此处不做细讲。
public enum ExecutorType {
SIMPLE, REUSE, BATCH
}
到此我们了解到openSession()方法只是获取到一些信息，生成了一个执行器，还没有开始sql执行流程。
接下来测试demo中继续执行LevelDao dao = sqlSession.getMapper(LevelDao.class);
则会调用configuration.getMapper(type, this)，继续调用mapperRegistry.getMapper(type, sqlSession)，其内部是获取具体Class从MapperRegistry类中的 Map中获取MapperProxyFactory，该MAP中的元素是我们在执行new SqlSessionFactoryBuilder().build(input)方法扫描mapper标签时且是package或class的方式存放进去的；
private final Map<Class, MapperProxyFactory> knownMappers = new HashMap<>();
最后通过SqlSession调用MapperProxyFactory类生成了一个代理对象并返回。
我们调用的List all = dao.findAll(); 实际上最后是会调用这个代理对象MapperProxy中的invoke方法
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
try {
if (Object.class.equals(method.getDeclaringClass())) {
return method.invoke(this, args);
} else if (method.isDefault()) {
if (privateLookupInMethod == null) {
return invokeDefaultMethodJava8(proxy, method, args);
} else {
return invokeDefaultMethodJava9(proxy, method, args);
}
}
} catch (Throwable t) {
throw ExceptionUtil.unwrapThrowable(t);
}
final MapperMethod mapperMethod = cachedMapperMethod(method);
return mapperMethod.execute(sqlSession, args);
}
当我们执行到我们自定义的方法时会执行execute方法，这句最终就会执行增删改查了；
再往下一层，就是执行JDBC那一套了，获取链接，执行，得到ResultSet，解析ResultSet映射成JavaBean。
最后总结一下具体流程：
- Mybatis 读取XML配置文件后会将内容放在一个Configuration类中，SqlSessionFactoryBuilder会读取Configuration类中信息创建SqlSessionFactory。
- 在初始化SqlSessionFactory时，Mapper 接口进行注册，注册在了名为 MapperRegistry 类的 HashMap中，key = Mapper class， value = 创建当前Mapper的工厂。
- SqlSessionFactory创建SqlSession。
- SqlSession中可以通过getMapper()拿到代理对象，SqlSession.getMapper 运用了 JDK动态代理，产生了目标Mapper接口的代理对象。
- 动态代理的 代理类是 MapperProxy ，这里边mapperMethod.execute(sqlSession, args)最终完成了增删改查方法的调用。