改善Hibernate性能――Hibernate的精细化使用总结

来源：互联网发布：python写股票软件编辑：程序博客网时间：2024/06/04 23:56

Hibernate使用不好就很容易出现性能问题。在这里总结一些方法以供参考。

1.按需加载

多对一的情况下一方的加载，一对多的情况多方的加载，默认都是延迟加载，为避免产生多条语句而导致多次DB往返，可以改变抓取策略，让Hibernate采用表连接来一次获取。例如，Item和History是一对多。

使用Hsql

Java代码

From Item item join fetch item.historys

使用Crerteria

Java代码

session. createCriteria(History.class).setFetchMode("item", FetchMode.JOIN).list();

2.采用多方进行管理，对多方进行筛选

一对多的情况下多方的加载。从一方去加载多方，多方会是一个Full List，默认不会对其进行DB级别的筛选。为了弥补性能，采用多方来表达业务逻缉会更好。有时候这不得不牺牲高层次的业务语义为代价的，因为从业务的角度来看用一方去表达更自然更清晰。例如：只抓取Item符合某种条件的History，而不是所有History的集合。这时候可以设定属性where来指定SQL语句来筛选。

Xml代码

<set name="historys" inverse="true" lazy="true" table="HISTROY" where="ACTION = 1">...</set>

对于一对多的特殊化：一对一。集合中符合条件的对象只有一个。虽然可以设定where来过滤，又或者由多方去管理，但是，用一对多去映射明显不符合业务语义。例如，要求抓取Item并抓取其最新的History，其余的History忽略。个人认为，这种复杂条件动态表关联查询，查询性能容易不理想。DB适度冗余便可以了。

3.使用公式

悲剧是这样产生的：获取Item所有History的数量。

Java代码

item.getHistorys().size()

如果是个Item List查询的话，行返回数量可能是n*m，简直是惨不忍睹。可以用公式(formula)这个属性，包含一个子查询语句来映射属性，当然，这个属性对Hibernate来说是只读的。

Xml代码

<property name="incompletedActionCount" type="int">
<formula>
(
select count(*) from HISTROY h where h.ITEM_ID = ITEM_ID
)
</formula>
</property>

启用show_sql可以看到，Hibernate会自动给ITEM_ID加上主表的别名，不用担心列名冲突。

4.细粒度的映射

ibatis可以针对某个经过调整的SQL Statement，定制一个专属的结果集映射。Hibernate也可以很灵活，持久化对象与数据表之间的可以进行多次不同的映射，他们之间通过entity-name来进行区分。entity-name我是理解成为对象不同环境下的profile标识，正如一个人很复杂具有多面性的。例如，对于基础数据表，不同模块的需要应用不同的粒度映射；在集合的映射方面，使用元素集合 / 组件集合而非持久化对象集合来映射；在某些模块，对某些不需要进行插入更新的属性设为insert="false",update="false"，减少对宽表更新所影响到的列。

XML配置:

Xml代码

<class name="xx.yy.Item" table="ITEM" entity-name=" Item.moduleName.functionName">
...
<set name="historys" inverse="true" lazy="true" table="HISTORY" where="ACTION = 0">
...
<one-to-many entity-name=" History.moduleName.functionName" />
</set>
</class>
<class name="xx.yy.History" table="History" entity-name=" History.moduleName.functionName">
...
<many-to-one name="item" entity-name="Item.moduleName.functionName">
...
</many-to-one>
</class>

Java Code:

Java代码

session.get("Item.moduleName.functionName", "ItemIdValue");

Java代码

session.createQuery("from Item.moduleName.functionName");

5.命名查询

除此之外，Hibernate也可以像ibatis一样SQL语句XML化来进行个性化定义。命名查询(Named Query)有ibatis的影子。使用DB专有特性的原生SQL来调整性能，可以用这种方式。命名查询返回的列必须和持久化对象的映射的全部属性一应对应，如果返回的是Hibernate托管对象的话。这往往需要结合细粒度映射一起进行。

Java代码

<resultset name="">
<return alias="alias in the sql" entity-name="entity name"></return>
<return-join alias="alias in the sql" property="entity-alias.property-path"></return-join>
</resultset>

