MyBatis 源碼解析（二）：SqlSession 執(zhí)行流程

Dionysus_go 發(fā)布于2019-08-16 14:01 / 516人閱讀

摘要：簡介上一篇文章源碼解析一初始化和動態(tài)代理分析了解析配置文件以及動態(tài)代理相關(guān)的源碼，這一篇接著上一篇探究的執(zhí)行流程，另外了解一下中的緩存。總結(jié)本文主要分析了的執(zhí)行流程，結(jié)合上一篇文章基本了解了的運(yùn)行原理。

簡介

上一篇文章（MyBatis 源碼解析（一）：初始化和動態(tài)代理）分析了 MyBatis 解析配置文件以及 Mapper 動態(tài)代理相關(guān)的源碼，這一篇接著上一篇探究 SqlSession 的執(zhí)行流程，另外了解一下 MyBatis 中的緩存。

openSession

MyBatis 在解析完配置文件后生成了一個 DefaultSqlSessionFactory 對象，后續(xù)執(zhí)行 SQL 請求的時候都是調(diào)用其 openSession 方法獲得 SqlSessison，相當(dāng)于一個 SQL 會話。 SqlSession 提供了操作數(shù)據(jù)庫的一些方法，如 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 中取出相關(guān)的配置，生成 Transaction，接著又創(chuàng)建了一個 Executor，最后返回了 DefaultSqlSession 對象。

這里的 Executor 是什么呢？它其實是一個執(zhí)行器，SqlSession 的操作會交給 Executor 去執(zhí)行。MyBatis 的 Executor 常用的有以下幾種：

SimpleExecutor: 默認(rèn)的 Executor，每個 SQL 執(zhí)行時都會創(chuàng)建新的 Statement

ResuseExecutor: 相同的 SQL 會復(fù)用 Statement

BatchExecutor: 用于批處理的 Executor

CachingExecutor: 可緩存數(shù)據(jù)的 Executor，用代理模式包裝了其它類型的 Executor

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

  public Executor newExecutor(Transaction transaction, ExecutorType executorType) {
    // 默認(rèn)是 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);
    }
    // 默認(rèn)啟動緩存
    if (cacheEnabled) {
      executor = new CachingExecutor(executor);
    }
    executor = (Executor) interceptorChain.pluginAll(executor);
    return executor;
  }

MyBatis 默認(rèn)啟用一級緩存，即同一個 SqlSession 會共用同一個緩存，上面代碼最終返回的是 CachingExecutor。

getMapper

在創(chuàng)建了 SqlSession 之后，下一步是生成 Mapper 接口的代理類，代碼如下：

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

可以看出是從 configuration 中取得 Mapper，最終調(diào)用了 MapperProxyFactory 的 newInstance。MapperProxyFactory 在上一篇文章已經(jīng)分析過，它是為了給 Mapper 接口生成代理類，其中關(guān)鍵的攔截邏輯在 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 然后調(diào)用
    final MapperMethod mapperMethod = cachedMapperMethod(method);
    return mapperMethod.execute(sqlSession, args);
  }

MapperProxy 中調(diào)用了 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;
      ...
}

可以看出，最終調(diào)用了 SqlSession 的對應(yīng)方法，也就是 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 中調(diào)用了 executor 的 query，上面提到，默認(rèn)的 Executor 是 CachingExecutor，看其中的代碼：

  @Override
  public  List 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  List 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 list = (List) tcm.getObject(cache, key);
        if (list == null) {
          list = delegate. query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
          tcm.putObject(cache, key, list); // issue #578 and #116
        }
        return list;
      }
    }
    // 調(diào)用代理對象的緩存
    return delegate. query(ms, parameterObject, rowBounds, resultHandler, key, boundSql);
  }

首先檢查緩存中是否有數(shù)據(jù)，如果沒有再調(diào)用代理對象的 query，默認(rèn)是 SimpleExecutor。Executor 是一個接口，下面有個實現(xiàn)類是 BaseExecutor，其中實現(xiàn)了其它 Executor 通用的一些邏輯，包括 doQuery 以及 doUpdate 等，其中封裝了 JDBC 的相關(guān)操作。

update

update 的執(zhí)行與 select 類似，都是從 CachingExecutor 開始，看代碼：

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

update 會使得緩存的失效，所以第一步是檢查是否需要刷新緩存，接下來再交給代理類去執(zhí)行真正的數(shù)據(jù)庫更新操作。

總結(jié)

本文主要分析了 SqlSession 的執(zhí)行流程，結(jié)合上一篇文章基本了解了 MyBatis 的運(yùn)行原理。對于 MyBatis 的源碼，還有很多地方?jīng)]有深入，例如SQL 解析時參數(shù)的處理、一級緩存與二級緩存的處理邏輯等，不過在熟悉 MyBatis 的整體框架之后，這些細(xì)節(jié)可以在需要用到的時候繼續(xù)學(xué)習(xí)。

如果我的文章對您有幫助，不妨點個贊支持一下(^_^)