深入淺出Mybatis系列（十）---SQL執行流程分析（源碼篇）(轉)
轉載自：http://www.cnblogs.com/dongying/p/4142476.html
1. SqlSessionFactory 與 SqlSession.
通過前面的章節對於mybatis 的介紹及使用，大家都能體會到SqlSession的重要性了吧， 沒錯，從表面上來看，咱們都是通過SqlSession去執行sql語句（註意：是從表面看，實際的待會兒就會講）。那麽咱們就先看看是怎麽獲取SqlSession的吧：
（1）首先，SqlSessionFactoryBuilder去讀取mybatis的配置文件，然後build一個DefaultSqlSessionFactory。源碼如下：
/**
* 一系列的構造方法最終都會調用本方法（配置文件為Reader時會調用本方法，還有一個InputStream方法與此對應）
* @param reader
* @param environment
* @param properties
* @return
*/
public SqlSessionFactory build(Reader reader, String environment, Properties properties) {
try {
//通過XMLConfigBuilder解析配置文件，解析的配置相關信息都會封裝為一個Configuration對象
XMLConfigBuilder parser = new XMLConfigBuilder(reader, environment, properties);
//這兒創建DefaultSessionFactory對象
return build(parser.parse());
} catch (Exception e) {
throw ExceptionFactory.wrapException("Error building SqlSession.", e);
} finally {
ErrorContext.instance().reset();
try {
reader.close();
} catch (IOException e) {
// Intentionally ignore. Prefer previous error.
}
}
}
public SqlSessionFactory build(Configuration config) {
return new DefaultSqlSessionFactory(config);
}
（2）當我們獲取到SqlSessionFactory之後，就可以通過SqlSessionFactory去獲取SqlSession對象。源碼如下：
/**
* 通常一系列openSession方法最終都會調用本方法
* @param execType
* @param level
* @param autoCommit
* @return
*/
private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
Transaction tx = null;
try {
//通過Confuguration對象去獲取Mybatis相關配置信息, Environment對象包含了數據源和事務的配置
final Environment environment = configuration.getEnvironment();
final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);
tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);
//之前說了，從表面上來看，咱們是用sqlSession在執行sql語句， 實際呢，其實是通過excutor執行， excutor是對於Statement的封裝
final Executor executor = configuration.newExecutor(tx, execType);
//關鍵看這兒，創建了一個DefaultSqlSession對象
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();
}
}
通過以上步驟，咱們已經得到SqlSession對象了。接下來就是該幹嘛幹嘛去了（話說還能幹嘛，當然是執行sql語句咯）。看了上面，咱們也回想一下之前寫的Demo,
SqlSessionFactory sessionFactory = null;
String resource = "mybatis-conf.xml";
try {
//SqlSessionFactoryBuilder讀取配置文件
sessionFactory = new SqlSessionFactoryBuilder().build(Resources
.getResourceAsReader(resource));
} catch (IOException e) {
e.printStackTrace();
}
//通過SqlSessionFactory獲取SqlSession
SqlSession sqlSession = sessionFactory.openSession();
還真這麽一回事兒，對吧！
SqlSession咱們也拿到了，咱們可以調用SqlSession中一系列的select..., insert..., update..., delete...方法輕松自如的進行CRUD操作了。 就這樣？ 那咱配置的映射文件去哪兒了？ 別急， 咱們接著往下看：
2. 利器之MapperProxy:
在mybatis中，通過MapperProxy動態代理咱們的dao， 也就是說， 當咱們執行自己寫的dao裏面的方法的時候，其實是對應的mapperProxy在代理。那麽，咱們就看看怎麽獲取MapperProxy對象吧：
（1）通過SqlSession從Configuration中獲取。源碼如下：
/**
* 什麽都不做，直接去configuration中找， 哥就是這麽任性
*/
@Override
public <T> T getMapper(Class<T> type) {
return configuration.<T>getMapper(type, this);
}
（2）SqlSession把包袱甩給了Configuration, 接下來就看看Configuration。源碼如下：
/**
* 燙手的山芋，俺不要，你找mapperRegistry去要
* @param type
* @param sqlSession
* @return
*/
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
return mapperRegistry.getMapper(type, sqlSession);
}
（3）Configuration不要這燙手的山芋，接著甩給了MapperRegistry， 那咱看看MapperRegistry。 源碼如下：
/**
* 爛活凈讓我來做了，沒法了，下面沒人了，我不做誰來做
* @param type
* @param sqlSession
* @return
*/
@SuppressWarnings("unchecked")
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
//能偷懶的就偷懶，俺把粗活交給MapperProxyFactory去做
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);
}
}
(4)MapperProxyFactory是個苦B的人，粗活最終交給它去做了。咱們看看源碼：
/**
* 別人虐我千百遍，我待別人如初戀
* @param mapperProxy
* @return
*/
@SuppressWarnings("unchecked")
protected T newInstance(MapperProxy<T> mapperProxy) {
//動態代理我們寫的dao接口
return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy);
}
public T newInstance(SqlSession sqlSession) {
final MapperProxy<T> mapperProxy = new MapperProxy<T>(sqlSession, mapperInterface, methodCache);
return newInstance(mapperProxy);
}
通過以上的動態代理，咱們就可以方便地使用dao接口啦， 就像之前咱們寫的demo那樣：
UserDao userMapper = sqlSession.getMapper(UserDao.class); User insertUser = new User();
這下方便多了吧， 呵呵， 貌似mybatis的源碼就這麽一回事兒啊。
別急，還沒完， 咱們還沒看具體是怎麽執行sql語句的呢。
3. Excutor:
接下來，咱們才要真正去看sql的執行過程了。
上面，咱們拿到了MapperProxy, 每個MapperProxy對應一個dao接口， 那麽咱們在使用的時候，MapperProxy是怎麽做的呢？ 源碼奉上：
MapperProxy:
/**
* MapperProxy在執行時會觸發此方法
*/
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
if (Object.class.equals(method.getDeclaringClass())) {
try {
return method.invoke(this, args);
} catch (Throwable t) {
throw ExceptionUtil.unwrapThrowable(t);
}
}
final MapperMethod mapperMethod = cachedMapperMethod(method);
//二話不說，主要交給MapperMethod自己去管
return mapperMethod.execute(sqlSession, args);
}
MapperMethod:
View Code
既然又回到SqlSession了， 那麽咱們就看看SqlSession的CRUD方法了，為了省事，還是就選擇其中的一個方法來做分析吧。這兒，咱們選擇了selectList方法：
public <E> List<E> selectList(String statement, Object parameter, RowBounds rowBounds) {
try {
MappedStatement ms = configuration.getMappedStatement(statement);
//CRUD實際上是交給Excetor去處理， excutor其實也只是穿了個馬甲而已，小樣，別以為穿個馬甲我就不認識你嘞！
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();
}
}
然後，通過一層一層的調用，最終會來到doQuery方法， 這兒咱們就隨便找個Excutor看看doQuery方法的實現吧，我這兒選擇了SimpleExecutor:
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 handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
stmt = prepareStatement(handler, ms.getStatementLog());
//StatementHandler封裝了Statement, 讓 StatementHandler 去處理
return handler.<E>query(stmt, resultHandler);
} finally {
closeStatement(stmt);
}
}
接下來，咱們看看StatementHandler 的一個實現類 PreparedStatementHandler（這也是我們最常用的，封裝的是PreparedStatement）, 看看它使怎麽去處理的：
public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
//到此，原形畢露， PreparedStatement, 這個大家都已經滾瓜爛熟了吧
PreparedStatement ps = (PreparedStatement) statement;
ps.execute();
//結果交給了ResultSetHandler 去處理
return resultSetHandler.<E> handleResultSets(ps);
}
到此， 一次sql的執行流程就完了。 我這兒僅拋磚引玉，建議有興趣的去看看Mybatis3的源碼。
好啦，本次就到此結束啦，最近太忙了， 又該忙去啦。
深入淺出Mybatis系列（十）---SQL執行流程分析（源碼篇）(轉)