Mybatis(七) - 结果集的封装与映射

上一章，我们把动态 SQL 的生成，以及 PreparedStatement 参数绑定的过程都研究明白了，对于 DML 来讲，只需要最后拿到影响结果的行数就可以，但对于 DQL 来讲，另一个很关键的过程，就是结果集的封装。

本章我们来着重探讨 MyBatis 如何对结果集进行封装和映射的。

在 Executor 执行查询时， prepareStatement 的动作完成后，下面就是实际的查询动作了：

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);
    }
}

StatementHandler 负责了发起查询的动作，它的 query 方法中会真正的调用 PreparedStatement 的 execute 方法，向数据库发起查询动作：

public <E> List<E> query(Statement statement, ResultHandler resultHandler) throws SQLException {
    PreparedStatement ps = (PreparedStatement) statement;
    ps.execute();
    return resultSetHandler.handleResultSets(ps);
}

发起请求动作后，下面会使用一个 ResultSetHandler 去处理结果集，这个方法就是本章要深入探讨的了，本章我们从这里出发。

1. ResultSetHandler

我们先简单了解一下这个 ResultSetHandler 是啥。跟其他 Handler 的设计一样，ResultSetHandler 同样是个接口：

public interface ResultSetHandler {
    <E> List<E> handleResultSets(Statement stmt) throws SQLException;
    <E> Cursor<E> handleCursorResultSets(Statement stmt) throws SQLException;
    void handleOutputParameters(CallableStatement cs) throws SQLException;
}

虽说是有三个方法，但第二个是跟 Cursor 有关，第三个跟存储过程有关，我们都不关心，最重要的还是 handleResultSets ，也就是上面我们看到 StatementHandler 调用的方法。

它的实现类，在 MyBatis 中就一个：DefaultResultSetHandler ，我们可以先简单过一遍它内部的成员：

public class DefaultResultSetHandler implements ResultSetHandler {

    // 延迟加载的标记
    private static final Object DEFERRED = new Object();

    private final Executor executor;
    private final Configuration configuration;
    private final MappedStatement mappedStatement;
    // 内存分页用
    private final RowBounds rowBounds;
    // 参数处理器
    private final ParameterHandler parameterHandler;
    // 结果处理器(默认为null)
    private final ResultHandler<?> resultHandler;
    private final BoundSql boundSql;

    // Cached Automappings
    // 自动缓存的映射
    private final Map<String, List<UnMappedColumnAutoMapping>> autoMappingsCache = new HashMap<>();

    // temporary marking flag that indicate using constructor mapping (use field to reduce memory usage)
    // 映射结果集时映射的对象是否要走构造器映射(<constructor>标签)
    private boolean useConstructorMappings;
}

上面的几个成员都是老生常谈的，组合在 ResultSetHandler 中也是很正常的，注意底下还有一个 autoMappingsCache ，各位小伙伴可以先记住它，下面我们会看到的。

OK ，下面我们开始走 handleResultSets 的逻辑。

2. handleResultSets

这个方法本身不算很长，所以小册不打算一上来就拆解为多段，先整体看一下，有一个大概的脉络认识：

public List<Object> handleResultSets(Statement stmt) throws SQLException {
    ErrorContext.instance().activity("handling results").object(mappedStatement.getId());

    // 通常情况下，只有使用存储过程时，才会产生多个结果集，否则这个列表只会有一个元素
    final List<Object> multipleResults = new ArrayList<>();

    // 2.1 ResultSet封装为ResultSetWrapper
    int resultSetCount = 0;
    ResultSetWrapper rsw = getFirstResultSet(stmt);

    // 2.2 获取statement中定义的ResultMap映射规则
    List<ResultMap> resultMaps = mappedStatement.getResultMaps();
    int resultMapCount = resultMaps.size();
    validateResultMapsCount(rsw, resultMapCount);
    while (rsw != null && resultMapCount > resultSetCount) {
        ResultMap resultMap = resultMaps.get(resultSetCount);
        // 处理单个ResultSet(本身也只会处理一次)
        handleResultSet(rsw, resultMap, multipleResults, null);
        rsw = getNextResultSet(stmt);
        cleanUpAfterHandlingResultSet();
        resultSetCount++;
    }

    // 存储过程相关，小册忽略掉
    // ......

    // 2.3 决定返回的元素类型
    return collapseSingleResultList(multipleResults);
}

