Hibernate延遲加載機制

 延遲加載機制是爲了不一些無謂的性能開銷而提出來的，所謂延遲加載就是當在真正須要數據的時候，才真正執行數據加載操做。在Hibernate中提供了對實體對象的延遲加載以及對集合的延遲加載，另外在Hibernate3中還提供了對屬性的延遲加載。下面咱們就分別介紹這些種類的延遲加載的細節。 A、實體對象的延遲加載： 若是想對實體對象使用延遲加載，必需要在實體的映射配置文件中進行相應的配置，以下所示： <hibernate-mapping> <class name=」com.neusoft.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=」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列表，就是所謂的數據索引。當查找數據索引時，若是沒有找到對應的數據索引，這時就會一條select SQL的執行，得到符合條件的數據，並構造實體對象集合和數據索引，而後返回實體對象的集合，而且將實體對象和數據索引歸入Hibernate的緩存之中。另外一方面，若是找到對應的數據索引，則從數據索引中取出id列表，而後根據id在緩存中查找對應的實體，若是找到就從緩存中返回，若是沒有找到，在發起select SQL查詢。在這裏咱們看出了另一個問題，這個問題可能會對性能產生影響，這就是集合類型的緩存策略。若是咱們以下配置集合類型： <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> 這裏咱們應用了<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=」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 * 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=」com.neusoft.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字段數據真正的讀取操做。