環境簡介與入口
記錄一下嘗試閱讀Mybatis源碼的過程,這篇筆記是我一邊讀,一遍記錄下來的,雖然內容也不多,對Mybatis整體的架構體系也沒有摸的很清楚,起碼也能把這個過程整理下來,這也是我比較喜歡的一種學習方式吧
單獨Mybatis框架搭建的環境,沒有和其他框架整合
入口點的源碼如下:
@Test
public void test01() {
try {
this.resourceAsStream = Resources.getResourceAsStream("SqlMapConfig.xml");
// 2. 創建SqlSessionFactory工廠
this.factory = new SqlSessionFactoryBuilder().build(resourceAsStream);
// 3. 創建sqlSession
// todo 怎么理解這個sqlSession？ 首先它是線程級別的，線程不安全， 其次它里面封裝了大量的CRUD的方法
this.sqlSession = factory.openSession();
IUserDao mapper = this.sqlSession.getMapper(IUserDao.class);
List<User> all = mapper.findAll();
for (User user : all) {
System.out.println(user);
}
// 事務性的操作,自動提交
this.sqlSession.commit();
// 6, 釋放資源
this.sqlSession.close();
this.resourceAsStream.close();
} catch (IOException e) {
e.printStackTrace();
}
}
構建SqlSessionFactory
首先跟進這個,看看如何構建SqlSessionFactory對象
this.factory = new SqlSessionFactoryBuilder().build(resourceAsStream);
這個SqlSessionFactoryBuilder類的存在很簡單,取名也叫他構建器,Mybatis的官網是這樣解釋它的,這個類可以被實例化(因為它有且僅有一個默認的無參構造),使用它的目的就是用來創建多個SqlSessionFactory實例,最好不要讓他一直存在,進而保證所有用來解析xml的資源可以被釋放
所以跳過對這個構建器的關注,轉而看的build()方法
首先會來到這個方法,直接可以看到存在一個XML配置解析器,這其實並不意外,畢竟現在是MyBatis是孤軍一人,就算我們使用的是注解開發模式,不也得存在主配置文件不是?
public SqlSessionFactory build(InputStream inputStream, String environment, Properties properties) {
try {
XMLConfigBuilder parser = new XMLConfigBuilder(inputStream, environment, properties);
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.
}
}
}
接着看看parser.parse(),它里面會解析主配置文件中的信息,解析哪些信息呢? 源碼如下: 很清楚的看到,涵蓋mybatis配置文件中的所有的標簽
private void parseConfiguration(XNode root) {
try {
//issue #117 read properties first
propertiesElement(root.evalNode("properties"));
Properties settings = settingsAsProperties(root.evalNode("settings"));
...
typeHandlerElement(root.evalNode("typeHandlers"));
mapperElement(root.evalNode("mappers"));
} catch (Exception e) {
throw new BuilderException("Error parsing SQL Mapper Configuration. Cause: " + e, e);
}
}
第一個問題: 解析的配置信息存在哪里呢? 其實存放在一個叫Configuration的封裝類中, 這個上面的解析器是XMLConfigBuilder 這個封裝類的保存者是它的父類BaseBuilder
繼續跟進build()方法,源碼如下:
public SqlSessionFactory build(Configuration config) {
return new DefaultSqlSessionFactory(config);
}
小結: 至此也就完成了DefaultSqlSessionFactory()的構建,回想下,這個構建器真的太無私了,犧牲了自己,不僅僅創建了默認的SqlSessionFactory,還將配置文件的信息給了他
打開SqlSession
創建完成SqlSession工廠的創建, 我們繼續跟進this.sqlSession = factory.openSession(); , 從工廠中獲取一個SqlSession
跟進幾個空殼方法,我們很快就能來到下面的方法:
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();
}
}
什么是SqlSession呢? 注釋是這么說的,他是MyBatis在java中主要干活的接口,通過這個接口,你可以執行命令(它里面定義了大量的 諸如selectList類似的方法),獲取mapper,合並事務
The primary Java interface for working with MyBatis.
Through this interface you can execute commands, get mappers and manage transactions.
通過上面的我貼出來的函數,大家可以看到,通過事務工廠實例化了一個事物Transaction,那么問題來了,這個Transaction又是什么呢? 注釋是這么解釋的: Transaction 包裝了一個數據庫的連接,處理這個連接的生命周期,包含: 它的創建,准備 提交/回滾 和 關閉
緊接着創建執行器:configuration.newExecutor(tx, execType),默認創建的是CachingExecutor它維護了一個SimpleExecutor, 這個執行器的特點是 在每次執行完成后都會關閉 statement 對象
關於mybatis的執行器,其實挺多事的,打算專門寫一篇筆記
繼續看 new DefaultSqlSession()我們得知,這個sqlSession的默認實現類是DefaultSqlSession
第三個參數autocommit為false, 這也是為什么我們如果不手動提交事務時,雖然測試會通過,但是事務不會被持久化的原因
小結: 當前函數是 openSession(), 如果說它是打開一個session,那跟沒說是一樣的,通過源碼我們也看到了,這一步其實是Mybatis將 數據庫連接,事務,執行器進行了一下封裝然后返回給程序員
獲取Mapper -- maperProxy
我們交給mybatis的mapper是一個接口,看看Mybatis是如何實例化我們的結果,返回給我們一個代理對象的
跟進源碼: IUserDao mapper = this.sqlSession.getMapper(IUserDao.class); ,經過一個空方法,我們進入Configuration類中的函數如下:
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
return mapperRegistry.getMapper(type, sqlSession);
}
從mapperRegistry中獲取mapper,他是Configuration屬性如下: 可以看到這個mapperRegistry甚至包含了Configuration,甚至還多了個 knownMappers
那么問題來了,這個knownMappers是干啥呢? 我直接說,這個map就是在上面解析xml配置文件時,存放程序員在<mappers>標簽下配置的<maper>
protected final MapperRegistry mapperRegistry = new MapperRegistry(this);
// 詳情:
public class MapperRegistry {
private final Configuration config;
private final Map<Class<?>, MapperProxyFactory<?>> knownMappers = new HashMap<>();
繼續跟進這個getMapper()如下: 並且我們在配置文件中是這樣配置的
<mappers>
<mapper class="com.changwu.dao.IUserDao"/>
</mappers>
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
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類型,它的主要成員如下: 說白了,這個 map代理工廠是個輔助對象,它是對程序員提供的mapper結果的描述,同時內置使用jdk動態代理的邏輯為mapper創建代理對象
public class MapperProxyFactory<T> {
private final Class<T> mapperInterface;
private final Map<Method, MapperMethod> methodCache = new ConcurrentHashMap<>();
...
protected T newInstance(MapperProxy<T> mapperProxy) {
return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy);
}
說到了為mapper創建動態代理,就不得不去看看是哪個類充當了動態代理的需要的InvoketionHandler -- 這個類是mybatis中的MapperProxy, 沒錯它實現了InvocationHandler接口,重寫了invoke()邏輯,源碼如下:
@Override
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 (isDefaultMethod(method)) {
return invokeDefaultMethod(proxy, method, args);
}
} catch (Throwable t) {
throw ExceptionUtil.unwrapThrowable(t);
}
final MapperMethod mapperMethod = cachedMapperMethod(method);
return mapperMethod.execute(sqlSession, args);
}
小結: 至此當前模塊的獲取mapper對象已經完結了,我們明明白白的看到了MyBatis為我們的mapper使用jdk的動態代理創建出來代理對象, 這也是為什么我們免去了自己寫實現類的粗活
執行Map -- maperProxy
上一個模塊我們知道了Mybatis為我們創建出來了mapper接口的代理對象,那當我們獲取到這個代理對象之后執行它的mapper.findAll();實際上觸發的是代理對象的invoke()方法
所以說,接着看上面的MapperProxy的invoke()方法:
@Override
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 (isDefaultMethod(method)) {
return invokeDefaultMethod(proxy, method, args);
}
} catch (Throwable t) {
throw ExceptionUtil.unwrapThrowable(t);
}
final MapperMethod mapperMethod = cachedMapperMethod(method);
return mapperMethod.execute(sqlSession, args);
}
上面的方法我們關注兩個地方,第一個地方就是final MapperMethod mapperMethod = cachedMapperMethod(method);,見名知意: 緩存MapperMethod
第一個問題: 這個MapperMethod是什么? 它其實是Mybatis為sql命令+方法全限定名設計的封裝類
*/
public class MapperMethod {
private final SqlCommand command;
private final MethodSignature method;
說白了,就是想為MapperProxy保存一份map格式的信息,key=方法全名 value=MapperMethod(command,method),存放在MapperProxy的屬性methodCache中
comand -> "name=com.changwu.dao.IUserDao,fingAll"
method -> "result= public abstract java.util.List.com.changwu.dao.IUserDao.findAll()"
為什么要給這個MapperProxy保存這里呢? 很簡單,它是mapper的代理對象啊,程序員使用的就是他,在這里留一份method的副本,再用的話多方便?
完成緩存后,繼續看它如何執行方法:,跟進 mapperMethod.execute(sqlSession, args)
因為我使用的是@Select("select * from user"),所以一定進入下面的 result = executeForMany(sqlSession, args);
public Object execute(SqlSession sqlSession, Object[] args) {
Object result;
switch (command.getType()) {
case INSERT: {
Object param = method.convertArgsToSqlCommandParam(args);
result = rowCountResult(sqlSession.insert(command.getName(), param));
break;
}
..
case SELECT:
if (method.returnsVoid() && method.hasResultHandler()) {
executeWithResultHandler(sqlSession, args);
result = null;
} else if (method.returnsMany()) {
result = executeForMany(sqlSession, args);
...
}
所以我們繼續關注這個 executeForMany(sqlSession, args);方法,看他的第一個參數是sqlSession,也就是我們的DefaultSqlSession,他里面存在兩大重要對象: 1是configuration 配置對象, 2是Executor 執行器對象
繼續跟進:
private <E> Object executeForMany(SqlSession sqlSession, Object[] args) {
List<E> result;
Object param = method.convertArgsToSqlCommandParam(args);
if (method.hasRowBounds()) {
RowBounds rowBounds = method.extractRowBounds(args);
result = sqlSession.selectList(command.getName(), param, rowBounds);
} else {
result = sqlSession.selectList(command.getName(), param);
}
我們在繼續跟進這個selectList方法之前,先看看這個command.getName()是啥? 其實我們上面的代碼追蹤中有記錄: 就是name=com.changwu.dao.IUserDao,fingAll
繼續跟進去到下面的方法:
這個方法就比較有趣了,首先來說,下面的入參都是什么
statement = "com.changwu.dao.IUserDao.findAll" parameter=null
第二個問題:MappedStatement是什么? 它是一個對象,維護了很多很多的配置信息,但是我們關心它里面的兩條信息,這其實可以理解成一種方法與sql之間的映射,如下圖
@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();
}
}
前面閱讀時,我們知道Mybatis為我們創建的默認的執行器 Executor是CachingExecutor,如下圖
繼續跟進,主要做了下面三件事, 獲取到綁定的sql,然后調用SimpleExecutor緩存key,然后繼續執行query()方法
@Override
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
BoundSql boundSql = ms.getBoundSql(parameterObject);
CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
}
接着調用SimpleExecutor的query()方法,然后我們關注SimpleExecutor的doQuery()方法,源碼如下
@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 handler = configuration.newStatementHandler(wrapper, ms, parameter, rowBounds, resultHandler, boundSql);
stmt = prepareStatement(handler, ms.getStatementLog());
return handler.query(stmt, resultHandler);
} finally {
closeStatement(stmt);
}
}
我們注意到.在SimpleExcutor中創建的了一個 XXXStatementHandler這樣一個處理器, 所以我們的只管感覺就是,sql真正執行者其實並不是Executor,而是Executor會為每一條sql的執行重新new 一個 StatementHandler ,由這個handler去具體的執行sql
關於這個StatementHandler到底是是何方神聖? 暫時了解它是Mybatis定義的一個規范接口,定義了如下功能即可
public interface StatementHandler {
// sql預編譯, 構建statement對象
Statement prepare(Connection connection, Integer transactionTimeout)
throws SQLException;
// 對prepare方法構建的預編譯的sql進行參數的設置
void parameterize(Statement statement)
throws SQLException;
// 批量處理器
void batch(Statement statement)
throws SQLException;
// create update delete
int update(Statement statement)
throws SQLException;
// select
<E> List<E> query(Statement statement, ResultHandler resultHandler)
throws SQLException;
<E> Cursor<E> queryCursor(Statement statement)
throws SQLException;
// 獲取sql的封裝對象
BoundSql getBoundSql();
// 獲取參數處理對象
ParameterHandler getParameterHandler();
}
了解了這個StatementHandler是什么,下一個問題就是當前我們創建的默認的statement是誰呢? routingStatementHandler如下圖
創建preparedStatement
馬上馬就發生了一件悄無聲息的大事!!!根據現有的sql等信息,構建 PreparedStatement,我們關注這個 prepareStatement(handler, ms.getStatementLog());方法,通過調試我們得知,prepareStatement()是RoutingStatementHandler的抽象方法,被PreparedStatementHandler重寫了,所以我們去看它如何重寫的,如下:
@Override
public Statement prepare(Connection connection, Integer transactionTimeout) throws SQLException {
ErrorContext.instance().sql(boundSql.getSql());
Statement statement = null;
try {
statement = instantiateStatement(connection);
我們關注這個instantiateStatement()方法, 並且進入它的connection.prepareStatement(sql);方法,如下圖:
純潔的微笑... 見到了原生JDK, jdbc的親人...
創建完事這個 preparedStatement,下一步總該執行了吧...繞這么多圈...
我們回到上面代碼中的return handler.query(stmt, resultHandler);准備執行,此時第一個參數就是我們的剛創建出來的PreparedStatement, 回想一下,上面創建的這個默認的statement中的代表是PreparedStatementHandler,所以,我們進入到這個StatementHandler的實現類RountingStatementHandler中,看他的query()方法
@Override
public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
return delegate.query(statement, resultHandler);
}
調用RountingStatementHandler中維護的代表的StatementHandler也就是PreparedStatementHandler的query()方法,順勢跟進去,最終會通過反射執行jdbc操作,如圖, 我圈出來的對象就是我們上面創建出來的preparedStatement
提交事務
跟進conmit()方法,分成兩步
- 清空緩存
- 提交事務
清空緩存是在CachingExecutor中調用了SimpleExecutor簡單執行器的方法commit(required)
@Override
public void commit(boolean required) throws SQLException {
delegate.commit(required);
tcm.commit();
}
接在SimpleExecutor的父類BaseExecutor中完成
@Override
public void commit(boolean required) throws SQLException {
if (closed) {
throw new ExecutorException("Cannot commit, transaction is already closed");
}
clearLocalCache();
flushStatements();
if (required) {
transaction.commit();
}
}
提交事務的操作在 tcm.commit();中完成
本文到這里也就行將結束了,如果您覺得挺好玩的,歡迎點贊支持,有錯誤的話,也歡迎批評指出