纵观整段逻辑，其实它要干的活，就是解析 Statement 中的所有 ResultSet ，并封装结果集，说白了，这里做的主要工作不是干实际的活，而只是循环调度而已，毕竟 MyBatis 本身支持我们调用存储过程，所以这里会对存储过程中返回的多个不同类型的结果集予以兼容。不过从实际使用的角度来看，我们还是使用单个 select 动作的场景为主，几乎不会使用存储过程，所以这里我们不对存储过程的相关逻辑予以展开。

接下来，小册针对上面提到的几个关键步骤，逐一展开。

2.1 包装ResultSetWrapper

ResultSet 本身是原生 jdbc 的东西，包装为 ResultSetWrapper 肯定是在此基础上增强一些便捷的操作。我们先看看它包装的动作：

private ResultSetWrapper getFirstResultSet(Statement stmt) throws SQLException {
    // 通常调用该方法就可以获取到ResultSet了
    ResultSet rs = stmt.getResultSet();
    // 但使用存储过程时，需要像迭代器一样先检查再获取
    while (rs == null) {
        // move forward to get the first resultset in case the driver
        // doesn't return the resultset as the first result (HSQLDB 2.1)
        if (stmt.getMoreResults()) {
            rs = stmt.getResultSet();
        } else {
            if (stmt.getUpdateCount() == -1) {
                // no more results. Must be no resultset
                break;
            }
        }
    }
    return rs != null ? new ResultSetWrapper(rs, configuration) : null;
}

获取完成后，直接封装为 ResultSetWrapper ，返回，逻辑非常朴实无华。但是吧，按照 MyBatis 一贯的尿性，ResultSetWrapper 的初始化，也就是构造方法中，一定有很重要的逻辑，所以我们得去看一眼。

2.1.1 ResultSetWrapper的构造方法

构造方法中藏了一个初始化的动作，我们要重点关注一下：

public ResultSetWrapper(ResultSet rs, Configuration configuration) throws SQLException {
    this.typeHandlerRegistry = configuration.getTypeHandlerRegistry();
    this.resultSet = rs;
    final ResultSetMetaData metaData = rs.getMetaData();
    final int columnCount = metaData.getColumnCount();
    for (int i = 1; i <= columnCount; i++) {
        columnNames.add(configuration.isUseColumnLabel() ? metaData.getColumnLabel(i) : metaData.getColumnName(i));
        jdbcTypes.add(JdbcType.forCode(metaData.getColumnType(i)));
        classNames.add(metaData.getColumnClassName(i));
    }
}

注意看，ResultSetWrapper 拿到 ResultSet 后，会先操作它获取 ResultSetMetaData ，这个家伙是原生 jdbc 的东西，它可以获取到关于 ResultSet 对象中列的类型和属性信息，正好 MyBatis 要封装结果集时，就得拿这些信息，所以这里有一系列的获取动作。获取完成后，它会存放到 ResultSetWrapper 的几个成员中：

private final List<String> columnNames = new ArrayList<>();
private final List<String> classNames = new ArrayList<>();
private final List<JdbcType> jdbcTypes = new ArrayList<>();

因为都是 List ，所以它们的位置也一一对应，这样收集好了，下面再用到的时候就不用重复操作 ResultSet 了。

2.1.2 getTypeHandler

ResultSetWrapper 中有一个比较重要的方法 getTypeHandler ，它可以获取到指定类型的 TypeHandler 对象，利用 TypeHandler 可以实现从结果集中取指定类型的数据。这个方法在下面 ResultSetHandler 中有一个重要的使用位置，我们可以先来扫一遍它的实现：

// 注意这是个双层Map
// 外层Map的key是属性名，内层的key是属性类型，value是处理该类型的TypeHandler实现类
// 换言之，这个typeHandlerMap的结构是 key-key-value
private final Map<String, Map<Class<?>, TypeHandler<?>>> typeHandlerMap = new HashMap<>();

