MyBatis 的執(zhí)行流程，寫得太好了！

點(diǎn)擊上方藍(lán)色字體，選擇“設(shè)為星標(biāo)”

來(lái)源 | blog.csdn.net/zwx900102/article/details/108455514

MyBatis可能很多人都一直在用，但是MyBatis的SQL執(zhí)行流程可能并不是所有人都清楚了，那么既然進(jìn)來(lái)了，通讀本文你將收獲如下：

1、Mapper接口和映射文件是如何進(jìn)行綁定的 

2、MyBatis中SQL語(yǔ)句的執(zhí)行流程 

3、自定義MyBatis中的參數(shù)設(shè)置處理器typeHandler 

4、自定義MyBatis中結(jié)果集處理器typeHandler 

PS：本文基于MyBatis3.5.5版本源碼

概要

在MyBatis中，利用編程式進(jìn)行數(shù)據(jù)查詢，主要就是下面幾行代碼：

SqlSession session = sqlSessionFactory.openSession();
UserMapper userMapper = session.getMapper(UserMapper.class);
List<LwUser> userList = userMapper.listUserByUserName("孤狼1號(hào)");

第一行是獲取一個(gè)SqlSession對(duì)象在上一篇文章分析過(guò)了，想要詳細(xì)了解的可以點(diǎn)擊這里，第二行就是獲取UserMapper接口，第三行一行代碼就實(shí)現(xiàn)了整個(gè)查詢語(yǔ)句的流程，接下來(lái)我們就來(lái)仔細(xì)分析一下第二和第三步。

獲取Mapper接口(getMapper)

第二步是通過(guò)SqlSession對(duì)象是獲取一個(gè)Mapper接口，這個(gè)流程還是相對(duì)簡(jiǎn)單的，下面就是我們調(diào)用session.getMapper方法之后的運(yùn)行時(shí)序圖：

1、在調(diào)用getMapper之后，會(huì)去Configuration對(duì)象中獲取Mapper對(duì)象，因?yàn)樵陧?xiàng)目啟動(dòng)的時(shí)候就會(huì)把Mapper接口加載并解析存儲(chǔ)到Configuration對(duì)象

2、通過(guò)Configuration對(duì)象中的MapperRegistry對(duì)象屬性，繼續(xù)調(diào)用getMapper方法

3、根據(jù)type類型，從MapperRegistry對(duì)象中的knownMappers獲取到當(dāng)前類型對(duì)應(yīng)的代理工廠類，然后通過(guò)代理工廠類生成對(duì)應(yīng)Mapper的代理類

4、最終獲取到我們接口對(duì)應(yīng)的代理類MapperProxy對(duì)象

而MapperProxy可以看到實(shí)現(xiàn)了InvocationHandler，使用的就是JDK動(dòng)態(tài)代理。

至此獲取Mapper流程結(jié)束了，那么就有一個(gè)問(wèn)題了MapperRegistry對(duì)象內(nèi)的HashMap屬性knownMappers中的數(shù)據(jù)是什么時(shí)候存進(jìn)去的呢？

Mapper接口和映射文件是何時(shí)關(guān)聯(lián)的

Mapper接口及其映射文件是在加載mybatis-config配置文件的時(shí)候存儲(chǔ)進(jìn)去的，下面就是時(shí)序圖：

1、首先我們會(huì)手動(dòng)調(diào)用SqlSessionFactoryBuilder方法中的build()方法：

2、然后會(huì)構(gòu)造一個(gè)XMLConfigBuilder對(duì)象，并調(diào)用其parse方法：

3、然后會(huì)繼續(xù)調(diào)用自己的parseConfiguration來(lái)解析配置文件，這里面就會(huì)分別去解析全局配置文件的頂級(jí)節(jié)點(diǎn)，其他的我們先不看，我們直接看最后解析mappers節(jié)點(diǎn)

4、繼續(xù)調(diào)用自己的mapperElement來(lái)解析mappers文件（這個(gè)方法比較長(zhǎng)，為了方便截圖完整，所以把字體縮小了1號(hào)），可以看到，這里面分了四種方式來(lái)解析mappers節(jié)點(diǎn)的配置，對(duì)應(yīng)了4種mapper配置方式，而其中紅框內(nèi)的兩種方式是直接配置的xml映射文件，藍(lán)框內(nèi)的兩種方式是解析直接配置Mapper接口的方式，從這里也可以說(shuō)明，不論配置哪種方式，最終MyBatis都會(huì)將xml映射文件和Mapper接口進(jìn)行關(guān)聯(lián)。

