Hibernate最佳化_Hibernate效能最佳化_Hibernate最佳化方案(下)

（來源：http://xiexiejiao.cn/hibernate/hibernate-performance-optimization-b.html ）

 

　　Hibernate 是筆者使用了超過5年的優秀ORM架構，雖然說使用了5年，但筆者並沒有把握說自己真正意義上的精通Hibernate。說道熟悉Hibernate還差不多，因為Hibernate用法和特性只要使用過或許都很簡單，但是要做到發揮Hibernate最大限度的潛力，Hibernate最佳化 ，或者說Hibernate效能最佳化 筆者僅僅是初窺門徑而已。這裡摘錄一篇牛人對於Hibernate最佳化 的文章，希望對自己以後的使用指引下方向吧。這篇是上一篇的續作，著實是不錯，推薦hibernate使用者，尤其是像我一樣的使用者看看，會有收穫的 4.6 HQL調優 4.6.1 索引調優

HQL看起來和SQL很相似。從HQL的WHERE子句中通常可以猜到相應的SQL WHERE子句。WHERE子句中的欄位決定了資料庫將選擇的索引。

大多數Hibernate開發人員所常犯的一個錯誤是無論何時，當需要新WHERE子句的時候都會建立一個新的索引。因為索引會帶來額外的資料更新開銷，所以應該爭取建立少量索引來覆蓋儘可能多的查詢。
4.1節 讓你使用一個集合來處理所有可能的資料搜尋條件。如果這不太實際，那麼你可以使用後端剖析工具來建立一個針對 應用程式涉及的所有 SQL的集合。基於那些搜尋條件的分類，你最終會得到一個小的索引集。與此同時，還可以嘗試向WHERE子句中添加額外的謂語來匹配其他WHERE子句。

範例7

有兩個UI搜尋器和一個後端守護進程搜尋器來搜尋名為iso_deals的表。第一個UI搜尋器在unexpectedFlag、dealStatus、tradeDate和isold屬性上有謂語。

第二個UI搜尋器基於使用者鍵入的過濾器，其中包括的內容除tradeDate和isold以外還有其他屬性。開始時所有這些過濾器屬性都是可選的。
後端搜尋器基於isold、participantCode和transactionType屬性。
經過進一步業務分析，發現第二個UI搜尋器實際是基於一些隱式的unexpectedFlag和dealStatus值來選擇資料的。我們還讓tradeDate成為過濾器的必要屬性（為了使用資料庫索引，每個搜尋過濾器都應該有必要屬性）。

鑒於這一點，我們依次使用unexpectedFlag、dealStatus、tradeDate和isold構造了一個複合索引。兩個UI搜尋 器都能共用它。（順序很重要，如果你的謂語以不同的順序指定這些屬性或在它們前羅列了其他屬性，資料庫就不會選擇該複合索引。）

後端搜尋器和UI搜尋器區別太大，因此我們不得不為它構造另一個複合索引，依次使用isold、participantCode和transactionType。 4.6.2綁定參數 vs.字串拼接

既可以使用綁定參數構造HQL的WHERE子句，也可以使用字串拼接的方法，該決定對效能會有一定影響。使用綁定參數的原因是讓資料庫一次解析 SQL，對後續的重複請求複用產生好的執行計畫，這樣做節省了CPU時間和記憶體。然而，為達到最優的資料訪問效率，不同的綁定值可能需要不同的SQL執行 計劃。

例如，一小段資料範圍可能只返回資料總量的5%，而一大段資料範圍可能返回資料總量的90%。前者使用索引更好，而後者則最好使用全表掃描。

建議OLTP使用綁定參數，資料倉儲使用字串拼接，因為OLTP通常在一個事務中重複插入和更新資料，只取少量資料；資料倉儲通常只有少量SQL查詢，有一個確定的執行計畫比節省CPU時間和記憶體更為重要。

要是你知道你的OLTP搜尋對不同綁定值應該使用相同執行計畫又該怎麼辦呢。

Oracle 9i及以後版本在第一次調用綁定參數並產生執行計畫時能探出參數值。後續調用不會再探測，而是重用之前的執行計畫。 4.6.3彙總及排序

