HIBERNATE性能优化

HIBERNATE性能优化

（初稿）

一、        前言

数据库的出现解放了我们的数据跟踪能力，然而长期以来，关系数据库的操作是基于行集的，对关系数据库的操纵接口也是基于行集的，应用程序中承担着从行集中提取数据的繁重工作。

然而，ORM（实体关系映射）的出现使得关系数据库中表的数据映射成为对象，以对象的形式展现，这样开发人员就可以把对数据库的操作转化为对这些对象的操作，实现了以面向对象的方法来操纵数据库。

能实现ORM这个功能的框架有很多，Hibernate可以说是这些框架中最流行、最受开发者关注的，甚至连JBoss公司也把它吸收进来，利用它在自己的项目中实现ORM功能。

然而，hibernate在数据库的操纵上也存在着问题，针对此问题须采用合适的方案来加以解决，否则将造成应用程序的性能瓶颈。

二、        性能优化

实现同一功能，用HIBERNATE与用JDBC性能相差十几倍很正常，如果不及

早调整，很可能影响整个项目的进度。

       对hibernate的性能主要考虑以下几点：

1、  hibernate版本选用

hibernate3.x提供了一些有助于性能提升的特性，如经过优化的批量处理机制、代理机制、属性的延迟加载支持等。

2、  数据库设计
a) 降低关联的复杂性
b) 尽量不使用联合主键
c) ID的生成机制，不同的数据库所提供的机制并不完全一样
d) 适当的冗余数据，不过分追求高范式

3、  制定合理的缓存策略

缓存对于整体性能有着关键的提升，制定合理的缓存是提高性能的一个

有效途径，减少与数据库的交互。

4、  合理的session管理机制

在利用Hibernate开发DAO模块时，我们和Session打的交道最多，所以

如何合理的管理Session，避免Session的频繁创建和销毁，对于提高系统的性能来说是非常重要的。

5、  尽量使用延迟加载特性

对于无需立即加载的数据，应通过延迟加载特性应需加载，以避免系统资

源的无谓消耗。

6、  事务控制
事务方面对性能有影响的主要包括:事务方式的选用，事务隔离级别以及锁

的选用
　　a) 事务方式选用:如果不涉及多个事务管理器事务的话，不需要使用JTA，只有JDBC的事务控制就可以。
　　b) 事务隔离级别:参见标准的SQL事务隔离级别
　　c) 锁的选用:悲观锁(一般由具体的事务管理器实现)，对于长事务效率低，但安全。乐观锁(一般在应用级别实现)，如在HIBERNATE中可以定义 VERSION字段，显然，如果有多个应用操作数据，且这些应用不是用同一种乐观锁机制，则乐观锁会失效。因此，针对不同的数据应有不同的策略，同前面许多情况一样，很多时候我们是在效率与安全/准确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解。

7、  使用合适的连接池

三、        优化策略

1.         使用缓存

对于ORM实现而言，缓存的使用是持久层性能提升的关键。相对JDBC数据存取，ORM实现往往需要借助更加复杂的机制，以实现内部状态的管理、OR关系的映射等。

缓存是数据库数据在内存中的临时容器，它包含了库表数据在内存中的临时拷贝，位于数据库与数据访问层之间：

ORM在进行数据读取时，会根据基缓存管理策略，首先在缓存中查询，如果在缓存中命中，则直接以此数据作业查询结果加以利用，从而避免了数据库调用的性能开销。往往从内存中读取数据比从数据库中读取要快得多。

ORM的数据缓存主要包括：事物级缓存、应用级缓存、分布式缓存。

1)        事务级缓存

当前事务范围内的数据级存策略，可以是一个数据库事务，也可以是某个应用级事务，对hibernate而言，事务级缓存是基于session生命周期实现的，每个session会在内部给持一个数据级存，此缓存随着session的创建而存在，销毁而消亡。

2)        应用级缓存

此缓存可由多个事务共享。在hibernate中，应用级缓存在

sessionfactory中实现，所以由sessionfactory所创建的session实例共享此缓存。

3)        分布式缓存