5、我們先看第2種和第3中（直接配置xml映射文件的解析方式），會(huì)構(gòu)建一個(gè)XMLMapperBuilder對(duì)象并調(diào)用其parse方法。

但是這里有一個(gè)問(wèn)題，如果有多重繼承或者多重依賴時(shí)在這里是可能會(huì)無(wú)法被完全解析的，比如說(shuō)三個(gè)映射文件互相依賴，那么if里面(假設(shè)是最壞情況)只能加載1個(gè)，失敗2個(gè)，然后走到下面if之外的代碼又只能加載1個(gè)，還有1個(gè)會(huì)失敗(如下代碼中，只會(huì)處理1次，再次失敗并不會(huì)繼續(xù)加入incompleteResultMaps)：

當(dāng)然，這個(gè)還是會(huì)被解析的，后面執(zhí)行查詢的時(shí)候會(huì)再次通過(guò)不斷遍歷去全部解析完畢，不過(guò)有一點(diǎn)需要注意的是，互相引用這種是會(huì)導(dǎo)致解析失敗報(bào)錯(cuò)的，所以在開發(fā)過(guò)程中我們應(yīng)該避免循環(huán)依賴的產(chǎn)生。

6、解析完映射文件之后，調(diào)用自身方法bindMapperForNamespace，開始綁定Mapper接口和映射文件：

7、調(diào)用Configuration對(duì)象的addMapper

8、調(diào)用Configuration對(duì)象的屬性MapperRegistry內(nèi)的addMapper方法，這個(gè)方法就是正式將Mapper接口添加到knownMappers，所以上面getMapper可以直接獲取：

到這里我們就完成了Mapper接口和xml映射文件的綁定 9、注意上面紅框里面的代碼，又調(diào)用了一次parse方法，這個(gè)parse方法主要是解析注解，比如下面的語(yǔ)句：

@Select("select * from lw_user")
List<LwUser> listAllUser();

所以這個(gè)方法里面會(huì)去解析@Select等注解，需要注意的是，parse方法里面會(huì)同時(shí)再解析一次xml映射文件，因?yàn)樯厦嫖覀兲岬搅薽appers節(jié)點(diǎn)有4種配置方式，其中兩種配置的是Mapper接口，而配置Mapper接口會(huì)直接先調(diào)用addMapper接口，并沒(méi)有解析映射文件，所以進(jìn)入注解解析方法parse之中會(huì)需要再嘗試解析一次XML映射文件。

解析完成之后，還會(huì)對(duì)Mapper接口中的方法進(jìn)行解析，并將每個(gè)方法的全限定類名作為key存入存入Configuration中的mappedStatements屬性。

需要指出的是，這里存儲(chǔ)的時(shí)候，同一個(gè)value會(huì)存儲(chǔ)2次，一個(gè)全限定名作為key，另一個(gè)就是只用方法名(sql語(yǔ)句的id)來(lái)作為key：

所以最終mappedStatements會(huì)是下面的情況：

事實(shí)上如果我們通過(guò)接口的方式來(lái)編程的話，最后來(lái)getStatement的時(shí)候，都是根據(jù)全限定名來(lái)取的，所以即使有重名對(duì)我們也沒(méi)有影響，而之所以要這么做的原因其實(shí)還是為了兼容早期版本的用法，那就是不通過(guò)接口，而是直接通過(guò)方法名的方式來(lái)進(jìn)行查詢：

session.selectList("com.lonelyWolf.mybatis.mapper.UserMapper.listAllUser");

這里如果shortName沒(méi)有重復(fù)的話，是可以直接通過(guò)簡(jiǎn)寫來(lái)查詢的：

session.selectList("listAllUser");

但是通過(guò)簡(jiǎn)寫來(lái)查詢一旦shortName重復(fù)了就會(huì)拋出以下異常：

這里的異常其實(shí)就是StrickMap的get方法拋出來(lái)的：

sql執(zhí)行流程分析

上面我們講到了，獲取到的Mapper接口實(shí)際上被包裝成為了代理對(duì)象，所以我們執(zhí)行查詢語(yǔ)句肯定是執(zhí)行的代理對(duì)象方法，接下來(lái)我們就以Mapper接口的代理對(duì)象MapperProxy來(lái)分析一下查詢流程。

整個(gè)sql執(zhí)行流程可以分為兩大步驟：

