關于hibernate效率問題讨論的整理

最近在csdn上看到一篇關于對hibernate性能的讨論，感覺裡面很多都是nr工作經驗的結晶，但還有很多是大衆化的觀點，現将各觀點整理如下：

1.hibernate和jdbc主要差別就是，hibernate先檢索緩存中的映射對象( 即hibernate操作的是對象)，而jdbc則是直接操作資料庫.

2.Hibernate是JDBC的輕量級的對象封裝，它是一個獨立的對象持久層架構，和App Server，和EJB沒有什麼必然的聯系。Hibernate可以用在任何JDBC可以使用的場合

3.Hibernate是一個和JDBC密切關聯的架構，是以Hibernate的相容性和JDBC驅動，和資料庫都有一定的關系，但是和使用它的Java程式，和App Server沒有任何關系，也不存在相容性問題。

還有一點,正确的使用JDBC技術,它的效率一定比hibernate要好,因為hibernate是基于jdbc的技術

--------------------------------------------------------------------------------------------

hibernate 是為了提高了開發人員的開發效率而開發的，但是最後執行也要轉化成jdbc。這肯定是以犧牲性能為代價的。這個代價你自己考慮着用咯。

--------------------------------------------------------------------------------------------

單表操作用hib開發效率很高,性能差不了多少。多表用hib，開發效率不曉得，性能大大降低是肯定。大項目一般關聯比較多，是以建議不要用hib來處理複雜的業務邏輯。

--------------------------------------------------------------------------------------------

就怕你的項目組對JDBC研究不夠，最後還沒有hibernate性能優越就慘了。

用DBUtil,最好能優化修改這個架構，那就厲害了。

 --------------------------------------------------------------------------------------------

深有體會，用jdbc查詢操作資料庫快些

理論上講JDBC效率比Hibernate高，但真正能用好JDBC的程式員并不多，往往最終不如Hibernate。簡單講使用JDBC對程式員要求較高。

 --------------------------------------------------------------------------------------------

Hibernate in action:

“However, the more complex and expressive your

domain model, the more you will benefit from using Hibernate; it shines

when dealing with the full complexity of object/relational persistence.”

 --------------------------------------------------------------------------------------------

hibernate最大的有點就是延遲加載，避免業務程式直接通路資料庫，建設資料庫的負載。

對于hibernate的二級緩存的運用更是提升了整個系統的緩沖能力，不過要真正用好hibernate，

對于系統的架構設計來說要求很高，首先需要充分的了解系統中個業務流程的聯系，設計完善的資料模型，

建構表直接正确的關系，這樣才能保證hibernate在映射的時候，級聯緩沖、操作的正确性，

其次如果要使用hibernate的二級緩存，必須先對其hibernate的緩存機制有很好的把握。

不要光認為能使用session的幾個api操作資料庫，就了解hibernate。如果項目是第一次運用hibernate，

且沒有成熟的業務分析，完善的系統架構設計，建議還是不要使用hibernate，畢竟駕馭hibernate還是需要一個時間，

起碼1-2年後。能對hibernate有個良好的了解就很不錯啦

--------------------------------------------------------------------------------------------

樓上各位都發表了不少高見，說說我的一點看法吧：

大家都從應用程式的性能為出發點來評價hibernate,jdbc甚至ejb,jdo等等常見的持久化技術。

直接說孰優孰劣，還是有點片面，應該結合具體應用。

ejb毫無疑問是分布式環境下持久層的首要選擇，這是它天然的特性決定了的：EJB就是為了分布式應用提出的解決方案。但正因為分布式環境在常見系統中并不多見（大部分J2EE應用都是intranet,分布式需求很少，而樓主說的OA，更談不上分布式了），加上分布式環境的系統設計、分布式資料庫設計等等異常複雜，而EJB本身又有一定的複雜性，是以現在SSH組合才如此火爆。可以說，在非分布式應用下用EJB是大材小用，是一種浪費。

抛開分布式應用，再來說說jdbc，hibernate，jdo等等。

可以說，jdbc是整個java資料庫應用的基石，不管是hibernate,jdo還是其他持久化架構，其最底層都是基于jdbc的。那麼說到這裡，在各位心底對三種技術/架構已經有了初步的比較了。

