第二种是开启全局的延迟加载。通过在Mybatis的配置文件的<settings>标签下加上如下配置可开启全局的延迟加载。开启了全局的延迟加载后我们就无需再在各个嵌套的子查询上配置延迟加载了，如果有某一个嵌套的子查询是不需要延迟加载的，可以设置其fetchType=”eager”。设置在嵌套查询上的fetchType可以覆盖全局的延迟加载设置。
1.2 分析
Mybatis的查询结果是由ResultSetHandler接口的handleResultSets()方法处理的。ResultSetHandler接口只有一个实现，DefaultResultSetHandler。有兴趣的朋友可以去看一下它的源码，看一下它是如何处理结果集的。对于本文的主题，延迟加载相关的一个核心的方法就是如下这个创建返回结果对象的方法。
在上面方法中我们可以看到Mybatis先是根据正常情况创建一个返回类型对应的对象。当我们的ResultMap是包含子查询的时候，其会在我们正常返回类型对象的基础上创建对应的代理对象。对，你没有看错，就是我们的直接结果是代理对象，而不是子查询对应的属性是代理对象。默认是基于JavassistProxyFactory类创建的代理对象。可以通过Mybatis的全局配置proxyFactory来更改，可选值是CGLIB和JAVASSIST，默认是后者。需要使用CGLIB代理时注意加入CGLIB的包。
回过头来看我们之前的那个延迟加载的配置，我们的一个查询返回的是SysWfProcess类型的对象，其有一个SysWfNode集合类型的nodes属性，nodes属性是通过一个子查询查出来的，而且是延迟加载。这个时候我们来进行以下测试。
这个时候你会发现，上面的测试代码的输出结果是一个代理类，而不是我们自己的com.elim.learn.mybatis.model.SysWfProcess类型。另外如果你启用了日志输出，并且是打印的DEBUG日志，你会看到Mybatis是发了两条SQL进行查询的。
但是如果我们把最后一个System.out.println()去掉，也就是说我们只是从数据库中查询出SysWfProcess对象，而不使用它的时候，通过查看日志输出你会发现Mybatis又只会发送一条SQL，即只是查询出SysWfProcess的信息。这是为什么呢？
1.3 aggressiveLazyLoading
这是因为当我们启用了延迟加载时，我们的查询结果返回的是一个代理对象，当我们访问该代理对象的方法时，都会触发加载所有的延迟加载的对象信息。这也就可以很好的解释上面的场景。但是如果是这样的设计，貌似Mybatis的延迟加载作用不大。但事实并非如此，这只是Mybatis的一个默认策略，我们可以通过Mybatis的全局配置aggressiveLazyLoading来改变它，默认是true，表示延迟加载时将在第一次访问代理对象的方法时就将全部的延迟加载对象加载出来。当设置为false时则会在我们第一次访问延迟加载的对象的时候才会从数据库加载对应的数据。注意在延迟对象未从数据库加载出来前，我们对应延迟对象的属性将是null，因为你没有对它赋值。
1.4 lazyLoadTriggerMethods
那如果我们设置了aggressiveLazyLoading=”false”，但又希望在调用某些方法之前把所有的延迟对象都从数据库加载出来，怎么办呢？这个时候我们可以通过lazyLoadTriggerMethods参数来指定需要加载延迟对象的方法调用。默认是equals、clone、hashCode和toString，也就是说我们在调用代理对象的这些方法之前就会把延迟加载对象从数据库加载出来。
Mybatis延迟加载生成的代理对象的代理过程，可以参考ProxyFactory的创建代理对象的过程，以下是基于Javassist创建的代理对象的代理过程，基于CGLIB的代理也是类似的。从下面的代码我们可以看到Mybatis的代理对象需要从数据库加载延迟对象时是在目标方法被调用以前发生的，这就可以保证我们的目标方法被调用时延迟加载的对象已经从数据库中加载出来了。
本文是介绍的都是基于<collection>这种关联，其实<association>关联的对象的延迟加载也是一样的，它们的默认策略也是一样的。
感谢阅读，希望能帮助到大家，谢谢大家对本站的支持！