一、尋找sql 

二、執(zhí)行sql語(yǔ)句

尋找sql

首先還是來(lái)看一下尋找sql語(yǔ)句的時(shí)序圖：

1、了解代理模式的應(yīng)該都知道，調(diào)用被代理對(duì)象的方法之后實(shí)際上執(zhí)行的就是代理對(duì)象的invoke方法

2、因?yàn)槲覀冞@里并沒(méi)有調(diào)用Object類中的方法，所以肯定走的else。else中會(huì)繼續(xù)調(diào)用MapperProxy內(nèi)部類MapperMethodInvoker中的方法cachedInvoker，這里面會(huì)有一個(gè)判斷，判斷一下我們是不是default方法，因?yàn)镴dk1.8中接口中可以新增default方法，而default方法是并不是一個(gè)抽象方法，所以也需要特殊處理（剛開始會(huì)從緩存里面取，緩存相關(guān)知識(shí)我們這里先不講，后面會(huì)單獨(dú)寫一篇來(lái)分析一下緩存)）。

3、接下來(lái)，是構(gòu)造一個(gè)MapperMethod對(duì)象,這個(gè)對(duì)象封裝了Mapper接口中對(duì)應(yīng)的方法信息以及對(duì)應(yīng)的sql語(yǔ)句信息：

這里面就會(huì)把要執(zhí)行的sql語(yǔ)句，請(qǐng)求參數(shù)，方法返回值全部解析封裝成MapperMethod對(duì)象，然后后面就可以開始準(zhǔn)備執(zhí)行sql語(yǔ)句了

執(zhí)行sql語(yǔ)句

還是先來(lái)看一下執(zhí)行Sql語(yǔ)句的時(shí)序圖：

1、我們繼續(xù)上面的流程進(jìn)入execute方法：

2、這里面會(huì)根據(jù)語(yǔ)句類型以及返回值類型來(lái)決定如何執(zhí)行，本人這里返回的是一個(gè)集合，故而我們進(jìn)入executeForMany方法：

3、這里面首先會(huì)將前面存好的參數(shù)進(jìn)行一次轉(zhuǎn)換，然后繞了這么一圈，回到了起點(diǎn)SqlSession對(duì)象，繼續(xù)調(diào)用selectList方法：

3、接下來(lái)又講流程委派給了Execute去執(zhí)行query方法，最終又會(huì)去調(diào)用queryFromDatabase方法：

4、到這里之后，終于要進(jìn)入正題了，一般帶了這種do開頭的方法就是真正做事的，Spring中很多地方也是采用的這種命名方式：

注意，前面我們的sql語(yǔ)句還是占位符的方式，并沒(méi)有將參數(shù)設(shè)置進(jìn)去，所以這里在return上面一行調(diào)用prepareStatement方法創(chuàng)建Statement對(duì)象的時(shí)候會(huì)去設(shè)置參數(shù)，替換占位符。參數(shù)如何設(shè)置我們先跳過(guò)，等把流程執(zhí)行完了我們?cè)趩为?dú)分析參數(shù)映射和結(jié)果集映射。

5、繼續(xù)進(jìn)入PreparedStatementHandler對(duì)象的query方法，可以看到，這一步就是調(diào)用了jdbc操作對(duì)象PreparedStatement中的execute方法，最后一步就是轉(zhuǎn)換結(jié)果集然后返回。

到這里，整個(gè)SQL語(yǔ)句執(zhí)行流程分析就結(jié)束了，中途有一些參數(shù)的存儲(chǔ)以及轉(zhuǎn)換并沒(méi)有深入進(jìn)去，因?yàn)閰?shù)的轉(zhuǎn)換并不是核心，只要清楚整個(gè)數(shù)據(jù)的流轉(zhuǎn)流程，我們自己也可以有自己的實(shí)現(xiàn)方式，只要存起來(lái)最后我們能重新解析讀出來(lái)就行。

參數(shù)映射

現(xiàn)在我們來(lái)看一下上面在執(zhí)行查詢之前參數(shù)是如何進(jìn)行設(shè)置的，我們先進(jìn)入prepareStatement方法：

我們發(fā)現(xiàn)，最終是調(diào)用了StatementHandler中的parameterize進(jìn)行參數(shù)設(shè)置，接下來(lái)這里為了節(jié)省篇幅，我們不會(huì)一步步點(diǎn)進(jìn)去，直接進(jìn)入設(shè)置參數(shù)的方法：

