[转]怎么提高hibernate性能

[转]如何提高hibernate性能

在一个拥有单独业务层的应用中，业务层必须在返回之前，为web层“准备”好其所需的数据集合。这就意味着业务层应该载入所有表现层/web层所需的数据，并将这些已实例化完毕的数据返回。通常，应用程序应该为web层所需的每个集合调用Hibernate.initialize()（这个调用必须发生咱session关闭之前）；或者使用带有FETCH从句，或FetchMode.JOIN的Hibernate查询，事先取得所有的数据集合。如果你在应用中使用了Command模式，代替Session Facade ，那么这项任务将会变得简单的多。

你也可以通过merge()或lock()方法，在访问未实例化的集合（或代理）之前，为先前载入的对象绑定一个新的Session。显然，Hibernate将不会，也不应该自动完成这些任务，因为这将引入一个特殊的事务语义。

有时候，你并不需要完全实例化整个大的集合，仅需要了解它的部分信息（例如其大小）、或者集合的部分内容。

你可以使用集合过滤器得到其集合的大小，而不必实例化整个集合：

( (Integer) s.createFilter( collection, "select count(*)" ).list().get(0) ).intValue()

这里的createFilter()方法也可以被用来有效的抓取集合的部分内容，而无需实例化整个集合：

s.createFilter( lazyCollection, "").setFirstResult(0).setMaxResults(10).list();

20.1.5. 使用批量抓取（Using batch fetching）

Hibernate可以充分有效的使用批量抓取，也就是说，如果仅一个访问代理（或集合），那么Hibernate将不载入其他未实例化的代理。批量抓取是延迟查询抓取的优化方案，你可以在两种批量抓取方案之间进行选择：在类级别和集合级别。

类/实体级别的批量抓取很容易理解。假设你在运行时将需要面对下面的问题：你在一个Session中载入了25个

随之，Hibernate将只需要执行三次查询，分别为10、10、 5。

你也可以在集合级别定义批量抓取。例如，如果每个Person都拥有一个延迟载入的Cats集合，现在，Sesssion中载入了10个person对象，遍历person集合将会引起10次SELECT查询，每次查询都会调用getCats()方法。如果你在Person的映射定义部分，允许对cats批量抓取, 那么，Hibernate将可以预先抓取整个集合。请看例子：

如果整个的batch-size是3（笔误？），那么Hibernate将会分四次执行SELECT查询，按照3、3、3、1的大小分别载入数据。这里的每次载入的数据量还具体依赖于当前Session中未实例化集合的个数。

如果你的模型中有嵌套的树状结构，例如典型的帐单－原料结构（bill-of-materials pattern），集合的批量抓取是非常有用的。（尽管在更多情况下对树进行读取时，嵌套集合（nested set）或原料路径(materialized path)（××）是更好的解决方法。）

20.1.6. 使用子查询抓取（Using subselect fetching）

假若一个延迟集合或单值代理需要抓取，Hibernate会使用一个subselect重新运行原来的查询，一次性读入所有的实例。这和批量抓取的实现方法是一样的，不会有破碎的加载。

20.1.7. 使用延迟属性抓取（Using lazy property fetching）

Hibernate3对单独的属性支持延迟抓取，这项优化技术也被称为组抓取（fetch groups）。请注意，该技术更多的属于市场特性。在实际应用中，优化行读取比优化列读取更重要。但是，仅载入类的部分属性在某些特定情况下会有用，例如在原有表中拥有几百列数据、数据模型无法改动的情况下。

可以在映射文件中对特定的属性设置lazy，定义该属性为延迟载入。

属性的延迟载入要求在其代码构建时加入二进制指示指令（bytecode instrumentation），如果你的持久类代码中未含有这些指令， Hibernate将会忽略这些属性的延迟设置，仍然将其直接载入。

你可以在Ant的Task中，进行如下定义，对持久类代码加入“二进制指令。”

还有一种可以优化的方法，它使用HQL或条件查询的投影（projection）特性，可以避免读取非必要的列，这一点至少对只读事务是非常有用的。它无需在代码构建时“二进制指令”处理，因此是一个更加值得选择的解决方法。

有时你需要在HQL中通过抓取所有属性，强行抓取所有内容。

20.2. 二级缓存（The Second Level Cache）

Hibernate的Session在事务级别进行持久化数据的缓存操作。当然，也有可能分别为每个类（或集合)，配置集群、或JVM级别(SessionFactory级别)的缓存。你甚至可以为之插入一个集群的缓存。注意，缓存永远不知道其他应用程序对持久化仓库（数据库）可能进行的修改（即使可以将缓存数据设定为定期失效）。

默认情况下，Hibernate使用EHCache进行JVM级别的缓存（目前，Hibernate已经废弃了对JCS的支持，未来版本中将会去掉它）。你可以通过设置hibernate.cache.provider_class属性，指定其他的缓存策略，该缓存策略必须实现org.hibernate.cache.CacheProvider接口。

表 20.1. 缓存策略提供商（Cache Providers）

CacheProvider classTypeCluster SafeQuery Cache SupportedHashtable (not intended for production use)org.hibernate.cache.HashtableCacheProvidermemory?yesEHCacheorg.hibernate.cache.EhCacheProvidermemory, disk?yesOSCacheorg.hibernate.cache.OSCacheProvidermemory, disk?yesSwarmCacheorg.hibernate.cache.SwarmCacheProviderclustered (ip multicast)yes (clustered invalidation)?JBoss TreeCacheorg.hibernate.cache.TreeCacheProviderclustered (ip multicast), transactionalyes (replication)yes (clock sync req.)

20.2.1. 缓存映射（Cache mappings）

类或者集合映射的“<cache>元素”可以有下列形式：

(1)

usage说明了缓存的策略:

20.2.3. 策略:读/写缓存（Strategy: read/write）

如果应用程序需要更新数据，那么使用读/写缓存

20.2.4. 策略:非严格读/写缓存（Strategy: nonstrict read/write）

如果应用程序只偶尔需要更新数据（也就是说，两个事务同时更新同一记录的情况很不常见），也不需要十分严格的事务隔离，那么比较适合使用非严格读/写缓存策略。如果在JTA环境中使用该策略，你必须为其指定hibernate.transaction.manager_lookup_class属性的值，在其它环境中，你必须保证在Session.close()、或Session.disconnect()调用前，整个事务已经结束。

20.2.5. 策略:事务缓存（transactional）

Hibernate的事务缓存策略提供了全事务的缓存支持，例如对JBoss TreeCache的支持。这样的缓存只能用于JTA环境中，你必须指定为其hibernate.transaction.manager_lookup_class属性。

没有一种缓存提供商能够支持上列的所有缓存并发策略。下表中列出了各种提供器、及其各自适用的并发策略。

表 20.2. 各种缓存提供商对缓存并发策略的支持情况（Cache Concurrency Strategy Support）

Cacheread-onlynonstrict-read-writeread-writetransactionalHashtable (not intended for production use)yesyesyes?EHCacheyesyesyes?OSCacheyesyesyes?SwarmCacheyesyes??JBoss TreeCacheyes??yes

20.3. 管理缓存（Managing the caches）

无论何时，当你给save()、update()或

如果你想得到所有实体、集合、查询和缓存区的数据，你可以通过以下方法获得实体、集合、查询和缓存区列表：getQueries()、getEntityNames()、?getCollectionRoleNames()和?getSecondLevelCacheRegionNames()。

[转]怎么提高hibernate性能

热点推荐