?

1. 简介
Hibernate是最流行提供数据固话和查询的ORM引擎之一。

在你的项目中引入Hibernate并使其可以工作是非常简单的。然而，使其工作的非常好则需要会费很多的时间以及大量的经验。

通过我们使用Hibernate3.3.1以及Oracle9i的energy项目中的一些例子，这篇文章介绍了Hibernate调优用到的一些技术。

我们假设您已对Hibernate具有最基本的了解。对于某些在Hibernate官方文档(HRD)或者其他的调优文章中有所讲述，我们将仅仅提供一个文档的引用以及从一个不同视角的简单解释。我们主要聚焦在一些很有效但是又缺乏文档的条有方法。

?

2. Hibernate性能调优

调优是围绕着软件开发生命周期(SDLC)所有阶段的一个持续不断的过程。在一个典型的利用Hibernate做固化的J2EE应用中，调优覆盖下面几个领域：

• 业务规则调优
• 设计调优
• Hibernate调优
• java GC调优
• 应用容器调优
• 底层系统，如数据库和操作系统的调优。

在没有一个规划好的技术方案的情况下就对以上几个方面进行调优将会是很耗时间，并且可能是不起作用的。优秀的调优方案中一个很重要的方面就是确定调优领域的优先级。根据帕拉图原理（亦即二八原则）的解释，80%的应用性能提高来自于所有性能问题中最主要的20%[5]。

相对于基于网络的访问，基于内存和CPU的访问具有较低的延迟以及较好的吞吐率。鉴于此， 基于IO的Hibernate调优以及底层系统IO部分的调优优先于基于内存和CPU的GC调优以及底层系统中基于内存和CPU部分的调优。

示例一

?

?

?

优秀调优方案的另外一个重要问题就是决定何时做优化。【4】

积极优化的倡导者建议从项目的开始就进行优化，例如在业务规则和设计阶段，在整个项目开发生命周期（SDLC）中持续优化，因为他们认为i，在后期改变业务规则和设计的代价经常会非常大。

消极优化的倡导者则建议在SDLC的后期进行优化。因为他们认为，早期的优化将会使设计和编码复杂化。他们经常以Donald Knuth的“过早的优化时罪恶的根源（premature optimization is the root of all evil）”作为论据【6】

我们需要一个调优和编码的权衡。根据笔者的经验，早期的适当优化，将会带来更谨慎的设计以及更仔细的编码。许多项目由于应用调优而失败，原因就是之前提到的“过早优化”被断章取义，从而导致优化被推到项目的极端后期或者投入非常少的资源。

不过，也不可能进行很多的前期优化，因为如果没有事先的分析(profiling)，你根本不知道应用的瓶颈在哪里，而且在此之上，应用经常还在不断的变化中。

通过对多层的企业级应用的监控可以发现，大部分的应用平均仅仅占用了20%-50%的CPU。剩余的CPU仅仅是超额得等待数据库和网络相关的IO。

基于以上的分析，我们推断出：与业务规则和设计一起的Hibernate调优属于二八原则中的20%，他们应该具有更高的优先级。

如下是一个有效的行为：

1. 确定一些主要的瓶颈-可以预见的是大部分的瓶颈出现在Hibernate，业务规则和设计当中(具体的数目取决于你调优的目标，通常3到5个是一个不错的开端)。
2. 修改你的应用来消除这些瓶颈。
3. 测试你的应用，然后重复以上步骤，直到达到你的调优目标。

关于性能调优策略的更一般性建