Hibernate延迟加载续

最新推荐文章于 2019-02-14 17:47:15 发布

longx_ok

最新推荐文章于 2019-02-14 17:47:15 发布

阅读量209

点赞数

分类专栏： Hibernate 文章标签： Hibernate延迟加载续

本文链接：https://blog.csdn.net/longx_ok/article/details/84523275

版权

Hibernate 专栏收录该内容

7 篇文章 0 订阅

订阅专栏

本文主要就Hibernate抓取策略加以分析，Hibernate抓取策略（fetching strategy）是指：当应用程序需要在（Hibernate实体对象图的）关联关系间进行导航的时候， Hibernate如何获取关联对象的策略。

抓取策略可以在O/R映射的元数据中声明，也可以在特定的HQL 或条件查询（Criteria Query）中重载声明。

如下几种Hibernate抓取策略：

◆连接抓取（Join fetching） - Hibernate通过在SELECT语句使用OUTER JOIN（外连接）来获得对象的关联实例或者关联集合。

◆查询抓取（Select fetching） - 另外发送一条 SELECT 语句抓取当前对象的关联实体或集合。除非你显式的指定lazy="false"禁止延迟抓取（lazy fetching），否则只有当你真正访问关联关系的时候，才会执行第二条select语句。

◆子查询抓取（Subselect fetching） - 另外发送一条SELECT 语句抓取在前面查询到（或者抓取到）的所有实体对象的关联集合。除非你显式的指定lazy="false" 禁止延迟抓取（lazy fetching），否则只有当你真正访问关联关系的时候，才会执行第二条select语句。

◆批量抓取（Batch fetching） - 对查询抓取的优化方案，通过指定一个主键或外键列表，Hibernate使用单条SELECT语句获取一批对象实例或集合。

Hibernate抓取策略会区分下列各种情况：

1.Immediate fetching，立即抓取 - 当宿主被加载时，关联、集合或属性被立即抓取。

2.Lazy collection fetching，延迟集合抓取- 直到应用程序对集合进行了一次操作时，集合才被抓取。（对集合而言这是默认行为。）

3."Extra-lazy" collection fetching,"Extra-lazy"集合抓取 -对集合类中的每个元素而言，都是直到需要时才去访问数据库。除非绝对必要，Hibernate不会试图去把整个集合都抓取到内存里来（适用于非常大的集合）。

4.Proxy fetching，代理抓取 - 对返回单值的关联而言，当其某个方法被调用，而非对其关键字进行get操作时才抓取。

5."No-proxy" fetching,非代理抓取 - 对返回单值的关联而言，当实例变量被访问的时候进行抓取。与上面的代理抓取相比，这种方法没有那么“延迟”得厉害(就算只访问标识符，也会导致关联抓取)但是更加透明，因为对应用程序来说，不再看到proxy。这种方法需要在编译期间进行字节码增强操作，因此很少需要用到。

6.Lazy attribute fetching，属性延迟加载 - 对属性或返回单值的关联而言，当其实例变量被访问的时候进行抓取。需要编译期字节码强化，因此这一方法很少是必要的。

这里有两个正交的概念：关联何时被抓取，以及被如何抓取（会采用什么样的SQL语句）。不要混淆它们！我们使用抓取来改善性能。我们使用延迟来定义一些契约，对某特定类的某个脱管的实例，知道有哪些数据是可以使用的。

1.操作延迟加载的关联

默认情况下，Hibernate 3对集合使用延迟select抓取，对返回单值的关联使用延迟代理抓取。对几乎是所有的应用而言，其绝大多数的关联，这种策略都是有效的。

注意:假若你设置了hibernate.default_batch_fetch_size,Hibernate会对延迟加载采取批量抓取优化措施（这种优化也可能会在更细化的级别打开）。

然而，你必须了解延迟抓取带来的一个问题。在一个打开的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关闭后，permessions集合将是未实例化的、不再可用，因此无法正常载入其状态。 Hibernate对脱管对象不支持延迟实例化. 这里的修改方法是：将permissions读取数据的代码移到tx.commit()之前。

除此之外，通过对关联映射指定lazy="false",我们也可以使用非延迟的集合或关联。但是，对绝大部分集合来说，更推荐使用延迟方式抓取数据。如果在你的对象模型中定义了太多的非延迟关联，Hibernate最终几乎需要在每个事务中载入整个数据库到内存中！