你可以在資料庫中進行彙總和“order by”，也可以在應用程式的服務層中事先載入所有資料然後做彙總和“order by”操作。推薦使用前者，因為資料庫在這方面通常會比你的應用程式做得好。此外，這樣做還能節省網路頻寬，這也是一種擁有跨資料庫移植性的做法。

當你的應用程式對資料彙總和排序有HQL不支援的特定商務規則時除外。 4.6.4覆蓋抓取策略

詳見4.7.1節 。 4.6.5本地查詢

本地查詢調優其實並不直接與HQL有關。但HQL的確可以讓你直接向底層資料庫傳遞本地查詢。我們並不建議這麼做，因為本地查詢在資料庫間不可移植。 4.7抓取策略調優

抓取策略決定了在應用程式需要訪問關聯對象時，Hibernate以何種方式以及何時擷取關聯對象。HRD中的第20章“改善效能” 對該主題作了很好的闡述，我們在此將關注它的使用方法。 4.7.1覆蓋抓取策略

不同的使用者可能會有不同的資料抓取要求。Hibernate允許在兩個地方定義資料抓取策略，一處是在映射中繼資料中，另一處是在HQL或Criteria中覆蓋它。

常見的做法是基於主要的抓取用例在映射中繼資料中定義預設抓取策略，針對少數用例在HQL和Criteria中覆蓋抓取策略。

假設pojoA和pojoB是父子關係執行個體。如果根據商務規則，只是偶爾需要從實體兩端載入資料，那你可以聲明一個消極式載入集合或代理抓取 （proxy fetching）。當你需要從實體兩端擷取資料時，可以用立即抓取（eager fetching）覆蓋預設策略，例如使用HQL或Criteria配置串連抓取（join fetching）。

另一方面，如果商務規則在大多數時候需要從實體兩端載入資料，那麼你可以聲明立即抓取並在Criteria中設定消極式載入集合或代理抓取來覆蓋它（HQL目前還不支援這樣的覆蓋）。 4.7.2 N+1模式或是反模式。

select抓取會導致N+1問題。如果你知道自己總是需要從關聯中載入資料，那麼就該始終使用串連抓取。在下面兩個情境中，你可能會把N+1視為一種模式而非反模式。

第一種情境，你不知道使用者是否會訪問關聯對象。如果他/她沒有訪問，那麼你贏了；否則你仍然需要額外的N次select SQL語句。這是一種令人左右為難的局面。

第二種情境，pojoA和很多其他POJO有one-to-many關聯，例如pojoB和pojoC。使用立即的內串連或外串連抓取會在結果集中 將pojoA重複很多次。當pojoA中有很多非空屬性時，你不得不將大量資料載入到持久層中。這種載入需要很多時間，既有網路頻寬的原因，如果 Hibernate的會話是有狀態的，其中也會有會話緩衝的原因（記憶體消耗和GC暫停）。

如果你有一個很長的one-to-many關聯鏈，例如從pojoA到pojoB到pojoC以此類推，情況也是類似的。

你也許會去使用HQL中的DISTINCT關鍵字或Cirteria中的distinct功能或是Java 的Set介面來消除重複資料。但所有這些都是在Hibernate（在持久層）中實現的，而非資料庫中。

如果基於你的網路和記憶體配置的測試表明N+1效能更好，那麼你可以使用批量抓取、subselect抓取或二級緩衝來做進一步調優。

範例8

以下是一個使用批量抓取的HBM檔案片段：

<class name="pojoA" table="pojoA">
…
<set name="pojoBs" fetch="select" batch-size="10">

<key column="pojoa_id"/>
…
</set>
</class>

以下是多端pojoB產生的SQL：

select … from pojoB where pojoa_id in(?,?,?,?,?, ?,?,?,?,?);

問號數量與batch-size值相等。因此N次額外的關於pojoB的select SQL語句被減少到了N/10次。

如果將fetch =“select “ 替換成fetch =“subselect “ ，pojoB產生的SQL語句就是這樣的：

select … from pojoB where pojoa_id in(select id from pojoA where …);

儘管N次額外的select減少到1次，但這隻在重複運行pojoA的查詢開銷很低時才有好處。

