Hibernate程序性能优化.docx

Hibernate程序性能优化.docx

《Hibernate程序性能优化.docx》由会员分享，可在线阅读，更多相关《Hibernate程序性能优化.docx（37页珍藏版）》请在冰点文库上搜索。

Hibernate程序性能优化

Hibernate程序性能优化

初用HIBERNATE的人也许都遇到过性能问题，实现同一功能，用HIBERNATE与用JDBC性能相差十几倍很正常，如果不及早调整，很可能影响整个项目的进度。

　　大体上，对于HIBERNATE性能调优的主要考虑点如下:

　　Ø数据库设计调整

　　ØHQL优化

　　ØAPI的正确使用（如根据不同的业务类型选用不同的集合及查询API）

　　Ø主配置参数（日志，查询缓存，fetch_size,batch_size等）

　　Ø映射文件优化（ID生成策略，二级缓存，延迟加载，关联优化）

　　Ø一级缓存的管理

　　Ø针对二级缓存，还有许多特有的策略

　　Ø事务控制策略。

　　1、数据库设计

　　a）降低关联的复杂性

　　b）尽量不使用联合主键

　　c）ID的生成机制，不同的数据库所提供的机制并不完全一样

　　d）适当的冗余数据，不过分追求高范式

　　2、HQL优化

　　HQL如果抛开它同HIBERNATE本身一些缓存机制的关联，HQL的优化技巧同普通的SQL优化技巧一样，可以很容易在网上找到一些经验之谈。

　　3、主配置

　　a）查询缓存，同下面讲的缓存不太一样，它是针对HQL语句的缓存，即完全一样的语句再次执行时可以利用缓存数据。

但是，查询缓存在一个交易系统（数据变更频繁，查询条件相同的机率并不大）中可能会起反作用:

它会白白耗费大量的系统资源但却难以派上用场。

　　b）fetch_size，同JDBC的相关参数作用类似，参数并不是越大越好，而应根据业务特征去设置

　　c）batch_size同上。

　　d）生产系统中，切记要关掉SQL语句打印。

　　4、缓存

　　a）数据库级缓存:

这级缓存是最高效和安全的，但不同的数据库可管理的层次并不一样，比如，在ORACLE中，可以在建表时指定将整个表置于缓存当中。

　　b）SESSION缓存:

在一个HIBERNATESESSION有效，这级缓存的可干预性不强，大多于HIBERNATE自动管理，但它提供清除缓存的方法，这在大批量增加/更新操作是有效的。

比如，同时增加十万条记录，按常规方式进行，很可能会发现OutofMemeroy的异常，这时可能需要手动清除这一级缓存:

Session.evict以及Session.clear

　　c）应用缓存:

在一个SESSIONFACTORY中有效，因此也是优化的重中之重，因此，各类策略也考虑的较多，在将数据放入这一级缓存之前，需要考虑一些前提条件:

　　i.数据不会被第三方修改（比如，是否有另一个应用也在修改这些数据?

）

　　ii.数据不会太大

　　iii.数据不会频繁更新（否则使用CACHE可能适得其反）

　　iv.数据会被频繁查询

　　v.数据不是关键数据（如涉及钱，安全等方面的问题）。

　　缓存有几种形式，可以在映射文件中配置:

read-only（只读，适用于很少变更的静态数据/历史数据），nonstrict-read-write，read-write（比较普遍的形式，效率一般），transactional（JTA中，且支持的缓存产品较少）

　　d）分布式缓存:

同c）的配置一样，只是缓存产品的选用不同，在目前的HIBERNATE中可供选择的不多，oscache,jbosscache，目前的大多数项目，对它们的用于集群的使用（特别是关键交易系统）都持保守态度。

在集群环境中，只利用数据库级的缓存是最安全的。

　　5、延迟加载

　　a）实体延迟加载:

通过使用动态代理实现

　　b）集合延迟加载:

通过实现自有的SET/LIST，HIBERNATE提供了这方面的支持

　　c）属性延迟加载:

　　6、方法选用

　　a）完成同样一件事，HIBERNATE提供了可供选择的一些方式，但具体使用什么方式，可能用性能/代码都会有影响。

