影响Hibernate性能的因素

影响
Hibernate

性能的因素

用了一段时间的
hibernate

后，总结了一些开发人员应该注意的一些影响其效率的细节。

1


、不同的主健生成机制对性能的影响



通常的生成机制又
10

几种，说一些常用的吧。数据库
提供的主键生成机制，往往是通过在一个内部表中保存当前主键状态（如对于自增型主键而言，此内部表中就维护着当前的最大值和递增量），之后每次插入数据会读取这个最大值，然后加上递增量作为新记录的主键，之后再把这个新的最大值更新回内部表中，这样，一次
Insert

操作可能导致数据库
内部多次表读写操作，同时伴随的还有数据的加锁解锁操作，这对性能产生了较大影响。我们系统中就是用这这种
hi/lo

生成方式么，但是它的好处跨不同数据库
没有影响。因此，对于并发
Insert

要求较高的系统，推荐采用
uuid.hex

作为主键生成机制。在
hibernate

指南中有
10

种生成主健方式，根据你们具体业务定，不同方式有不同的优缺点。

2


、


配置文件中外健的配置方式对性能的影响



在写
*.hbm.xml

配置文件时，多考虑业务上的需要，看看表现层是否真的需要显示关联信息。

比如合同表中存在
employeeid

外健，因为表现层需要显示，所以需要配上多对
1

等配置，如果，页面不一定需要显示，则只配成外健性能更好些。

3


、


保存信息时关联表保存方式对性能的影响



用员工合同表举例，比如其中
employee

已经被配置成多对一了。那么，

那么比如在添加记录时，我们系统中，原来的写法：

需要设置
contractPO

的相关必添信息以及需要
employeeid

调用查询方法，查找
employeePO

，然后，
contractPO.setEmployee(employeePO) ;

这样就多了一次查询，我试验过，可以这样写：

EmployeePO employee = new EmloyeePO();

employee.setOid(oid)
;

contractPO.setEmployee(employeePO)

这样写，就可以少一次查询。

4


、


数据库
方面对性能的影响



hibernate

本身没有什么可以提高性能的，它已经很不错了，主要是在我们的系统设计和写法上。此时，数据库
的性能也是相关的一个方向，我的
blog

上有一个关于不同写法
sql

语句有不同的影响。
使用
hibernate

开发时，要将
sql

语句打印到控制台上，当你发现一个超作出现的查询次数和你的数据量有关系时，那么，你已经在代码设计上制造了一个很大的
bug

，调试他吧。还有，数据库在使用触发器时，没必要尽量少用，当然这算数据库方面对了，呵呵。

5


、


批处理参数对性能的影响



根据你们产品的经常需要的批处理数量，适当设置配置文件属性中的配置：

[1] hibernate.jdbc.fetch_size
[2]
hibernate.jdbc.batch_size

这个多少是好我没研究过，满江红上的开源
bbs

用的是

[1]50 [2]25

。我们的用的多少我没去看，你那也有代码。

6


、


配置文件参数对性能的影响



dynamic-update

参数设定为生成
Update SQL

时候，只包括当前发生变化的字段（提高
DB Update

性能）。

7


、
JavaBean


的写法对性能的影响



注意：在编写代码的时候请，对将
POJO

的
getter/setter

方法设定为
public

，如果设定为
private

，
Hibernate

将无法对属性的存取进行优化，只能转而采用传统的反射机制进行操作，这将导致大量的性能开销（特别是在
1.4

之前的
Sun JDK

版本以及
IBM JDK

中，反射所带来的系统开销相当可观）。

8


、缓存技术对性能的影响



如果，业务中需要对某信息经常反复性的查询，但是却不进行修改，或者是很少进行修改，那么，利用缓存机制，也是一种不错的选择。我还没用上，以后尝试下。引入
Cache

机制的难点是如何保证内存中数据的有效性，否则脏数据的出现将给系统带来难以预知的严重后果。
Hibernate

中实现了良好的
Cache

机制，我们可以借助
Hibernate

内部的
Cache

迅速提高系统数据读取性能。需要注意的是：
Hibernate

做为一个应用级的数据访问层封装，只能在其作用范围内保持
Cache

中数据的的有效性，也就是说，在我们的系统与第三方系统共享数据库的情况下，
Hibernate

的
Cache

机制可能失效。

9


、延迟加载对性能的影响



延迟加载，一般我们都会选择，因为可以节省一部分性能。如，示例中
user

对象在加载的时候，会同时读取其所关联的多个地址（
address

）对象，对于需要对
address

进行操作的应用逻辑而言，关联数据的自动加载机制的确非常有效。但是，如果我们只是想要获得
user

的性别（
sex

）属性，而不关心
user

的地址（
address

）信息，那么自动加载
address

的特性就显得多余，并且造成了极大的性能浪费。为了获得
user

的性别属性，我们可能还要同时从数据库中读取数条无用的地址数据，这导致了大量无谓的系统开销。

10


、初始化对性能的影响



关于事物，利用
Hibernate

来完成启动和提交
UserTransaction

的功能的确可以，但这样的做法比原本直接通过
InitialContext

获取
UserTransaction

的做法消耗了更多的资源，得不偿失。

还有其他一些常用的资源也可以在系统初始化时完成，这样，系统启动时间慢，但是运行会快一些。

11


、
hibernate


的锁机制的选择对性能的影响



相对悲观锁而言，乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。
optimistic-lock="version"

其中通过
version

实现的乐观锁机制是
Hibernate

官方推荐的乐观锁实现，同时也是
Hibernate

中，目前唯一在数据对象脱离
Session

发生修改的情况下依然有效的锁机制。因此，一般情况下，我们都选择
version

方式作为
Hibernate

乐观锁实现机制。

12


、
Session


管理对性能的影响：



有效的
Session

管理机制
,

是
Hibernate

应用设计的关键。在各种
Session

管理方案中，
ThreadLocal

模式得到了大量使用。
ThreadLocal

是
Java

中一种较为特殊的线程绑定机制。通过
ThreadLocal

存取的数据，总是与当前线程相关，也就是说，
JVM

为每个运行的线程，绑定了私有的本地实例存取空间，从而为多线程环境常出现的并发访问问题提供了一种隔离机制。我们系统中也用的这个。