hibernate 如何實現延遲加載

延遲加載：  
 
   延遲加載機制是爲了不一些無謂的性能開銷而提出來的，所謂延遲加載就是當在真正須要數據的時候，才真正執行數據加載操做。在Hibernate中提供了 對實體對象的延遲加載以及對集合的延遲加載，另外在Hibernate3中還提供了對屬性的延遲加載。下面咱們就分別介紹這些種類的延遲加載的細節。  
 
A、實體對象的延遲加載：  
 
若是想對實體對象使用延遲加載，必需要在實體的映射配置文件中進行相應的配置，以下所示：  
 
<hibernate-mapping>  
 
<class name=」net.ftng.entity.user」 table=」user」 lazy=」true」>  
 
    ……  
 
</class>  
 
</hibernate-mapping>  
 
經過將class的lazy屬性設置爲true，來開啓實體的延遲加載特性。若是咱們運行下面的代碼：  
 
User user=(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 * from user where id=’1’;來查詢數據，並構造目標對象，而且將它賦值到CGLIB$CALBACK_0.target屬性中。  
 
    這樣，經過一箇中間代理對象，Hibernate實現了實體的延遲加載，只有當用戶真正發起得到實體對象屬性的動做時，才真正會發起數據庫查詢操做。因此 實體的延遲加載是用經過中間代理類完成的，因此只有session.load()方法纔會利用實體延遲加載，由於只有session.load()方法才 會返回實體類的代理類對象。  
 
B、        集合類型的延遲加載：  
 
在Hibernate的延遲加載機制中，針對集合類型的應用，意義是最爲重大的，由於這有可能使性能獲得大幅度的提升，爲此Hibernate進 行了大量的努力，其中包括對JDK Collection的獨立實現，咱們在一對多關聯中，定義的用來容納關聯對象的Set集合，並非java.util.Set類型或其子類型，而是 net.sf.hibernate.collection.Set類型，經過使用自定義集合類的實現，Hibernate實現了集合類型的延遲加載。爲了 對集合類型使用延遲加載，咱們必須以下配置咱們的實體類的關於關聯的部分：  
 
<hibernate-mapping>  
 
    <class name=」net.ftng.entity.User」 table=」user」>  
 
…..  
 
<set name=」addresses」 table=」address」 lazy=」true」 inverse=」true」>  
 
<key column=」user_id」/>  
 
<one-to-many class=」net.ftng.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列表，就是所謂的數據索引。當查找數據索引時，若是沒有找到對應的數據 索引，這時就會一條select SQL的執行，得到符合條件的數據，並構造實體對象集合和數據索引，而後返回實體對象的集合，而且將實體對象和數據索引歸入Hibernate的緩存之 中。另外一方面，若是找到對應的數據索引，則從數據索引中取出id列表，而後根據id在緩存中查找對應的實體，若是找到就從緩存中返回，若是沒有找到，在發 起select SQL查詢。在這裏咱們看出了另一個問題，這個問題可能會對性能產生影響，這就是集合類型的緩存策略。若是咱們以下配置集合類型：  
 
<hibernate-mapping>  
 
    <class name=」net.ftng.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=」net.ftng.entity.Arrderss」/>  
 
</set>  
 
    </class>  
 
</hibernate-mapping>  
 
這裏咱們應用了<cache usage=」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根據找到的數據索引起起了兩條select SQL的查詢操做，這裏形成了對性能的浪費，怎樣才能避免這種狀況呢？咱們必須對集合類型中的實體也指定緩存策略，因此咱們要以下對集合類型進行配 置：  
 
<hibernate-mapping>  
 
    <class name=」net.ftng.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=」net.ftng.entity.Arrderss」/>  
 
</set>  
 
    </class>  
 
</hibernate-mapping>  
 
此時Hibernate會對集合類型中的實體也進行緩存，若是根據這個配置再次運行上面的代碼，將會獲得相似以下的輸出：  
 
Select * from user where id=’1’;  
 
Select * from address where user_id=’1’;  
 
Tianjin  
 
Dalian  
 
Second query……  
 
Tianjin  
 
Dalian  
 
這時將不會再有根據數據索引進行查詢的SQL語句，由於此時能夠直接從緩存中得到集合類型中存放的實體對象。  
 
C、       屬性延遲加載：  
 
   在Hibernate3中，引入了一種新的特性——屬性的延遲加載，這個機制又爲獲取高性能查詢提供了有力的工具。在前面咱們講大數據對象讀取時，在 User對象中有一個resume字段，該字段是一個java.sql.Clob類型，包含了用戶的簡歷信息，當咱們加載該對象時，咱們不得不每一次都要 加載這個字段，而不論咱們是否真的須要它，並且這種大數據對象的讀取自己會帶來很大的性能開銷。在Hibernate2中，咱們只有經過咱們前面講過的面 性能的粒度細分，來分解User類，來解決這個問題（請參照那一節的論述），可是在Hibernate3中，咱們能夠經過屬性延遲加載機制，來使咱們得到 只有當咱們真正須要操做這個字段時，纔去讀取這個字段數據的能力，爲此咱們必須以下配置咱們的實體類：  
 
<hibernate-mapping>  
 
<class name=」net.ftng.entity.User」 table=」user」>  
 
……  
 
<property name=」resume」 type=」java.sql.Clob」 column=」resume」 lazy=」true」/>  
 
    </class>  
 
</hibernate-mapping>  
 
經過對<property>元素的lazy屬性設置true來開啓屬性的延遲加載，在Hibernate3中爲了實現屬性的延遲加 載，使用了類加強器來對實體類的Class文件進行強化處理，經過加強器的加強，將CGLIB的回調機制邏輯，加入實體類，這裏咱們能夠看出屬性的延遲加 載，仍是經過CGLIB來實現的。CGLIB是Apache的一個開源工程，這個類庫能夠操縱java類的字節碼，根據字節碼來動態構造符合要求的類對 象。根據上面的配置咱們運行下面的代碼：  
 
String sql=」from User user where user.name=’zx’ 」;  
 
Query query=session.createQuery(sql);    (1)  
 
List list=query.list();  
 
for(int i=0;i<list.size();i++){  
 
User user=(User)list.get(i);  
 
System.out.println(user.getName());  
 
System.out.println(user.getResume());    (2)  
 
}  
 
當執行到(1)處時，會生成相似以下的SQL語句：  
 
Select id,age,name from user where name=’zx’;  
 
這時Hibernate會檢索User實體中全部非延遲加載屬性對應的字段數據，當執行到(2)處時，會生成相似以下的SQL語句：  
 
Select resume from user where id=’1’;  
 
這時會發起對resume字段數據真正的讀取操做。