面試官：MyBatis 的執行流程說這麼好，從網上抄的吧！

作者：雙子孤狼

blog.csdn.net/zwx900102/article/details/108455514

MyBatis 可能很多人都一直在用，但是 MyBatis 的 SQL 執行流程可能並不是所有人都清楚了，那麼既然進來了，通讀本文你將收穫如下：

1、Mapper 接口和映射文件是如何進行綁定的

2、MyBatis 中 SQL 語句的執行流程

3、自定義 MyBatis 中的參數設置處理器 typeHandler

4、自定義 MyBatis 中結果集處理器 typeHandler

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

概要

在 MyBatis 中，利用編程式進行數據查詢，主要就是下面幾行代碼：

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

第一行是獲取一個 SqlSession 對象在上一篇文章分析過了，想要詳細瞭解的可以點擊這裏，第二行就是獲取 UserMapper 接口，第三行一行代碼就實現了整個查詢語句的流程，接下來我們就來仔細分析一下第二和第三步。

獲取 Mapper 接口 (getMapper)

第二步是通過 SqlSession 對象是獲取一個 Mapper 接口，這個流程還是相對簡單的，下面就是我們調用 session.getMapper 方法之後的運行時序圖：

1、在調用 getMapper 之後，會去 Configuration 對象中獲取 Mapper 對象，因爲在項目啓動的時候就會把 Mapper 接口加載並解析存儲到 Configuration 對象

2、通過 Configuration 對象中的 MapperRegistry 對象屬性，繼續調用 getMapper 方法

3、根據 type 類型，從 MapperRegistry 對象中的 knownMappers 獲取到當前類型對應的代理工廠類，然後通過代理工廠類生成對應 Mapper 的代理類

4、最終獲取到我們接口對應的代理類 MapperProxy 對象

而 MapperProxy 可以看到實現了 InvocationHandler，使用的就是 JDK 動態代理。

至此獲取 Mapper 流程結束了，那麼就有一個問題了 MapperRegistry 對象內的 HashMap 屬性 knownMappers 中的數據是什麼時候存進去的呢？

Mapper 接口和映射文件是何時關聯的

Mapper 接口及其映射文件是在加載 mybatis-config 配置文件的時候存儲進去的，下面就是時序圖：

1、首先我們會手動調用 SqlSessionFactoryBuilder 方法中的 build() 方法：

2、然後會構造一個 XMLConfigBuilder 對象，並調用其 parse 方法：

3、然後會繼續調用自己的 parseConfiguration 來解析配置文件，這裏面就會分別去解析全局配置文件的頂級節點，其他的我們先不看，我們直接看最後解析 mappers 節點

4、繼續調用自己的 mapperElement 來解析 mappers 文件（這個方法比較長，爲了方便截圖完整，所以把字體縮小了 1 號），可以看到，這裏面分了四種方式來解析 mappers 節點的配置，對應了 4 種 mapper 配置方式，而其中紅框內的兩種方式是直接配置的 xml 映射文件，藍框內的兩種方式是解析直接配置 Mapper 接口的方式，從這裏也可以說明，不論配置哪種方式，最終 MyBatis 都會將 xml 映射文件和 Mapper 接口進行關聯。

5、我們先看第 2 種和第 3 中（直接配置 xml 映射文件的解析方式），會構建一個 XMLMapperBuilder 對象並調用其 parse 方法。

但是這裏有一個問題，如果有多重繼承或者多重依賴時在這裏是可能會無法被完全解析的，比如說三個映射文件互相依賴，那麼 if 裏面 (假設是最壞情況) 只能加載 1 個，失敗 2 個，然後走到下面 if 之外的代碼又只能加載 1 個，還有 1 個會失敗(如下代碼中，只會處理 1 次，再次失敗並不會繼續加入 incompleteResultMaps)：

當然，這個還是會被解析的，後面執行查詢的時候會再次通過不斷遍歷去全部解析完畢，不過有一點需要注意的是，互相引用這種是會導致解析失敗報錯的，所以在開發過程中我們應該避免循環依賴的產生。

6、解析完映射文件之後，調用自身方法 bindMapperForNamespace，開始綁定 Mapper 接口和映射文件：

7、調用 Configuration 對象的 addMapper

8、調用 Configuration 對象的屬性 MapperRegistry 內的 addMapper 方法，這個方法就是正式將 Mapper 接口添加到 knownMappers，所以上面 getMapper 可以直接獲取：

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

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

所以這個方法裏面會去解析 @Select 等註解，需要注意的是，parse 方法裏面會同時再解析一次 xml 映射文件，因爲上面我們提到了 mappers 節點有 4 種配置方式，其中兩種配置的是 Mapper 接口，而配置 Mapper 接口會直接先調用 addMapper 接口，並沒有解析映射文件，所以進入註解解析方法 parse 之中會需要再嘗試解析一次 XML 映射文件。

解析完成之後，還會對 Mapper 接口中的方法進行解析，並將每個方法的全限定類名作爲 key 存入存入 Configuration 中的 mappedStatements 屬性。

需要指出的是，這裏存儲的時候，同一個 value 會存儲 2 次，一個全限定名作爲 key，另一個就是隻用方法名 (sql 語句的 id) 來作爲 key：

所以最終 mappedStatements 會是下面的情況：

事實上如果我們通過接口的方式來編程的話，最後來 getStatement 的時候，都是根據全限定名來取的，所以即使有重名對我們也沒有影響，而之所以要這麼做的原因其實還是爲了兼容早期版本的用法，那就是不通過接口，而是直接通過方法名的方式來進行查詢：

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

這裏如果 shortName 沒有重複的話，是可以直接通過簡寫來查詢的：

session.selectList("listAllUser");

但是通過簡寫來查詢一旦 shortName 重複了就會拋出以下異常：

這裏的異常其實就是 StrickMap 的 get 方法拋出來的：

sql 執行流程分析

上面我們講到了，獲取到的 Mapper 接口實際上被包裝成爲了代理對象，所以我們執行查詢語句肯定是執行的代理對象方法，接下來我們就以 Mapper 接口的代理對象 MapperProxy 來分析一下查詢流程。

整個 sql 執行流程可以分爲兩大步驟：

一、尋找 sql

二、執行 sql 語句

尋找 sql

首先還是來看一下尋找 sql 語句的時序圖：

1、瞭解代理模式的應該都知道，調用被代理對象的方法之後實際上執行的就是代理對象的 invoke 方法

2、因爲我們這裏並沒有調用 Object 類中的方法，所以肯定走的 else。else 中會繼續調用 MapperProxy 內部類 MapperMethodInvoker 中的方法 cachedInvoker，這裏面會有一個判斷，判斷一下我們是不是 default 方法，因爲 Jdk1.8 中接口中可以新增 default 方法，而 default 方法是並不是一個抽象方法，所以也需要特殊處理（剛開始會從緩存裏面取，緩存相關知識我們這裏先不講，後面會單獨寫一篇來分析一下緩存)）。

3、接下來，是構造一個 MapperMethod 對象, 這個對象封裝了 Mapper 接口中對應的方法信息以及對應的 sql 語句信息：

這裏面就會把要執行的 sql 語句，請求參數，方法返回值全部解析封裝成 MapperMethod 對象，然後後面就可以開始準備執行 sql 語句了

執行 sql 語句

還是先來看一下執行 Sql 語句的時序圖：

1、我們繼續上面的流程進入 execute 方法：

2、這裏面會根據語句類型以及返回值類型來決定如何執行，本人這裏返回的是一個集合，故而我們進入 executeForMany 方法：

3、這裏面首先會將前面存好的參數進行一次轉換，然後繞了這麼一圈，回到了起點 SqlSession 對象，繼續調用 selectList 方法：

3、接下來又講流程委派給了 Execute 去執行 query 方法，最終又會去調用 queryFromDatabase 方法：

4、到這裏之後，終於要進入正題了，一般帶了這種 do 開頭的方法就是真正做事的，Spring 中很多地方也是採用的這種命名方式：

注意，前面我們的 sql 語句還是佔位符的方式，並沒有將參數設置進去，所以這裏在 return 上面一行調用 prepareStatement 方法創建 Statement 對象的時候會去設置參數，替換佔位符。參數如何設置我們先跳過，等把流程執行完了我們在單獨分析參數映射和結果集映射。

5、繼續進入 PreparedStatementHandler 對象的 query 方法，可以看到，這一步就是調用了 jdbc 操作對象 PreparedStatement 中的 execute 方法，最後一步就是轉換結果集然後返回。

到這裏，整個 SQL 語句執行流程分析就結束了，中途有一些參數的存儲以及轉換並沒有深入進去，因爲參數的轉換並不是核心，只要清楚整個數據的流轉流程，我們自己也可以有自己的實現方式，只要存起來最後我們能重新解析讀出來就行。

參數映射

現在我們來看一下上面在執行查詢之前參數是如何進行設置的，我們先進入 prepareStatement 方法：