如果pojoA中的pojoB集合很穩定，或pojoB有pojoA的many-to-one關聯，而且pojoA是唯讀引用資料，那麼你可以使用二級緩衝來緩衝pojoA以消除N+1問題（4.8.1節 中有一個例子）。 4.7.3延遲屬性抓取

除非有一張擁有很多你不需要的欄位的遺留表，否則不應該使用這種抓取策略，因為它的延遲屬性分組會帶來額外的SQL。

在業務分析和設計過程中，你應該將不同資料擷取或修改分組放到不同的領域對象實體中，而不是使用這種抓取策略。

如果不能重新設計遺留表，可以使用HQL或Criteria提供的投影功能來擷取資料。 4.8 二級緩衝調優

HRD第20.2節 “二級緩衝” 中的描述對大多數開發人員來說過於簡單，無法做出選擇。3.3版及以後版本不再推薦使用基於“CacheProvider”的緩衝，而用基於“RegionFactory”的緩衝，這也讓人更糊塗了。但是就算是最新的3.5參考文檔也沒有提及如何使用新緩衝方法。

出於下述考慮，我們將繼續關注於老方法： 所有流行的Hibernate二級緩衝供應商中只有JBoss Cache 2 、Infinispan 4 和Ehcache 2 支援新方法。OSCache 、SwarmCache 、Coherence 和Gigaspaces XAP-Data Grid 只支援老方法。 兩種方法共用相同的<cache>配置。例如，它們仍舊使用相同的usage屬性值“transactional|read-write|nonstrict-read-write|read-only”。 多個cache-region適配器仍然內建老方法的支援，理解它能協助你快速理解新方法。 4.8.1 基於CacheProvider的緩衝機制

理解該機制是做出合理選擇的關鍵。關鍵的類/介面是CacheConcurrencyStrategy和它針對4中不同緩衝使用的實作類別，還有EntityUpdate/Delete/InsertAction。

針對並發緩衝訪問，有三種實現模式： 針對“read-only”的唯讀模式。

無論是鎖還是事務都沒影響，因為緩衝自資料從資料庫載入後就不會改變。 針對“read-write”和“nonstrict-read-write”的非事務感知（non-transaction-aware）讀寫入模式。

對緩衝的更新發生在資料庫事務完成後。緩衝需要支援鎖。 針對“transactional”的事務感知讀寫。

對緩衝和資料庫的更新被封裝在同一個JTA事務中，這樣緩衝與資料庫總是保持同步的。資料庫和緩衝都必須支援JTA。儘管緩衝事務內部依賴於緩衝鎖，但Hibernate不會顯式調用任何的緩衝鎖函數。

以資料庫更新為例。EntityUpdateAction對於事務感知讀寫、“read-write”的非事務感知讀寫，還有“nonstrict-read-write”的非事務感知讀寫相應有如下調用序列： 在一個JTA事務中更新資料庫；在同一個事務中更新緩衝。 軟鎖緩衝；在一個事務中更新資料庫；在上一個事務成功完成後更新緩衝；否則釋放軟鎖。

軟鎖只是一種特定的緩衝值失效表述方式，在它獲得新資料庫值前阻止其他事務讀寫緩衝。那些事務會轉而直接讀取資料庫。

緩衝必須支援鎖；事務支援則不是必須的。如果緩衝是一個叢集，“更新緩衝”的調用會將新值推送給所有副本，這通常被稱為“推（push）”更新策略。 在一個事務中更新資料庫；在上一個事務完成前就清除緩衝；為了安全起見，無論事務成功與否，在事務完成後再次清除緩衝。

既不需要支援緩衝鎖，也不需要支援事務。如果是緩衝叢集，“清除緩衝”調用會讓所有副本都失效，這通常被稱為“拉（pull）”更新策略。

對於實體的刪除或插入動作，或者集合變更，調用序列都是相似的。

實際上，最後兩個非同步呼叫序列仍能保證資料庫和緩衝的一致性（基本就是“read committed”的隔離了層級），這要歸功於第二個序列中的軟鎖和“更新資料庫”後的“更新緩衝”，還有最後一個調用序列中的悲觀“清除緩衝”。