Java代码

<sql-query name="sql query name">
…
</sql-query>

Java代码

<span style="white-space: normal; background-color: #ffffff;"> </span>session.getNamedQuery("sqlQueryName").list();

6.其他一些技巧集锦

A.把一级缓存，对象生命周期，自动脏检查，自动级联等ORM对象容器的高级功能阉割掉，让Hibernate退成ibatis/spring-jdbc。大批量更新的时候启用改善会明显。

Java代码

<span style="white-space: normal; background-color: #ffffff;">sessionFactory.openStatelessSession()</span>

B.返回非hibernate托管对象。可以不受返回映射列数目的限制，返回的是非字节码增强对象。不过ms仅支持简单命名的值类型属性，不支持引用对象类型的映射，用处有限。

Java代码

session.getNamedQuery("xx")
.setResultTransformer(Transformers.aliasToBean(XXDTO.class))
.list()

C.DML风格对象更新

启用dynamic-update并不一定带来性能的改善。瞬时/脱管态对象的更新会额外多一次查询。这时候，可以采用DML式更新来指明真正需要更新的列，减少更新影响的列。这个API容易产生歧义，又是query又是update，比较别扭。

Java代码

session.createQuery("xxx")
executeUpdate();

D.获取Hibernate映射元数据。

可以用来扩展hibernate功能 / 再造ORM轮子 / 自定义代码生成模版。详细看Hiberante文档

Java代码

sessionfactory.getClassMetadata(XX.class)

最后，附上Hibernate推荐最佳实践。有些问题不仅仅是性能问题，性能问题只是对ORM的理解和使用的问题的集中体现。

设计细颗粒度的持久类并且使用<component> 来实现映射：

使用一个 Address 持久类来封装　street，suburb，state，postcode。这将有利于代码重用和简化代码重构（refactoring）的工作。

对持久类声明标识符属性（identifierproperties）：

Hibernate 中标识符属性是可选的，不过有很多原因来说明你应该使用标识符属性。我们建议标识符应该是“人造”的（自动生成，不涉及业务含义）。

使用自然键（naturalkeys）标识：

对所有的实体都标识出自然键，用 <natural-id> 进行映射。实现 equals() 和 hashCode()，在其中用组成自然键的属性进行比较。

为每个持久类写一个映射文件：

不要把所有的持久类映射都写到一个大文件中。把 com.eg.Foo 映射到 com/eg/Foo.hbm.xml中。在团队开发环境中，这一点尤其重要。

把映射文件作为资源加载：

把映射文件和他们的映射类放在一起进行部署。

考虑把查询字符串放在程序外面：

如果你的查询中调用了非ANSI 标准的 SQL 函数，那么这条实践经验对你适用。把查询字符串放在映射文件中可以让程序具有更好的可移植性。

使用绑定变量

就像在 JDBC 编程中一样，应该总是用占位符 "?" 来替换非常量值，不要在查询中用字符串值来构造非常量值。你也应该考虑在查询中使用命名参数。

不要自己来管理 JDBC 连接：

Hibernate 允许应用程序自己来管理 JDBC 连接，但是应该作为最后没有办法的办法。如果你不能使用Hibernate 内建的connections providers，那么考虑实现自己来实现org.hibernate.connection.ConnectionProvider。

考虑使用用户自定义类型（customtype）：

假设你有一个 Java 类型，来自某些类库，需要被持久化，但是该类没有提供映射操作需要的存取方法。那么你应该考虑实现 org.hibernate.UserType 接口。这种办法使程序代码写起来更加自如，不再需要考虑类与 Hibernate type 之间的相互转换。

在性能瓶颈的地方使用硬编码的JDBC：

在系统中对性能要求很严格的一些部分，某些操作也许直接使用 JDBC 会更好。但是请先确认这的确是一个瓶颈，并且不要想当然认为 JDBC 一定会更快。如果确实需要直接使用 JDBC，那么最好打开一个 Hibernate Session 然后将 JDBC 操作包裹为 org.hibernate.jdbc.Work 并使用 JDBC 连接。按照这种办法你仍然可以使用同样的transaction 策略和底层的 connection provider。