jdbc就是程式員直接通過java.sql及javax.sql類庫提供的資料庫接口與資料庫互動,程式員關注一切資料庫細節，包括擷取并打開連接配接，啟動事務，進行資料庫增删改查，送出，關閉連接配接，還有異常處理。也就是說，程式員不僅要把握業務（這應該是系統的核心），還要去關注最基本的資料庫操作。但靈活性非常高，畢竟你可以把sql,存儲過程随時随地的嵌入你的代碼中。但hibernate就不行了,你所有可以進行的舉動都被限制在映射檔案的條條框框之内了

hibernate/jdo是什麼？網上說的很濫的一句話就“是對jdbc的輕量級封裝”，說白了就是一個第三方類庫。但是做了很好的封裝，完全可配置化的資料庫操作(映射檔案)，提供了面向對象風格的查詢語句(hql)--這很重要，不要忘了java本身是oo的！純sql語句卻不是oo的，是結構化的。相信各位用過hibernate的大俠都體驗了再各個關聯對象之間随意導航的便利了(user.depart.userset...)吧。至于L1和L2緩存，Lazy等等，這都是hibernate對性能提升的一種機制。

jdo和hibernate類似（我說的是jdo與hibernate的出發點是類似的，技術細節不在讨論之内）。

這樣，純粹從性能角度對比jdbc與hibernate是很片面的。hibernate的初衷并不是提高程式的性能而是簡化程式開發流程，讓程式員把工作注意力關注在業務處理上---至少hibernate可以不用做異常處理。

回到樓主說你們的經理說hibernate的緩存會帶來問題，這隻能說沒有用好hibernate的緩存，甚至對它的緩存機制停留在模糊認識狀态。如果你不在意性能問題，完全可以禁用它的緩存都沒問題。

一句話：任何一種技術/架構的出現都是為了解決特定的問題，并非對先前技術的完全颠覆

--------------------------------------------------------------------------------------------

任何一個架構都不會比純的實作在性能上有優勢的..

如你所說的緩存等問題, 固然, hibernate做了相當好的處理, 但是, 這種通用架構, 一般都會為了通用型而損耗一些性能, 這是必然的, 為了良好的描述ORMapping, 必然會有一些你的業務可能用不到的東西仍然在耗費着一些性能, 是以, 當團隊開發人員技術能力允許, 時間允許時, 根據業務實作有針對性的資料通路, 資料更新, 緩存, 甚至事務, 對于性能來說是很有效的.

樓主的項目經理考慮的問題完全合理, 一個地區的電信項目, 估計使用者不會太少, 那麼對應的資料量就不會太砢碜吧....這個時候, 資料庫這邊的性能以及server的并發能力往往是比較明顯的兩個瓶頸.

以上純屬個人意見....請高手拍磚.

--------------------------------------------------------------------------------------------

hibernate 效率問題，看你怎麼去用，用的當，效率差不了多少，用不當，效率相差肯定很大，當然前提是大量資料，

1w條資料吧，hibernate 級聯查詢一張表，就會出現效率根本上的問題，但我們實際開發中，跟本不可能要查詢1w條資料，

頂多也就100條以下.如果真要查那麼多，可能就是你的系統有問題，和你的邏輯有問題，或者那個客戶腦子有問題.是以現在考慮，hibernate 可以從根本上解決你的問題..效率應不是我們考試的問題，如果你的做的是電子商務的大型網站，要大量查詢資料庫，可以考慮一下用ibatis.

--------------------------------------------------------------------------------------------

我雖然對hibernate沒實際應用經驗，但對jdbc有豐富的使用經驗，兩者的在概念、技術上還是比較清晰的。

而且剛好有六年的電信省集中業務支撐系統部分功能子產品的開發經曆，應該也算是所謂的主流ISV裡的老兵。

相對于一個地區級的OA其性能要求應該遠低于省集中的BOSS，我們經常碰到的一個性能問題就是Db伺服器忙死

，而App伺服器卻在休息，這個可能是完全面向資料庫的jdbc大量應用的而導緻的一個問題吧！另外為什麼不把某些簡單功能轉為hibernate其在人力教育訓練方面消耗較大，畢竟大環境是業務強于技術的原因有關。不過個人覺得這種o/r技術應該是趨勢，隻是現在還沒有一個統一的、可以完全替換jdbc類技術的技術出現而已

--------------------------------------------------------------------------------------------

批量的update/save/delete,hibernate效率要慢很多

用于查詢，正如樓上部分同志所說：如果你一次就要查詢w級以上的記錄，我個人認為你們的業務邏輯有問題。

通常的小資料量(幾十條)查詢，由于緩存，還是hibernate快一些的，而這正是我們實際中經常用到的。