上面的BaseTypeHandler是一個(gè)抽象類，setNonNullParameter并沒(méi)有實(shí)現(xiàn)，都是交給子類去實(shí)現(xiàn)，而每一個(gè)子類就是對(duì)應(yīng)了數(shù)據(jù)庫(kù)的一種類型。下圖中就是默認(rèn)的一個(gè)子類StringTypeHandler，里面沒(méi)什么其他邏輯，就是設(shè)置參數(shù)。

可以看到String里面調(diào)用了jdbc中的setString方法，而如果是int也會(huì)調(diào)用setInt方法。看到這些子類如果大家之前閱讀過(guò)我前面講的MyBatis參數(shù)配置，應(yīng)該就很明顯可以知道，這些子類就是系統(tǒng)默認(rèn)提供的一些typeHandler。而這些默認(rèn)的typeHandler會(huì)默認(rèn)被注冊(cè)并和Java對(duì)象進(jìn)行綁定：

正是因?yàn)镸yBatis中默認(rèn)提供了常用數(shù)據(jù)類型的映射，所以我們寫Sql的時(shí)候才可以省略參數(shù)映射關(guān)系，可以直接采用下面的方式，系統(tǒng)可以根據(jù)我們參數(shù)的類型，自動(dòng)選擇合適的typeHander進(jìn)行映射：

select user_id,user_name from lw_user where user_name=#{userName}

上面這條語(yǔ)句實(shí)際上和下面這條是等價(jià)的：

select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR}

或者說(shuō)我們可以直接指定typeHandler：

select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=org.apache.ibatis.type.IntegerTypeHandler}

這里因?yàn)槲覀兣渲昧藅ypeHandler，所以會(huì)優(yōu)先以配置的typeHandler為主不會(huì)再去讀取默認(rèn)的映射，如果類型不匹配就會(huì)直接報(bào)錯(cuò)了：

看到這里很多人應(yīng)該就知道了，如果我們自己自定義一個(gè)typeHandler，然后就可以配置成我們自己的自定義類。所以接下來(lái)就讓我們看看如何自定義一個(gè)typeHandler

自定義typeHandler 自定義typeHandler需要實(shí)現(xiàn)BaseTypeHandler接口，BaseTypeHandler有4個(gè)方法，包括結(jié)果集映射，為了節(jié)省篇幅，代碼沒(méi)有寫上來(lái)：

public class MyTypeHandler extends BaseTypeHandler<String> {
    @Override
    public void setNonNullParameter(PreparedStatement preparedStatement, int index, String param, JdbcType jdbcType) throws SQLException {
    System.out.println("自定義typeHandler生效了");
    preparedStatement.setString(index,param);
    }

然后我們改寫一下上面的查詢語(yǔ)句：

select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=com.lonelyWolf.mybatis.typeHandler.MyTypeHandler}

然后執(zhí)行，可以看到，自定義的typeHandler生效了：

結(jié)果集映射

接下來(lái)讓我們看看結(jié)果集的映射，回到上面執(zhí)行sql流程的最后一個(gè)方法：

resultSetHandler.handleResultSets(ps)

結(jié)果集映射里面的邏輯相對(duì)來(lái)說(shuō)還是挺復(fù)雜的，因?yàn)橐紤]到非常多的情況，這里我們就不會(huì)去深究每一個(gè)細(xì)節(jié)，直接進(jìn)入到正式解析結(jié)果集的代碼，下面的5個(gè)代碼片段就是一個(gè)簡(jiǎn)單的但是完整的解析流程：

從上面的代碼片段我們也可以看到，實(shí)際上解析結(jié)果集還是很復(fù)雜的，就如我們上一篇介紹的復(fù)雜查詢一樣，一個(gè)查詢可以不斷嵌套其他查詢，還有延遲加載等等一些復(fù)雜的特性的處理，所以邏輯分支是有很多，但是不管怎么處理，最后的核心還是上面的一套流程，最終還是會(huì)調(diào)用typeHandler來(lái)獲取查詢到的結(jié)果。

是的，你沒(méi)猜錯(cuò)，這個(gè)就是上面我們映射參數(shù)的typeHandler，因?yàn)閠ypeHandler里面不只是一個(gè)設(shè)置參數(shù)方法，還有獲取結(jié)果集方法(上面設(shè)置參數(shù)的時(shí)候省略了)。

自定義typeHandler結(jié)果集