基於上述分析，我們的建議是： 如果資料是唯讀，例如引用資料，那麼總是使用“read-only”策略，因為它是最簡單、最高效的策略，也是叢集安全的策略。 除非你真的想將緩衝更新和資料庫更新放在一個JTA事務裡，否則不要使用“transactional”策略，因為JTA需要漫長的兩階段交易認可處理，這導致它基本是效能最差的策略。

依筆者看來，二級緩衝並非一級資料來源，因此使用JTA也未必合理。實際上最後兩個調用序列在大多數情境下是個不錯的替代方案，這要歸功於它們的資料一致性保障。 如果你的資料讀很多或者很少有並發緩衝訪問和更新，那麼可以使用“nonstrict-read-write”策略。感謝它的輕量級“拉”更新策略，它通常是效能第二好的策略。 如果你的資料是又讀又寫的，那麼使用“read-write”策略。這通常是效能倒數第二的策略，因為它要求有緩衝鎖，緩衝叢集中使用重量級的“推”更新策略。

範例9

以下是一個ISO收費類型的HBM檔案片段：

<class name="IsoChargeType">
   <property name="isoId" column="ISO_ID" not-null="true"/>

   <many-to-one name="estimateMethod" fetch="join" lazy="false"/>

   <many-to-one  name="allocationMethod" fetch="join" lazy="false"/>

   <many-to-one name="chargeTypeCategory" fetch="join" lazy="false"/>

</class>

一些使用者只需要ISO收費類型本身；一些使用者既需要ISO收費類型，還需要它的三個關聯對象。簡單起見，開發人員會立即載入所有三個關聯對象。如果項目中沒人負責Hibernate調優，這是很常見的。

4.7.1節 中講過了最好的方法。因為所有的關聯對象都是唯讀引用資料，另一種方法是使用延遲抓取，開啟這些對象的二級緩衝以避免N+1問題。實際上前一種方法也能從參考資料快取中獲益。

因為大多數項目都有很多被其他資料引用的唯讀引用資料，上述兩種方法都能改善全域系統效能。 4.8.2 RegionFactory

下表是新老兩種方法中對應的主要類/介面：

新方法	老方法
RegionFactory	CacheProvider
Region	Cache
EntityRegionAccessStrategy	CacheConcurrencyStrategy
CollectionRegionAccessStrategy	CacheConcurrencyStrategy

第一個改進是RegionFactory構建了特定的Region，例如EntityRegion和TransactionRegion，而不是使 用一個通用的訪問Region。第二個改進是對於特定緩衝的“usage”屬性值，Region要求構建自己的存取原則，而不是所有Region都一直使 用CacheConcurrencyStrategy的4種實現。

要使用新方法，應該設定factory_class而非provider_class配置屬性。以Ehcache 2.0為例：

<property name="hibernate.cache.region.factory_class">
        net.sf.ehcache.hibernate.EhCacheRegionFactory
</property>

其他相關的Hibernate緩衝配置都和老方法一樣。

新方法也能向後相容遺留方法。如果還是只配了CacheProvider，新方法中將使用下列自說明（self-explanatory）適配器和橋隱式地調用老的介面/類：

RegionFactoryCacheProviderBridge、EntityRegionAdapter、 CollectionRegionAdapter、QueryResultsRegionAdapter、 EntityAccessStrategyAdapter和CollectionAccessStrategyAdapter 4.8.3 查詢快取

二級緩衝也能緩衝查詢結果。如果查詢開銷很大而且要重複運行，這也會很有協助。 4.9批量處理調優

大多數Hibernate的功能都很適合那些每個事務都通常只處理少量資料的OLTP系統。但是，如果你有一個資料倉儲或者事務需要處理大量資料，那麼就另當別論了。 4.9.1使用有狀態會話的非DML風格批處理

如果你已經在使用常規會話了，那這是最自然的方法。你需要做三件事： 配置下列3個屬性以開啟批處理特性：

  hibernate.jdbc.batch_size 30
  hibernate.jdbc.batch_versioned_data true
  hibernate.cache.use_second_level_cache false

