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

 

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

 

 

 

• 1.按需加载

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

使用Hsql

 

From Item item join fetch item.historys

使用Crerteria

 

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

 

 

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

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

 

 

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

 

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

 

 

• 3.使用公式

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

 

 

item.getHistorys().size()

 

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

 

<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配置:

 

 

<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:

 

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

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

 

 

• 5.命名查询

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

 

<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>

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

 session.getNamedQuery("sqlQueryName").list();

 

 

• 6.其他一些技巧集锦

 

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

 

sessionFactory.openStatelessSession()

 

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

 

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

 

 

C.DML风格对象更新

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

 

 

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

 

 

D.获取Hibernate映射元数据。

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

 

 

sessionfactory.getClassMetadata(XX.class)

 

 

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

 

 

 

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

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

 

 

• 对持久类声明标识符属性（identifier properties）：

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

 

 

• 使用自然键（natural keys）标识：

对所有的实体都标识出自然键，用 <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。

 

 

• 考虑使用用户自定义类型（custom type）：

假设你有一个 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() 或者进行一次查询。

 

 

• 对于关联优先考虑 lazy fetching：

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

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

 

使用 open session in view 模式，或者执行严格的装配期（assembly phase）策略来避免再次抓取数据带来的问题：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 张表的应用程序并不适合。

 

 

• 不要用怪异的连接映射：

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

 

 

• 偏爱双向关联：

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