public TypeHandler<?> getTypeHandler(Class<?> propertyType, String columnName) {
    TypeHandler<?> handler = null;
    // 先检查当前传入的属性是否有处理过
    Map<Class<?>, TypeHandler<?>> columnHandlers = typeHandlerMap.get(columnName);
    if (columnHandlers == null) {
        // 没有的话，初始化一个内层的Map
        columnHandlers = new HashMap<>();
        typeHandlerMap.put(columnName, columnHandlers);
    } else {
        // 初始化过Map，那就查一下Map中有没有存TypeHandler
        handler = columnHandlers.get(propertyType);
    }
    // 没有初始化过具体的TypeHandler
    if (handler == null) {
        JdbcType jdbcType = getJdbcType(columnName);
        // 问TypeHandlerRegistry能不能搞定当前这个属性的类型
        handler = typeHandlerRegistry.getTypeHandler(propertyType, jdbcType);
        // 如果TypeHandlerRegistry还是搞不定，那就再尝试别的办法
        if (handler == null || handler instanceof UnknownTypeHandler) {
            // 根据ResultSet中提供的信息，获取到jdbc认为的类型
            final int index = columnNames.indexOf(columnName);
            final Class<?> javaType = resolveClass(classNames.get(index));
            // 再问一次TypeHandlerRegistry能不能搞定
            if (javaType != null && jdbcType != null) {
                handler = typeHandlerRegistry.getTypeHandler(javaType, jdbcType);
            } else if (javaType != null) {
                handler = typeHandlerRegistry.getTypeHandler(javaType);
            } else if (jdbcType != null) {
                handler = typeHandlerRegistry.getTypeHandler(jdbcType);
            }
        }
        // 如果还是搞不定，那就只能封装Object了
        if (handler == null || handler instanceof UnknownTypeHandler) {
            handler = new ObjectTypeHandler();
        }
        columnHandlers.put(propertyType, handler);
    }
    return handler;
}

自上往下走完一遍，我们能很清楚的感受到一个事情：这个 getTypeHandler 是尽力的帮我们去处理结果集中每一个列的封装处理了，这样做的目的也很明确，MyBatis 希望给我们做结果集映射的时候，做到每一列都能用最准确的类型去封装和处理。

2.2 获取映射规则

回到 ResultSetHandler 中，上面封装好 ResultSetWrapper 后，下面的一个最最重要的动作，就是获取映射规则，以及封装实际的数据了。这个步骤相当难，小伙伴们一定要好好静下心来看。

2.2.1 ResultMaps里有什么

首先我们来看 List<ResultMap> resultMaps = mappedStatement.getResultMaps(); 这句代码，它会从 MappedStatement 中获取到 ResultMap 的一个集合。不同的场景下取到的东西不一样，我们分别来看。

2.2.1.1 resultType

以前面我们 Debug 测试时用的 dynamic.findAllDepartment 来看，Debug 至此时，可以发现它特别简陋：

img

阿这？底下的好多属性都是空的，就保存了一个 id 一个 type ，没了？合着用 resultType 的方式就保存这么点？还真是，下面我们看处理过程的时候，就会意识到，其实这么点就够了。

2.2.1.2 resultMap

上面调用的 dynamic.findAllDepartment ，本身是用 resultType 接收返回结果集的，但如果是 resultMap 呢？我们拿 mybatis-03-mapper 工程的 com.linkedbear.mybatis.mapper.UserMapper.findAllLazy 测试：

InputStream xml = Resources.getResourceAsStream("mybatis-config.xml");
SqlSessionFactory sqlSessionFactory = new SqlSessionFactoryBuilder().build(xml);
SqlSession sqlSession = sqlSessionFactory.openSession();

sqlSession.selectList("com.linkedbear.mybatis.mapper.UserMapper.findAllLazy");
<resultMap id="userlazy" type="com.linkedbear.mybatis.entity.User">
    <id property="id" column="id"/>
    <result property="name" column="name"/>
    <result property="age" column="age"/>
    <result property="birthday" column="birthday"/>
    <association property="department" javaType="com.linkedbear.mybatis.entity.Department"
                 select="com.linkedbear.mybatis.mapper.DepartmentMapper.findById" column="department_id"/>
</resultMap>

再次 Debug ，在断点处观察获取到的 resultMaps 如下：

img

好家伙，这可真全啊，要映射的属性、列名，以及封装的一个一个 ResultMapping 全部都在里面，后面我们可要好好地看这部分啊。