所以說(shuō)我們還是用上面那個(gè)MyTypeHandler 例子來(lái)重寫一下取值方法(省略了設(shè)置參數(shù)方法)：

public class MyTypeHandler extends BaseTypeHandler<String> {
    /**
 * 設(shè)置參數(shù)
 */
@Override
public void setNonNullParameter(PreparedStatement preparedStatement, int index, String param, JdbcType jdbcType) throws SQLException {
    System.out.println("設(shè)置參數(shù)->自定義typeHandler生效了");
    preparedStatement.setString(index,param);
}
/**
 * 根據(jù)列名獲取結(jié)果
 */
@Override
public String getNullableResult(ResultSet resultSet, String columnName) throws SQLException {
    System.out.println("根據(jù)columnName獲取結(jié)果->自定義typeHandler生效了");
    return resultSet.getString(columnName);
}

/**
 * 根據(jù)列的下標(biāo)來(lái)獲取結(jié)果
 */
@Override
public String getNullableResult(ResultSet resultSet, int columnIndex) throws SQLException {
    System.out.println("根據(jù)columnIndex獲取結(jié)果->自定義typeHandler生效了");
    return resultSet.getString(columnIndex);
}

/**
 * 處理存儲(chǔ)過(guò)程的結(jié)果集
 */
@Override
public String getNullableResult(CallableStatement callableStatement, int columnIndex) throws SQLException {
    return callableStatement.getString(columnIndex);
}

改寫Mapper映射文件配置：

<resultMap id="MyUserResultMap" type="lwUser">
    <result column="user_id" property="userId" jdbcType="VARCHAR" typeHandler="com.lonelyWolf.mybatis.typeHandler.MyTypeHandler" />
    <result column="user_name" property="userName" jdbcType="VARCHAR" />
</resultMap>

執(zhí)行之后輸出如下：

因?yàn)槲覀儗傩陨厦嬷慌渲昧艘粋€(gè)屬性，所以只輸出了一次。

工作流程圖

上面介紹了代碼的流轉(zhuǎn)，可能繞來(lái)繞去有點(diǎn)暈，所以我們來(lái)畫一個(gè)主要的對(duì)象之間流程圖來(lái)更加清晰的展示一下MyBatis主要工作流程：

從上面的工作流程圖上我們可以看到，SqlSession下面還有4大對(duì)象，這4大對(duì)象也很重要，后面學(xué)習(xí)攔截器的時(shí)候就是針對(duì)這4大對(duì)象進(jìn)行的攔截，關(guān)于這4大對(duì)象的具體詳情，我們下一篇文章再展開分析。

總結(jié)

本文主要分析了MyBatis的SQL執(zhí)行流程。在分析流程的過(guò)程中，我們也舉例論證了如何自定義typeHandler來(lái)實(shí)現(xiàn)自定義的參數(shù)映射和結(jié)果集映射，不過(guò)MyBatis中提供的默認(rèn)映射其實(shí)可以滿足大部分的需求，如果我們對(duì)某些屬性需要特殊處理，那么就可以采用自定義的typeHandle來(lái)實(shí)現(xiàn)，相信如果本文如果讀懂了，以下幾點(diǎn)大家應(yīng)該至少會(huì)有一個(gè)清晰的認(rèn)識(shí)：

1、Mapper接口和映射文件是如何進(jìn)行綁定的 

2、MyBatis中SQL語(yǔ)句的執(zhí)行流程 

????????????????3、自定義MyBatis中的參數(shù)設(shè)置處理器typeHandler 

4、自定義MyBatis中結(jié)果集處理器typeHandler

當(dāng)然，其中很多細(xì)節(jié)并沒(méi)有提到，而看源碼我們也并不需要追求每一行代碼都能看懂，就比如我們一個(gè)稍微復(fù)雜一點(diǎn)的業(yè)務(wù)系統(tǒng)，即使我們是項(xiàng)目開發(fā)者如果某一個(gè)模塊不是本人負(fù)責(zé)的，恐怕也很難搞清楚每一行代碼的含義。所以對(duì)于MyBatis及其他框架的源碼中也是一樣，首先應(yīng)該從大局入手，掌握整體流程和設(shè)計(jì)思想，然后如果對(duì)某些實(shí)現(xiàn)細(xì)節(jié)感興趣，再深入進(jìn)行了解。

后臺(tái)回復(fù) 學(xué)習(xí)資料 領(lǐng)取學(xué)習(xí)視頻

如有收獲，點(diǎn)個(gè)在看，誠(chéng)摯感謝