关于hibernate效率问题讨论的整理
关于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了]，高人们指正