2.2.2 处理单个映射结果集

接下来就是重头戏 handleResultSet 方法了，它用来处理单个结果集的映射，也就是上面 resultMaps 集合中的每一个映射规则。通常情况下，这个集合中只会有一个元素，所以处理结果集的动作也只会执行一次。

好，下面我们来看方法的实现：

private void handleResultSet(ResultSetWrapper rsw, ResultMap resultMap, 
        List<Object> multipleResults, ResultMapping parentMapping) throws SQLException {
    try {
        // 如果有父级映射规则，则处理父级(也是兼容存储过程的，我们忽略)
        if (parentMapping != null) {
            handleRowValues(rsw, resultMap, null, RowBounds.DEFAULT, parentMapping);
        } else {
            // 如果没有resultHandler，则使用默认的实现处理
            if (resultHandler == null) {
                DefaultResultHandler defaultResultHandler = new DefaultResultHandler(objectFactory);
                // 实际的封装动作
                handleRowValues(rsw, resultMap, defaultResultHandler, rowBounds, null);
                multipleResults.add(defaultResultHandler.getResultList());
            } else {
                // 否则直接使用现成的ResultHandler(一般不会有)
                handleRowValues(rsw, resultMap, resultHandler, rowBounds, null);
            }
        }
    } finally {
        // issue #228 (close resultsets)
        closeResultSet(rsw.getResultSet());
    }
}

前面关于存储过程的部分我们就不看了，重点是下面的 else 部分，这里面它会先判断一下 ResultSetHandler 中是否有内置的 resultHandler ，然而通过 Debug 发现并没有：

img

为什么没有呢？一路向上爬，最终发现是我们调用 SqlSession 的 selectList 方法中，传入的 Executor.NO_RESULT_HANDLER 本身是个 null 。。。

ResultHandler NO_RESULT_HANDLER = null;

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 自己就没指望我们自己传 ResultHandler ，那我们也甭费心了，直接研究默认实现就 OK 。

这个 ResultHandler 跟着其余的参数，进入到了下面的 handleRowValues 方法，我们继续往下看。

2.2.3 handleRowValues

这里面有一个先行的判断需要各位注意：

public void handleRowValues(ResultSetWrapper rsw, ResultMap resultMap, ResultHandler<?> resultHandler, 
        RowBounds rowBounds, ResultMapping parentMapping) throws SQLException {
    // 检查是否存在嵌套的resultMap
    if (resultMap.hasNestedResultMaps()) {
        ensureNoRowBounds();
        checkResultHandler();
        handleRowValuesForNestedResultMap(rsw, resultMap, resultHandler, rowBounds, parentMapping);
    } else {
        // 处理单层的resultMap
        handleRowValuesForSimpleResultMap(rsw, resultMap, resultHandler, rowBounds, parentMapping);
    }
}

注意源码的注释中提到了一个 “嵌套 resultMap ” 的概念，什么是嵌套 resultMap 呢？其实之前我们都写过很多了，比方说下面两种：

<resultMap id="userMap" type="com.linkedbear.mybatis.entity.User">
    <!-- 直接声明的方式 -->
    <association property="department" javaType="com.linkedbear.mybatis.entity.Department">
        <id property="id" column="department_id"/>
        <result property="name" column="department_name"/>
    </association>
</resultMap>

<resultMap id="userWithPrefix" type="com.linkedbear.mybatis.entity.User">
    <!-- 引用其他resultMap的方式 -->
    <association property="department" javaType="com.linkedbear.mybatis.entity.Department"
                 resultMap="com.linkedbear.mybatis.mapper.DepartmentMapper.department" columnPrefix="department_"/>
</resultMap>

这两种方式，都是在实际查询的时候，多查出一些字段，在映射结果集时，将一些多余的列数据放入实体类中组合的其他类中，从而形成嵌套模型类，反映到结果集的映射上，就是嵌套结果集。

注意，延迟加载的属性不属于嵌套 resultMap ：

<resultMap id="userlazy" type="com.linkedbear.mybatis.entity.User">
    <!-- 下面这种不算 -->
    <association property="department" javaType="com.linkedbear.mybatis.entity.Department"
                 select="com.linkedbear.mybatis.mapper.DepartmentMapper.findById" column="department_id"/>