但是，另一方面，在一些特殊的事务中，我们也经常需要使用到连接抓取（它本身上就是非延迟的），以代替查询抓取。下面我们将会很快明白如何具体的定制Hibernate中的抓取策略。在Hibernate3中，具体选择哪种抓取策略的机制是和选择单值关联或集合关联相一致的。

2. 调整抓取策略（Tuning fetch strategies）

查询抓取（默认的）在N+1查询的情况下是极其脆弱的，因此我们可能会要求在映射文档中定义使用连接抓取：

<set name="permissions"
fetch="join">
<key column="userId"/>
<one-to-many class="Permission"/>
set
<many-to-one name="mother" class="Cat" fetch="join"/>

在映射文档中定义的抓取策略将会对以下列表条目产生影响：通过get()或load()方法取得数据。只有在关联之间进行导航时，才会隐式的取得数据。

条件查询，使用了subselect抓取的HQL查询

不管你使用哪种抓取策略，定义为非延迟的类图会被保证一定装载入内存。注意这可能意味着在一条HQL查询后紧跟着一系列的查询。

通常情况下，我们并不使用映射文档进行抓取策略的定制。更多的是，保持其默认值，然后在特定的事务中，使用HQL的左连接抓取（left join fetch）对其进行重载。这将通知 Hibernate在第一次查询中使用外部关联（outer join），直接得到其关联数据。在条件查询 API中，应该调用 setFetchMode(FetchMode.JOIN)语句。

也许你喜欢仅仅通过条件查询，就可以改变get() 或 load()语句中的数据抓取策略。例如：

User user = (User) session.createCriteria(User.class)
.setFetchMode("permissions", FetchMode.JOIN)
.add( Restrictions.idEq(userId) )
.uniqueResult();

（这就是其他ORM解决方案的“抓取计划(fetch plan)”在Hibernate中的等价物。）截然不同的一种避免N+1次查询的方法是，使用二级缓存。

学习Hibernate时，经常会遇到实体对象延迟加载问题，这里将介绍问题的解决方法Hibernate实现实体对象延迟加载。

延迟加载机制是为了避免一些无谓的性能开销而提出来的，所谓延迟加载就是当在真正需要数据的时候，才真正执行数据加载操作。在Hibernate中提供了对实体对象的延迟加载以及对集合的延迟加载，另外在Hibernate3中还提供了对属性的延迟加载。下面我们就分别介绍这些种类的延迟加载的细节。

Hibernate实现实体对象延迟加载：

如果想Hibernate实现实体对象延迟加载，必须要在实体的映射配置文件中进行相应的配置，如下所示：

<hibernate-mapping>
<classname=”com.neusoft.entity.User” table=”user” lazy=”true”>
……
</class>
</hibernate-mapping>

通过将class的lazy属性设置为true，来开启实体的延迟加载特性。如果我们运行下面的代码：

User user=(User)session.load(User.class,”1”);
System.out.println(user.getName());

当运行到第一条时，Hibernate并没有发起对数据的查询，如果我们此时通过一些调试工具(比如JBuilder2005的Debug工具)，观察此时user对象的内存快照，我们会惊奇的发现，此时返回的可能是 User$EnhancerByCGLIB$$bede8986类型的对象，而且其属性为null,这是怎么回事？还记得前面我曾讲过session.load()方法，会返回实体对象的代理类对象，这里所返回的对象类型就是User对象的代理类对象。在Hibernate中通过使用CGLIB,来实现动态构造一个目标对象的代理类对象，并且在代理类对象中包含目标对象的所有属性和方法，而且所有属性均被赋值为null。通过调试器显示的内存快照，我们可以看出此时真正的User对象，是包含在代理对象的CGLIB$CALBACK_0.target属性中，当代码运行到第二条时，此时调用user.getName()方法，这时通过CGLIB赋予的回调机制，实际上调用 CGLIB$CALBACK_0.getName()方法，当调用该方法时，Hibernate会首先检查CGLIB$CALBACK_0.target属性是否为null，如果不为空，则调用目标对象的getName方法，如果为空，则会发起数据库查询，生成类似这样的SQL语句：select * from user where id=’1’;来查询数据，并构造目标对象，并且将它赋值到 CGLIB$CALBACK_0.target属性中。