batch_size設定為正值會開啟JDBC2的批次更新，Hibernate的建議值是5到30。基於我們的測試，極低值和極高值效能都很差。只要取值在合理範圍內，區別就只有幾秒而已。如果網路夠快，這個結果是一定的。

第二個配置設為true，這要求JDBC驅動在executeBatch()方法中返回正確的行數。對於Oracle使用者而言，批次更新時不能將其設為true。請閱讀Oracle的《JDBC Developer’s Guide and Reference》中的“標準批處理的Oracle實現中的更新計數 ”（Update Counts in the Oracle Implementation of Standard Batching ）以獲得更多詳細資料。因為它對批量插入來說還是安全的，所以你可以為批量插入建立單獨的專用資料來源。最後一個配置項是可選的，因為你可以在會話中顯式關閉二級緩衝。 像如下範例中那樣定期重新整理（flush）並清除一級會話緩衝：

 Session session = sessionFactory.openSession();
 Transaction tx = session.beginTransaction();

 for ( int i=0; i<100000; i++ ) {
     Customer customer = new Customer(.....);
     //if your hibernate.cache.use_second_level_cache is true, call the following:
     session.setCacheMode(CacheMode.IGNORE);
     session.save(customer);
     if (i % 50 == 0) { //50, same as the JDBC batch size
     //flush a batch of inserts and release memory:
     session.flush();
     session.clear();
     }
 }
 tx.commit();
 session.close();

批處理通常不需要資料緩衝，否則你會將記憶體耗盡並大量增加GC開銷。如果記憶體有限，那這種情況會很明顯。 總是將批量插入嵌套在事務中。

每次事務修改的對象數量越少就意味著會有更多資料庫提交，正如4.5節 所述每次提交都會帶來磁碟相關的開銷。

另一方面，每次事務修改的對象數量越多就意味著鎖定變更時間越長，同時資料庫需要更大的redo log。 4.9.2使用無狀態會話的非DML風格批處理

無狀態會話執行起來比上一種方法更好，因為它只是JDBC的簡單封裝，而且可以繞開很多常規會話要求的操作。例如，它不需要會話緩衝，也不和任何二級緩衝或查詢快取有互動。
然而它的用法並不簡單。尤其是它的操作並不會級聯到所關聯的執行個體上；你必須自己來處理它們。 4.9.3 DML風格

使用DML風格的插入、更新或刪除，你直接在資料庫中操作資料，這和前兩種方法在Hibernate中操作資料的情況有所不同。

因為一個DML風格的更新或刪除相當於前兩種方法中的多個單獨的更新或刪除，所以如果更新或刪除中的WHERE子句暗示了恰當的資料庫索引，那麼使用DML風格的操作能節省網路開銷，執行得更好。

強烈建議結合使用DML風格操作和無狀態會話。如果使用有狀態會話，不要忘記在執行DML前清除緩衝，否則Hibernate將會更新或清除相關緩衝（見下面的範例10）。 4.9.4批量載入

如果你的HQL或Criteria會返回很多資料，那麼要注意兩件事： 用下列配置開啟批量抓取特性：

hibernate.jdbc.fetch_size 10

fetch_size設定為正值將開啟JDBC批量抓取特性。相對快速網路，在慢速網路中這一點更為重要。Oracle建議的經驗值是10。你應該基於自己的環境進行測試。 在使用上述任一方法時都要關閉緩衝，因為批量載入一般是一次性任務。受限於記憶體容量，向緩衝中載入大量資料通常也意味著它們很快會被清除出去，這會增加GC開銷。

範例10

我們有一個背景工作，分段載入大量的IsoDeal資料用於後續處理。我們還會在分段資料交給下遊系統處理前將其更新為處理中狀態。最大的一段有50萬行資料。以下是原始代碼中截取出來的一段：

Query query = session.createQuery("FROM IsoDeal d WHERE chunk-clause");
query.setLockMode("d", LockMode.UPGRADE); //for Inprocess status update
List<IsoDeal> isoDeals = query.list();
for (IsoDeal isoDeal : isoDeals) { //update status to Inprocess
   isoDeal.setStatus("Inprocess");
}
return isoDeals;

