Hibernate延迟加载机制.docx

延迟加载：

延迟加载机制是为了避免一些无谓的性能开销而提出来的，所谓延迟

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

Hibernate中提供了对实体对象的延迟加载以及对集合的延迟加载，另外在Hibernate3中还提供了对属性的延迟加载。下面我们就分别介绍这些种类的延迟加载的细节。

A、实体对象的延迟加载：

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

hibernate-mapping

classname=”com.neusoft.entity.User”table=”user”lazy=”true”

……

/class

/hibernate-mapping

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

Useruser=(User)session.load(User.class,”1”);（1）

System.out.println(user.getName());（2）

当运行到(1)处时，Hibernate并没有发起对数据的查询，如果我们此时通过一些调试工具(比如JBuilder2005的Debug工具)，观察此时user对象的内存快照，我们会惊奇的发现，此时返回的可能是

User$EnhancerByCGLIB$$bede8986类型的对象，而且其属性为null,这是怎么回事？还记得前面我曾讲过session.load()方法，会返回实体对象的代理类对象，这里所返回的对象类型就是User对象的代理类对象。在Hibernate中通过使用CGLIB,来实现动态构造一个目标对象的代理类对象，并且在代理类对象中包含目标对象的所有属性和方法，而且所有属性均被赋值为null。通过调试器显示的内存快照，我们

可以看出此时真正的User对象，是包含在代理对象的CGLIB$CALBACK_0.target属性中，当代码运行到（2）处时，此时

调用user.getName()方法，这时通过CGLIB赋予的回调机制，实际上调用CGLIB$CALBACK_0.getName()方法，当调用该方法时，Hibernate会首先检查CGLIB$CALBACK_0.target属性是否为null，如果不为空，则调用目标对象的getName方法，如果为空，则

会发起数据库查询，生成类似这样的SQL语句：select*fromuserwhereid=’1’来;查询数据，并构造目标对象，并且将它赋值到CGLIB$CALBACK_0.target属性中。

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

session.load()方法才会利用实体延迟加载，因为只有session.load()

方法才会返回实体类的代理类对象。

B、 集合类型的延迟加载：

在Hibernate的延迟加载机制中，针对集合类型的应用，意义是最为重大的，因为这有可能使性能得到大幅度的提高，为此Hibernate进行了大量的努力，其中包括对JDKCollection的独立实现，我们在一对多关联中，定义的用来容纳关联对象的Set集合，并不是java.util.Set类型或其子类型，而是net.sf.hibernate.collection.Set类型，通过使用自定义集合类的实

现，Hibernate实现了集合类型的延迟加载。为了对集合类型使用延迟加载，我们必须如下配置我们的实体类的关于关联的部分：

hibernate-mapping

classname=”com.neusoft.entity.User”table=”user”

…..

setname=”addresses”table=”address”lazy=”true”inverse=”true”

keycolumn=”user_id”/

one-to-manyclass=”com.neusoft.entity.Arrderss”/

/set

/class

/hibernate-mapping

通过将set元素的lazy属性设置为true来开启集合类型的延迟加载特性。我们看下面的代码：

Useruser=(User)session.load(User.class,”1”);

Collectionaddset=user.getAddresses(); (1)

Iteratorit=addset.iterator(); (2)while(i