这样，通过一个中间代理对象，Hibernate实现实体对象延迟加载，只有当用户真正发起获得实体对象属性的动作时，才真正会发起数据库查询操作。所以实体的延迟加载是用通过中间代理类完成的，所以只有session.load()方法才会利用实体延迟加载，因为只有session.load()方法才会返回实体类的代理类对象。

为了避免在某些情况下，关联关系所带来的无谓的性能开销。

所谓延迟加载，就是在需要数据的时候，才真正执行数据加载操作。

Hibernate2中的延迟加载实现主要针对：
1．实体对象。
2．集合（Collection）。
Hibernate3同时提供了属性的延迟加载功能。
1. 实体对象的延迟加载

通过load方法可以指定可以返回目标实体对象的代理。

通过class的lazy属性，可以打开实体对象的延迟加载功能。（映射文件）

(Hibernate2中，lazy默认为false；Hibernate3默认true）

非延迟加载的例子：

 
         < 
         hibernate-mapping 
         > 
        
         < 
         class 
         name 
         = 
         "...TUser" 
        
         table 
         = 
         "t_user" 
        
         dynamic-update 
         = 
         "false" 
        
         dynamic-insert 
         = 
         "false" 
        
         select-before-update 
         = 
         "false" 
        
         optimistic-lock 
         = 
         "version" 
        
         lazy 
         = 
         "false" 
        
         > 
        
         ... 
        
         < 
         hibernate-mapping 
         >

 
    
         TUser user = (Tuser)session.load(TUser. 
         class 
         ,  
         new 
         Integer( 
         1 
         ));      ( 
         1 
         ) 
        
 
         System.out.println(user.getName());     ( 
         2 
         ) 
        
 
  

当程序运行到（1）时，Hibernate已经从库表中取出了对应的记录，并构造了一个完整的TUser对象。

对以上映射配置修改：
lazy=”true”
看代码运行至（1）后的user对象状态(Eclipse Debug视图)

可以看到，此时的user对象与我们之前定义的实体类并不相同，其当前类型描述为TUser$EnhancerByCGLIB$$bede8986,且其属性均为null。

同时观察屏幕日志，此时并没有任何Hibernate SQL输出，也就意味着，当我们获得user对象引用的时候，Hibernate并没有执行数据库查询操作。

代码运行至（2），再次观察user对象状态

看到user对象的name属性仍然是null，但是观察屏幕输出，看到查询操作已经执行，同时user.name属性也正确输出。

两次查询操作为什么会有这样的差异？
原因就在于Hibernate的代理机制。
Hibernate中引入了CGLib作为代理机制实现的基础。这也就是为什么我们会获得一个诸如TUser$EnhancerByCGLIB$$bede8986类型对象的缘由。
CGLib可以在运行期动态生成Java Class。这里的代理机制，其基本实现原理就是通过由CGLib构造一个包含目标对象所有属性和方法的动态对象（相当于动态构造目标对象的一个子类）返回，并以之作为中介，为目标对象提供更多的特性。
从内存快照可以看到，真正的TUser对象位于代理类的CGLIB$CALLBACK_0.target属性中。
当我们调用user.getName方法时，调用的实际上是CGLIB$CALLBACK_0.getName()方法，当方法调用后，它会首先检查CGLIB$CALLBACK_0.target中是否存在目标对象。
如果存在，则调用目标对象的getName方法返回，如果目标对象为空，则发起数据库查询指令，读取记录、构建目标对象并将其设入CGLIB$CALLBACK_0.target。
这样，通过一个中间代理，实现了数据延迟加载功能，只有当客户程序真正调用实体类的取值方法时，Hibernate才会执行数据库查询操作。
2. 集合类型的延迟加载

Hibernate延迟加载机制中，关于集合的延迟加载特性意义最为重大，也是实际应用中相当重要的一个环节。

如果我们只想要获得user的年龄（age）属性，而不关心user的地址信息(地址是集合类型)，那么自动加载address的特性就显得特别多余，并造成了极大的性能浪费。

将前面一对多关系中的lazy属性修改为true，即指定了关联对象采用延迟加载：

 
    
         < 
         hibernate-mapping 
         > 
        
 
          
         < 
         class 
         name 
         = 
         "" 
         table 
         = 
         "" 
         dynamic-update 
         = 
         "" 
        
 
          
         dynamic-insert 
         = 
         "" 
         > 
        
 
          
         ... 
        
 
          
         < 
         set 
         name 
         = 
         "addresses" 
         table 
         = 
         "t_address" 
        
 
          
         lazy 
         = 
         "true" 
         ...> 
        
 
         ... 
        
 
  

尝试执行以下代码：

 
         Criteria criteria = session.createCriteria(TUser. 
         class 
         ); 
        
         criteria.add(Expression.eq( 
         "name" 
         , 
         "Erica" 
         )); 
        
         List userList = criteria.list(); 
        
         Tuser user = (Tuser)userList.get( 
         0 
         ); 
        
         System.out.println( 
         "User Name=>" 
         +user.getName()); 
        
         Set hset = user.getAddresses(); 
        
         session.close(); 
         //关闭session 
        
         Taddress addr = (Taddress)hset.toArray()[ 
         0 
         ]; 
        
         System.out.println(addr.getAddress());

运行时抛出异常：
LazyInitializationException – failed to lazily initialize a collection – no session or session was closed
如果稍做调整，将session.close放在代码末尾，则不会发生这样的问题。
这意味着，只有我们实际加载user关联的address时，Hibernate才试图通过session从数据库中加载实际的数据集，而由于我们读取address之前已经关闭了session，所以出现了以上的错误。
这里有个问题，如果我们采用了延迟加载机制，但希望在一些情况下实现非延迟加载时的功能，也就是说，希望在session关闭后，仍然允许操作user的address属性。
Hibernate.initialize方法可以强制Hibernate立即加载关联对象集：

1

2

3

4

5

6

7

 
         Hibernate.initialize(user.getAddress()); 
        
         session.close(); 
        
         //通过Hibernate.initialize方法强制读取数据 
        
         //addresses对象即可脱离session进行操作 
        
         Set hset = user.getAddresses(); 
        
         Taddress addr = (Taddress)hset.toArray()[ 
         0 
         ]; 
        
System.out.println(addr.getAddress());

为了实现透明化的延迟加载机制，Hibernate进行了大量努力。其中包括JDK Collection接口的独立实现。

如果尝试用HashSet强行转化Hibernate返回的Set型对象：
Set hset = (HashSet)user.getAddresses();
就会在运行期得到一个java.lang.ClassCastException，实际上，此时返回的是一个Hibernate的特定Set实现“net.sf.hibernate.collection.Set”, 而非传统意义上的JDK Set实现。
这也正是为什么在编写POJO时，必须用JDK Collection Interface（如Set，Map），而非特定的JDK Collection实现类（如HashSet, HashMap)声明Colleciotn型属性的原因（如private Set addresses; 而非private HashSet addresses)。