包含上述代碼的方法加上了Spring 2.5聲明式事務的註解。載入並更新50萬行資料大約花了10分鐘。我們識別出了以下這些問題： 由於會話緩衝和二級緩衝的原因，系統會頻繁地記憶體溢出。 就算沒有記憶體溢出，當記憶體消耗很高時GC的開銷也會很大。 我們還未設定fetch_size。 就算我們設定了batch_size，for迴圈也建立了太多update SQL語句。

不幸的是Spring 2.5不支援Hibernate無狀態會話，所以我們只能關閉二級緩衝；設定fetch_size；用DML風格的更新來代替for迴圈，以此改善效能。

但是，執行時間還是要6分鐘。將Hibernate的記錄層級調成trace後，我們發現是更新會話緩衝造成了延時。通過在DML更新前清除會話緩衝，我們將時間縮短到了4分鐘，全部都是將資料載入到會話緩衝中花費的時間。 4.10 SQL產生調優

本節將向你展示如何減少SQL產生的數量。 4.10.1 N+1抓取問題

“select抓取”策略會導致N+1問題。如果“串連抓取”策略適合你的話，你應該始終使用該策略避免N+1問題。

但是，如果“串連抓取”策略執行效果不理想，就像4.7.2節 中那樣，你可以使用“subselect抓取”、“批量抓取”或“延遲集合抓取”來減少所需的額外SQL語句數。 4.10.2 Insert+Update問題

範例11

我們的ElectricityDeal與DealCharge有單向one-to-many關聯，如下列HBM檔案片段所示：

<class name="ElectricityDeal"
select-before-update="true" dynamic-update="true"

dynamic-insert="true">
<id name="key" column="ID">

<generator class="sequence">
<param name="sequence">SEQ_ELECTRICITY_DEALS</param>

</generator>
</id>
    …
    <set name="dealCharges" cascade="all-delete-orphan">

<key column="DEAL_KEY" not-null="false" update="true"

on-delete="noaction"/>
<one-to-many class="DealCharge"/>
</set>  </class>

在“key”元素中，“not-null”和“update”對應的預設值是false和true，上述代碼為了明確這些取值，將它們寫了出來。

如果你想建立一個ElectricityDeal和十個DealCharge，會產生如下SQL語句： 1句ElectricityDeal的插入語句； 10句DealCharge的插入語句，其中不包括外鍵“DEAL_KEY”； 10句DealCharge欄位“DEAL_KEY”的更新語句。

為了消除那額外的10句更新語句，可以在那10句DealCharge插入語句中包含“DEAL_KEY”，你需要將“not-null”和“update”分別修改為true和false。

另一種做法是使用雙向或many-to-one關聯，讓DealCharge來管理關聯。 4.10.3 更新前執行select

在範例11中，我們為ElectricityDeal加上了select-before-update，這會對瞬時（transient）對象或分離（detached）對象產生額外的select語句，但卻能避免不必要的資料庫更新。

你應該做出一些權衡，如果對象沒多少屬性，不需要防止不必要的資料庫更新，那麼就不要使用該特性，因為你那些有限的資料既沒有太多網路傳輸開銷，也不會帶來太多資料庫更新開銷。

如果對象的屬性較多，例如是一張大的遺留表，那你應該開啟該特性，和“dynamic-update”結合使用以避免太多資料庫更新開銷。 4.10.4 串聯刪除

在範例11中，如果你想刪除1個ElectricityDeal和它的100個DealCharge，Hibernate會對DealCharge做100次刪除。

如果將“on-delete”修改為“cascade”，Hibernate不會執行DealCharge的刪除動作；而是讓資料庫根據ON CASCADE DELETE約束自動刪除那100個DealCharge。不過，需要讓DBA開啟ON CASCADE DELETE約束，大多數DBA不願意這麼做，因為他們想避免父物件的意外刪除級聯到它的依賴對象上。此外，還要注意，該特性會繞過Hibernate對 版本資料（versioned data）的常用樂觀鎖策略。 4.10.5 增強序列標識符產生器

範例11中使用Oracle的序列作為標識符產生器。假設我們儲存100個ElectricityDeal，Hibernate會將下面的SQL語句執行100次來擷取下一個可用的標識符：

