初用HIBERNATE的人也許都遇到過(guò)性能問(wèn)題，實(shí)現同一功能，用HIBERNATE與用JDBC性能相差十幾倍很正常，如果不及早調整，很可能影響整個(gè)項目的進(jìn)度。
大體上，對於HIBERNATE性能調優(yōu)的主要考慮點(diǎn)如下:
Ø 數據庫設計調整
Ø HQL優(yōu)化
Ø API的正確使用(如根據不同的業(yè)務(wù)類(lèi)型選用不同的集合及查詢(xún)API)
Ø 主配置參數(日誌，查詢(xún)緩存，fetch_size, batch_size等)
Ø 映射文件優(yōu)化(ID生成策略，二級緩存，延遲載入，關(guān)聯(lián)優(yōu)化)
Ø 一級緩存的管理
Ø 針對二級緩存，還有許多特有的策略
Ø 事務(wù)控制策略。
1、 數據庫設計
a) 降低關(guān)聯(lián)的複雜性
b) 儘量不使用聯(lián)合主鍵
c) ID的生成機制，不同的數據庫所提供的機制並不完全一樣
d) 適當的冗余數據，不過(guò)分追求高範式
2、 HQL優(yōu)化
HQL如果拋開(kāi)它同HIBERNATE本身一些緩存機制的關(guān)聯(lián)，HQL的優(yōu)化技巧同普通的SQL優(yōu)化技巧一樣，可以很容易在網(wǎng)上找到一些經(jīng)驗之談。
3、 主配置
a) 查詢(xún)緩存，同下面講的緩存不太一樣，它是針對HQL語(yǔ)句的緩存，即完全一樣的語(yǔ)句再次執行時(shí)可以利用緩存數據。但是，查詢(xún)緩存在一個(gè)交易系統(數據變更頻繁，查詢(xún)條件相同的機率並不大)中可能會(huì )起反作用:它會(huì )白白耗費大量的系統資源但卻難以派上用場(chǎng)。
b) fetch_size，同JDBC的相關(guān)參數作用類(lèi)似，參數並不是越大越好，而應根據業(yè)務(wù)特徵去設置
c) batch_size同上。
d) 生產(chǎn)系統中，切記要關(guān)掉SQL語(yǔ)句列印。
4、 緩存
a) 數據庫級緩存:這級緩存是最高效和安全的，但不同的數據庫可管理的層次並不一樣，比如，在ORACLE中，可以在建表時(shí)指定將整個(gè)表置於緩存當中。
b) SESSION緩存:在一個(gè)HIBERNATE SESSION有效，這級緩存的可干預性不強，大多於HIBERNATE自動(dòng)管理，但它提供清除緩存的方法，這在大批量增加/更新操作是有效的。比如，同時(shí)增加十萬(wàn)條記錄，按常規方式進(jìn)行，很可能會(huì )發(fā)現OutofMemeroy的異常，這時(shí)可能需要手動(dòng)清除這一級緩存:Session.evict以及Session.clear
c) 應用緩存:在一個(gè)SESSIONFACTORY中有效，因此也是優(yōu)化的重中之重，因此，各類(lèi)策略也考慮的較多，在將數據放入這一級緩存之前，需要考慮一些前提條件:
i. 數據不會(huì )被第三方修改(比如，是否有另一個(gè)應用也在修改這些數據?)
ii. 數據不會(huì )太大
iii. 數據不會(huì )頻繁更新(否則使用CACHE可能適得其反)
iv. 數據會(huì )被頻繁查詢(xún)
v. 數據不是關(guān)鍵數據(如涉及錢(qián)，安全等方面的問(wèn)題)。
緩存有幾種形式，可以在映射文件中配置:read-only(只讀，適用於很少變更的靜態(tài)數據/歷史數據)，nonstrict-read-write，read-write(比較普遍的形式，效率一般)，transactional(JTA中，且支援的緩存產(chǎn)品較少)
d) 分佈式緩存:同c)的配置一樣，只是緩存產(chǎn)品的選用不同，在目前的HIBERNATE中可供選擇的不多，oscache, jboss cache，目前的大多數項目，對它們的用於集群的使用(特別是關(guān)鍵交易系統)都持保守態(tài)度。在集群環(huán)境中，只利用數據庫級的緩存是最安全的。
5、 延遲載入
a) 實(shí)體延遲載入:通過(guò)使用動(dòng)態(tài)代理實(shí)現
b) 集合延遲載入:通過(guò)實(shí)現自有的SET/LIST，HIBERNATE提供了這方面的支援
c) 屬性延遲載入:
6、 方法選用
a) 完成同樣一件事，HIBERNATE提供了可供選擇的一些方式，但具體使用什麼方式，可能用性能/代碼都會(huì )有影響。顯示，一次返回十萬(wàn)條記錄(List/Set/Bag/Map等)進(jìn)行處理，很可能導致記憶體不夠的問(wèn)題，而如果用基於遊標(ScrollableResults)或Iterator的結果集，則不存在這樣的問(wèn)題。
b) Session的load/get方法，前者會(huì )使用二級緩存，而後者則不使用。
c) Query和list/iterator，如果去仔細研究一下它們，你可能會(huì )發(fā)現很多有意思的情況，二者主要區別(如果使用了Spring，在HibernateTemplate中對應find,iterator方法):
i. list只能利用查詢(xún)緩存(但在交易系統中查詢(xún)緩存作用不大)，無(wú)法利用二級緩存中的單個(gè)實(shí)體，但list查出的對象會(huì )寫(xiě)入二級緩存，但它一般只生成較少的執行SQL語(yǔ)句，很多情況就是一條(無(wú)關(guān)聯(lián))。
ii. iterator則可以利用二級緩存，對於一條查詢(xún)語(yǔ)句，它會(huì )先從數據庫中找出所有符合條件的記錄的ID，再通過(guò)ID去緩存找，對於緩存中沒(méi)有的記錄，再構造語(yǔ)句從數據庫中查出，因此很容易知道，如果緩存中沒(méi)有任何符合條件的記錄，使用iterator會(huì )產(chǎn)生N+1條SQL語(yǔ)句(N為符合條件的記錄數)
iii. 通過(guò)iterator，配合緩存管理API，在海量數據查詢(xún)中可以很好的解決記憶體問(wèn)題，如:
while(it.hasNext()){
YouObject object = (YouObject)it.next();
session.evict(youObject);
sessionFactory.evice(YouObject.class, youObject.getId());
}
如果用list方法，很可能就出OutofMemory錯誤了。
iv. 通過(guò)上面的說(shuō)明，我想你應該知道如何去使用這兩個(gè)方法了。
7、 集合的選用
在HIBERNATE 3.1文檔的“19.5. Understanding Collection performance”中有詳細的說(shuō)明。
8、 事務(wù)控制
事務(wù)方面對性能有影響的主要包括:事務(wù)方式的選用，事務(wù)隔離級別以及鎖的選用
a) 事務(wù)方式選用:如果不涉及多個(gè)事務(wù)管理器事務(wù)的話(huà)，不需要使用JTA，只有JDBC的事務(wù)控制就可以。
b) 事務(wù)隔離級別:參見(jiàn)標準的SQL事務(wù)隔離級別
c) 鎖的選用:悲觀(guān)鎖(一般由具體的事務(wù)管理器實(shí)現)，對於長(cháng)事務(wù)效率低，但安全。樂(lè )觀(guān)鎖(一般在應用級別實(shí)現)，如在HIBERNATE中可以定義VERSION字段，顯然，如果有多個(gè)應用操作數據，且這些應用不是用同一種樂(lè )觀(guān)鎖機制，則樂(lè )觀(guān)鎖會(huì )失效。因此，針對不同的數據應有不同的策略，同前面許多情況一樣，很多時(shí)候我們是在效率與安全/準確性上找一個(gè)平衡點(diǎn)，無(wú)論如何，優(yōu)化都不是一個(gè)純技術(shù)的問(wèn)題，你應該對你的應用和業(yè)務(wù)特徵有足夠的了解。
9、 批量操作
即使是使用JDBC，在進(jìn)行大批數據更新時(shí)，BATCH與不使用BATCH有效率上也有很大的差別。我們可以通過(guò)設置batch_size來(lái)讓其支援批量操作。
舉個(gè)例子，要批量刪除某表中的對象，如“delete Account”，打出來(lái)的語(yǔ)句，會(huì )發(fā)現HIBERNATE找出了所有ACCOUNT的ID，再進(jìn)行刪除，這主要是為了維護二級緩存，這樣效率肯定高不了，在後續的版本中增加了bulk delete/update，但這也無(wú)法解決緩存的維護問(wèn)題。也就是說(shuō)，由於有了二級緩存的維護問(wèn)題，HIBERNATE的批量操作效率並不盡如人意!
從前面許多要點(diǎn)可以看出，很多時(shí)候我們是在效率與安全/準確性上找一個(gè)平衡點(diǎn)，無(wú)論如何，優(yōu)化都不是一個(gè)純技術(shù)的問(wèn)題，你應該對你的應用和業(yè)務(wù)特徵有足夠的了解，一般的，優(yōu)化方案應在架構設計期就基本確定，否則可能導致沒(méi)必要的返工，致使項目延期，而作為架構師和項目經(jīng)理，還要面對開(kāi)發(fā)人員可能的抱怨，必竟，我們對用戶(hù)需求更改的控制力不大，但技術(shù)/架構風(fēng)險是應該在初期意識到並制定好相關(guān)的對策。
還有一點(diǎn)要注意，應用層的緩存只是錦上添花，永遠不要把它當救命稻草，應用的根基(數據庫設計，演算法，高效的操作語(yǔ)句，恰當API的選擇等)才是最重要的。
聯(lián)系客服