</resultMap>

我们先来看单层的 resultMap 如何封装，继续往下走。

2.2.4 handleRowValuesForSimpleResultMap

源码中先把每个关键步骤都标注上注释，各位先有个整体的印象：

private void handleRowValuesForSimpleResultMap(ResultSetWrapper rsw, ResultMap resultMap, 
        ResultHandler<?> resultHandler, RowBounds rowBounds, ResultMapping parentMapping) throws SQLException {
    // 注意这是一个新的Context概念
    DefaultResultContext<Object> resultContext = new DefaultResultContext<>();
    ResultSet resultSet = rsw.getResultSet();
    // 2.2.4.2 内存分页
    skipRows(resultSet, rowBounds);
    // 循环封装
    while (shouldProcessMoreRows(resultContext, rowBounds) && !resultSet.isClosed() && resultSet.next()) {
        // 2.2.4.3 鉴定器决定使用哪个ResultMap
        ResultMap discriminatedResultMap = resolveDiscriminatedResultMap(resultSet, resultMap, null);
        // 2.2.4.4 获取一行数据
        Object rowValue = getRowValue(rsw, discriminatedResultMap, null);
        // 2.2.4.5 映射后的数据保存到集合中
        storeObject(resultHandler, resultContext, rowValue, parentMapping, resultSet);
    }
}

呦，这个方法中终于看到 ResultSet 的真身了，那是不是就意味着从 ResultSet 中取数据的动作真的来了呢？答案是肯定的！我们赶紧来分步看看这里都干了什么吧！

2.2.4.1 DefaultResultContext

这个家伙的出现，是不是让各位想起来了 DynamicContext 呢？哎，确实有那么一点点的味道，但这个 DefaultResultContext 的设计相当的简单：