显示，一次返回十万条记录（List/Set/Bag/Map等）进行处理，很可能导致内存不够的问题，而如果用基于游标（ScrollableResults）或Iterator的结果集，则不存在这样的问题。

　　b）Session的load/get方法，前者会使用二级缓存，而后者则不使用。

　　c）Query和list/iterator，如果去仔细研究一下它们，你可能会发现很多有意思的情况，二者主要区别（如果使用了Spring，在HibernateTemplate中对应find,iterator方法）:

　　i.list只能利用查询缓存（但在交易系统中查询缓存作用不大），无法利用二级缓存中的单个实体，但list查出的对象会写入二级缓存，但它一般只生成较少的执行SQL语句，很多情况就是一条（无关联）。

　　ii.iterator则可以利用二级缓存，对于一条查询语句，它会先从数据库中找出所有符合条件的记录的ID，再通过ID去缓存找，对于缓存中没有的记录，再构造语句从数据库中查出，因此很容易知道，如果缓存中没有任何符合条件的记录，使用iterator会产生N+1条SQL语句（N为符合条件的记录数）

　　iii.通过iterator，配合缓存管理API，在海量数据查询中可以很好的解决内存问题，如:

　　while（it.hasNext（））{

　　YouObjectobject=（YouObject）it.next（）;

　　session.evict（youObject）;

　　sessionFactory.evice（YouObject.class,youObject.getId（））;

　　}

　　如果用list方法，很可能就出OutofMemory错误了。

　　iv.通过上面的说明，我想你应该知道如何去使用这两个方法了。

　　7、集合的选用

　　在HIBERNATE3.1文档的“19.5.UnderstandingCollectionperformance”中有详细的说明。

　　8、事务控制

　　事务方面对性能有影响的主要包括:

事务方式的选用，事务隔离级别以及锁的选用

　　a）事务方式选用:

如果不涉及多个事务管理器事务的话，不需要使用JTA，只有JDBC的事务控制就可以。

　　b）事务隔离级别:

参见标准的SQL事务隔离级别

　　c）锁的选用:

悲观锁（一般由具体的事务管理器实现），对于长事务效率低，但安全。

乐观锁（一般在应用级别实现），如在HIBERNATE中可以定义VERSION字段，显然，如果有多个应用操作数据，且这些应用不是用同一种乐观锁机制，则乐观锁会失效。

因此，针对不同的数据应有不同的策略，同前面许多情况一样，很多时候我们是在效率与安全/准确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解。

　　9、批量操作

　　即使是使用JDBC，在进行大批数据更新时，BATCH与不使用BATCH有效率上也有很大的差别。

我们可以通过设置batch_size来让其支持批量操作。

　　举个例子，要批量删除某表中的对象，如“deleteAccount”，打出来的语句，会发现HIBERNATE找出了所有ACCOUNT的ID，再进行删除，这主要是为了维护二级缓存，这样效率肯定高不了，在后续的版本中增加了bulkdelete/update，但这也无法解决缓存的维护问题。

也就是说，由于有了二级缓存的维护问题，HIBERNATE的批量操作效率并不尽如人意!

　　从前面许多要点可以看出，很多时候我们是在效率与安全/准确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解，一般的，优化方案应在架构设计期就基本确定，否则可能导致没必要的返工，致使项目延期，而作为架构师和项目经理，还要面对开发人员可能的抱怨，必竟，我们对用户需求更改的控制力不大，但技术/架构风险是应该在初期意识到并制定好相关的对策。

　　还有一点要注意，应用层的缓存只是锦上添花，永远不要把它当救命稻草，应用的根基（数据库设计，算法，高效的操作语句，恰当API的选择等）才是最重要的。

Hibernate的映射类型（转）

关键字:

hibernate

 Hibernate映射类型分为两种：

内置映射类型和客户化映射类型。

内置映射类型负责把一些常见的Java类型映射到相应的SQL类型；此外，Hibernate还允许用户实现UserType或CompositeUserType接口，来灵活地定制客户化映射类型。

客户化类型能够把用户定义的Java类型映射到数据库表的相应字段。

一、Hibernate的内置映射类型

1、Java基本类型的Hibernate映射类型