当调用session.save(user);时，Hibernate如何处理其关联的Addresses对象集？

假设TUser定义如下：

 
         public 
         class 
         TUser  
         implements 
         Serializable{ 
        
         … 
        
         private 
         Set addresses =  
         new 
         HashSet(); 
        
         … 
        
         }

我们通过Set接口，声明了一个addresses属性，并创建了一个HashSet作为addresses的初始实例，以便创建TUser实例后，就可以为其添加关联的address对象：

 
         TUser user =  
         new 
         TUser(); 
        
         TAddress addr =  
         new 
         TAddress(); 
        
         addr.setAddress(“HongKong”); 
        
         user.getAddresses().add(addr); 
        
         session.save(user);

通过Eclipse的Debug视图，可以看到session.save方法执行前后user对象发生的变化：

首先，由于Insert操作，Hibernate获得数据库产生的id值，并填充到user对象的id属性。

另一方面，Hibernate使用了自己的Collection实现”net.sf.hibernate.collection.Set”对user中的HashSet型addresses属性进行了替换，并用数据对其进行填充，保证新的addresses与原有的addresses包含同样的实体元素。

再来看下面的代码：

 
         TUser user = (TUser)session.load(TUser. 
         class 
         ,  
         new 
         Integer( 
         1 
         )); 
        
         Collection addSet = user.getAddresses();( 
         1 
         ) 
        
         Iterator it = addSet.iterator();( 
         2 
         ) 
        
         while 
         (it.hasNext()){ 
        
         TAddress addr = (TAddress)it.next(); 
        
         System.out.println(addr.getAddresses()); 
        
         }