public class DefaultResultContext<T> implements ResultContext<T> {
    // 当前返回结果集封装的对象
    private T resultObject;
    // 这个对象在返回集合的位置(下标)
    private int resultCount;
    // 是否停止后续的映射
    private boolean stopped;

这三个属性似乎乍一看会让我们感觉多余，不要着急，后面各位会看到它的必要性的。

2.2.4.2 内存分页

MyBatis 设计的超级没用之一的地方就是这个内存分页，我们貌似从来都没用过它。不过出于尊重，我们还是看一看吧。

private void skipRows(ResultSet rs, RowBounds rowBounds) throws SQLException {
    if (rs.getType() != ResultSet.TYPE_FORWARD_ONLY) {
        if (rowBounds.getOffset() != RowBounds.NO_ROW_OFFSET) {
            rs.absolute(rowBounds.getOffset());
        }
    } else {
        // 循环执行ResultSet的next方法
        for (int i = 0; i < rowBounds.getOffset(); i++) {
            if (!rs.next()) {
                break;
            }
        }
    }
}

看，多么的朴实无华。。。就是一行一行的跳数据。。。这种用法需要我们必须查出全部的数据来，才能进行内存分页，但这样的话性能是不是有点太。。。所以你懂得，我们都不用，这里大家知道一下就得了。

2.2.4.3 鉴定器的决定

鉴定器是干啥的各位还记得吧，它可以根据结果集的某一行数据，决定使用哪个 ResultMap 去实际的映射结果集，它的实现原理如下：

public ResultMap resolveDiscriminatedResultMap(ResultSet rs, ResultMap resultMap, String columnPrefix) throws SQLException {
    Set<String> pastDiscriminators = new HashSet<>();
    // 获取这个resultMap中声明的鉴定器
    Discriminator discriminator = resultMap.getDiscriminator();
    while (discriminator != null) {
        // 逐个值判断
        final Object value = getDiscriminatorValue(rs, discriminator, columnPrefix);
        // 根据指定列的值，看看能不能获取到可以用的resultMap
        final String discriminatedMapId = discriminator.getMapIdFor(String.valueOf(value));
        if (configuration.hasResultMap(discriminatedMapId)) {
            // 如果可以找到，加载它，并把当前的鉴定器记录下来
            resultMap = configuration.getResultMap(discriminatedMapId);
            Discriminator lastDiscriminator = discriminator;
            // 可能引用的resultMap还有使用鉴定器，相当于套了多层if判断
            discriminator = resultMap.getDiscriminator();
            // 避免鉴定器循环引用
            if (discriminator == lastDiscriminator || !pastDiscriminators.add(discriminatedMapId)) {
                break;
            }
        } else {
            break;
        }
    }
    // 最终逃出来的resultMap就是经过一系列鉴定器后最终推断出来的
    return resultMap;
}

2.2.4.4 获取一行数据的值并映射为对象

得到最终可用的 resultMap 后，下面终于来到获取值和映射对象的过程了！这个方法本身也是稍微复杂一些，我们先看一下方法总体逻辑：

private Object getRowValue(ResultSetWrapper rsw, ResultMap resultMap, String columnPrefix) throws SQLException {
    final ResultLoaderMap lazyLoader = new ResultLoaderMap();
    // 创建需要封装的结果集类型的空对象(相当于空的实体类/空Map)
    Object rowValue = createResultObject(rsw, resultMap, lazyLoader, columnPrefix);
    if (rowValue != null && !hasTypeHandlerForResultObject(rsw, resultMap.getType())) {
        // 借助反射处理下面的属性赋值
        final MetaObject metaObject = configuration.newMetaObject(rowValue);
        boolean foundValues = this.useConstructorMappings;
        // 对未明确声明的属性映射进行自动映射(处理resultType)
        if (shouldApplyAutomaticMappings(resultMap, false)) {
            foundValues = applyAutomaticMappings(rsw, resultMap, metaObject, columnPrefix) || foundValues;
        }
        // 处理resultMap中配置好的列的映射
        foundValues = applyPropertyMappings(rsw, resultMap, metaObject, lazyLoader, columnPrefix) || foundValues;
        // 如果整个过程没有映射到任何属性，则根据配置决定返回空对象还是null
        foundValues = lazyLoader.size() > 0 || foundValues;
        rowValue = foundValues || configuration.isReturnInstanceForEmptyRow() ? rowValue : null;
    }
    return rowValue;
}

自上而下走完流程之后，一行数据也就封装完毕了，这里面涉及到的几个比较复杂的方法我们再展开看一看。

2.2.4.4.1 创建空对象

要封装结果集，肯定要先有一个空的模型类对象，或者空的 Map 才可以吧，这一步就是先把 “空壳” 创建出来。这个 createResultObject 里面设计的逻辑比较复杂，小册不把源码都贴出来了，只粘出一些重要的逻辑片段，各位看一下就 OK 了：

private Object createResultObject(ResultSetWrapper rsw, ResultMap resultMap, ResultLoaderMap lazyLoader, 
        String columnPrefix) throws SQLException {
    // ......
    Object resultObject = createResultObject(rsw, resultMap, constructorArgTypes, constructorArgs, columnPrefix);
    // ......
    this.useConstructorMappings = resultObject != null && !constructorArgTypes.isEmpty(); // set current mapping result
    return resultObject;
}

private Object createResultObject(ResultSetWrapper rsw, ResultMap resultMap, List<Class<?>> constructorArgTypes, 
        List<Object> constructorArgs, String columnPrefix) throws SQLException {
    final Class<?> resultType = resultMap.getType();
    final MetaClass metaType = MetaClass.forClass(resultType, reflectorFactory);
    final List<ResultMapping> constructorMappings = resultMap.getConstructorResultMappings();
    // 根据结果集接收的对象类型，有以下四中情况
    // 如果可以直接被TypeHandler处理，则大概率为基本类型，直接处理
    // 当然还存在一种情况：自定义了TypeHandler处理某些特殊的实体类型，此处也可以处理
    if (hasTypeHandlerForResultObject(rsw, resultType)) {
        return createPrimitiveResultObject(rsw, resultMap, columnPrefix);
    }
    // 定义的resultMap标签中存在<constructor>子标签，则走下面的分支
    else if (!constructorMappings.isEmpty()) {
        return createParameterizedResultObject(rsw, resultType, constructorMappings, 
                       constructorArgTypes, constructorArgs, columnPrefix);
    }
    // 有默认的无参构造器，则直接借助ObjectFactory创建
    else if (resultType.isInterface() || metaType.hasDefaultConstructor()) {
        return objectFactory.create(resultType);
    }
    // 没有默认构造器，则MyBatis会自己试探性寻找合适的构造方法创建对象
    else if (shouldApplyAutomaticMappings(resultMap, false)) {
        return createByConstructorSignature(rsw, resultType, constructorArgTypes, constructorArgs);
    }
    throw new ExecutorException("Do not know how to create an instance of " + resultType);
}

四种方式都可以创建出空对象，一般情况下我们使用的实体类都是带默认无参构造器的，所以都是走第三种方式，借助 ObjectFactory 创建对象。

2.2.4.4.2 未声明的属性自动映射

创建出空对象之后，接下来就该处理属性映射了。下面的 applyAutomaticMappings 方法是处理自动映射，说到这个自动映射，我们要提一下上面的那个伏笔了。使用 resultType 声明结果集接收类型时，我们发现经过封装后的 resultMap 对象中属性值好少，只记录了 Class 类型的信息，这个时候 MyBatis 就觉得，既然你只告诉我类型，那我就按照属性名和列名一一对应的方式，处理属性映射和赋值了。

下面我们来看看方法的实现，本身逻辑不复杂，快速过一遍即可：

private boolean applyAutomaticMappings(ResultSetWrapper rsw, ResultMap resultMap, 
        MetaObject metaObject, String columnPrefix) throws SQLException {
    // 解析出需要自动映射的列
    List<UnMappedColumnAutoMapping> autoMapping = createAutomaticMappings(rsw, resultMap, metaObject, columnPrefix);
    boolean foundValues = false;
    if (!autoMapping.isEmpty()) {
        for (UnMappedColumnAutoMapping mapping : autoMapping) {
            // 使用TypeHandler从ResultSet中获取列的值
            final Object value = mapping.typeHandler.getResult(rsw.getResultSet(), mapping.column);
            if (value != null) {
                foundValues = true;
            }
            if (value != null || (configuration.isCallSettersOnNulls() && !mapping.primitive)) {
                // 利用反射设置属性值
                metaObject.setValue(mapping.property, value);
            }
        }
    }
    return foundValues;
}

哦，合着逻辑就是 “解析列 → 获取值 → 反射 set 值” ，一套连招完事啊，那逻辑确实简单。不过这里面有两个细节我们可以关注一下。

一个是自动映射的列，这个获取的依据是什么呢？

还记得上面封装 ResultSetWrapper 的时候，它在构造方法中获取了 ResultSet 的所有列名吗？这个地方获取的列名，会保存在一个属性名为 columnNames 的集合中。换言之，查询返回的结果集中有哪些列，这里需要自动映射的列就有哪些。

另一个小细节是 TypeHandler 获取值，它是怎么获取的呢？

很简单，MyBatis 本身是对原生 jdbc 进行的封装，所以底层肯定是操作 ResultSet 的方法了。我们以其中一个为例看一下：

final Object value = mapping.typeHandler.getResult(rsw.getResultSet(), mapping.column);

public T getResult(ResultSet rs, String columnName) throws SQLException {
    try {
        return getNullableResult(rs, columnName);
    } // catch ......
}

// StringTypeHandler
public String getNullableResult(ResultSet rs, String columnName) throws SQLException {
    // 此处操作ResultSet
    return rs.getString(columnName);
}

经过这个方法的处理后，如果结果集类型是用 resultType 封装的，那就大功告成了。

2.2.4.4.3 处理显式声明的属性映射

如果是使用 resultMap 呢？我们知道用 resultMap 声明的结果集，需要对属性的映射一一声明，也就是显式的声明。这个 applyPropertyMappings 方法就是对付这些 resultMap 映射的，方法比较长，各位只需要看其中标有注释的步骤即可：

private boolean applyPropertyMappings(ResultSetWrapper rsw, ResultMap resultMap, 
        MetaObject metaObject, ResultLoaderMap lazyLoader, String columnPrefix) throws SQLException {
    // 此处获取的是resultMap中定义的列，不是ResultSet返回的列
    final List<String> mappedColumnNames = rsw.getMappedColumnNames(resultMap, columnPrefix);
    boolean foundValues = false;
    // 获取resultMap中定义的所有映射关系(<id> <property>等)
    final List<ResultMapping> propertyMappings = resultMap.getPropertyResultMappings();
    for (ResultMapping propertyMapping : propertyMappings) {
        // 如果有声明columnPrefix，则拼接列名
        String column = prependPrefix(propertyMapping.getColumn(), columnPrefix);
        if (propertyMapping.getNestedResultMapId() != null) {
            // the user added a column attribute to a nested result map, ignore it
            column = null;
        }
        if (propertyMapping.isCompositeResult()
            || (column != null && mappedColumnNames.contains(column.toUpperCase(Locale.ENGLISH)))
            || propertyMapping.getResultSet() != null) {
            // 从ResultSet中取值
            Object value = getPropertyMappingValue(rsw.getResultSet(), metaObject, propertyMapping, lazyLoader, columnPrefix);
            // 看看这个值要设置到哪个属性中
            final String property = propertyMapping.getProperty();
            if (property == null) {
                continue;
            } else if (value == DEFERRED) {
                foundValues = true;
                continue;
            }
            if (value != null) {
                foundValues = true;
            }
            if (value != null || (configuration.isCallSettersOnNulls() && !metaObject.getSetterType(property).isPrimitive())) {
                // 反射设置属性值
                metaObject.setValue(property, value);
            }
        }
    }
    return foundValues;
}

可以看到，这个处理的大体思路，跟处理 resultType 的基本相仿呀，都是获取属性 → 从 ResultSet 中取值 → 反射设置值。

经过这一大串的处理后，一行数据就全部封装好了。

2.2.4.5 映射后的对象放入集合额

一行数据封装完成后，下一步自然是放入即将返回的集合中。这个处理本身难度不高，但是有点绕，小伙伴们集中注意力哦。

private void storeObject(ResultHandler<?> resultHandler, DefaultResultContext<Object> resultContext, 
        Object rowValue, ResultMapping parentMapping, ResultSet rs) throws SQLException {
    if (parentMapping != null) {
        // 存储过程的情况才会出现，不管
        linkToParents(rs, parentMapping, rowValue);
    } else {
        // 这才是我们要关注的
        callResultHandler(resultHandler, resultContext, rowValue);
    }
}

private void callResultHandler(ResultHandler<?> resultHandler, DefaultResultContext<Object> resultContext, Object rowValue) {
    resultContext.nextResultObject(rowValue);
    ((ResultHandler<Object>) resultHandler).handleResult(resultContext);
}

storeObject 方法往下调用到 callResultHandler 方法中，这个方法有两个动作，小心这个绕过来绕过去的动作哈。

首先是 nextResultObject ，它会将本次封装好的一行数据存入 ResultContext 中，并且给下标索引 + 1 ：

public void nextResultObject(T resultObject) {
    resultCount++;
    this.resultObject = resultObject;
}

存入 resultObject 还可以理解，这个下标 + 1 的用意为何呢？

别忘了，MyBatis 有个内存分页，比方说我只想查 10 条，那这个下标索引到 10 的时候，你 ResultSet 后面有再多的数据，对不起我不管了，我走了。所以这个地方的索引值是为了内存分页。

至于后面的 ResultHandler.handleResult 方法，那就更简单了，它就是往 List 中放入一个对象：

public void handleResult(ResultContext<?> context) {
    list.add(context.getResultObject());
}

如此循环，处理完毕后，结果集的封装也就基本完成了。

2.3 决定返回的元素类型

最后的最后，还有一个小小的动作：

private List<Object> collapseSingleResultList(List<Object> multipleResults) {
    return multipleResults.size() == 1 ? (List<Object>) multipleResults.get(0) : multipleResults;
}

诶？这是为何呢？为什么还要检查一下 multipleResults 的集合大小呢？是这样，MyBatis 本身支持对存储过程的处理，这个 multipleResults 本身就是考虑到可能一个存储过程中会返回多个结果集，所以这里有一个兜底处理，如果返回的结果集封装不止一个，那就说明我们走存储过程了。这个描述比较抽象，我们可以用一个很简单的图来解释一下：

img

一般情况下我们调用单次的查询，返回的都是这样一个家伙，但是我们根本不需要外层的那个 List ，所以 MyBatis 会在最后帮我们判断一下这个 multipleResults 集合的大小，如果只有一个 List ，那就直接扒出内层的返回给我们，完事。

经过漫长的处理，终于结果集的封装和映射的逻辑也走完了，一次完整的查询动作也就结束了。