MyBatis 源碼解析（二）：SqlSession 執行流程

簡介

上一篇文章（MyBatis 源碼解析（一）：初始化和動態代理）分析了 MyBatis 解析配置文件以及 Mapper 動態代理相關的源碼，這一篇接着上一篇探究 SqlSession 的執行流程，另外瞭解一下 MyBatis 中的緩存。

openSession

MyBatis 在解析完配置文件後生成了一個 DefaultSqlSessionFactory 對象，後續執行 SQL 請求的時候都是調用其 openSession 方法得到 SqlSessison，至關於一個 SQL 會話。 SqlSession 提供了操做數據庫的一些方法，如 select、update 等。

先看一下 DefaultSqlSessionFactory 的 openSession 的代碼：

public SqlSession openSession() {
    return openSessionFromDataSource(configuration.getDefaultExecutorType(), null, false);
  }

  private SqlSession openSessionFromDataSource(ExecutorType execType, TransactionIsolationLevel level, boolean autoCommit) {
    Transaction tx = null;
    try {
      // 從 configuration 取出配置
      final Environment environment = configuration.getEnvironment();
      final TransactionFactory transactionFactory = getTransactionFactoryFromEnvironment(environment);
      tx = transactionFactory.newTransaction(environment.getDataSource(), level, autoCommit);
      // 每一個 SqlSession 都有一個單獨的 Executor 對象
      final Executor executor = configuration.newExecutor(tx, execType, autoCommit);
      // 返回 DefaultSqlSession 對象
      return new DefaultSqlSession(configuration, executor);
    } 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();
    }
  }

主要代碼在 openSessionFromDataSource，首先是從 Configuration 中取出相關的配置，生成 Transaction，接着又建立了一個 Executor，最後返回了 DefaultSqlSession 對象。

這裏的 Executor 是什麼呢？它實際上是一個執行器，SqlSession 的操做會交給 Executor 去執行。MyBatis 的 Executor 經常使用的有如下幾種：

• SimpleExecutor: 默認的 Executor，每一個 SQL 執行時都會建立新的 Statement
• ResuseExecutor: 相同的 SQL 會複用 Statement
• BatchExecutor: 用於批處理的 Executor
• CachingExecutor: 可緩存數據的 Executor，用代理模式包裝了其它類型的 Executor

瞭解了 Executor 的類型後，看一下 configuration.newExecutor(tx, execType, autoCommit) 的代碼：

public Executor newExecutor(Transaction transaction, ExecutorType executorType) {
    // 默認是 SimpleExecutor
    executorType = executorType == null ? defaultExecutorType : executorType;
    executorType = executorType == null ? ExecutorType.SIMPLE : executorType;
    Executor executor;
    if (ExecutorType.BATCH == executorType) {
      executor = new BatchExecutor(this, transaction);
    } else if (ExecutorType.REUSE == executorType) {
      executor = new ReuseExecutor(this, transaction);
    } else {
      executor = new SimpleExecutor(this, transaction);
    }
    // 默認啓動緩存
    if (cacheEnabled) {
      executor = new CachingExecutor(executor);
    }
    executor = (Executor) interceptorChain.pluginAll(executor);
    return executor;
  }

MyBatis 默認啓用一級緩存，即同一個 SqlSession 會共用同一個緩存，上面代碼最終返回的是 CachingExecutor。

getMapper

在建立了 SqlSession 以後，下一步是生成 Mapper 接口的代理類，代碼以下：

public <T> T getMapper(Class<T> type) {
    return configuration.<T>getMapper(type, this);
  }

能夠看出是從 configuration 中取得 Mapper，最終調用了 MapperProxyFactory 的 newInstance。MapperProxyFactory 在上一篇文章已經分析過，它是爲了給 Mapper 接口生成代理類，其中關鍵的攔截邏輯在 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);
    }
    // 從緩存中獲取 MapperMethod 而後調用
    final MapperMethod mapperMethod = cachedMapperMethod(method);
    return mapperMethod.execute(sqlSession, args);
  }

MapperProxy 中調用了 MapperMethod 的 execute，下面是部分代碼：

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 UPDATE: {
        Object param = method.convertArgsToSqlCommandParam(args);
        result = rowCountResult(sqlSession.update(command.getName(), param));
        break;
      }
      case DELETE: {
        Object param = method.convertArgsToSqlCommandParam(args);
        result = rowCountResult(sqlSession.delete(command.getName(), param));
        break;
      }
      case SELECT:
        if (method.returnsVoid() && method.hasResultHandler()) {
          executeWithResultHandler(sqlSession, args);
          result = null;
      ...
}

能夠看出，最終調用了 SqlSession 的對應方法，也就是 DefaultSqlSession 中的方法。

select

先看一下 DefaultSqlSession 中 select 的代碼：

public void select(String statement, Object parameter, RowBounds rowBounds, ResultHandler handler) {
    try {
      MappedStatement ms = configuration.getMappedStatement(statement);
      executor.query(ms, wrapCollection(parameter), rowBounds, handler);
    } catch (Exception e) {
      throw ExceptionFactory.wrapException("Error querying database.  Cause: " + e, e);
    } finally {
      ErrorContext.instance().reset();
    }
  }

select 中調用了 executor 的 query，上面提到，默認的 Executor 是 CachingExecutor，看其中的代碼：

@Override
  public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler) throws SQLException {
    BoundSql boundSql = ms.getBoundSql(parameterObject);
    // 獲取緩存的key
    CacheKey key = createCacheKey(ms, parameterObject, rowBounds, boundSql);
    return query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
  }
public <E> List<E> query(MappedStatement ms, Object parameterObject, RowBounds rowBounds, ResultHandler resultHandler, CacheKey key, BoundSql boundSql)
      throws SQLException {
    // 獲取緩存
    Cache cache = ms.getCache();
    if (cache != null) {
      flushCacheIfRequired(ms);
      if (ms.isUseCache() && resultHandler == null) {
        ensureNoOutParams(ms, boundSql);
        @SuppressWarnings("unchecked")
        List<E> list = (List<E>) tcm.getObject(cache, key);
        if (list == null) {
          list = delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
          tcm.putObject(cache, key, list); // issue #578 and #116
        }
        return list;
      }
    }
    // 調用代理對象的緩存
    return delegate.<E> query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
  }

首先檢查緩存中是否有數據，若是沒有再調用代理對象的 query，默認是 SimpleExecutor。Executor 是一個接口，下面有個實現類是 BaseExecutor，其中實現了其它 Executor 通用的一些邏輯，包括 doQuery 以及 doUpdate 等，其中封裝了 JDBC 的相關操做。

update

update 的執行與 select 相似， 都是從 CachingExecutor 開始，看代碼：

@Override
  public int update(MappedStatement ms, Object parameterObject) throws SQLException {
    // 檢查是否須要刷新緩存
    flushCacheIfRequired(ms);
    // 調用代理類的 update
    return delegate.update(ms, parameterObject);
  }

update 會使得緩存的失效，因此第一步是檢查是否須要刷新緩存，接下來再交給代理類去執行真正的數據庫更新操做。

總結

本文主要分析了 SqlSession 的執行流程，結合上一篇文章基本瞭解了 MyBatis 的運行原理。對於 MyBatis 的源碼，還有不少地方沒有深刻，例如SQL 解析時參數的處理、一級緩存與二級緩存的處理邏輯等，不過在熟悉 MyBatis 的總體框架以後，這些細節能夠在須要用到的時候繼續學習。

若是個人文章對您有幫助，不妨點個贊支持一下(^_^)