Mybatis源码解析《二》

导语

在前一篇文章Mybatis源码解析《一》中，已经简单了捋了一下mybatis核心文件和mapper配置文件的一个基本的解析流程，这是理解mybatis的基本，和spring中的配置文件的加载解析是一样的道理。

既然说完了文件的加载，那么接下来便是关于mybatis的核心流程了，SqlSession的创建、SQL语句的操作、session的commit和关闭。在正式开始之前先回顾下上一篇文章中的测试代码。

public class MybatisTest {@Testpublic void test() throws Exception {User user = new User();user.setAddress("北京市海淀区");user.setBirthday(new Date(2000-10-01));user.setSex("男");user.setUsername("李清源");InputStream inputStream = Resources.getResourceAsStream("mybatis-config.xml");SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(inputStream);SqlSession sqlSession = sqlSessionFactory.openSession();sqlSession.insert("insertUser", user);sqlSession.commit();sqlSession.close();}
}

本篇文章将从SqlSession sqlSession = sqlSessionFactory.openSession()这行代码开始，那么就不多说了，开始mybatis源码的旅行了。

二、创建SqlSession对象

从代码中可以得知，sqlSesssion是通过sqlSessionFactory去打开session的，那就看下代码具体是如何体现的：

DefaultSqlSessionFactory.java

  public SqlSession openSession() {// 通过数据源打开session，第一个参数是通过configuration获取默认的执行器类型（这个configuration贯穿整个mybatis的执行），对于它的作用，后面看return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, false);}

这段代码中调用openSessionFromDataSource方法，方法中传入默认执行器类型、null、和false，这几个参数的意义分别是：默认执行器类型、事务隔离级别、是否自动提交数据库。继续看这个调用方法的代码：

  private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {Transaction tx = null;try {// 通过configuration获取开发环境（这个在核心配置文件中在environments有个environment标签）final Environment environment = configuration.getEnvironment();// 通过environment获取事务工厂（在我上面那段配置文件中写的是JDBC）final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);// 通过环境中获取的数据源、事务的隔离级别、是否自动提交来创建一个事务tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);// configuration通过事务和执行器类型来创建一个执行器final Executor executor = configuration.newExecutor(tx, execType);// 最后通过configuration（配置对象）、执行器、是否自动提交创建一个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();}}

这段代码中还算比较清晰的，在这段代码中，它的基本流程有如下几步：

通过configuration获取开发环境（这个在核心配置文件中在environments有个environment标签）
然后再通过上面所得到的environment获取事务工厂（在我前面文章中那段配置文件中写的是JDBC）
通过环境中获取的数据源、事务的隔离级别、是否自动提交这几个参数来创建一个事务
configuration通过事务和执行器类型来创建一个执行器
最后通过configuration（配置对象）、执行器、是否自动提交创建一个DefaultSqlSession返回

三、操作SQL语句

通过sqlSessionFactory去打开sqlSession后，便可以通过sqlSession来操作SQL语句了，但是这里所要考虑的是通过这个操作是怎么操作数据的，那就带着这个疑问来看代码中是怎么实现的。

  public int insert(String statement, Object parameter) {// 这里传入的两个参数是sqlSession.insert("insertUser", user)这行代码所传的第一个参数"insertUser"，这个参数是SQL命令的id编号，也就是mapper配置文件中所对应的，// 第二个参数是user对象return update(statement, parameter);}

上面提到了通过insert这个方法是怎么最后实现数据库的操作的，说到这里，从上面代码中来看，来把问题细分一下。在注释里说了"insertUser"这个参数的值是mapper文件中，所对应的标签id，因此在这里首先就要思考下这个id和SQL语句是如何进行定位的？当定位好之后对于所传入的user对象中的数据应该如何与SQL命令进行绑定呢？最后在数据与SQL命令绑定好之后，这样的SQL命令是如何输送的呢？

带着上面的这样的几个问题，来继续看代码中是如何实现的。首先来看下上面代码中所调用的update(statement, parameter)方法：

  public int update(String statement, Object parameter) {try {// 这里算是首次出现dirty，这个意思是脏的意思，是为了把SQLSession设置为true，这是个关注点dirty = true;// 通过所传入的参数statement，由configuration对象来获取mappedStatement并赋值给MappedStatement对象MappedStatement ms = configuration.getMappedStatement(statement);// 然后通过所获取到的mappedStatement和wrapCollection(parameter)锁处理后的object对象交由执行器执行return executor.update(ms, wrapCollection(parameter));} catch (Exception e) {throw ExceptionFactory.wrapException("Error updating database.  Cause: " + e, e);} finally {ErrorContext.instance().reset();}}

上面的代码中大体就三步：

设置dirty为true，这个作用后面再说
通过所传入的参数statement，由configuration对象来获取mappedStatement并赋值给MappedStatement对象
然后通过所获取到的mappedStatement和wrapCollection(parameter)锁处理后的object对象交由执行器执行

这三步中的第二步锁获取到的结果最后所赋值给ms的这个对象的结果如下图：

从上图中，可以清晰的看出通过所传入的参数，然后又这个参数定位这个SQL的位置，然后再找到这个SQL配置文件中的真正SQL语句。

Configuration.java

  public MappedStatement getMappedStatement(String id) {return this.getMappedStatement(id, true);}

  public MappedStatement getMappedStatement(String id, boolean validateIncompleteStatements) {if (validateIncompleteStatements) {// 这个方法是做各种校验的，但是按照现在的测试代码来看，是基本上都不走的buildAllStatements();}// 通过id在缓存中获取Statement相关数据return mappedStatements.get(id);}

    public V get(Object key) {V value = super.get(key);if (value == null) {throw new IllegalArgumentException(name + " does not contain value for " + key);}if (value instanceof Ambiguity) {throw new IllegalArgumentException(((Ambiguity) value).getSubject() + " is ambiguous in " + name+ " (try using the full name including the namespace, or rename one of the entries)");}return value;}

上面的代码，就是configuration.getMappedStatement(statement)的整个执行流程，其实就是把之前mapper文件所解析缓存的内容，此时再取出来。

在得到mappedStatement对象后，按照一开始的几个问题来看，这里的SQL定位已经完成了，那么现在要做的就是SQL模板的赋值了。那继续看executor.update(ms, wrapCollection(parameter))方法中的具体操作。在看update方法之前先看下wrapCollection这个方法中做了什么。

  private Object wrapCollection(final Object object) {// 判断所传入的对象是否是集合，是的话就走当前的逻辑if (object instanceof Collection) {StrictMap<Object> map = new StrictMap<Object>();map.put("collection", object);if (object instanceof List) {map.put("list", object);}return map;} else if (object != null && object.getClass().isArray()) {StrictMap<Object> map = new StrictMap<Object>();map.put("array", object);return map;}return object;}

因为前面所传入的参数，既不是集合也不是数组，所以这里返回的还是原对象。那就来看update方法。

BaseExecutor.java

  public int update(MappedStatement ms, Object parameter) throws SQLException {ErrorContext.instance().resource(ms.getResource()).activity("executing an update").object(ms.getId());if (closed) {throw new ExecutorException("Executor was closed.");}clearLocalCache();// 核心入口return doUpdate(ms, parameter);}

这段代码很简单，但是还是没有到达我们的核心代码中，那只有继续看核心入口doUpdate(ms, parameter)方法的具体实现了。

SimpleExecutor.java

  public int doUpdate(MappedStatement ms, Object parameter) throws SQLException {// 总算看到点希望了，在JDBC里面所有的SQL都是依赖Statement去输送的Statement stmt = null;try {// 从前面所传入的mappedStatement中来获取configuration配置对象Configuration configuration = ms.getConfiguration();// 通过this（SimpleExecutor）、ms（sql）、parameter（传入的对象）、行绑定等来创建一个StatementHandler对象StatementHandler handler = configuration.newStatementHandler(this, ms, parameter, RowBounds.DEFAULT, null, null);// 这里是把所传入的对象的数据和SQL模板进行一个绑定合成一句完整的SQLstmt = prepareStatement(handler, ms.getStatementLog());// 最后执行SQLreturn handler.update(stmt);} finally {closeStatement(stmt);}}

这段代码中主要的两个作用就是把所传入的对象的数据和SQL模板进行一个绑定合成一句完整的SQL和执行SQL操作数据库，那先看下prepareStatement(handler, ms.getStatementLog())方法：

  private Statement prepareStatement(StatementHandler handler, Log statementLog) throws SQLException {Statement stmt;// 获取链接信息Connection connection = getConnection(statementLog);// 准备stmtstmt = handler.prepare(connection, transaction.getTimeout());// 最后参数绑定整合handler.parameterize(stmt);return stmt;}

先看下准备stmt的过程，这里代码很简单。

  public Statement prepare(Connection connection, Integer transactionTimeout) throws SQLException {ErrorContext.instance().sql(boundSql.getSql());Statement statement = null;try {// 实例化statementstatement = instantiateStatement(connection);// 设置statement超时时间setStatementTimeout(statement, transactionTimeout);// 设置fetch的sizesetFetchSize(statement);return statement;} catch (SQLException e) {closeStatement(statement);throw e;} catch (Exception e) {closeStatement(statement);throw new ExecutorException("Error preparing statement.  Cause: " + e, e);}}

接下来看下最后参数的整合绑定，核心代码如下：

DefaultParameterHandler.java

  public void setParameters(PreparedStatement ps) {ErrorContext.instance().activity("setting parameters").object(mappedStatement.getParameterMap().getId());List<ParameterMapping> parameterMappings = boundSql.getParameterMappings();if (parameterMappings != null) {for (int i = 0; i < parameterMappings.size(); i++) {ParameterMapping parameterMapping = parameterMappings.get(i);if (parameterMapping.getMode() != ParameterMode.OUT) {Object value;String propertyName = parameterMapping.getProperty();if (boundSql.hasAdditionalParameter(propertyName)) { // issue #448 ask first for additional paramsvalue = boundSql.getAdditionalParameter(propertyName);} else if (parameterObject == null) {value = null;} else if (typeHandlerRegistry.hasTypeHandler(parameterObject.getClass())) {value = parameterObject;} else {MetaObject metaObject = configuration.newMetaObject(parameterObject);value = metaObject.getValue(propertyName);}TypeHandler typeHandler = parameterMapping.getTypeHandler();JdbcType jdbcType = parameterMapping.getJdbcType();if (value == null && jdbcType == null) {jdbcType = configuration.getJdbcTypeForNull();}try {typeHandler.setParameter(ps, i + 1, value, jdbcType);} catch (TypeException e) {throw new TypeException("Could not set parameters for mapping: " + parameterMapping + ". Cause: " + e, e);} catch (SQLException e) {throw new TypeException("Could not set parameters for mapping: " + parameterMapping + ". Cause: " + e, e);}}}}}}

这里的代码相对比较复杂，感兴趣的同学可以自己debug进来研究一下，这里就是最后数据的绑定SQL模板的过程了。在看完第二个问题后，那来看看最后一个问题，就是SQL的执行了。

PreparedStatementHandler.java

  public int update(Statement statement) throws SQLException {// 把statement赋给PreparedStatementPreparedStatement ps = (PreparedStatement) statement;// 最后做执行操作ps.execute();// 把执行结果返回int rows = ps.getUpdateCount();Object parameterObject = boundSql.getParameterObject();KeyGenerator keyGenerator = mappedStatement.getKeyGenerator();keyGenerator.processAfter(executor, mappedStatement, ps, parameterObject);return rows;}

写着写着发现篇幅又很长了，看来后面的操作的代码解析只能放到下篇文章去做解析了，这有点超出我的所预想的，那本篇文章就先到这里了，感谢大家的阅读，如有错误请大家指出，谢谢！