jdbc与hibernate的优毛病斗劲（转载的精华）
添加时间:2013-7-8 点击量:
一 Hibernate是JDBC的轻量级的对象封装，它是一个自力的对象持久层框架，和App Server，和EJB没有什么必定的接洽。Hibernate可以用在任何JDBC可以应用的场合，例如Java应用法度的数据库接见代码，DAO接口 的实现类，甚至可所以BMP里面的接见数据库的代码。从这个意义上来说，Hibernate和EB不是一个局限的器材，也不存在非此即彼的关系。
二、Hibernate是一个和JDBC亲近接洽关系的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有必然的关系，然则和应用它的Java法度，和App Server没有任何干系，也不存在兼容性题目。
三、Hibernate不克不及用来直接和Entity Bean做对比，只有放在全部J2EE项目标框架中才干斗劲。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的调换者呈现的，而 不是Entity Bean的调换者呈现的，让我再列一次我已经列n次的框架布局：
传统的架构：
1） Session Bean <-> Entity Bean <-> DB
为懂得决机能障碍的调换架构：
2） Session Bean <-> DAO <-> JDBC <-> DB
应用Hibernate来进步上方架构的开辟效力的架构：
3） Session Bean <-> DAO <-> Hibernate <-> DB
就上方3个架构来解析：
1、内存消费：采取JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。
2、运行效力： 若是JDBC的代码写的很是优化，那么JDBC架构运行效力高，然则实际项目中，这一点几乎做不到，这须要法度员很是精通JDBC，应用Batch语 句，调剂PreapredStatement的Batch Size和Fetch Size等参数，以及在须要的景象下采取成果集cache等等。而一般景象下法度员是做不到这一点的。是以Hibernate架构发挥解析出快的运行效力。 EB的架构效力会差的很远。
3、开辟效力：在有JBuilder的支撑下以及简单的项目，EB架构开辟效力高，JDBC次之，Hibernate最差。然则在大的项目，希罕是持久层关系映射很错杂的景象下，Hibernate效力高的惊人，JDBC次之，而EB架构很可能会失败。
4、分布式，安然搜检，集群，负载均衡的支撑 因为有SB做为Facade，3个架构没有差别。
四、EB和Hibernate进修难度在哪里？
EB的难度在哪里？不在错杂的XML设备文件上，而在于EB应用稍微不慎，就有严重的机能障碍。所以难在你须要进修很多EJB设计模式来避开机能题目，须要进修App Server和EB的设备来优化EB的运行效力。做EB的开辟工作，法度员的大项目组精力都被放到了EB的机能题目上了，反而没有更多的精力存眷本身就首要投入精力去推敲的对象持久层的设计上来。
Hibernate难在哪里？不在Hibernate本身的错杂，实际上Hibernate很是的简单，难在Hibernate太灵活了。 当你用EB来实现持久层的时辰，你会发明EB其实是太笨拙了，笨拙到你底子没有什么可以选择的余地，所以你底子就不消花费精力去设计规划，去均衡规划的好 坏，去费思维推敲选择哪个规划，因为只有独一的规划摆在你面前，你只能这么做，没得选择。Hibernate相反，它太灵活了，雷同的题目，你至少可以设 计出十几种规划来解决，所以特此外犯难，毕竟用这个，还是用那个呢？这些规划之间到底有什么差别呢？他们的运行道理有什么不合？运行效力哪个斗劲好？光是 主键生成，就有七八种规划供你选择，你难堪不难堪？凑集属性可以用Set，可以用List，还可以用Bag，到底哪个效力高，你难堪不难堪？查询可以用 iterator，可以用list，哪个好，有什么差别？你难堪不难堪？复合主键你可以直接在hbm里面设备，也可以自定义CustomerType，哪 种斗劲好些？你难堪不难堪？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么景象下用哪种规划斗劲 好，你难堪不难堪？ 这个列表可以一向开列下去，直到你不想再看下去为止。当你面前摆着无数的目炫纷乱的规划的时辰，你会感觉幸福呢？还是悲哀呢？若是你是一个负责的法度员， 那么你必然会细心研究每种规划的差别，每种规划的效力，每种规划的实用处合，你会感觉你已经陷入进去拔不出来了。若是是用EB，你第一秒种就已经做出了决 定，底子没得选择，比如说凑集属性，你只能用Collection，若是是Hibernate，你会在Bag，List和Set之间往返迟疑不决，甚至搞 不清楚的话，法度都没有办法写。
补充:
JDBC与Hibernate在机能上比拟，JDBC灵活性有上风。而Hibernate在易学性，易用性上有些上风。当用到很多错杂的多表联查和错杂的数据库操纵时，JDBC有上风。
雷同点：
◆两者都是JAVA的数据库操纵中心件。
◆两者对于数据库进行直接操纵的对象都不是线程安然的，都须要及时封闭。
◆两者都可以对数据库的更新操纵进行显式的事务处理惩罚。
不合点：
◆应用的SQL说话不合：JDBC应用的是基于关系型数据库的标准SQL说话，Hibernate应用的是HQL（Hibernate query language）说话
◆操纵的对象不合：JDBC操纵的是数据，将数据经由过程SQL语句直接传送到数据库中履行，Hibernate操纵的是持久化对象，由底层持久化对象的数据更新到数据库中。
◆数据状况不合：JDBC操纵的数据是“瞬时”的，变量的值无法与数据库中的值对峙一致，而Hibernate操纵的数据是可持久的，即持久化对象的数据属性的值是可以跟数据库中的值对峙一致的。
JDBC与Hibernate读取机能
1、JDBC仍然是快的接见体式格式，非论是Create还是Read操纵，都是JDBC快。
2、Hibernate应用uuid.hex机关主键，机能稍微有点丧失，然则不大。
3、Create操纵，JDBC在应用批处理惩罚的体式格式下速度比Hibernate快，应用批处理惩罚体式格式耗用JVM内存比不应用批处理惩罚体式格式要多得多。
4、读取数据，Hibernate的Iterator速度很是迟缓，因为他是每次next的时辰才去数据库取数据，这一点从调查任务经管器的java过程占用内存的变更也可以看得很清楚，内存是几十K几十K的增长。
5、读取数据，Hibernate的List速度很快，因为他是一次性把数据取完，这一点从调查任务经管器的java过程占用内存的变更也可以看得很清楚，内存几乎是10M的10M的增长。
6、JDBC读取数据的体式格式和Hibernate的List体式格式是一样的（这跟JDBC驱动有很大关系，不合的JDBC驱动，成果会很不一样），这 从调查java过程内存变更可以断定出来，因为JDBC不须要像Hibernate那样机关一堆Cat对象实例，所以占用JVM内存要比 Hibernate的List体式格式可能少一半阁下。
7、Hibernate的Iterator体式格式并非一无可取，它合适于从大的成果集中拔取少量的数据，即不须要占用很多内存，又可以敏捷获得成果。别的Iterator合适于应用JCS缓冲。终极结论：
因为MySQL的JDBC驱动的重大缺点，使得测试成果变得毫无意义，不具备任何参考价值，只是我们可以或容许能断定出一些结论：
一、精心编写的JDBC无论如何都是快的。
二、Hibernate List和Iterator实用的场合不合，不存在孰优孰劣的题目
我小我认为Hibernate Iterator是JDBC Result的封装，Hibernate List是Scrollable Result的封装，所以我揣摩，若是在Oracle或者DB2上方做同样的Read测试，若是成果集小于FetchSize，4者在速度上应当都不会有 差别；若是成果集大于FetchSize的话，然则不是FetchSize的很多倍，速度排名应当是：
JDBC Scrollable Result （消费时候起码） < Hibernate List < JDBC Result < Hibernate Iterator
若是成果集很是大，然则只取成果集中的项目组记录，那么速度排名：
JDBC Result < Hibernate Iterator < JDBC Scrollable Result < Hibernate List
为了避免造成误导，我最后夸大一下我的结论：
一、“精心编写”的JDBC必然是机能好的
实际上，不管CMP，Hibernate，JDO等等，所有的ORM都是对JDBC的封装，CMP则是一个重量级封装，JDO中度封 装，Hibernate是轻量级的封装。从理论上来说，ORM永远也不成能比JDBC机能好。就像任何高等说话的运行机能永远也不会好过汇编说话一个道 理。
对于Create和Update操纵来说，因为通俗的Java法度员未必会应用JDBC的Batch的功能，所以Hibernate会发挥解析出跨越JDBC的运行速度。
对于Read的操纵来说，ORM广泛都邑带有双层缓冲，即PrepreadStatement缓冲和ResultSet缓冲，而JDBC本身没有缓 冲机制，在应用连接池的景象下，一些连接池将会供给PrepreadStatement缓冲，有的甚至供给ResultSet缓冲，然则广泛景象 下，Java法度员一般都不会推敲到在写JDBC的时辰优化缓冲，并且如许做也不太实际，所以在某些景象下，ORM会发挥解析出跨越JDBC的Read速度。
二、Hibernate List和Iterator体式格式的斗劲
JDBC与Hibernate在测试中想要重点查核的方面是 List与Iterator，然则因为JDBC驱动题目，成果变的很不成信，不过仍然可以获得一些有效的结论。
Read操纵包含两步：第一步是把数据库的数据取出，机关成果集，把数据放入到成果集中；第二步是遍历成果集，取每行数据。
List体式格式是1次性把所有的数据全部取到内存中，机关一个超大的成果集，首要的时候开销是这一步，这一步的时候开销要远远跨越JDBC和 Iterator体式格式下机关成果集的时候开销，并且内存开销也很惊人；而对成果集的遍历操纵，速度则是很是的惊人（从上方的测试成果来看，30万记录的内 存遍历不到100ms，因为这一步不受JDBC影响，是以成果可托）。是以，List体式格式合适于对成果集进行反复多次操纵的景象，例如分页显示，往后往前 遍历，跳到第一行，跳到最后一行等等。
Iterator体式格式只取记录id到内存中，并没有把所稀有据取到内存中，是以机关成果集的时候开销很小，比JDBC和List体式格式都要少，并且内 存开销也小很多。而对成果集的遍历的操纵的时辰，Iterator仍然要接见数据库，所有首要的时候开销都花在这里。是以，Iterator体式格式合适于只 对成果集进行1次遍历操纵的景象，并且Iterator体式格式希罕合适于从超大成果集中取少量数据，这种景象Iterator机能很是好。
别的Iterator体式格式可以哄骗JCS缓冲，在应用缓冲的景象下Iterator体式格式的遍历操纵速度将不受数据库接见速度的影响，获得的提 升。Hibernate Iterator JCS体式格式应当是快的，Hibernate List速度与JDBC斗劲接近，而Hibernate Iterator速度还是慢的离谱。别的JDBC和List受到Fetch Size的影响很大，当Fetch Size大于50的时辰，速度有很是明显的提拔，而Hibernate Iterator的速度似乎不受Fetch Size的影响
本文来自CSDN博客，转载请标明出处：http://www.cnblogs.com/frankliiu-java/articles/1915994.html
我们永远不要期待别人的拯救，只有自己才能升华自己。自己已准备好了多少容量，方能吸引对等的人与我们相遇，否则再美好的人出现、再动人的事情降临身边，我们也没有能量去理解与珍惜，终将擦肩而过。—— 姚谦《品味》
一 Hibernate是JDBC的轻量级的对象封装，它是一个自力的对象持久层框架，和App Server，和EJB没有什么必定的接洽。Hibernate可以用在任何JDBC可以应用的场合，例如Java应用法度的数据库接见代码，DAO接口 的实现类，甚至可所以BMP里面的接见数据库的代码。从这个意义上来说，Hibernate和EB不是一个局限的器材，也不存在非此即彼的关系。
二、Hibernate是一个和JDBC亲近接洽关系的框架，所以Hibernate的兼容性和JDBC驱动，和数据库都有必然的关系，然则和应用它的Java法度，和App Server没有任何干系，也不存在兼容性题目。
三、Hibernate不克不及用来直接和Entity Bean做对比，只有放在全部J2EE项目标框架中才干斗劲。并且即使是放在软件整体框架中来看，Hibernate也是做为JDBC的调换者呈现的，而 不是Entity Bean的调换者呈现的，让我再列一次我已经列n次的框架布局：
传统的架构：
1） Session Bean <-> Entity Bean <-> DB
为懂得决机能障碍的调换架构：
2） Session Bean <-> DAO <-> JDBC <-> DB
应用Hibernate来进步上方架构的开辟效力的架构：
3） Session Bean <-> DAO <-> Hibernate <-> DB
就上方3个架构来解析：
1、内存消费：采取JDBC的架构2无疑是最省内存的，Hibernate的架构3次之，EB的架构1最差。
2、运行效力： 若是JDBC的代码写的很是优化，那么JDBC架构运行效力高，然则实际项目中，这一点几乎做不到，这须要法度员很是精通JDBC，应用Batch语 句，调剂PreapredStatement的Batch Size和Fetch Size等参数，以及在须要的景象下采取成果集cache等等。而一般景象下法度员是做不到这一点的。是以Hibernate架构发挥解析出快的运行效力。 EB的架构效力会差的很远。
3、开辟效力：在有JBuilder的支撑下以及简单的项目，EB架构开辟效力高，JDBC次之，Hibernate最差。然则在大的项目，希罕是持久层关系映射很错杂的景象下，Hibernate效力高的惊人，JDBC次之，而EB架构很可能会失败。
4、分布式，安然搜检，集群，负载均衡的支撑 因为有SB做为Facade，3个架构没有差别。
四、EB和Hibernate进修难度在哪里？
EB的难度在哪里？不在错杂的XML设备文件上，而在于EB应用稍微不慎，就有严重的机能障碍。所以难在你须要进修很多EJB设计模式来避开机能题目，须要进修App Server和EB的设备来优化EB的运行效力。做EB的开辟工作，法度员的大项目组精力都被放到了EB的机能题目上了，反而没有更多的精力存眷本身就首要投入精力去推敲的对象持久层的设计上来。
Hibernate难在哪里？不在Hibernate本身的错杂，实际上Hibernate很是的简单，难在Hibernate太灵活了。 当你用EB来实现持久层的时辰，你会发明EB其实是太笨拙了，笨拙到你底子没有什么可以选择的余地，所以你底子就不消花费精力去设计规划，去均衡规划的好 坏，去费思维推敲选择哪个规划，因为只有独一的规划摆在你面前，你只能这么做，没得选择。Hibernate相反，它太灵活了，雷同的题目，你至少可以设 计出十几种规划来解决，所以特此外犯难，毕竟用这个，还是用那个呢？这些规划之间到底有什么差别呢？他们的运行道理有什么不合？运行效力哪个斗劲好？光是 主键生成，就有七八种规划供你选择，你难堪不难堪？凑集属性可以用Set，可以用List，还可以用Bag，到底哪个效力高，你难堪不难堪？查询可以用 iterator，可以用list，哪个好，有什么差别？你难堪不难堪？复合主键你可以直接在hbm里面设备，也可以自定义CustomerType，哪 种斗劲好些？你难堪不难堪？对于一个表，你可以选择单一映射一个对象，也可以映射成父子对象，还可以映射成两个1:1的对象，在什么景象下用哪种规划斗劲 好，你难堪不难堪？ 这个列表可以一向开列下去，直到你不想再看下去为止。当你面前摆着无数的目炫纷乱的规划的时辰，你会感觉幸福呢？还是悲哀呢？若是你是一个负责的法度员， 那么你必然会细心研究每种规划的差别，每种规划的效力，每种规划的实用处合，你会感觉你已经陷入进去拔不出来了。若是是用EB，你第一秒种就已经做出了决 定，底子没得选择，比如说凑集属性，你只能用Collection，若是是Hibernate，你会在Bag，List和Set之间往返迟疑不决，甚至搞 不清楚的话，法度都没有办法写。
补充:
JDBC与Hibernate在机能上比拟，JDBC灵活性有上风。而Hibernate在易学性，易用性上有些上风。当用到很多错杂的多表联查和错杂的数据库操纵时，JDBC有上风。
雷同点：
◆两者都是JAVA的数据库操纵中心件。
◆两者对于数据库进行直接操纵的对象都不是线程安然的，都须要及时封闭。
◆两者都可以对数据库的更新操纵进行显式的事务处理惩罚。
不合点：
◆应用的SQL说话不合：JDBC应用的是基于关系型数据库的标准SQL说话，Hibernate应用的是HQL（Hibernate query language）说话
◆操纵的对象不合：JDBC操纵的是数据，将数据经由过程SQL语句直接传送到数据库中履行，Hibernate操纵的是持久化对象，由底层持久化对象的数据更新到数据库中。
◆数据状况不合：JDBC操纵的数据是“瞬时”的，变量的值无法与数据库中的值对峙一致，而Hibernate操纵的数据是可持久的，即持久化对象的数据属性的值是可以跟数据库中的值对峙一致的。
JDBC与Hibernate读取机能
1、JDBC仍然是快的接见体式格式，非论是Create还是Read操纵，都是JDBC快。
2、Hibernate应用uuid.hex机关主键，机能稍微有点丧失，然则不大。
3、Create操纵，JDBC在应用批处理惩罚的体式格式下速度比Hibernate快，应用批处理惩罚体式格式耗用JVM内存比不应用批处理惩罚体式格式要多得多。
4、读取数据，Hibernate的Iterator速度很是迟缓，因为他是每次next的时辰才去数据库取数据，这一点从调查任务经管器的java过程占用内存的变更也可以看得很清楚，内存是几十K几十K的增长。
5、读取数据，Hibernate的List速度很快，因为他是一次性把数据取完，这一点从调查任务经管器的java过程占用内存的变更也可以看得很清楚，内存几乎是10M的10M的增长。
6、JDBC读取数据的体式格式和Hibernate的List体式格式是一样的（这跟JDBC驱动有很大关系，不合的JDBC驱动，成果会很不一样），这 从调查java过程内存变更可以断定出来，因为JDBC不须要像Hibernate那样机关一堆Cat对象实例，所以占用JVM内存要比 Hibernate的List体式格式可能少一半阁下。
7、Hibernate的Iterator体式格式并非一无可取，它合适于从大的成果集中拔取少量的数据，即不须要占用很多内存，又可以敏捷获得成果。别的Iterator合适于应用JCS缓冲。终极结论：
因为MySQL的JDBC驱动的重大缺点，使得测试成果变得毫无意义，不具备任何参考价值，只是我们可以或容许能断定出一些结论：
一、精心编写的JDBC无论如何都是快的。
二、Hibernate List和Iterator实用的场合不合，不存在孰优孰劣的题目
我小我认为Hibernate Iterator是JDBC Result的封装，Hibernate List是Scrollable Result的封装，所以我揣摩，若是在Oracle或者DB2上方做同样的Read测试，若是成果集小于FetchSize，4者在速度上应当都不会有 差别；若是成果集大于FetchSize的话，然则不是FetchSize的很多倍，速度排名应当是：
JDBC Scrollable Result （消费时候起码） < Hibernate List < JDBC Result < Hibernate Iterator
若是成果集很是大，然则只取成果集中的项目组记录，那么速度排名：
JDBC Result < Hibernate Iterator < JDBC Scrollable Result < Hibernate List
为了避免造成误导，我最后夸大一下我的结论：
一、“精心编写”的JDBC必然是机能好的
实际上，不管CMP，Hibernate，JDO等等，所有的ORM都是对JDBC的封装，CMP则是一个重量级封装，JDO中度封 装，Hibernate是轻量级的封装。从理论上来说，ORM永远也不成能比JDBC机能好。就像任何高等说话的运行机能永远也不会好过汇编说话一个道 理。
对于Create和Update操纵来说，因为通俗的Java法度员未必会应用JDBC的Batch的功能，所以Hibernate会发挥解析出跨越JDBC的运行速度。
对于Read的操纵来说，ORM广泛都邑带有双层缓冲，即PrepreadStatement缓冲和ResultSet缓冲，而JDBC本身没有缓 冲机制，在应用连接池的景象下，一些连接池将会供给PrepreadStatement缓冲，有的甚至供给ResultSet缓冲，然则广泛景象 下，Java法度员一般都不会推敲到在写JDBC的时辰优化缓冲，并且如许做也不太实际，所以在某些景象下，ORM会发挥解析出跨越JDBC的Read速度。
二、Hibernate List和Iterator体式格式的斗劲
JDBC与Hibernate在测试中想要重点查核的方面是 List与Iterator，然则因为JDBC驱动题目，成果变的很不成信，不过仍然可以获得一些有效的结论。
Read操纵包含两步：第一步是把数据库的数据取出，机关成果集，把数据放入到成果集中；第二步是遍历成果集，取每行数据。
List体式格式是1次性把所有的数据全部取到内存中，机关一个超大的成果集，首要的时候开销是这一步，这一步的时候开销要远远跨越JDBC和 Iterator体式格式下机关成果集的时候开销，并且内存开销也很惊人；而对成果集的遍历操纵，速度则是很是的惊人（从上方的测试成果来看，30万记录的内 存遍历不到100ms，因为这一步不受JDBC影响，是以成果可托）。是以，List体式格式合适于对成果集进行反复多次操纵的景象，例如分页显示，往后往前 遍历，跳到第一行，跳到最后一行等等。
Iterator体式格式只取记录id到内存中，并没有把所稀有据取到内存中，是以机关成果集的时候开销很小，比JDBC和List体式格式都要少，并且内 存开销也小很多。而对成果集的遍历的操纵的时辰，Iterator仍然要接见数据库，所有首要的时候开销都花在这里。是以，Iterator体式格式合适于只 对成果集进行1次遍历操纵的景象，并且Iterator体式格式希罕合适于从超大成果集中取少量数据，这种景象Iterator机能很是好。
别的Iterator体式格式可以哄骗JCS缓冲，在应用缓冲的景象下Iterator体式格式的遍历操纵速度将不受数据库接见速度的影响，获得的提 升。Hibernate Iterator JCS体式格式应当是快的，Hibernate List速度与JDBC斗劲接近，而Hibernate Iterator速度还是慢的离谱。别的JDBC和List受到Fetch Size的影响很大，当Fetch Size大于50的时辰，速度有很是明显的提拔，而Hibernate Iterator的速度似乎不受Fetch Size的影响
本文来自CSDN博客，转载请标明出处：http://www.cnblogs.com/frankliiu-java/articles/1915994.html
我们永远不要期待别人的拯救，只有自己才能升华自己。自己已准备好了多少容量，方能吸引对等的人与我们相遇，否则再美好的人出现、再动人的事情降临身边，我们也没有能量去理解与珍惜，终将擦肩而过。—— 姚谦《品味》