当代码执行到（1）处时，addresses数据集尚未读入，我们得到的addrSet对象实际上只是一个未包含任何数据的net.sf.hibernate.collection.Set实例。
代码运行至（2），真正的数据读取操作才开始执行。

观察一下net.sf.hibernate.collection.Set.iterator方法可以看到：

 
         public 
         Iterator iterator(){ 
        
         read(); 
        
         return 
         new 
         IteratorProxy(set.iterator()); 
        
         }

直到此时，真正的数据加载（read方法）才开始执行。
read方法将首先在缓存中查找是否有符合条件的数据索引。

这里注意数据索引的概念，Hibernate在对集合类型进行缓存时，分两部分保存，首先是这个集合中所有实体的id列表（也就是所谓的数据索引，对于这里的例子，数据索引中包含了所有userid=1的address对象的id清单），其次是各个实体对象。

【如果没有发现对应的数据索引】，则执行一条Select SQL（对于本例就是select…from t_address where user_id=?）获得所有符合条件的记录，接着构造实体对象和数据索引后返回。实体对象和数据索引也同时被分别纳入缓存。

【如果发现了对应的数据索引】，则从这个数据索引中取出所有id列表，并根据id列表依次从缓存中查询对应的address对象，如果找到，则以缓存中的数据返回，如果没找到当前id对应的数据，则执行相应的Select SQL获得对应的address记录（对于本例就是select…from t_address where user_id=?）。
这里引出另一个性能关注点，即关联对象的缓存策略。
如果我们为某个集合类设定了缓存，如：

 
         < 
         set 
        
         name 
         = 
         "addresses" 
        
         table 
         = 
         "t_address" 
        
         lazy 
         = 
         "true" 
        
         inverse 
         = 
         "true" 
        
         cascade 
         = 
         "all" 
        
         sort 
         = 
         "unsorted" 
        
         > 
        
         < 
         cache 
         usage 
         = 
         "read-only" 
         /> 
        
         < 
         key 
         column 
         = 
         "user_id" 
         /> 
        
         < 
         one-to-many 
         class 
         = 
         "…TAddress" 
         /> 
        
         </ 
         set 
         >

注意这里的<cache usage=”read-only”/>只会使得Hibernate对数据索引进行缓存，也就是说，这里的配置实际上只是缓存了集合中的数据索引，并不包括这个集合中的各个实体元素。

执行下面的代码：

 
         TUser user = (TUser)session.load(TUser. 
         class 
         ,  
         new 
         Integer( 
         1 
         )); 
        
         Collection addSet = user.getAddresses(); 
        
         //第一次加载user.addresses 
        
         Iterator it = addSet.iterator(); 
        
         while 
         (it.hasNext()){ 
        
         TAddress addr = (TAddress)it.next(); 
        
         System.out.println(addr.getAddresses()); 
        
         } 
        
         System.out.println( 
         "\n=== Second Query ===\n" 
         ); 
        
         TUser user2 = (TUser)session2.load(TUser. 
         class 
         ,  
         new 
         Integer( 
         1 
         )); 
        
         Collection addSet2 = user2.getAddress(); 
        
         //第二次加载user.addresses 
        
         Iterator it2 = addSet2.iterator(); 
        
         while 
         (it2.hasNext()){ 
        
         TAddress addr = (TAddress)it2.next(); 
        
         System.out.println(addr.getAddress()); 
        
         }

观察屏幕日志输出：

Hibernate: select tuser0_.id as id3_0_, tuser0_.name as name3_0_, tuser0_.age as age3_0_, tuser0_.group_id as group4_3_0_ from t_user3 tuser0_ where tuser0_.id=?
Hibernate: select addresses0_.user_id as user7_1_, addresses0_.id as id1_, addresses0_.id as id7_0_, addresses0_.address as address7_0_, addresses0_.zipcode as zipcode7_0_, addresses0_.tel as tel7_0_, addresses0_.type as type7_0_, addresses0_.idx as idx7_0_, addresses0_.user_id as user7_7_0_ from t_address addresses0_ where addresses0_.user_id=? order by addresses0_.zipcode asc
Hongkong
Hongkong