select SEQ_ELECTRICITY_DEALS.NEXTVAL from dual;

如果網路不是很快，那這無疑會降低效率。3.2.3及後續版本中增加了一個增強產生器“SequenceStyleGenerator”，它帶了兩個最佳化器：hilo和pooled。儘管HRD的第5章“基礎O/R映射” 講到了這兩個最佳化器，不過內容有限。兩個最佳化器都使用了HiLo演算法，該演算法產生的標識符等於Hi值加上Lo值，其中Hi值代表組號，Lo值順序且重複地從1迭代到最大組大小，組號在Lo值“轉回到”1時加1。

假設組大小是5（可以用max_lo或increment_size參數來表示），下面是個例子：

hibernate效能最佳化 hilo最佳化器

組號取自資料庫序列的下一個可用值，Hi值由Hibernate定義，是組號乘以increment_size參數值。 pooled最佳化器

Hi值直接取自資料庫序列的下一個可用值。資料庫序列的增量應該設定為increment_size參數值。

直到記憶體組中的值耗盡後，兩個最佳化器才會去訪問資料庫，上面的例子每5個標識值符訪問一次資料庫。使用hilo最佳化器時，你的序列不能再被其他應用程式使用，除非它們使用與Hibernate相同的邏輯。使用pooled最佳化器，在其他應用程式使用同一序列時則相當安全。

兩個最佳化器都有一個問題，如果Hibernate崩潰，當前組內的一些標識符值就會丟失，然而大多數應用程式都不要求擁有連續的標識符值（如果你的資料庫，比方說Oracle，緩衝了序列值，當它崩潰時你也會丟失標識符值）。

如果在範例11中使用pooled最佳化器，新的id配置如下：

<id name="key" column="ID">
<generator class="org.hibernate.id.enhance.SequenceStyleGenerator">
        <param name="sequence_name">SEQ_ELECTRICITY_DEALS</param>

<param name="initial_value">0</param>
<param name="increment_size">100</param>

<param name="optimizer ">pooled</param>
</generator>
</id>

5 總結

本文涵蓋了大多數你在Hibernate應用程式調優時會覺得很有用的調優技巧，其中的大多數時間都在討論那些行之有效卻缺乏文檔的調優主題，例如繼承映射、二級緩衝和增強序列標識符產生器。

它還提到了一些Hibernate調優所必需的資料庫知識。一些範例中包含了你可能遇到的問題的實際解決方案。

除此之外，值得一提的是Hibernate也可以和In-Memory Data Grid（IMDG）一起使用，例如Oracle的Coherance或GigaSpaces IMDG，這能讓你的應用程式達到毫秒層級。 6 資源

[1] Latest Hibernate Reference Documentation on jboss.com

[2] Oracle 9i Performance Tuning Guide and Reference

[3] Performance Engineering on Wikipedia

[4] Program Optimization on Wikipedia

[5] Pareto Principle (the 80/20 rule) on Wikipedia

[6] Premature Optimization on acm.org

[7] Java Performance Tuning by Jack Shirazi

[8] The Law of Leaky Abstractions by Joel Spolsky

[9] Hibernate’s StatisticsService Mbean configuration with Spring

[10] JProbe by Quest Software

[11] Java VisualVM

[12] Column-oriented DBMS on Wikipedia

[13] Apache DBCP BasicDataSource

[14] JDBC Connection Pool by Oracle

[15] Connection Failover by Oracle

[16] Last Resource Commit Optimization (LRCO)

[17] GigaSpaces for Hibernate ORM Users 關於作者

Yongjun Jiao 是SunGard Consulting Services的技術主管。過去10年中他一直是專業軟體開發人員，他的專長包括Java SE、Java EE、Oracle和應用程式調優。他最近的關注點是高效能運算，包括記憶體資料格、並行計算和格線運算。

Stewart Clark 是SunGard Consulting Services的負責人。過去15年中他一直是專業軟體開發人員和專案經理，他的專長包括Java核心編程、Oracle和能源交易。

摘自: infoq
英文地址：http://www.infoq.com/articles/hibernate_tuning

Related posts: