大廠面試題：請講下MyBatis 的執行流程！網友：講的太好了！

前言

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

• 1、Mapper介面和映射檔案是如何進行系結的
• 2、MyBatis中SQL陳述句的執行流程
• 3、自定義MyBatis中的引數設定處理器typeHandler
• 4、自定義MyBatis中結果集處理器typeHandler

PS：本文基于MyBatis3.5.5版本原始碼 關于MyBatis的知識點總結了個思維導圖分享給大家    

概要

在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個方法，包括結果集映射，為了節省篇幅，代碼沒有寫上來：

package com.lonelyWolf.mybatis.typeHandler;

import org.apache.ibatis.type.BaseTypeHandler;
import org.apache.ibatis.type.JdbcType;

import java.sql.CallableStatement;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

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 例子來重寫一下取值方法(省略了設定引數方法)：

package com.lonelyWolf.mybatis.typeHandler;

import org.apache.ibatis.type.BaseTypeHandler;
import org.apache.ibatis.type.JdbcType;

import java.sql.CallableStatement;
import java.sql.PreparedStatement;
import java.sql.ResultSet;
import java.sql.SQLException;

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

<select id="listUserByUserName" parameterType="String" resultMap="MyUserResultMap">
        select user_id,user_name from lw_user where user_name=#{userName,jdbcType=VARCHAR,typeHandler=com.lonelyWolf.mybatis.typeHandler.MyTypeHandler}
    </select>

執行之后輸出如下：     因為我們屬性上面只配置了一個屬性，所以只輸出了一次，

作業流程圖

上面介紹了代碼的流轉，可能繞來繞去有點暈，所以我們來畫一個主要的物件之間流程圖來更加清晰的展示一下MyBatis主要作業流程：     從上面的作業流程圖上我們可以看到，SqlSession下面還有4大物件，這4大物件也很重要，后面學習攔截器的時候就是針對這4大物件進行的攔截，關于這4大物件的具體詳情，我們下一篇文章再展開分析，

總結

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

• 1、Mapper介面和映射檔案是如何進行系結的
• 2、MyBatis中SQL陳述句的執行流程
• 3、自定義MyBatis中的引數設定處理器typeHandler
• 4、自定義MyBatis中結果集處理器typeHandler

當然，其中很多細節并沒有提到，而看原始碼我們也并不需要追求每一行代碼都能看懂，就比如我們一個稍微復雜一點的業務系統，即使我們是專案開發者如果某一個模塊不是本人負責的，恐怕也很難搞清楚每一行代碼的含義，所以對于MyBatis及其他框架的原始碼中也是一樣，首先應該從大局入手，掌握整體流程和設計思想，然后如果對某些實作細節感興趣，再深入進行了解，

最后，小編總結了2020面試題，這份面試題的包含的模塊分為19個模塊，分別是： Java 基礎、容器、多執行緒、反射、物件拷貝、Java Web 、例外、網路、設計模式、Spring/Spring MVC、Spring Boot/Spring Cloud、Hibernate、MyBatis、RabbitMQ、Kafka、Zookeeper、MySQL、Redis、JVM ，

關注我的公眾號：程式員白楠楠，獲取上述資料，

轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/238881.html

標籤：Java

上一篇：阿里的御用框架，MyBatis與設計模式的激情碰撞

下一篇：Java 持久層框架之 MyBatis