我們發現，最終是調用了 StatementHandler 中的 parameterize 進行參數設置，接下來這裏爲了節省篇幅，我們不會一步步點進去，直接進入設置參數的方法：

上面的 BaseTypeHandler 是一個抽象類，setNonNullParameter 並沒有實現，都是交給子類去實現，而每一個子類就是對應了數據庫的一種類型。下圖中就是默認的一個子類 StringTypeHandler，裏面沒什麼其他邏輯，就是設置參數。

可以看到 String 裏面調用了 jdbc 中的 setString 方法，而如果是 int 也會調用 setInt 方法。看到這些子類如果大家之前閱讀過我前面講的 MyBatis 參數配置，應該就很明顯可以知道，這些子類就是系統默認提供的一些 typeHandler。而這些默認的 typeHandler 會默認被註冊並和 Java 對象進行綁定：

正是因爲 MyBatis 中默認提供了常用數據類型的映射，所以我們寫 Sql 的時候纔可以省略參數映射關係，可以直接採用下面的方式，系統可以根據我們參數的類型，自動選擇合適的 typeHander 進行映射：

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

上面這條語句實際上和下面這條是等價的：

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

或者說我們可以直接指定 typeHandler：

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

這裏因爲我們配置了 typeHandler，所以會優先以配置的 typeHandler 爲主不會再去讀取默認的映射，如果類型不匹配就會直接報錯了：

看到這裏很多人應該就知道了，如果我們自己自定義一個 typeHandler，然後就可以配置成我們自己的自定義類。所以接下來就讓我們看看如何自定義一個 typeHandler

自定義 typeHandler 自定義 typeHandler 需要實現 BaseTypeHandler 接口，BaseTypeHandler 有 4 個方法，包括結果集映射，爲了節省篇幅，代碼沒有寫上來：

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);
    }

然後我們改寫一下上面的查詢語句：

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

然後執行，可以看到，自定義的 typeHandler 生效了：

結果集映射

接下來讓我們看看結果集的映射，回到上面執行 sql 流程的最後一個方法：

resultSetHandler.handleResultSets(ps)

結果集映射裏面的邏輯相對來說還是挺複雜的，因爲要考慮到非常多的情況，這裏我們就不會去深究每一個細節，直接進入到正式解析結果集的代碼，下面的 5 個代碼片段就是一個簡單的但是完整的解析流程：

從上面的代碼片段我們也可以看到，實際上解析結果集還是很複雜的，就如我們上一篇介紹的複雜查詢一樣，一個查詢可以不斷嵌套其他查詢，還有延遲加載等等一些複雜的特性的處理，所以邏輯分支是有很多，但是不管怎麼處理，最後的核心還是上面的一套流程，最終還是會調用 typeHandler 來獲取查詢到的結果。

是的，你沒猜錯，這個就是上面我們映射參數的 typeHandler，因爲 typeHandler 裏面不只是一個設置參數方法，還有獲取結果集方法 (上面設置參數的時候省略了)。

自定義 typeHandler 結果集

所以說我們還是用上面那個 MyTypeHandler 例子來重寫一下取值方法 (省略了設置參數方法)：

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);
}
/**
 * 根據列名獲取結果
 */
@Override
public String getNullableResult(ResultSet resultSet, String columnName) throws SQLException {
    System.out.println("根據columnName獲取結果->自定義typeHandler生效了");
    return resultSet.getString(columnName);
}

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

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

改寫 Mapper 映射文件配置：

<resultMap 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>

執行之後輸出如下：

因爲我們屬性上面只配置了一個屬性，所以只輸出了一次。

工作流程圖

上面介紹了代碼的流轉，可能繞來繞去有點暈，所以我們來畫一個主要的對象之間流程圖來更加清晰的展示一下 MyBatis 主要工作流程：

從上面的工作流程圖上我們可以看到，SqlSession 下面還有 4 大對象，這 4 大對象也很重要，後面學習攔截器的時候就是針對這 4 大對象進行的攔截，關於這 4 大對象的具體詳情，我們下一篇文章再展開分析。

總結

本文主要分析了 MyBatis 的 SQL 執行流程。在分析流程的過程中，我們也舉例論證瞭如何自定義 typeHandler 來實現自定義的參數映射和結果集映射，不過 MyBatis 中提供的默認映射其實可以滿足大部分的需求，如果我們對某些屬性需要特殊處理，那麼就可以採用自定義的 typeHandle 來實現，相信如果本文如果讀懂了，以下幾點大家應該至少會有一個清晰的認識：