Hibernate映射类型

Java类型

标准SQL类型

大小和取值范围

integer或者int

int或者java.lang.Integer

INTEGER

4字节

long

long Long

BIGINT

8字节

short

short Short

SMALLINT

2字节

byte

byte Byte

TINYINT

1字节

float

float Float

FLOAT

4字节

double

double Double

DOUBLE

8字节

big_decimal

java.math.BigDecimal

NUMERIC

NUMERIC（8,2）8位

character

char Character String

CHAR

（1）

定长字符

string

String

VARCHAR

变长字符串

boolean

boolean Boolean

BIT

布尔类型

yes_no

boolean Boolean

CHAR

（1）（Y-N）

布尔类型

true_false

boolean Boolean

CHAR

（1）（T-F）

布尔类型

2、Java时间和日期类型的Hibernate映射

映射类型

Java类型

标准SQL类型

描述

date

util.Date或者sql.Date

DATE

YYYY-MM-DD

time

Date   Time

TIME

HH:

MM:

SS

timestamp

Date  Timestamp

TIMESTAMP

YYYYMMDDHHMMSS

calendar

calendar

TIMESTAMP

YYYYMMDDHHMMSS

calendar_date

calendar

DATE

YYYY-MM-DD

3、Java大对象类型的Hibernate映射类型

映射类型

Java类型

标准SQL类型

MySQL类型

Oracle类型

binary

byte[]

VARBINARY（或BLOB）

BLOB

BLOB

text

String

CLOB

TEXT

CLOB

serializable

Serializable接口任意实现类

VARBINARY（或BLOB）

BLOB

BLOB

clob

java.sql.Clob

CLOB

TEXT

CLOB

blob

java.sql.Blob

BLOB

BLOB

BLOB

      在程序中通过Hibernate来保存java.sql.Clob或者java.sql.Blob实例时，必须包含两个步骤：

●        在一个数据库事务中先保存一个空的Blob或Clob实例。

●        接着锁定这条记录，更新上面保存的Blob或Clob实例，把二进制数据或文本数据写到Blob或Clob实例中。

OO+分布式计算=软件架构的方向（转）

最近，一个新名词“云计算（cloudcomputing）”很热门，它是网格计算的进一步细化，我们看看网络上一些对云计算的定义：

　　Googel搜索引擎计算用来解读云计算再合适不过：

网页的变更通常大量而复杂，但云计算可很容易地处理海量数据，它不仅可以将搜索任务切分为多个小的任务模块执行，而且单个任务模块可以采用不同的算法，这样的计算结果集合就是搜索结果。

（摘自云计算泄露Google的秘密）

　　“云”，既是对那些网状分布的计算机的比喻，也指代数据的计算过程被隐匿起来，由服务器按你的需要，从大云中“雕刻”出你所需要的那一朵。

实在是非常浪漫的比喻。

　　云计算是一个新兴的商业计算模型。

利用高速互联网的传输能力，将数据的处理过程从个人计算机或服务器移到互联网上的计算机集群中。

这些计算机都是很普通的工业标准服务器，由一个大型的数据处理中心管理着，数据中心按客户的需要分配计算资源，达到与超级计算机同样的效果。

（摘自如果云计算）

　　所以，从概念上看，云计算实质也就是一种分布式计算，这种计算模式相对于传统数据库中心的计算模式，无疑拥有巨大潜力和优越性。

　　所谓数据库中心的计算模式，就是将软件系统的处理能力和负载主要集中在一两台数据库服务器，如果要提高计算处理能力，只能不断提高数据库服务器的硬件水平，从普通双核多核PC机到小型机，直至中型机和超级计算机，随着处理能力提高，系统的建设成本也越来越高，最后，享受超级计算能力不再成为普通百姓的权利，而成为贵族和特殊国防领域的专利，并成为国家炫耀计算机实力一个象征。

　　其实，也许我们又走上了一个错误的方向，如果Google当初选择了这种集中式超级计算模式，那么也许就没有我们普通百姓可以享用的方便低廉的搜索服务，使用搜索已经成为我8岁儿子基本工具，他一学会汉字，就会用这些汉字在google中找到自己想玩的小游戏，搜索和汉字已经同时融入我们下一代人的血液中，这些都得益于计算思维的转变：

