Hibernate延迟加载你真正会了吗?
之所以用Hibernate框架,肯定是有化点。Hibernate上手容易，用好难。就拿我们最近一个项目来说吧，其中有两个配置文件中lazy设成false，这也许是同事为了不让报初始化异常而改的。当时信息量不是很大，看不出什么大的问题。但是最这段时间，客户打电话过来说经常down机，前几天过去帮他们做了一下性能测试，发没这个罪魁祸首就是这个lazy="false"，还有一个就是属性延迟加载没有起作用。当是时以为将属性节点中的lazy="true"就可以啦，后来一看官方文档，还要对class进行字节码增强。
下面就来具体探讨一下实体对象延迟加载，属性延迟加载，单值延迟加载，集全延迟加载四个方面
实体对象延迟加载
其实就是只类延迟加载
如果想对实体对象使用延迟加载，必须要在实体的映射配置文件中进行相应的配置，如下所示：
<hibernate-mapping>
<class name=”com.itdcl.pojo.Schedule” table=”schedule” lazy=”true”>
……
</class>
</hibernate-mapping>通过将class的lazy属性设置为true，来开启实体的延迟加载特性。如果我们运行下面的代码：
Scheduleschedule=(Schedule)session.load(Schedule.class,”1”);（1）
System.out.println(schedule.getName());（2）
当运行到(1)处时，Hibernate并没有发起对数据的查询，如果我们此时通过一些调试工具(比如JBuilder2005的Debug工具)，观察此时user对象的内存快照，我们会惊奇的发现，此时返回的可能是Schedule$EnhancerByCGLIB$$bede8986类型的对象，而且其属性为null,这是怎么回事？还记得前面我曾讲过session.load()方法，会返回实体对象的代理类对象，这里所返回的对象类型就是User对象的代理类对象。在Hibernate中通过使用CGLIB,来实现动态构造一个目标对象的代理类对象，并且在代理类对象中包含目标对象的所有属性和方法，而且所有属性均被赋值为null。通过调试器显示的内存快照，我们可以看出此时真正的Schedule对象，是包含在代理对象的CGLIB$CALBACK_0.target属性中，当代码运行到（2）处时，此时调用schedule.getName()方法，这时通过CGLIB赋予的回调机制，实际上调用CGLIB$CALBACK_0.getName()方法，当调用该方法时，Hibernate会首先检查CGLIB$CALBACK_0.target属性是否为null，如果不为空，则调用目标对象的getName方法，如果为空，则会发起数据库查询，生成类似这样的SQL语句：select*fromSchedulewhereid=’1’;来查询数据，并构造目标对象，并且将它赋值到CGLIB$CALBACK_0.target属性中。
这样，通过一个中间代理对象，Hibernate实现了实体的延迟加载，只有当用户真正发起获得实体对象属性的动作时，才真正会发起数据库查询操作。所以实体的延迟加载是用通过中间代理类完成的，所以只有session.load()方法才会利用实体延迟加载，因为只有session.load()方法才会返回实体类的代理类对象。
属性延迟加载
属性延迟加载用得很少，但是用延迟加载时别忘记进行字节码增强
Hibernate3开始增加了通过property节点的lazy属性，为特定的属性指定延迟加载策略，以避免实体整体加载可能带来的性能浪费，尤其是像长文本之类的大字段。那么实现属性延迟加载需要做两件事：
1.修改映射配置文件，将需要延迟加载的字段增加lazy属性并设置成true;
2.与实体和集合类型的延迟加载不同，Hibernate3属性延迟加载机制在配置外，还需要用类增强器对二进制Class文件进行强化处理（借助ANT）
下面来演示下如何用ANT调用Hibernate类增强器对class文件进行强化处理.
1.下载ANT，配置ANT环境；（如果有Eclipse，直接就可以用它的ant）；
2.新建ANT的build.xml脚本；
<?xml version="1.0" encoding="UTF-8"?>
<project name="hibernatelazy" default="instrument" basedir=".">
<property name="lib.dir" value="./lib"/>
<property name="classes.dir" value="./classes"/>
<path id="lib.class.path">
<fileset dir="${lib.dir}">
<include name="**/*.jar"/>
</fileset>
</path>
<target name="instrument">
<taskdef name="instrument" classname="org.hibernate.tool.instrument.InstrumentTask">
<classpath path="${classes.dir}"/>
<classpath refid="lib.class.path"/>
</taskdef>
<instrument verbose="true">
<fileset dir="${classes.dir}/com/derek/known/hbm">
<include name="Knownquestions.class"/>
</fileset>
</instrument>
</target>
</project>其中注意
<propertyname="lib.dir"value="./lib"/>所需的JAR文件路径
propertyname="classes.dir"value="./classes"/>编译输出路径
单值延迟加载
也就是many-to-manyone-to-onemany-to-one，延迟加载是默认，默认值是产生一个代理对象，结合抓取策略进行性能调优。下面看看fetch的作用及用法。
Fetchingstrategies(取策略)
Fetchingstategies是指hibernate在需要关联数据的时候所采用的取关联数据的策略。这个策略既可以在O/R映射文件里配，也可以通过特殊的HQL:或Criteria语句实现。
Hibernate定义了以下取策略：
Joinfetching:Hibernate取关联数据或集合是通过OUTERJOIN的方式，通过同一条select语句来实现。
Selectfetching:在没有指定了lazy="false"（既延迟加载有效）的情况下，通过另一条select语句来获得与已经获得的实体相关的实体或集合。当然
这种情况发生在用户真正要获得关联对象的时候。
Subselectfetching:在没有指定了lazy="false"（既延迟加载有效）的情况下，先通过一条查询语句获得了一个实体集，然后对这个实体集中的每一个对象通过另一条select语句来获得与它相关的实体或集合。
当然这种情况发生在用户真正要获得关联对象的时候。
Batchfetching：它是为查询数据提供的一种优化策略。通过指定主键或外键的列表的方式来实现一条select语句获得一批实体或集合。
从另一个角度来看，hibernate的fetching分成以下几种。
Immediatefetching:如果实体已经被加载了，他的关联对象，关联集合，属性也要及时加载。
lazycollectionfetching:只有应用程序真正使用这个集合的时候，才加栽这个集合。
"Extra-lazy"collectionfetching:hibernate不加载一个集合的所有对象到内存里，需要哪个个体，加载哪个。
Proxyfetching:当前对象的单值相关对象只有在调用它的主键外的其他属性的get方法时才加载它。
"NO-proxy"fetching:当前对象的单值相关对象在它的实体变量被访问的时候就被加载。相对于Proxyfetching来说，Proxyfetching更延迟。
（因为"NO-proxy"fetching即使是访问关联对象的主健，关联对象都要被加载）。"NO-proxy"fetching对于应用来说更条理清晰。因为在应用中没有一个可见的proxy.
个人认为可以这样理解上述情况，假如在数据库中存在两张表 A,B.表A中有一个指向表B主健的外键。如果想知道A表中的某条
数据对应B表中的那条记录的主键。完全不用访问B表，A表中的此条数据的外键值就是B表中对应数据的主键。所有只有访问B表中
对应数据的主键外其他属性时，才需要加载B表中的这条数据。
Lazyattributefetching：当前对象的某个属性或单值相关对象只有在与它对应的实体变量被访问的时候才加载。
Workingwithlazyassociations
默认的情况下，Hibernate3在获取关联对象集合的时候使用的是lazy策略，获得单值关联对象的时候使用的是lazyproxy策略。这样的策略
几乎适用所有的应用。
如果你设置了hibernate.default_batch_fetch_size,Hibernate就会通过批量获取来优化lazyfetching.
lazyfetching会引起一个问题。就是关闭了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在一次事务中可以需要把整个数据库加载到内存中。
从另一个角度来说，在一次事务中，我们经常使用jointfetching这种方式（它天生就不是延迟加载）来代替selectfetching这种方式。
下边我们就要看到怎么自定义取策略。在hibernate3中,单值和集合关联对象的取策略的指定方式是一致的。
Tuningfetchstrategies
默认的selectfetching这种取策略很容器导致N+1次select操作这样的问题。所以我们可以在配置文件里指定joinfetching策略。如下：
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里使用leftjoin来覆盖默认的取
策略。对于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-levelcache.
Single-endedassociationproxies
集合的延迟加载是通过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);//hitthedbtoinitializetheproxy
System.out.println(dc.getWeight());//11.0
还需注意的是如果一个类是finalclass,或者它有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方法。
Initializingcollectionsandproxies
如果在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关掉，即使是在你的页面处理发生异常的情况下。(spring的OpenSessionInViewFilter就是基于此开发出来的)
2如果你的应用有一个单独的业务层。在业务逻辑这里要保证在返回给web层信息之前完成所有的集合初始化工作。这意味着你的
业务层需要加载所有的数据并且把这些包括延迟加载的数据传给与一个特定的用户请求的相关呈现部分。一般来说这是通过在session
关闭之前针对相关的集合调用Hibernate.initialize()方法或者是采用Criteria的FetchMode.JOIN方式。采用命令模式往往比采用session
Facade容易一些。
3你也可以在访问没有初试化的集合（或代理）之前把先前加载的一个对象通过merge()或lock()放到新的Session里。但是hibernate不
会也不应该自动完成这样的工作，因为这样需要使用特殊的事务处理语法。
有时候，你需要获得集合中数据的个数，或者集合数据的一部分就不需要初始话整个集合。你可以通过Collectionfilter来获得集合中数据
的个数（不需要初始化整个集合）
((Integer)s.createFilter(collection,"selectcount(*)").list().get(0)).intValue()。
当然Collectionfilter也可以获取集合的一部分数据
s.createFilter(lazyCollection,"").setFirstResult(0).setMaxResults(10).list();
Usingbatchfetching
批量获取数据可以提高Hibernate的效率.批量获取是延迟selectfetching策略的一种优化.我们可以对类或者集合两个角度采用批量取数据.
批量获取类/实体容易理解，假设有如下情况：
在你的session里加载了25个Cat实例。每一个Cat都有一个own的引用指向一个person.在这里这个关联的person是通过代理的方式延迟加载
（单值关联对象）。如果你现在要通过循环调用所有cat的getOwner()方法。hibernate会默认的执行25个select语句来获得被代理的owner对象。
我们可以通过在Person这个表的映射文件中指定batch-size来实现批量取数据。
<classname="Person"batch-size="10">...</class>
Hibernate现在会执行三条查询语句来完成查询，模式是10,10,5.
你也可以对集合进行批量取操作.例如,每一个person都有一个被延迟加载的集合Cats.现在在session中已经加载了10个person实例.循环调用
所有的person的getCats()方法会产生10条select语句.如果你在person的映射文件中定义了批量获取模式:
<classname="Person">
<setname="cats"batch-size="3">
...
</set>
</class>
通过设置batch-size设为3，Hibernate会以3,3,3,1的模式通过四条select语句加载集合。
Usingsubselectfetching
如果要加载一个延迟加载的集合或一个单值的代理，Hibernate通过一个subselect运行原来的查询语句，这种情况和batch-fetching是异曲同工的。
Usinglazypropertyfetching
Hibernate支持对单个属性的延迟加载。这个优化技术也被称为fetchgroups.需要注意的是，这个技术还处于推销阶段。因为在实际中，对行的读取
优化比对列的优化更重要。然而在一些特殊情况下，加载一个类的部分属性还是有必要的，比如一个继承的表有几百列而且数据模型还不能改变。
为了使某个属性被延迟加载，只需要在这个属性的影射文件中加上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指定fetchallproperties来加载全部属性。
集合延迟加载
在Hibernate的延迟加载机制中，针对集合类型的应用，意义是最为重大的，因为这有可能使性能得到大幅度的提高，为此Hibernate进行了大量的努力，其中包括对JDKCollection的独立实现，我们在一对多关联中，定义的用来容纳关联对象的Set集合，并不是java.util.Set类型或其子类型，而是net.sf.hibernate.collection.Set类型，通过使用自定义集合类的实现，Hibernate实现了集合类型的延迟加载。为了对集合类型使用延迟加载，我们必须如下配置我们的实体类的关于关联的部分：
<hibernate-mapping>
<class name=”com.neusoft.entity.User” table=”user”>
…..
<set name=”addresses” table=”address” lazy=”true” inverse=”true”>
<key column=”user_id”/>
<one-to-many class=”com.neusoft.entity.Arrderss”/>
</set>
</class>
</hibernate-mapping>通过将<set>元素的lazy属性设置为true来开启集合类型的延迟加载特性。我们看下面的代码：
引用
引用
User user=(User)session.load(User.class,”1”);
Collection addset=user.getAddresses(); (1)
Iterator it=addset.iterator(); (2)
while(it.hasNext()){
Address address=(Address)it.next();
System.out.println(address.getAddress());
}当程序执行到(1)处时，这时并不会发起对关联数据的查询来加载关联数据，只有运行到(2)处时，真正的数据读取操作才会开始，这时Hibernate会根据缓存中符合条件的数据索引，来查找符合条件的实体对象。
这里我们引入了一个全新的概念——数据索引，下面我们首先将接一下什么是数据索引。在Hibernate中对集合类型进行缓存时，是分两部分进行缓存的，首先缓存集合中所有实体的id列表，然后缓存实体对象，这些实体对象的id列表，就是所谓的数据索引。当查找数据索引时，如果没有找到对应的数据索引，这时就会一条selectSQL的执行，获得符合条件的数据，并构造实体对象集合和数据索引，然后返回实体对象的集合，并且将实体对象和数据索引纳入Hibernate的缓存之中。另一方面，如果找到对应的数据索引，则从数据索引中取出id列表，然后根据id在缓存中查找对应的实体，如果找到就从缓存中返回，如果没有找到，在发起selectSQL查询。在这里我们看出了另外一个问题，这个问题可能会对性能产生影响，这就是集合类型的缓存策略。如果我们如下配置集合类型：
引用
<hibernate-mapping>
<class name=”com.neusoft.entity.User” table=”user”>
…..
<set name=”addresses” table=”address” lazy=”true” inverse=”true”>
<cache usage=”read-only”/>
<key column=”user_id”/>
<one-to-many class=”com.neusoft.entity.Arrderss”/>
</set>
</class>
</hibernate-mapping>这里我们应用了<cacheusage=”read-only”/>配置，如果采用这种策略来配置集合类型，Hibernate将只会对数据索引进行缓存，而不会对集合中的实体对象进行缓存。如上配置我们运行下面的代码：
User user=(User)session.load(User.class,”1”);
Collection addset=user.getAddresses();
Iterator it=addset.iterator();
while(it.hasNext()){
Address address=(Address)it.next();
System.out.println(address.getAddress());
}
System.out.println(“Second query……”);
User user2=(User)session.load(User.class,”1”);
Collection it2=user2.getAddresses();
while(it2.hasNext()){
Address address2=(Address)it2.next();
System.out.println(address2.getAddress());
}运行这段代码，会得到类似下面的输出：
Select * from user where id=’1’; Select * from address where user_id=’1’; Tianjin Dalian Second query…… Select * from address where id=’1’; Select * from address where id=’2’; Tianjin Dalian
我们看到，当第二次执行查询时，执行了两条对address表的查询操作，为什么会这样？这是因为当第一次加载实体后，根据集合类型缓存策略的配置，只对集合数据索引进行了缓存，而并没有对集合中的实体对象进行缓存，所以在第二次再次加载实体时，Hibernate找到了对应实体的数据索引，但是根据数据索引，却无法在缓存中找到对应的实体，所以Hibernate根据找到的数据索引发起了两条selectSQL的查询操作，这里造成了对性能的浪费，怎样才能避免这种情况呢？我们必须对集合类型中的实体也指定缓存策略，所以我们要如下对集合类型进行配置：
<hibernate-mapping>
<class name=”com.neusoft.entity.User” table=”user”>
…..
<set name=”addresses” table=”address” lazy=”true” inverse=”true”>
<cache usage=”read-write”/>
<key column=”user_id”/>
<one-to-many class=”com.neusoft.entity.Arrderss”/>
</set>
</class>
</hibernate-mapping>此时Hibernate会对集合类型中的实体也进行缓存，如果根据这个配置再次运行上面的代码，将会得到类似如下的输出：
Select*fromuserwhereid=’1’;
Select*fromaddresswhereuser_id=’1’;
Tianjin
Dalian
Secondquery……
Tianjin
Dalian
这时将不会再有根据数据索引进行查询的SQL语句，因为此时可以直接从缓存中获得集合类型中存放的实体对象。