上一章，我们把动态 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 至此时，可以发现它特别简陋：
阿这？底下的好多属性都是空的，就保存了一个 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 如下：
好家伙，这可真全啊，要映射的属性、列名，以及封装的一个一个 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 发现并没有：
为什么没有呢？一路向上爬，最终发现是我们调用 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 本身就是考虑到可能一个存储过程中会返回多个结果集，所以这里有一个兜底处理，如果返回的结果集封装不止一个，那就说明我们走存储过程了。这个描述比较抽象，我们可以用一个很简单的图来解释一下：
一般情况下我们调用单次的查询，返回的都是这样一个家伙，但是我们根本不需要外层的那个 List ，所以 MyBatis 会在最后帮我们判断一下这个 multipleResults 集合的大小，如果只有一个 List ，那就直接扒出内层的返回给我们，完事。
经过漫长的处理，终于结果集的封装和映射的逻辑也走完了，一次完整的查询动作也就结束了。