分布式计算云计算。

　　在Java领域，从EJB诞生那天开始，就已经宣布分布式计算革命的开始，EJB最重要的价值就是让我们开发一个分布式计算模式的软件系统不再变得困难和复杂。

现在的云计算模式更上升为SOA和We服务，看看下面IBM的蓝云架构中，一个基础核心就是EJB/SOA服务器Websphere（图来自云计算泄露Google的秘密）：

　　说了这么多分布式计算，那么和面向对象OO这样设计思维有什么关系呢？

这两者其实是一脉相承，这个观点我已经在论坛中提及了好几年：

试想想：

分布式计算处理的是数据，只有数据被包装在对象Object中，而对象是运行在应用服务器的内存中，这样，整个计算负载才会集中到这些应用服务器上，然后我们就可以架设多台应用服务器，进行分布计算；如果这些数据是被包装在数据表中，就是只能运行在数据库服务器中，那就只能走集中式主机的发展道路。

　　千里之行，始于足下，时尚革命的云计算好像和我们无关，其实它的方向就开始于我们最基础的编程设计中，只有我们树立了OO编程思想，将我们的业务数据使用对象这个容器封装起来，才能在将来可能享受分布式云计算的好处，否则只能推倒重来重新设计，这也说明：

追求软件的可拓展性和伸缩性是现代软件的灵魂。

　　当你使用EvansDDD这些OO分析方法提炼你的需求以后，你就得到你系统的很多业务对象，那么如何让这些业务对象在计算机中以分布式计算方式运行呢：

目前在Java世界，有两种路线可以实现集群分布式集群计算：

　　1.EJB或SOA路线。

IBM的蓝云产品就是试图走这条路，你选择IBM这样产品提供商，就象买了辆日本车，舒适型、操控性和空间内饰以及外表都适中，各种指标都很中庸，OO方面有一点但差一点；分布式性能上有一点但也差一点；分布式事务方面有一点但也差一点，所以，如果你只是一般商务应用项目，EJB/SOA也许是一种选择，这也是日本车畅销的一个原因。

　　而EJB/SOA前提也是必须首先将你的业务对象和业务服务从数据库的SQL语句中独立出来，否则，你提供的SOA服务就是SQL语句服务，实际就是数据库存储服务，有一种观点认为云计算就是云存储的延伸，这个我不敢苟同，有这种观点的人实际还是数据库中心思维的延伸，难道他们认为分布式处理就是将包含业务内容的SQL语句分开运行？

　　这里面就忽视了一个重要概念：

对象，必须将业务逻辑从你的SQL语句中分离出来，形成业务对，再通过对象缓存或服务的分布化，才能真正实现分布式计算或云计算。

所以，我们必须对EJB/SOA这些现成解决方案的内部机制掌握开始，这就是第二条路线：

　　2.分布式计算定制DIY路线：

google走的就是这条路，德美车福克斯很流行，就是因为其操控性和5星安全性（内饰几乎很差），这说明我们也开始选择一些个性产品，就像川菜那么辣，但是在全国都很受欢迎一样，所以，走分布式云计算路线，我们也可以个性定制自己的架构路线：

如果你只追求高的计算性能，而不必太在意计算的安全和稳定性（这点其实也很重要，否则就容易发生ATM吐钱的事件:

恶意取款案是中国软件悲哀），那么我就选用分布式缓存。

　　现在Hibernate等ORM持久方案很流行，它不但让我们软件变得更加OO更加自然，克服了对象和关系数据库的矛盾，同时，它还提供了对这些持久对象的缓存支持，包括一级和二级缓存，这两个特点几乎成为Hibernate等ORM或其他持久层框架的本质特点。

同时也验证了只有OO+对象缓存才是一个完美架构。

Hibernate可支持各种缓存产品，包括JBossCache、Ehcache以及Terracotta，这些缓存都可以无缝地扩展到分布式缓存运行模式。