最後，使用jdbc和hibernate的開發效率還是差很多的。

--------------------------------------------------------------------------------------------

效率和很多的方面都有關聯

怎麼就單和hibernate扯上關系了

那個門兒的認識也太淺了哇

--------------------------------------------------------------------------------------------

所謂批量問題，Hibernate還是提供了使用SQL的機會的，它沒強制你完全使用HQL。

真正可怕的是外鍵的映射，比如one-to-one、many-to-one等等。如果你用了，那麼性能肯定好不了。用即時加載，會大量的提可能用不到的資料；用延遲加載，會在延遲加載時進行很多次的查詢。是以，抛棄這部分功能後，你用Hibernate會快不少。

還有一個地方，就是它預設的是會提取你映射的所有字段。養成這個習慣的話，在一次提取資料比較多的時候，或者字段比較多、字段大小比較大的時候，會有影響。

其他地方的所謂性能損失，無非就是由ResultSet到Bean屬性的反射指派，或者從資料庫特定類型到Bean屬性類型的類型轉換，或者從HQL到SQL的翻譯等等一些雞毛蒜皮的小事了.

--------------------------------------------------------------------------------------------

一看你的項目就是很大，hibernate做聚集性的操作和緩存不同步，資料肯能會不一緻。

--------------------------------------------------------------------------------------------

Gavin king就是不想寫sql才寫的這個架構 哈哈 可能不适合你現在的項目吧 

這類架構他隻是讓程式開發更具對象化了 ORM嘛 可以屏蔽底層資料庫的一些差異 

但具Gavin king說他的hql語言效率還是很高的 2003年9月，Gavin King在他網站上向全世界發起挑戰：誰要是能對一段代碼用JDBC開發做到效率比hibernate高好多，就給他100美金。

--------------------------------------------------------------------------------------------

我們公司的項目都用Hibernate，效率還挺高的啊，靈活性也很大，批量操作的效率也很高，隻是你們沒有把握技巧罷了，

比如插入用batchupdate，删除就直接用原生sql了，當然你用對象去删除效率肯定低了，對于不經常變化的表采用緩存那是必要的，

是以我得出的結論是hibernate的效率并不低，隻是你們的優化工作沒做好。

--------------------------------------------------------------------------------------------

hibernate 做 批量資料操作時 貌似性能很低 。

批量資料操作時應該用ibatis

hibernate 的延遲加載和緩沖,hql是非常不錯的。

hibernate确實要好好的學學。

--------------------------------------------------------------------------------------------

hibernate和jdbc的使用各有自己的優勢，最重要的是如何權衡二者的利弊，達到一個最佳的平衡點，這就要求項目經理和架構師

對整個項目進行評估，選擇最适合自己的架構，這才是最主要的，最好的東西不一定适合自己

--------------------------------------------------------------------------------------------

hibernate其實它隻是做了一層包裝底層還是調用的jdbc就是在查詢主外建的時候先更具你在關聯類的對象去做一個轉換這樣可能在執

行時間上出現了一定的差額，hibernate的二級緩存就是為了放置預定義的一些sql語句和映射原資料是映射檔案中資料的拷貝而預定義

的sql語句是更具映射原資料推倒出來的（這裡的映射原資料就是映射檔案）和一級緩存就是為了存儲使用者已經查詢出的資料，如果查

詢的資料和前一次一樣使用hibernate的話不會再和資料庫進行互動，直接從緩存中取出資料顯示給使用者，如果在修改的時候使用者修改

前的資料存儲在一級緩存中和使用者修改的資料進行髒資料對比如果更改過進行送出，如果沒有更改過不進行送出，hibernate在做級聯

資料處理的時候還是很好的對于和使用jdbc的性質是一樣的隻是在hibernate中你通過程式給他一個對象在執行資料庫語句的時候

hibernate在解析這個對象的辨別時可能使用了一點時間如果大量資料時一定會出現時間差異，對于性能有一定的延時。

--------------------------------------------------------------------------------------------

各有各的好啊，項目越大就越應該用Hibernate，不然過度的關注細節，項目就不好做了，後期更新、維護也不好做了。

關注一下,我們的項目中,使用了hibernate,但是基本上和資料庫打交道用的都是HQL……不知道這個算不算對hibernate了解不夠[我們主要是覺得，使用hiberntae的表關聯加載延遲等等很麻煩，是以就主要使用了HQL了]，高人們指正