=== Second Query ===

Hibernate: select tuser0_.id as id3_0_, tuser0_.name as name3_0_, tuser0_.age as age3_0_, tuser0_.group_id as group4_3_0_ from t_user3 tuser0_ where tuser0_.id=?
Hibernate: select taddress0_.id as id7_0_, taddress0_.address as address7_0_, taddress0_.zipcode as zipcode7_0_, taddress0_.tel as tel7_0_, taddress0_.type as type7_0_, taddress0_.idx as idx7_0_, taddress0_.user_id as user7_7_0_ from t_address taddress0_ where taddress0_.id=?
Hibernate: select taddress0_.id as id7_0_, taddress0_.address as address7_0_, taddress0_.zipcode as zipcode7_0_, taddress0_.tel as tel7_0_, taddress0_.type as type7_0_, taddress0_.idx as idx7_0_, taddress0_.user_id as user7_7_0_ from t_address taddress0_ where taddress0_.id=?
Hongkong
Hongkong

看到，第二次获取关联的addresses集合的时候，执行了2次Select SQL。

正是由于<set…><cache usage=”read-only”/>…</set>的设定，第一次addresses集合被加载之后，数据索引已经被放入缓存。

第二次再加载addresses集合的时候，Hibernate在缓存中发现了这个数据索引，于是从索引里面取出当前所有的id（此时数据库中有3条符合的记录，所以共获得3个id），然后依次根据3个id在缓存中查找对应的实体对象，但是没有找到，于是发起了数据库查询，由Select SQL根据id从t_address表中读取记录。

由于缓存中数据索引的存在，似乎SQL执行的次数更多了，这导致第二次借助的数据查询比第一次性能开销更大。
导致这个问题出现的原因何在？
这是由于我们只为集合类型配置了缓存，这样Hibernate只会缓存数据索引，而不会将集合中的实体元素同时也纳入缓存。
我们必须为集合类型中的实体对象也指定缓存策略，如：

 
         < 
         hibernate-mapping 
         > 
        
         < 
         class 
        
         name 
         = 
         "…TAddress" 
        
         table 
         = 
         "t_address" 
        
         dynamic-update 
         = 
         "false" 
        
         dynamic-insert 
         = 
         "false" 
        
         select-before-update 
         = 
         "false" 
        
         optimistic-lock 
         = 
         "version" 
        
         > 
        
         < 
         cache 
         usage 
         = 
         "read-write" 
         /> 
        
         … 
        
         </ 
         hibernate-mapping 
         >

此时，Hibernate才会对集合中的实体也进行缓存。

再次运行以上代码：

两次输出好像一样，哪里有问题（？）

上面讨论了net.sf.hibernate.collection.Set.iterate方法，同样，观察net.sf.hibernate.collection.Set.size/isEmpty方法或者其他hibernate.collection中的同类型方法实现，我们可以看到同样的处理方式。

通过自定义Collection类型实现数据延迟加载的原理也就在于此。
这样，通过自身的Collection实现，Hibernate就可以在Collection层从容的实现延迟加载特性。只有程序真正读取这个Collection的内容时，才激发底层数据库操作，这为系统的性能提供了更加灵活的调整手段。
3. 属性的延迟加载

假设t_user表中存在一个长文本类型的Resume字段，此字段中保存了用户的简历数据。长文本字段的读取相对而言会带来较大的性能开销，因此，我们决定为其设为延迟加载，只有真正需要处理简历信息的时候，才从库表中读取。

首先，修改映射配置文件，将Resume字段的lazy属性设置为true：

 
         < 
         hibernate-mapping 
         > 
        
         < 
         class 
        
         name 
         = 
         "…TUser" 
        
         table 
         = 
         "t_user" 
        
         batch-size 
         = 
         "5" 
        
         > 
        
         … 
        
         < 
         property 
        
         name 
         = 
         "resume" 
        
         type 
         = 
         "java.lang.String" 
        
         column 
         = 
         "resume" 
        
         lazy 
         = 
         "true" 
         /> 
        
         </ 
         class 
         > 
        
         </ 
         hibernate-mapping 
         >

