"最近太忙了，一直没时间继续更新博客，今天忙里偷闲继续我的 Mybatis 学习之旅。在前九篇中，介绍了 mybatis 的配置以及使用，那么本篇将走进 mybatis 的源码，分析 mybatis 的执行流程，好啦，鄙人不喜欢口水话，还是直接上干活吧： 1. SqlSessionFactory ...."

someone1
AI专业者开发社区 1 号成员
AI开发者社区 • 0 回帖 • 2 浏览 • 5 个月前

深入浅出Mybatis系列（十）---SQL执行流程分析（源码篇）

最近太忙了，一直没时间继续更新博客，今天忙里偷闲继续我的 Mybatis 学习之旅。在前九篇中，介绍了 mybatis 的配置以及使用，那么本篇将走进 mybatis 的源码，分析 mybatis 的执行流程，好啦，鄙人不喜欢口水话，还是直接上干活吧：

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:

 /**
   * 看着代码不少，不过其实就是先判断 CRUD 类型，然后根据类型去选择到底执行 sqlSession 中的哪个方法，绕了一圈，又转回 sqlSession 了
   * @param sqlSession
   * @param args
   * @return
   */
  public Object execute(SqlSession sqlSession, Object[] args) {
    Object result;
    if (SqlCommandType.INSERT == command.getType()) {
      Object param = method.convertArgsToSqlCommandParam(args);
      result = rowCountResult(sqlSession.insert(command.getName(), param));} else if (SqlCommandType.UPDATE == command.getType()) {
      Object param = method.convertArgsToSqlCommandParam(args);
      result = rowCountResult(sqlSession.update(command.getName(), param));} else if (SqlCommandType.DELETE == command.getType()) {
      Object param = method.convertArgsToSqlCommandParam(args);
      result = rowCountResult(sqlSession.delete(command.getName(), param));} else if (SqlCommandType.SELECT == command.getType()) {
      if (method.returnsVoid() && method.hasResultHandler()) {executeWithResultHandler(sqlSession, args);
        result = null;
      } else if (method.returnsMany()) {
        result = executeForMany(sqlSession, args);
      } else if (method.returnsMap()) {
        result = executeForMap(sqlSession, args);
      } else {
        Object param = method.convertArgsToSqlCommandParam(args);
        result = sqlSession.selectOne(command.getName(), param);}
    } else {
      throw new BindingException("Unknown execution method for:" + command.getName());}
    if (result == null && method.getReturnType().isPrimitive() && !method.returnsVoid()) {
      throw new BindingException("Mapper method'" + command.getName() 
          + "attempted to return null from a method with a primitive return type (" + method.getReturnType() + ").");}
    return result;
  }

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执行流程分析（源码篇）

相关帖子

随便看看

深入浅出Mybatis系列（十）---SQL执行流程分析（源码篇）