MyBatis 之源码浅读

环境简介与入口

记录一下尝试阅读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();中完成

本文到这里也就行将结束了,如果您觉得挺好玩的,欢迎点赞支持,有错误的话,也欢迎批评指出