在多个应用实例、多个JVM之间共享缓存。

由多个应用级缓存实例组成集群，通过某种远程机制，如：RMI或JMS，实现各个缓存实例间的数据同步，任何一个实例的数据修改将导致整个集群间的数据状态同步。

Hibernate缓存分为二级，第一级存放于session中称为一级缓存，默认带有且不能卸载。

    第二级是由sessionFactory控制的进程级缓存。是全局共享的缓存，凡是会调用二级缓存的查询方法 都会从中受益。只有经正确的配置后二级缓存才会发挥作用。同时在进行条件查询时必须使用相应的方法才能从缓存中获取数据。比如Query.iterate()方法、load、get方法等。必须注意的是session.find方法永远是从数据库中获取数据，不会从二级缓存中获取数据，即便其中有其所需要的数据也是如此。

查询时使用缓存的实现过程为：首先查询一级缓存中是否具有需要的数据，如果没有，查询二级缓存，如果二级缓存中也没有，此时再执行查询数据库的工作。要注意的是：此3种方式的查询速度是依次降低的。

1)        一级缓存

Query中：get() 、load() 、iterate均使用一级缓存。

因为Session的生命期往往很短，存在于Session内部的第一级最快缓存的生命期当然也很短，所以第一级缓存的命中率是很低的。其对系统性能的改善也是很有限的。当然，这个Session内部缓存的主要作用是保持Session内部数据状态同步。

2)        二级缓存

hibernate会自行维护二级缓存中的数据，以保证缓存中的数据和数据库中的真实数据的一致性！无论何时，当你调用save()、update()或 saveOrUpdate()方法传递一个对象时，或使用load()、 get()、list()、iterate() 或scroll()方法获得一个对象时, 该对象都将被加入到Session的内部缓存中。 当随后flush()方法被调用时，对象的状态会和数据库取得同步。

也就是说删除、更新、增加数据的时候，同时更新缓存。当然这也包括二级缓存！

只要是调用hibernate API执行数据库相关的工作。hibernate都会为你自动保证缓存数据的有效性！

3)        使用缓存时应注意的问题

并非所有的情况都适合于使用二级缓存，需要根据具体情况来决定。同时可以针对某一个持久化对象配置其具体的缓存策略，并且须符合以下条件：

 数据不会被第三方修改：

       一般情况下，会被hibernate以外修改的数据最好不要配置二级缓存，以免引起不一致的数据。但是如果此数据因为性能的原因需要被缓存，同时又有可能被第3方比如SQL修改，如果你使用了JDBC绕过hibernate直接执行对数据库的操作。此时，Hibernate不会/也不可能自行感知到数据库被进行的变化改动，也就不能再保证缓存中数据的有效性！只是此时需要在sql执行修改后手动调用cache的清除方法。以保证数据的一致性

       虽然hibernate提供了cache手动调用的方法，但是维护起来极其不方便，为此在使用缓存时尽量避免数据被第三方修改，统一由hibernate进行维护。

 

数据大小在可接收范围之内：

如果数据表数据量特别巨大，此时不适合于二级缓存。原因是缓存的数据量过大可能会引起内存资源紧张，反而降低性能。

 如果数据表数据量特别巨大，但是经常使用的往往只是较新的那部分数据。此时，也可为其配置二级缓存。但是必须单独配置其持久化类的缓存策略，比如最大缓存数、缓存过期时间等，将这些参数降低至一个合理的范围（太高会引起内存资源紧张，太低了缓存的意义不大）。

数据更新频率高：

对于数据更新频率过高的数据，频繁同步缓存中数据的代价可能和 查询缓存中的数据从中获得的好处相当，坏处益处相抵消。此时缓存的意义也不大。

 关键数据：

 财务数据等是非常重要的数据，绝对不允许出现或使用无效的数据，所以此时为了安全起见最好不要使用二级缓存。

 N＋1问题：

