Hibernate关联映射关系下的延迟加载剖析讲述.docx

Hibernate关联映射关系下的延迟加载剖析 一对多模式下的普通延迟加载 当在一对多关联映射模式下，设置Dept类的映射文件的Set标签的lazy属性为true： Dept类的映射文件如下： 测试代码： 运行结果： 运行结果解释：既然开启了懒加载模式，那么在加载Dept对象的时候就只会查询DEPT表的数据，而与其关联的EMP表的数据则不会查询出来。懒加载模式就是为了查询到该查询的数据，避免无用数据一起被携带出来，提高性能，提高效率。 当在一对多关联映射模式下，设置Set标签的lazy属性为true： 配置文件和上同，现在需要使用迭代器Iterator来调用集合的iterator()方法进行访问集合操作： 测试代码： 运行结果： 运行结果解释：这里与上面的那种情况不同的是，这里在下方使用迭代器进行集合访问，当程序第一次访问此对象时（即调用iterator()、size()、isEmpty()或contains()方法时），就会初始化Dept对象引用的getEmps()属性的集合代理类的实例，从而取出Dept相关联的Emp对应的EMP表的内容，即结果中显示的两条SQL语句。 当在一对多关联映射模式下，设置Set标签的lazy属性为true： 配置文件和上同，现在需要使用Hibernate类的initialize()方法来显式的初始化Dept代理类的实例： 测试代码： 运行结果： 运行结果解释：此处与上面的情况差不多，只不过这里使用了另一种方式来初始化Dept代理类的实例。 之后比较一下这两种方式的最终结果： 当然，结果谁都能想到，完全一样，目的都是要初始化Dept对象的代理类的实例，查询出与其关联到的Emp对象的数据来。 一对多模式下的增强型延迟加载 当在一对多关联映射模式下，设置Dept类的映射文件的Set标签的lazy属性为extra： 此时，仅加载Dept类的对象： Dept类的映射文件如下： 测试代码： 运行结果： 运行结果解释：既然是增强型加载，那么一定兼容普通延迟加载，所以结果也可想而知，并无太大变化。都只查出了Dept类的对象，而关联对象并未查出。 当在一对多关联映射模式下，设置Dept类的映射文件的Set标签的lazy属性为extra： 此时，仅加载Dept类的对象： 映射文件与上同： 测试代码： 运行结果： 运行结果解释：第二段代码尝试调用Dept对象所引用的emps对象的集合时，触发了其初始化代理类实例的机制，查询出了Dept关联对象Emp对象的数据。 有人会问，普通懒加载和增强型懒加载到底有何不同呢？看到上面的结果都一样啊？关键来了，下面还是用上面的代码，现在仍在增强型懒加载模式下，加载类后调用一个size()方法，看看会如何？ 测试代码： 运行结果： 运行结果解释：看到当调用Dept对象所引用的emps集合属性的非iterator()方法后（这里调用的是集合的size()方法），并没有像上面一样查询出关联的数据，而是仅到关联对象的数据表中统计了一下元素总个数并返回给了程序。 所以： 增强型懒加载的特性就是当调用非迭代器方法时，他并不会查询出过多的关联表信息，比普通懒加载延迟的更多一些，比如在实际应用中，要统计（size()方法）、比较（contains()方法）、判断是否为空（isEmpty()方法）时，并不需要全部查出关联表的信息就可以完成操作。 可以理解为：增强型懒加载比普通懒加载的延迟加载程度更高一些。 多对一模式下的普通延迟加载 当在一对多关联映射模式下，设置Emp类的映射文件的 many-to-one标签的lazy属性为proxy： 此时，仅加载Emp类的对象： Emp类的映射文件如下（此时Emp为主动方）： 测试代码： 变量监视： 运行结果： 运行结果解释：在多对一模式下，加载Emp对象只会查询出Emp对象的信息，而与其关联的Dept对象并不会查出来。 当在一对多关联映射模式下，设置Emp类的映射文件的 many-to-one标签的lazy属性为no-proxy，表示无代理延迟加载： 此时，仅加载Emp类的对象： Emp类的映射文件同上： 测试代码： 运行结果： 多对一模式下的立即加载 当在一对多关联映射模式下，设置Emp类的映射文件的 many-to-one标签的lazy属性为false： 此时，仅加载Emp类的对象： Emp类的映射文件同上。 测试代码： 运行结果： 运行结果解释：此时禁用了任何延迟加载，所以当在加载Emp对象时就会将与其关联的Dept对象的数据一起查询出来。