Hibernate延迟加载
Hibernate中的取策略延迟加载(翻译hibernate官方文挡19章部分内容)
Fetching strategies(取策略)
Fetching stategies是指hibernate在需要关联数据的时候所采用的取关联数据的策略。这个策略既可以在O/R映射文件里配，也可以通过特殊的HQL:或Criteria语句实现。
Hibernate定义了以下取策略：
- Join fetching : Hibernate取关联数据或集合是通过OUTER JOIN的方式，通过同一条select 语句来实现。
Select fetching:在没有指定了lazy = "false"（既延迟加载有效）的情况下，通过另一条select 语句来获得与已经获得的实体相关的实体或集合。当然这种情况发生在用户真正要获得关联对象的时候。 - Subselect fetching:在没有指定了lazy = "false"（既延迟加载有效）的情况下，先通过一条查询语句获得了一个实体集， 然后对这个实体集中的每一个对象通过另一条select 语句来获得与它相关的实体或集合。当然这种情况发生在用户真正要获得关联对象的时候。
- Batch fetching ：它是为查询数据提供的一种优化策略。通过指定主键或外键的列表的方式来实现一条select 语句获得一批实体或集合。
从另一个角度来看，hibernate的fetching 分成以下几种。
- Immediate fetching: 如果实体已经被加载了，他的关联对象，关联集合，属性也要及时加栽。
lazy collection fetching: 只有应用程序真正使用这个集合的时候，才加栽这个集合。 - "Extra-lazy" collection fetching : hibernate 不加载一个集合的所有对象到内存里，需要哪个个体，加载哪个。
- Proxy fetching :当前对象的单值相关对象只有在调用它的主键外的其他属性的get方法时才加载它。
"NO-proxy"fetching :当前对象的单值相关对象在它的实体变量被访问的时候就被加载。相对于Proxy fetching来说，Proxy fetching更延迟。（因为"NO-proxy"fetching即使是访问关联对象的主健，关联对象都要被加载）。"NO-proxy"fetching对于应用来说更条理清晰。因为在应用中没有一个可见的proxy.
个人认为可以这样理解上述情况，假如在数据库中存在两张表 A,B.表A中有一个指向表B主健的外键。如果想知道A表中的某条数据对应B表中的那条记录的主键。完全不用访问B表，A表中的此条数据的外键值就是B表中对应数据的主键。所有只有访问B表中对应数据的主键外其他属性时，才需要加载B表中的这条数据。
- Lazy attribute fetching ：当前对象的某个属性或单值相关对象只有在与它对应的实体变量被访问的时候才加载。
Working with lazy associations
默认的情况下，Hibernate3 在获取关联对象集合的时候使用的是lazy策略，获得单值关联对象的时候使用的是lazy proxy策略。这样的策略几乎适用所有的应用。如果你设置了hibernate.default_batch_fetch_size,Hibernate就会通过批量获取来优化lazy fetching. lazy fetching 会引起一个问题。就是关闭了hibernate session以后加载延迟加载的对象。这样会引起异常。如下：
s = sessions.openSession();
Transaction tx = s.beginTransaction();
User u = (User) s.createQuery("from User u where u.name=:userName")
.setString("userName", userName).uniqueResult();
Map permissions = u.getPermissions();
tx.commit();
s.close();
Integer accessLevel = (Integer) permissions.get("accounts"); // Error!
由于在session被关闭之前，permissions 没有被初始化，所以它的数据没有被加载。hibernate不支持已经被分离的对象的延迟加载。修改的方法是把相关代码移到tx.commit()之前。
或者我们可以在配置文件里通过在关联对象那里指定 lazy="false"来使关联集合或对象不被延迟加载。但是如果你定义太多的非延迟加载对象，hibernate 在一次事务中可以需要把整个数据库加载到内存中。
从另一个角度来说，在一次事务中，我们经常使用joint fetching 这种方式（它天生就不是延迟加载）来代替select fetching 这种方式。
下边我们就要看到怎么自定义取策略。在hibernate3中,单值和集合关联对象的取策略的指定方式是一致的。
Tuning fetch strategies
默认的select fetching 这种取策略很容器导致N+1次select 操作这样的问题。所以我们可以在配置文件里指定join fetching 策略。如下：
Cat对应的配置文件：
<set name="permissions" fetch="join"> <key column="userId"/> <one-to-many class="Permission"/> </set>
Permission对应的配置文件：
<many-to-one name="mother" class="Cat" fetch="join"/>
在映射文件里定义的取策略会影响如下操作：
- 由 get() 或load()执行的取操作。
- 操作关联对象而引发的取操作。
- Criteria查询。
如果使用了subselect 这种取策略还会影响HQL这种查询方式。
一般来说，我们不是通过在映射配置文件自定义取策略，而是通过在一个事务里，通过在特定的HQL里使用 left join 来覆盖默认的取策略。对于Criteria 来说，提供了setFetchMode(FetchMode.JOIN) API.如下：
User user = (User) session.createCriteria(User.class)
.setFetchMode("permissions", FetchMode.JOIN)
.add( Restrictions.idEq(userId) )
.uniqueResult();
另一种完全不同的避免N+1次selects 的方式是使用second-level cache.
Single-ended association proxies
集合的延迟加载是通过Hibernate自己的持久化集合实现的,但是对于单个相关对象的延迟加载需要一个不同的机制.相关的对象必须被代理.Hibernate 对持久化对象的代理的延迟加载是通过对运行时字节的动态注入实现的(通过CGLIB实现). 默认的情况下,Hibernate3为所有的持久化类生成代理,通过这些代理来完成 many-to-one 和one-to-one 关联对象的延迟加载.
在映射文件中可以为类声明一个接口做为它的代理接口,通过proxy属性指定。实际上,hibernate真正代理的是
这个类的子类。需要注意的是，被代理的类必须实现一个默认的构造函数（此构造函数的范围至少是包内可见的）。
推荐所有的持久化类使用这种构造函数。我们现在可以看到的是在类的多态的时候会采用这种方式：
<class name="Cat" proxy="Cat"> ...... <subclass name="DomesticCat"> ..... </subclass> </class>
首先要注意的是，Cat的实例不能当作DomesticCat实例使用。即使Cat和DomesticCat对应的是同一条数据。
Cat cat = (Cat) session.load(Cat.class, id); // instantiate a proxy (does not hit the db)
if ( cat.isDomesticCat() ) { // hit the db to initialize the proxy
DomesticCat dc = (DomesticCat) cat; // Error!
....
}
其次，两者之间不能使用==
Cat cat = (Cat) session.load(Cat.class, id); // instantiate a Cat proxy DomesticCat dc = (DomesticCat) session.load(DomesticCat.class, id); // acquire new DomesticCat proxy! System.out.println(cat==dc);
实际情况并非如我们看到的那么糟糕。即使我们引用了两个不同的代理对象，实际的对象却是相同的。
cat.setWeight(11.0); // hit the db to initialize the proxy System.out.println( dc.getWeight() ); // 11.0
还需注意的是如果一个类是final class,或者它有final方法。我们就不能使用CGLIB代理.
最后，如果你的持久化对象在实例化的过程中获得的任何资源(例如 在initializers或者默认的构造函数里),这些资源也将被proxy获得.实际上代理的是这个类的子类。
这些问题的根源是java不能多重继承.如果你想避免这些问题,你应该让每一个类(子类和父类)实现一个声明了业务方法的接口.
在你的映射文件中指定这些接口,如下:
<class name="CatImpl" proxy="Cat"> ...... <subclass name="DomesticCatImpl" proxy="DomesticCat"> ..... </subclass> </class>
CatImpl实现了接口Cat,DomesticCatImpl实现了接口DomesticCat.Cat和DomesticCat实例的代理可以
被load()或iterator()方法返回.(list()方法一般不返回代理).
Cat cat = (Cat) session.load(CatImpl.class, catid);
Iterator iter = session.iterate("from CatImpl as cat where cat.name='fritz'");
Cat fritz = (Cat) iter.next();
关系也被延迟加载.这意味这你必须在Cat中声明所有的属性，而不仅仅是CatImpl.
以下方法不需要代理的初始值。
equals() 此方法没有被覆盖的时候。
hashCode() 此方法没有被覆盖的时候。
主键对应的get方法。
Initializing collections and proxies
如果在session的外边访问一个没有初始化的集合或代理，会抛出一个LazyInitializationException异常。例如在分离的状态下（session 已经close的情况下）访问一个实体的延迟加载的集合或代理对象。
有时候我们需要在session关闭之前确保一个代理或集合被初始化。当然我们可以通过cat.getSex()或cat.getKittents().size()这种方式来强迫初始化。但是这样会使代码阅读者迷茫而且不是一种通用的方便的编码格式。
静态方法Hibernate.initialize() 和Hibernate.isInitialized()为应用提供了处理延迟加载集合或代理的一种便捷方式。
Hibernate.initialize(Cat) 会强制加载代理 cat. Hibernate.initialize(cat.getKittens())初始化kittens集合。当然这些方法要在session关闭之前执行。
另一种方式是在所有需要的集合和代理对象都被加载之后再关闭session. 在一些应用中，尤其是当应用使用hibernate来获取数据，却在其他的应用层处理这些数据。或是这些数据是在其他的处理过程中使用。为了确保这些集合在初始化的时候session
还处于打开状态，可以通过以下两种方式：
1 基于 web 的应用可以通过filter 在一次请求的最后关闭session.当然这样做是基于你的应用可以正确处理异常。非常重要的一点是要确保把信息返回给用户之前把事务结束和把session关掉，即使是在你的页面处理发生异常的情况下。
2 如果你的应用有一个单独的业务层。在业务逻辑这里要保证在返回给web 层信息之前完成所有的集合初始化工作。这意味着你的业务层需要加载所有的数据并且把这些包括延迟加载的数据传给与一个特定的用户请求的相关呈现部分。一般来说这是通过在session关闭之前针对相关的集合调用Hibernate.initialize()方法或者是采用Criteria 的FetchMode.JOIN 方式。采用命令模式往往比采用session Facade容易一些。
3 你也可以在访问没有初试化的集合（或代理）之前把先前加载的一个对象通过merge()或lock()放到新的Session里。但是hibernate 不会也不应该自动完成这样的工作，因为这样需要使用特殊的事务处理语法。
有时候，你需要获得集合中数据的个数，或者集合数据的一部分就不需要初始化整个集合。你可以通过Collection filter来获得集合中数据的个数（不需要初始化整个集合）
( (Integer) s.createFilter( collection, "select count(*)" ).list().get(0) ).intValue()。
当然Collection filter也可以获取集合的一部分数据
s.createFilter( lazyCollection, "").setFirstResult(0).setMaxResults(10).list();
Using batch fetching
批量获取数据可以提高Hibernate的效率.批量获取是延迟select fetching策略的一种优化.我们可以对类或者集合两个角度采用批量取数据.
批量获取类/实体容易理解，假设有如下情况：
在你的session里加载了25个Cat实例。每一个Cat都有一个own的引用指向一个person.在这里这个关联的person是通过代理的方式延迟加载（单值关联对象）。如果你现在要通过循环调用所有cat的getOwner()方法。hibernate会默认的执行25个select 语句来获得被代理的owner对象。
我们可以通过在Person这个表的映射文件中指定batch-size来实现批量取数据。
<class name="Person" batch-size="10">...</class>
Hibernate 现在会执行三条查询语句来完成查询，模式是10,10,5.
你也可以对集合进行批量取操作.例如,每一个person都有一个被延迟加载的集合Cats.现在在session中已经加载了10个 person实例.循环调用所有的person的getCats()方法会产生10条select 语句.如果你在person的映射文件中定义了批量获取模式:
<class name="Person"> <set name="cats" batch-size="3"> ... </set> </class>
通过设置batch-size设为3，Hibernate 会以3,3,3,1的模式通过四条select语句加载集合。
Using subselect fetching
如果要加载一个延迟加载的集合或一个单值的代理，Hibernate通过一个subselect 运行原来的查询语句，这种情况和batch-fetching是异曲同工的。
Using lazy property fetching
Hibernate支持对单个属性的延迟加载。这个优化技术也被 称为fetch groups. 需要注意的是，这个技术还处于推销阶段。因为在实际中，对行的读取优化比对列的优化更重要。然而在一些特殊情况下，加载一个类的部分属性还是有必要的，比如一个继承的表有几百列而且数据模型还不能改变。
为了使某个属性被延迟加载，只需要在这个属性的影射文件中加上lazy属性即可。
<class name="Document"> <id name="id"> <generator class="native"/> </id> <property name="name" not-null="true" length="50"/> <property name="summary" not-null="true" length="200" lazy="true"/> <property name="text" not-null="true" length="2000" lazy="true"/> </class>
属性的延迟加载需要使用运行时的字节设备来处理。如果你的持久化类还没有被这个设备处理。hibernate 会忽略这个设置采用及时加载的方式。
要想使用此字节设备处理持久化类，使用如下的Ant 任务。
<target name="instrument" depends="compile">
<taskdef name="instrument" classname="org.hibernate.tool.instrument.InstrumentTask">
<classpath path="${jar.path}"/>
<classpath path="${classes.dir}"/>
<classpath refid="lib.class.path"/>
</taskdef>
<instrument verbose="true">
<fileset dir="${testclasses.dir}/org/hibernate/auction/model">
<include name="*.class"/>
</fileset>
</instrument>
</target>
另一种避免加载不需要的列的方式，至少在只读事务中，是通过使用HQL或Criteria查询属性。这样可以避免使用字节
处理工具。
你可以通过在HQL指定fetch all properties 来加载全部属性。