懒加载&嵌套映射
前言：
基于动态代理实现懒加载，在使用过程中，如果会话关闭、跨线程、序列化等情况下，是否能够继续加载？
懒加载
懒加载是为改善，解析对象属性时大量的嵌套子查询的并发问题。设置懒加载后，只有在使用指定属性时才会加载，从而分散SQL请求。
<resultMap id="blogMap" type="blog" autoMapping="true">
<id column="id" property="id"></id>
<association property="comments" column="id" select="selectCommentsByBlog" fetchType="lazy"/>
</resultMap>
在嵌套子查询中指定 fetchType="lazy" 即可设置懒加载。在调用getComments时才会真正加载。此外调用："equals", "clone", "hashCode", "toString" 均会触发当前对象所有未执行的懒加载。通过设置全局参数aggressiveLazyLoading=true ，也可指定调用对象任意方法触发所有懒加载。
| 参数 | 描述 |
|---|---|
| lazyLoadingEnabled | 全局懒加载开关 默认false |
| aggressiveLazyLoading | 任意方法触发加载 默认false。 |
| fetchType | 加载方式 eager实时 lazy懒加载。默认eager |
set覆盖 &序列化
当调用setXXX方法手动设置属性之后，对应的属性懒加载将会被移除，不会覆盖手动设置的值。
当对象经过序列化和反序列化之后，默认不在支持懒加载。但如果在全局参数中设置了configurationFactory类，而且采用JAVA原生序列化是可以正常执行懒加载的。其原理是将懒加载所需参数以及配置一起进行序列化，反序列化后在通过configurationFactory获取configuration构建执行环境。
configurationFactory 是一个包含 getConfiguration 静态方法的类
public static class ConfigurationFactory { public static Configuration getConfiguration() { return configuration; } }
原理
通过对Bean的动态代理，重写所有属性的getXxx方法。在获取属性前先判断属性是否加载？然后加载之。
内部结构：
代理之后Bean会包含一个MethodHandler，内部在包含一个Map用于存放待执行懒加载，执行前懒加载前会移除。LoadPair用于针对反序列化的Bean准备执行环境。ResultLoader用于执行加载操作，执行前如果原执行器关闭会创建一个新的。
特定属性如果加载失败，不会在进行二次加载。
Bean代理过程
代理过程发生在结果集解析 交创建对象之后(DefaultResultSetHandler.createResultObject)，如果对应的属性设置了懒加载，则会通过ProxyFactory 创建代理对象，该对象继承自原对象,然后将对象的值全部拷贝到代理对像。并设置相应MethodHandler（原对象直接抛弃）
联合查询&嵌套映射
映射说明
映射是指返回的ResultSet列与Java Bean 属性之间的对应关系。通过ResultMapping进行映射描述，在用ResultMap封装成一个整体。映射分为简单映射与复合嵌套映射。
简单映射：即返回的结果集列与对象属性是1对1的关系，这种情况下ResultHandler 会依次遍历结果集中的行，并给每一行创建一个对象，然后在遍历结果集列填充至对象的映射属性。
嵌套映射：但很多时候对象结构， 是树级程现的。即对象中包含对象。与之对应映射也是这种嵌套结构。
在配置方式上可以直接配置子映射，也以引入外部映射和自动映射。共有两类嵌套结构分别是一对多 与多对多 。
关于映射的使用方式，官网有非常详细的文档。这里就不在赘述。接下来分析一下，嵌套映射结果集填充过程。
联合查询
有了映射之后如何获取结果？普通的单表查询是无法获取复合映射所需结果，这就必须用到联合查询。然后在将联合查询返回的数据列，拆分给不同的对象属性。1对1与1对多拆分和创建的方式是一样的。
1对1查询映射
select a.id,
a.title,
b.id as user_id,
b.name as user_name
from blog a
left join users b on a.author_id=b.id
where a.id = 1;
通过上述语句联合查询语句，可以得出下表中结果。结果中前两字段对应Blog，后两个字段对应User。然后在将User作为author属性填充至Blog对象。
上述两个例子中，每一行都会产生两个对象，一个Blog父对象，一个User子对象。
1对多查询
sql语句
select a.id,a.title, c.id as comment_id, c.body as comment_bodyfrom blog a left join comment c on a.id=c.blog_idwhere a.id = 1;
上述语句可得出三条结果，前两个字段对应Blog，后两个字段对应Comment(评论)。与1对1不同的是，三行指向的是同一Blog。因为它ID都是一样的。
上述结果中，相同的三行Blog将会创建一个Blog，同时分别创建三个不同的Comment组成一个集合，并填充至comments对象。
RowKey创建机制
在1对多的查询过程中，是基于RowKey来断定两行数据是否相同的 。RowKey一般基于。但有时并不会指定 这时将会采用其它映射字段创建RowKey具体规则如下：
结果集解析流程
*TODO:待补充源码地图*
这里直接采用1对多的情况进行解析，因为1对1就是1对多的简化版。查询的结果如下表：
其整个解析流程如下图：
流程说明：
所有映射流程的解析都是在DefaultResultSetHandler当中完成。主要方法如下：
handleRowValuesForNestedResultMap()
嵌套结果集解析入口，在这里会遍历结果集中所有行。并为每一行创建一个RowKey对象。然后调用getRowValue()获取解析结果对象。最后保存至ResultHandler中。
注：调用getRowValue前会基于RowKey获取已解析的对象，然后作为partialObject参数发给getRowValue
getRowValue()
该方法最终会基于当前行生成一个解析好对象。具体职责包括，1.创建对象、2.填充普通属性和3.填充嵌套属性。在解析嵌套属性时会以递归的方式在调用getRowValue获取子对象。最后一步4.基于RowKey 暂存当前解析对象。
如果partialObject参数不为空 只会执行 第3步。因为1、2已经执行过了。
applyNestedResultMappings()
解析并填充嵌套结果集映射，遍历所有嵌套映射,然后获取其嵌套ResultMap。接着创建RowKey 去获取暂存区的值。然后调用getRowValue 获取属性对象。最后填充至父对象。
如果通过RowKey能获取到属性对象，它还是会去调用getRowsValue，因为有可能属下还存在未解析的属性。
循环引用
两个对象之间互相引用即循环引用，如下图就是一个例子：
对应ResultMap如下：
这种情况会导致解析死循环吗？答案是不会。DefaultResultSetHandler 在解析复合映射之前都会在上下文中填充当前解析对象（使用resultMapId做为Key）。如果子属性又映射引用了父映射ID，就可以直接获取不需要在去解析父对象。具体流程如下：
具体代码：