与实体和集合类型的延迟加载不同，Hibernate3属性延迟加载机制在配置之外，还需要借助类增强器对二进制Class文件进行强化处理（buildtime bytecode instrumentation）。

在这里，我们通过Ant调用Hibernate类增强器对TUser.class文件进行强化处理。Ant脚本如下：

 
    
         < 
         project 
         name 
         = 
         "HibernateSample" 
         default 
         = 
         "instrument” basedir=" 
         ."> 
        
 
          
         < 
         property 
         name 
         = 
         "lib.dir" 
         value 
         = 
         "./lib" 
         /> 
        
 
          
         < 
         property 
         name 
         = 
         "classes.dir" 
         value 
         = 
         "./bin" 
         /> 
        
 
          
         < 
         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/redsaga/hibernate/db/entity" 
         > 
        
 
          
         < 
         include 
         name 
         = 
         "TUser.class" 
         /> 
        
 
          
         </ 
         fileset 
         > 
        
 
          
         </ 
         instrument 
         > 
        
 
          
         </ 
         target 
         > 
        
 
         </ 
         project 
         > 
        
 
  

使用这个脚本时需要注意各个路径的配置。本例中，此脚本位于Eclipse项目的根目录下，./bin为Eclipse的默认编译输出路径，./bin下存放了执行所需的jar文件（hibernate3.jar及Hibernate所需的类库）。
以上Ant脚本将对TUser.class文件进行强化，如果对其进行反编译，可以看到如下内容：

 
         package 
         com.redsaga.hibernate.db.entity; 
        
         import 
         java.io.Serializable; 
        
         import 
         java.util.Set; 
        
         import 
         net.sf.cglib.transform.impl.InterceptFieldCallback; 
        
         import 
         net.sf.cglib.transform.impl.InterceptFieldEnabled; 
        
         public 
         class 
         TUser 
        
         implements 
         Serializable, InterceptFieldEnabled { 
        
         public 
         InterceptFieldCallback getInterceptFieldCallback(){ 
        
         return 
         $CGLIB_READ_WRITE_CALLBACK; 
        
         } 
        
         public 
         InterceptFieldCallback setInterceptFieldCallback( 
        
         InterceptFieldCallback interceptFieldcallback){ 
        
         $CGLIB_READ_WRITE_CALLBACK= interceptFieldcallback; 
        
         } 
        
         …略… 
        
         public 
         String $cglib_read_resume(){ 
        
         resume; 
        
         if 
         ($CGLIB_READ_WRITE_CALLBACK!= 
         null 
         )  
         goto 
         _L2; 
         else 
         goto 
         _L1; 
        
         _L1: 
         return 
         ; 
        
         _L2:String s; 
        
         s; 
        
         return 
         (String) $CGLIB_READ_WRITE_CALLBACK.readObject( 
         this 
         ,”resume”,s); 
        
         } 
        
         public 
         void 
         $cglib_write_resume(String s){ 
        
         resume=$CGLIB_READ_WRITE_CALLBACK ==  
         null 
         ? s:(String) 
        
         $CGLIB_READ_WRITE_CALLBACK.writeObject( 
         this 
         , “resume”,resume,s); 
        
         } 
        
         …略… 
        
         }

可以看到，TUser类的内容已经发生了很大的变化。其间，cglib相关代码被大量植入，通过这些代码，Hibernate运行期间即可截获TUser类的方法调用，从而为延迟加载机制提供实现的技术基础。

经过以上处理，运行以下测试代码：

 
         String hql = “from TUser user where user.name=’Erica’”; 
        
         Query query = session.createQuery(hql); 
        
         List list = query.list(); 
        
         Iterator it = list.iterator(); 
        
         while 
         (it.hasNext()){ 
        
         TUser user = (TUser)it.next(); 
        
         System.out.println(user.getName()); 
        
         System.out.println(user.getResume()); 
        
         }

观察输出日志：

可以看到，在此过程中，Hibernate先后执行了两条SQL，第一句用于读取TUser类中的非延迟加载字段。而之后，当user.getResume()方法调用时，随即调用第二条SQL从库表中读取Resume字段数据。属性的延迟加载已经实现。