　　这样，数据被包装在对象中，而对象被存储在缓存Cache中，因为这些对象不是简单的数据包装，它们就是业务模型对象，有重要的业务意义，比如订单对象；产品对象等，这些对象就是你的业务系统的数据核心，是经常被访问到的，而这些业务对象被缓存在ObjectCache中了，无疑这个ObjectCache的击中率是很高的，这相当于优化后缓存，肯定比数据库自身没有针对具体项目优化的缓存要高。

更重要的是，因为ObjectCache是在应用服务器中，我们通过ObjectCache以及各种服务和业务计算将整个系统的运行负载拦截在了应用服务器中，那么我们再通过分布式缓存将这些业务对象带到其他计算机内存中，这才是分布式云计算的本质。

　　综上所述：

如果说分布式云计算是一条我们普通老百姓通往美好未来的康庄大道，那么如何驶入这条道路？

以及选择怎样的座驾工具？

无疑是关系到我们每个程序员的职业素质和水平。

很显然，OO分析设计编程是一个最基本的要求，（OO+分布式计算）=软件架构的方向。

缩略显示

分布式缓存问题解决（转）

关键字:

分布式

解决数据库数据缓存的问题

缓存产品目标锁定在支持分布式应用的3种开源产品身上：

JbossCache、OSCache和SwarmCache，JbossCache采用数据复制策略，OSCache又大又全，重点在页面缓存上，SwarmCache虽然很小巧，但分布式是核心，采用的是失效机制。

最终采用SwarmCache实现。

全面了解一种开源产品，首要的是看它的文档了，随后的日志我会贴出他的Tutorial。

Hibernate3对各种缓存的提供了很好的支持，细看它的文档才发现它支持的额外3种缓存产品正好是上面列出的，EHCache是Hibernate自身的缓存实现，不支持分布式应用。

这下子倒免去了写CacheProvider的工作。

下载swarmcache-1.0RC2a二进制和源码，将jgroups-all.jar和swarmcache-1.0RC2.jar拷贝至\WEB-INF\lib\下，

配置Hibernate.cfg.xml将provider_class换为指定的Provider

net.sf.hibernate.cache.SwarmCacheProvider

打开查询缓存的支持

true

配置

关于最后一行配置的说明，因为SwarmCache不支持严格的读写缓存，所以要配置成nonstrict-read-write，各个缓存之间需要用名字隔离，如cache.region。

重新启动Tomcat后，SwarmCache中的组播服务启动：

-------------------------------------------------------

GMS:

addressispysh:

1967

-------------------------------------------------------

如果另外一个也作了同样配置的web启动，他们之间通过组播消息可以相互通知：

2006-09-1917:

49:

06INFOJavaGroupsCommunicator:

76-Ahosthasjoinedthecachenotificationbus:

pysh:

1967

测试应用：

在机器A上，通过Hibernate对Entity做了修改，机器B得知缓存Entity已经无效，机器B会remove此缓存，重新从数据库里加载。

SpringMVCframework深入总体分析（转）

关键字:

springmvc

下面列举一下Spring的MVCframework在设计时做出的一些重要的决定，并将之和相关的MVCframework如Webwork2或struts进行对比：

　　一、Spring的整个MVC配置是基于IOC容器的

　　与struts或webwork2相比，这是一个ms有点奇怪的决定，看一下SpringMVC的配置文件，最先看到的不是action或者form，而是一些有着特定名字的bean，Bean下面的配置是一些简单或有点复杂的属性。

我们看到的是机器更容易的数据结构，而不是人更容易理解的元素。

　　但是这恰恰是Spring的MVC强大的根源!

因为它的配置就是Spring的核心IOC容器的配置，这意味着所有IOC容器的威力都可以在这里展现，我们可以为所欲为地对SpringMVC进行扩展和增强，我们可以完成在其它MVCframwork中很多难以想象的任务。

想扩展新的URL映射方式吗?

要换一个themeResolver或LocalReolver的实现吗?

想在页面中显示新类型的View（比如说RDF，呵呵，一个小秘密：

xiecc是研究语义网的，虽然成天不务正业，不写论文，只写八卦）?

甚至想直接在Controller里定义AOP吗?

这些对Spring的MVC来说都是小菜一碟。

　　我没有仔细研究过Webwork2的扩展机