执行条件查询时，iterate（）方法具有著名的 “n+1”次查询的问题，也就是说在第一次查询时iterate方法查询的方式是：将满足条件的记录ID查询出来，然后在进行迭代查询时再用查询结果集中的ID去逐个查询。查询的效次数就是（n＋1）次，查询的结果被保留在缓存当中，下一次查询时将从缓存中取，该问题须特别注意，最好的情况下，n＋1全部命中，最坏的情况下则将查询n＋1次数据库。

4)        缓存机制的实现与配置

Hibernate本身并未提供二级缓存的产品化实现（只是提供了一个基于Hashtable的简单缓存以供调试），而是为众多的第三方缓存组件提供了接入接口，可以根据实际情况选择不同的缓存实现。

较常用的第三方组件有：

1.       JCS

2.       EHCache

3.       OSCache

4.       JBossCache

5.         SwarmCache
    Hibernate中启用二级缓存，需要在hibernate.cfg.xml配置hibernate.cache.provider_class参数，之后，需要在映射文件中指定各个映射实体(以及collection)的缓存同步策略。Hibernate提供了一下4种内置的缓存同步策略：
    1. read-only
    只读。对于不会发生改变的数据，可使用只读型缓存。
    2. nonstrict-read-write
    如果程序对并发访问下的数据同步要求不是非常严格，且数据更新操作频率较低，可以采用本选项，获得较好的性能。
    3. read-write
    严格可读写缓存。基于时间戳判定机制，实现了“read committed”事务隔离等级。可用于对数据同步要求严格的情况，但不支持分布式缓存。这也是实际应用中使用最多的同步策略。
    4. transactional
    事务型缓存，必须运行在JTA事务环境中。

2.         使用EHCache

EHCache是一种常用的轻量级二级缓存工具，hibernate对其提供了接入接口，能较好地进行结合。具体的配置请参见ehcache配置文档。

3.         session管理

在利用Hibernate开发DAO模块时，我们和Session打的交道最多，所以如何合理的管理Session，避免Session的频繁创建和销毁，对于提高系统的性能来说是非常重要的。

Session是由SessionFactory负责创建的，而SessionFactory的实现是线程安全的，多个并发的线程可以同时访问一个SessionFactory并从中获取Session实例，然而Session却并非线程安全的。Session中包含了数据库操作相关的状态信息，那么说如果多个线程同时使用一个Session实例进行CRUD，就很有可能导致数据存取的混乱。

幸运的是，Spring框架为Hibernate延迟加载与DAO模式的整合提供了一种方便的解决方法。以一个Web应用为例，Spring提供了OpenSessionInViewFilter和OpenSessionInViewInterceptor。我们可以随意选择一个类来实现相同的功能。两种方法唯一的不同就在于interceptor在Spring容器中运行并被配置在web应用的上下文中，而Filter在Spring之前运行并被配置在web.xml中。不管用哪个，他们都在请求将当前会话与当前（数据库）线程绑定时打开Hibernate会话。一旦已绑定到线程，这个打开了的Hibernate会话可以在DAO实现类中透明地使用。这个会话会为延迟加载数据库中值对象的视图保持打开状态。一旦这个逻辑视图完成了，Hibernate会话会在Filter的doFilter方法或者Interceptor的postHandle方法中被关闭。

实现方法在web.xml中加入：

　　<filter>

　　<filter-name>hibernateFilter</filter-name>

　　<filter-class>

　　org.springframework.orm.hibernate3.support.OpenSessionInViewFilter

　　</filter-class>

　　</filter

　　<filter-mapping>

　　<filter-name>hibernateFilter</filter-name>

　　<url-pattern>/*</url-pattern>

　　</filter-mapping>

四、        CDMS系统优化建议

CDMS2.0中也存在着相当多的性能问题与瓶颈，数据库的操纵都是使用hibernate进行操纵和管理，然而对于一个业务逻辑的流程，却容易导致多次操作数据库，以及在终端数目较多的情况下频繁创建和销毁session对象，这样造成的系统开销极大，虽然使用了连接池，但是性能上还是存在缺陷。

解决cdms2.0性能上的问题主要集中在缓存的使用和对session的管理，此前曾做过简单的测试，查询1000台终端，在使用缓存的情况下效率是不使用缓存的3～5倍，因此解决以上两个问题至关重要。