理解 Session 冲刷（flushing）：

Session 会不时的向数据库同步持久化状态，如果这种操作进行的过于频繁，性能会受到一定的影响。有时候你可以通过禁止自动 flushing，尽量最小化非必要的 flushing 操作，或者更进一步，在一个特定的transaction 中改变查询和其它操作的顺序。

在三层结构中，考虑使用脱管对象（detached object）：

当使用一个 servlet/ session bean 类型的架构的时候, 你可以把已加载的持久对象在session bean 层和 servlet / JSP 层之间来回传递。使用新的 session 来为每个请求服务，使用Session.merge() 或者Session.saveOrUpdate() 来与数据库同步。

在两层结构中，考虑使用长持久上下文（long persistence contexts）：

为了得到最佳的可伸缩性，数据库事务（Database Transaction）应该尽可能的短。但是，程序常常需要实现长时间运行的“应用程序事务（Application Transaction）”，包含一个从用户的观点来看的原子操作。这个应用程序事务可能跨越多次从用户请求到得到反馈的循环。用脱管对象（与 session 脱离的对象）来实现应用程序事务是常见的。或者，尤其在两层结构中，把 Hibernate Session 从 JDBC 连接中脱离开，下次需要用的时候再连接上。绝不要把一个 Session 用在多个应用程序事务（Application Transaction）中，否则你的数据可能会过期失效。

不要把异常看成可恢复的：

这一点甚至比“最佳实践”还要重要，这是“必备常识”。当异常发生的时候，必须要回滚Transaction ，关闭 Session。如果你不这样做的话，Hibernate 无法保证内存状态精确的反应持久状态。尤其不要使用 Session.load() 来判断一个给定标识符的对象实例在数据库中是否存在，应该使用 Session.get() 或者进行一次查询。

对于关联优先考虑 lazyfetching：

谨慎的使用主动抓取（eagerfetching）。对于关联来说，若其目标是无法在第二级缓存中完全缓存所有实例的类，应该使用代理（proxies）与/或具有延迟加载属性的集合（lazy collections）。若目标是可以被缓存的，尤其是缓存的命中率非常高的情况下，应该使用lazy="false"，明确的禁止掉 eager fetching。如果那些特殊的确实适合使用 join fetch 的

场合，请在查询中使用left join fetch。

使用 opensession in view 模式，或者执行严格的装配期（assemblyphase）策略来避免再次抓取数据带来的问题：Hibernate让开发者们摆脱了繁琐的Data Transfer Objects（DTO）。在传统的 EJB 结构中，DTO 有双重作用：首先，他们解决了 entity bean 无法序列化的问题；其次，他们隐含地定义了一个装配期，在此期间，所有view层需要用到的数据，都被抓取、集中到了 DTO 中，然后控制才被装到表示层。Hibernate终结了第一个作用。然而，除非你做好了在整个渲染过程中都维护一个打开的持久化上下文（session）的准备，你仍然需要一个装配期（想象一下，你的业务方法与你的表示层有严格的契约，数据总是被放置到脱管对象中）。这并非是 Hibernate 的限制，这是实现安全的事务化数据访问的基本需求。

考虑把 Hibernate 代码从业务逻辑代码中抽象出来：

把 Hibernate 的数据存取代码隐藏到接口（interface）的后面，组合使用 DAO 和 ThreadLocal Session 模式。通过 Hibernate 的UserType，你甚至可以用硬编码的 JDBC 来持久化那些本该被 Hibernate 持久化的类。然而，该建议更适用于规模足够大应用软件中，对于那些只有 5 张表的应用程序并不适合。

不要用怪异的连接映射：

多对多连接用得好的例子实际上相当少见。大多数时候你在“连接表”中需要保存额外的信息。这种情况下，用两个指向中介类的一对多的连接比较好。实际上，我们认为绝大多数的连接是一对多和多对一的。因此，你应该谨慎使用其它连接风格。

偏爱双向关联：

单向关联更加难于查询。在大型应用中，几乎所有的关联必须在查询中可以双向导航。