Hibernate是一个
开放源代码的
对象关系映射框架，它对
JDBC进行了非常轻量级的对象封装，它将POJO与数据库表建立映射关系，是一个
全自动的orm框架，hibernate可以自动生成SQL语句，自动执行，使得
Java程序员可以随心所欲的使用对象编程思维来操纵数据库。 Hibernate可以应用在任何使用JDBC的场合，既可以在Java的客户端程序使用，也可以在Servlet/
JSP的Web应用中使用，最具革命意义的是，Hibernate可以在应用
EJB的
JavaEE架构中取代CMP，完成
数据持久化的重任。
简介
Hibernate作为数据库与界面之间的桥梁，需要
面向对象思想操纵对象。对象可能是普通
JavaBeans/
POJO。应用程序通过抽象将应用从底层事务隔离开。使用底层的API或Transaction对象完成轻量级框架提供一级缓存和二级缓存。Hibernate直接提供相关支持，
底层驱动可以随意切换数据库，快速简洁。使
业务层与具体数据库分开，只针对Hibernate 进行开发，完成数据和对象的持久化。针对不同的数据库形成不同的SQL 查询语句，降低数据库之间迁移的成本。Hibernate支持多种缓存机制，Hibernate适配
MS SQLSERVER、ORACLE、SQL、
H2、Access和
Mysql等多种数据库。
Hibernate用
反射机制实现持久化对象操作，实现与
IDE(Integrated Development Environment)的
耦合度。Hibernate使用数据库和配置信息为应用程序提供持久化服务。从配置文件中读取数据库相关参数，将持久化类和
数据表对应使用。用Hibernate API
对象持久化，利用映像信息将持久化操作翻译为SQL语句进行查询。
Hibernate框架技术最关键是
数据持久化，是将数据保存到
持久层的过程。持久层的数据在
掉电后也不会丢失的数据。持久层是基于Hibernate技术的检索
系统开发的基本。
系统结构的
层次模型有三个阶段。
整个过程首先实现应用层和
数据层。数据层保存持久化数据，应用层接收输入的数据。然后通过MVC 模式实现业务
逻辑与表示层的分开。表示层和用户实现交互，
业务逻辑层处理数据持久化操作。将第二阶段
业务逻辑层的功能部署拆分后，业务逻辑层完成核心业务逻辑处理，持久层完成对象持久化。降低业务逻辑层复杂度的同时将数据持久化让其他组件完成。
发展历程
2001年，
澳大利亚墨尔本一位名为
Gavin King的27岁的程序员，上街买了一本SQL编程的书，他厌倦了实体bean，认为自己可以开发出一个符合
对象关系映射理论，并且真正好用的
Java持久化层框架，因此他需要先学习一下SQL。这一年的11月，Hibernate的第一个版本发布了。
2002年，已经有人开始关注和使用Hibernate了。
2003年9月，Hibernate开发团队进入JBoss公司，开始全职开发Hibernate，从这个时候开始Hibernate得到了突飞猛进的普及和发展。
2004年，整个Java社区开始从实体bean向Hibernate转移，特别是在
Rod Johnson的著作《Expert One-on-One J2EE Development without
EJB》出版后，由于这本书以扎实的理论、充分的论据和详实的论述否定了EJB，提出了轻量级
敏捷开发理念之后，以Hibernate和Spring为代表的轻量级
开源框架开始成为Java世界的主流和
事实标准。在2004年Sun领导的J2EE5.0标准制定当中的持久化框架标准正式以Hibernate为蓝本。
2006年，J2EE5.0标准正式发布以后，持久化框架标准Java Persistent API（简称
JPA）基本上是参考Hibernate实现的，而Hibernate在3.2版本开始，已经完全兼容JPA标准。
编程开发
编程环境
Hibernate是一个以
LGPL（Lesser GNU Public License）许可证形式发布的
开源项目。在Hibernate官网上有下载Hibernate包的说明。Hibernate包以
源代码或者二进制的形式提供。
编程工具
Eclipse：一个
开放源代码的、基于
Java的可扩展
开发平台。
IntelliJ IDEA：在代码自动提示、代码分析等方面的具有很好的功能。
MyEclipse：由
Genuitec公司开发的一款商业化软件，是应用比较广泛的Java
应用程序集成开发环境。
EditPlus：如果正确配置Java的
编译器“
Javac”以及
解释器“Java”后，可直接使用EditPlus
编译执行Java程序。
语言特点
核心API
Hibernate的API一共有6个，分别为:Session、
SessionFactory、Transaction、Query、
Criteria和Configuration。通过这些接口，可以对持久化对象进行存取、事务控制。
Session
Session接口负责执行被持久化对象的
CRUD操作(CRUD的任务是完成与数据库的交流，包含了很多常见的SQL语句)。但需要注意的是
Session对象是非
线程安全的。同时，Hibernate的session不同于JSP应用中的
HttpSession。这里当使用session这个术语时，其实指的是Hibernate中的session，而以后会将HttpSession对象称为用户session。
SessionFactory
SessionFactory接口负责初始化Hibernate。它充当数据存储源的代理，并负责创建
Session对象。这里用到了
工厂模式。需要注意的是SessionFactory并不是轻量级的，因为一般情况下，一个项目通常只需要一个SessionFactory就够，当需要操作多个数据库时，可以为每个数据库指定一个SessionFactory。
Transaction
Transaction 接口是一个可选的API，可以选择不使用这个接口，取而代之的是Hibernate 的设计者自己写的底层
事务处理代码。 Transaction 接口是对实际事务实现的一个抽象，这些实现包括JDBC的事务、JTA 中的UserTransaction、甚至可以是
CORBA 事务。之所以这样设计是能让开发者能够使用一个统一事务的操作界面，使得自己的项目可以在不同的环境和容器之间方便地移植。
Query
Query接口让你方便地对数据库及持久对象进行查询，它可以有两种
表达方式：HQL语言或
本地数据库的SQL语句。Query经常被用来绑定
查询参数、限制查询记录数量，并最终执行查询操作。
Criteria
Criteria接口与Query接口非常类似，允许创建并执行面向对象的标准化查询。值得注意的是Criteria接口也是轻量级的，它不能在Session之外使用。
Configuration
Configuration 类的作用是对Hibernate 进行配置，以及对它进行启动。在Hibernate 的
启动过程中，Configuration 类的实例首先定位映射文档的位置，读取这些配置，然后创建一个SessionFactory对象。虽然Configuration 类在整个Hibernate 项目中只扮演着一个很小的角色，但它是启动hibernate 时所遇到的第一个对象。
回调接口
当⼀个对象发生了特定的事件，例如对象被保存，删除，更新和装载时，Hibernate应用可以通过回调接口来响应这⼀事件，做相应的操作，主要有两类实现方式：
1）
持久化类实现LifeCycle和Validatabale接口。这种方式使Hibernate 接口渗透到了持久化类中，会影响持久化类的
可移植性。
2）Interceptor接口，
应用程序可以定义专门的
拦截器实现类，由它负责事件的响应，这种方式持久化类不会受到影响。
可扩展点
1）定制
主键的生成策略，IdentifierGenarator接口
2）定制本地SQL方言，Dialect抽象类
3）定制缓存机制，Cache和CacheProvider接口
4）定制JDBC连接管理，ConnectionProvider接口
5）定制
事务管理，TransactionFactory，Transaction，TransactionManagerLookup接口
6）定制
ORM策略，classPersister接口及
子接口7）定制属性访问策略，PropertyAccessor接口
8）创建代理，ProxyFactory接口
9）定制客户化映射关系，UserType和CompositeUserType接口
版本
Hibernate版本更新速度很快，有多个阶段性的版本：Hibernate3、Hibernate4、Hibernate5、Hibernate ORM 5.2.12.Final Released。Hibernate2系列的最高版本是Hibernate2.1.8，Hibernate3系列的最高版本是hibernate-distribution-3.6.10.Final-dist版，但使用较多且较稳定的版本是Hibernate 3.1.3或Hibernate 3.1.2。
另外，自Hibernate3发布以来，其产品线愈加成熟，相继出现了Hibernate注释、Hibernate实体管理器、Hibernate插件工具等一系列产品套件。在方便程序员使用Hibernate进行应用程序的开发的同时，也逐渐增强了Hibernate产品线的实力。Hibernate已经出现了4.0以及5.0的版本
主键介绍
Assigned
Assigned方式由用户生成主键值，并且要在save()之前指定否则会
抛出异常特点：主键的生成值完全由用户决定，与底层数据库无关。用户需要维护主键值，在调用session.save()之前要指定主键值。
Hilo
Hilo使用高低位算法生成主键，高低位算法使用一个高位值和一个低位值，然后把算法得到的两个值拼接起来作为数据库中的唯一主键。Hilo方式需要额外的数据库表和字段提供高位值来源。默认情况下使用的表是
hibernate_unique_key，默认字段叫作next_hi。next_hi必须有一条记录否则会出现错误。
特点：需要额外的数据库表的支持，能保证同一个数据库中主键的唯一性，但不能保证多个数据库之间主键的唯一性。Hilo主键生成方式由Hibernate 维护，所以Hilo方式与底层数据库无关，但不应该手动修改hi/lo算法使用的表的值，否则会引起主键重复的异常。
Increment
Increment方式对主键值采取自动增长的方式生成新的主键值，但要求底层数据库的主键类型为
long,int等数值型。主键按数值顺序递增，增量为1。
/*特点：由Hibernate本身维护，适用于所有的数据库，不适合
多进程并发更新数据库，适合单一进程访问数据库。不能用于群集环境。*/
Identity
Identity方式根据底层数据库，来支持自动增长，不同的数据库用不同的主键增长方式。
特点：与底层数据库有关，要求
数据库支持Identity，如MySQl中是auto_
increment, SQL Server 中是Identity，支持的数据库有MySql、SQL Server、
DB2、Sybase和HypersonicSQL。 Identity无需Hibernate和用户的干涉，使用较为方便，但不便于在不同的数据库之间移植程序。
Sequence
Sequence需要底层数据库支持Sequence方式，例如
Oracle数据库等
特点：需要底层数据库的支持序列，支持序列的数据库有DB2、PostgreSql、
Oracle、SAPDb等在不同数据库之间移植程序，特别从支持序列的数据库移植到不支持序列的数据库需要修改
配置文件。
Native
Native主键生成方式会根据不同的底层数据库
自动选择Identity、Sequence、Hilo主键生成方式
特点：根据不同的底层数据库采用不同的主键生成方式。由于Hibernate会根据底层数据库采用不同的映射方式，因此便于程序移植，项目中如果用到多个数据库时，可以使用这种方式。
UUID使用128位UUID算法生成主键，能够保证
网络环境下的主键唯一性，也就能够
保证在不同数据库及不同服务器下主键的唯一性。特点：能够保证数据库中的主键唯一性，生成的主键占用比较多的存贮空间
Foreign用于
一对一关系中。GUID主键生成方式使用了一种特殊算法，保证生成主键的唯一性，支持SQL Server和
MySQL包的作用
net.sf.hibernate.*
该包的类基本上都是接口类和异常类
net.sf.hibernate.cache.*
JCS的实现类
net.sf.hibernate.cfg.*
net.sf.hibernate.collection.*
Hibernate集合接口实现类，例如List，Set，Bag等等，Hibernate之所以要自行编写集合接口实现类是为了支持lazy loading
net.sf.hibernate.connection.*
net.sf.hibernate.dialect.*
支持多种数据库特性，每个Dialect实现类代表一种数据库，描述了该
数据库支持的
数据类型和其它特点，例如是否有AutoIncrement，是否有Sequence，是否有
分页sql等等
net.sf.hibernate. eg.*
Hibernate文档中用到的例子
net.sf.hibernate.engine.*
这个包的类作用比较散
net.sf.hibernate.expression.*
net.sf.hibernate.hq.*
HQL实现
net.sf.hibernate. id.*
ID生成器
net.sf.hibernate.impl.*
最核心的包，一些重要接口的实现类，如Session，
SessionFactory，Query等
net.sf.hibernate.jca.*
JCA支持，把Session包装为支持JCA的接口实现类
net.sf.hibernate.jmx.*
JMX是用来编写
App Server的
管理程序的，大概是JMX部分接口的实现，使得App Server可以通过JMX接口管理Hibernate
net.sf.hibernate.loader.*
net.sf.hibernate.lob.*
Blob和Clob支持
net.sf.hibernate.mapping.*
hbm文件的属性实现
net.sf.hibernate.metadata.*
PO的Meta实现
net.sf.hibernate.odmg.*
ODMG是一个ORM标准，这个包是ODMG标准的实现类
net.sf.hibernate.persister.*
net.sf.hibernate.proxy.*
Proxy和Lazy Loading支持
net.sf.hibernate. ps.*
该包是PreparedStatment Cache
net.sf.hibernate.sql.*
net.sf.hibernate.test.*
测试类，你可以用
junit来测试Hibernate
net.sf.hibernate.tool.hbm2ddl.*
net.sf.hibernate.transaction.*
Hibernate Transaction实现类
net.sf.hibernate.type.*
Hibernate中定义的持久对象的属性的数据类型
net.sf.hibernate.util.*
一些工具类，作用比较散
net.sf.hibernate.xml.*
缓存管理
Hibernate 中提供了两级Cache（
高速缓冲存储器），第一级别的缓存是Session级别的缓存，它是属于
事务范围的缓存。这一级别的缓存由hibernate管理的，一般情况下无需进行干预；第二级别的缓存是SessionFactory级别的缓存，它是属于进程范围或集群范围的缓存。这一级别的缓存可以进行配置和更改，并且可以
动态加载和卸载。 Hibernate还为查询结果提供了一个查询缓存，它依赖于第二级缓存。
事务范围，每个事务都有单独的第
一级缓存进程范围或集群范围，缓存被同一个进程或集群范围内的所有事务共享 并发访问策略由于每个事务都拥有单独的第一级缓存，不会出现并发问题，无需提供并发访问策略由于多个事务会同时访问第二级缓存中相同数据，因此必须提供适当的并发访问策略，来保证特定的
事务隔离级别数据过期策略没有提供数据过期策略。处于一级缓存中的对象永远不会过期，除非应用程序显式清空缓存或者清除特定的对象必须提供数据过期策略，如基于内存的缓存中的对象的最大数目，允许对象处于缓存中的最长时间，以及允许对象处于缓存中的最长
空闲时间。
物理
存储介质内存和硬盘 对象的散装数据首先存放在基于内存的缓存中，当内存中对象的数目达到数据过期策略中指定上限时，就会把其余的对象写入基于硬盘的缓存中。
缓存的软件实现 在Hibernate的Session的实现中包含了缓存的实现由第三方提供，Hibernate仅提供了缓存
适配器(CacheProvider)。用于把特定的缓存插件集成到Hibernate中。启用缓存的方式只要应用程序通过Session接口来执行保存、更新、删除、加载和查询数据库数据的操作，Hibernate就会启用第一级缓存，把数据库中的数据以对象的形式拷贝到缓存中，对于
批量更新和批量删除操作，如果不希望启用第一级缓存，可以绕过Hibernate
API，直接通过JDBC API来执行指操作。用户可以在单个类或类的单个集合的粒度上配置第二级缓存。如果类的实例被经常读但很少被修改，就可以考虑使用第二级缓存。只有为某个类或集合配置了第二级缓存，Hibernate在
运行时才会把它的实例加入到第二级缓存中。 用户管理缓存的方式第一级缓存的物理介质为内存，由于
内存容量有限，必须通过恰当的
检索策略和检索方式来限制加载对象的数目。Session的evict()方法可以显式清空缓存中特定对象，但这种方法不值得推荐。 第二级缓存的物理介质可以是内存和硬盘，因此第二级缓存可以存放大量的数据，数据过期策略的maxElementsInMemory
属性值可以控制内存中的对象数目。管理第二级缓存主要包括两个方面：选择需要使用第二级缓存的
持久类，设置合适的并发访问策略：选择缓存适配器，设置合适的数据过期策略。
一级缓存
当应用程序调用Session的save()、update()、saveOrUpdate()、get()或load()，以及调用查询接口的 list()、iterate()或filter()方法时，如果在Session缓存中还不存在相应的对象，Hibernate就会把该对象加入到第一级缓存中。当清理缓存时，Hibernate会根据缓存中对象的状态变化来同步更新数据库。 Session为应用程序提供了两个管理缓存的方法： evict(Object obj)：从缓存中清除参数指定的持久化对象。 clear()：清空缓存中所有持久化对象。
二级缓存
3.1. Hibernate的二级缓存策略的一般过程如下：
1) 条件查询的时候，总是发出一条select * from table_name where …. （选择所有字段）这样的SQL语句查询数据库，一次获得所有的
数据对象。
2) 把获得的所有数据对象根据ID放入到第二级缓存中。
3) 当Hibernate根据ID访问数据对象的时候，首先从Session一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照ID放入到缓存。
4) 删除、更新、增加数据的时候，同时更新缓存。
Hibernate的二级缓存策略，是针对于ID查询的缓存策略，对于条件查询则毫无作用。为此，Hibernate提供了针对条件查询的Query Cache。
3.2. 什么样的数据适合存放到第二级缓存中？ 1 很少被修改的数据 2 不是很重要的数据，允许出现偶尔并发的数据 3 不会被并发访问的数据 4
参考数据,指的是供应用参考的常量数据，它的实例数目有限，它的实例会被许多其他类的实例引用，实例极少或者从来不会被修改。
3.3. 不适合存放到第二级缓存的数据？ 1 经常被修改的数据 2 财务数据，绝对不允许出现并发 3 与其他应用共享的数据。
3.4. 常用的缓存插件 Hibernater 的二级缓存是一个插件，下面是几种常用的缓存插件：
l EhCache：可作为进程范围的缓存，存放数据的物理介质可以是内存或硬盘，对Hibernate的查询缓存提供了支持。
l OSCache：可作为进程范围的缓存，存放数据的物理介质可以是内存或硬盘，提供了丰富的缓存数据过期策略，对Hibernate的查询缓存提供了支持。
l SwarmCache：可作为群集范围内的缓存，但不支持Hibernate的查询缓存。
l
JBossCache：可作为群集范围内的缓存，支持
事务型并发访问策略，对Hibernate的查询缓存提供了支持。
上述4种缓存插件的对比情况列于表9-3中。
表9-3 4种缓存插件的对比情况
它们的提供器列于表9-4中。
表9-4 缓存策略的提供器
在默认情况下，Hibernate使用EhCache进行JVM级别的缓存。用户可以通过设置Hibernate
配置文件中的hibernate.cache.provider_class的属性，指定其他的缓存策略，该缓存策略必须实现org.hibernate.cache.CacheProvider接口。配置二级缓存的主要步骤：
1) 选择需要使用二级缓存的
持久化类，设置它的命名缓存的并发访问策略。这是最值得认真考虑的步骤。
2) 选择合适的缓存插件，然后编辑该插件的配置文件。
延迟加载
Hibernate
对象关系映射提供延迟的与非延迟的对象初始化。非
延迟加载在读取一个对象的时候会将与这个对象所有相关的其他对象一起读取出来。这有时会导致成百的（如果不是成千的话）select语句在读取对象的时候执行。这个问题有时出现在使用双向关系的时候，经常会导致整个数据库都在初始化的阶段被读出来了。当然，你可以不厌其烦地检查每一个对象与其他对象的关系，并把那些最昂贵的删除，但是到最后，我们可能会因此失去了本想在ORM工具中获得的便利。
一个明显的
解决方法是使用Hibernate提供的延迟加载机制。这种初始化策略只在一个对象调用它的一对多或
多对多关系时才将关系对象读取出来。这个过程对开发者来说是透明的，而且只进行了很少的
数据库操作请求，因此会得到比较明显的性能提升。这项技术的一个缺陷是
延迟加载技术要求一个Hibernate会话要在对象使用的时候一直开着。这会成为通过使用
DAO模式将
持久层抽象出来时的一个主要问题。为了将持久化机制完全地抽象出来，所有的数据库逻辑，包括打开或关闭会话，都不能在应用层出现。最常见的是，一些实现了简单接口的DAO实现类将数据库逻辑完全封装起来了。一种快速但是笨拙的解决方法是放弃DAO模式，将数据库连接逻辑加到应用层中来。这可能对一些小的应用程序有效，但是在大的系统中，这是一个严重的
设计缺陷，妨碍了系统的
可扩展性。
幸运的是，Spring框架为Hibernate
延迟加载与DAO模式的整合提供了一种方便的解决方法。以一个Web应用为例，Spring提供了
OpenSessionInViewFilter和OpenSessionInViewInterceptor。我们可以随意选择一个类来实现相同的功能。两种方法唯一的不同就在于interceptor在Spring容器中运行并被配置在web应用的
上下文中，而Filter在Spring之前运行并被配置在
web.xml中。不管用哪个，他们都在请求将当前会话与当前（数据库）线程绑定时打开Hibernate会话。一旦已绑定到线程，这个打开了的Hibernate会话可以在DAO实现类中透明地使用。这个会话会为
延迟加载数据库
中值对象的视图保持打开状态。一旦这个
逻辑视图完成了，Hibernate会话会在Filter的doFilter方法或者Interceptor的postHandle方法中被关闭。
实现方法在web.xml中加入
hibernateFilter
org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
hibernateFilter
性能优化
初用HIBERNATE的人也许都遇到过性能问题，实现同一功能，用HIBERNATE与用JDBC性能相差十几倍很正常，如果不及早调整，很可能影响整个项目的进度。 大体上，对于HIBERNATE
性能调优的主要考虑点如下：
.HQL优化
.
API的正确使用(如根据不同的业务类型选用不同的集合及查询API)
.主配置参数(日志，查询缓存，fetch_size,
batch_size等)
.映射文件优化(ID生成策略，二级缓存，
延迟加载，关联优化)
.针对二级缓存，还有许多特有的策略
数据库设计
a) 降低关联的复杂性
b) 尽量不使用联合主键
c) ID的生成机制，不同的数据库所提供的机制并不完全一样
HQL优化
HQL如果抛开它同HIBERNATE本身一些缓存机制的关联，HQL的优化技巧同普通的SQL优化技巧一样，可以很容易在网上找到一些经验之谈。
主配置
a) 查询缓存，同下面讲的缓存不太一样，它是针对HQL语句的缓存，即完全一样的语句再次执行时可以利用缓存数据。但是，查询缓存在一个
交易系统(数据变更频繁，查询条件相同的机率并不大)中可能会起反作用:它会白白耗费大量的
系统资源但却难以派上用场。
b) fetch_size，同JDBC的
相关参数作用类似，参数并不是越大越好，而应根据
业务特征去设置
c) batch_size同上。
缓存
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)的配置一样，只是缓存产品的选用不同，
oscache, jboss cache，的大多数项目，对它们的用于集群的使用(特别是关键交易系统)都持保守态度。在集群环境中，只利用数据库级的缓存是最安全的。
延迟加载
b) 集合延迟加载:通过实现自有的SET/LIST，HIBERNATE提供了这方面的支持
c) 属性延迟加载:
方法选用
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()){
YouObject object = (YouObject)it.next();
session.evict(youObject);
sessionFactory.evice(YouObject.class, youObject.getId());
}
如果用list方法，很可能就出OutofMemory错误了。
集合的选用
在Hibernate3.1文档的“19.5. Understanding Collection performance”中有详细的说明。
事务控制
事务方面对性能有影响的主要包括:事务方式的选用，
事务隔离级别以及锁的选用
a)
事务方式选用:如果不涉及多个事务管理器事务的话，不需要使用JTA，只有
JDBC的事务控制就可以。
b) 事务隔离级别:参见标准的SQL事务隔离级别
c) 锁的选用:
悲观锁(一般由具体的事务管理器实现)，对于
长事务效率低，但安全。
乐观锁(一般在应用级别实现)，如在HIBERNATE中可以定义 VERSION字段，显然，如果有多个应用操作数据，且这些应用不是用同一种乐观锁机制，则乐观锁会失效。因此，针对不同的数据应有不同的策略，同前面许多情况一样，很多时候我们是在效率与安全/
准确性上找一个平衡点，无论如何，优化都不是一个纯技术的问题，你应该对你的应用和业务特征有足够的了解。
批量操作
即使是使用JDBC，在进行大批
数据更新时，BATCH与不使用BATCH
有效率上也有很大的差别。可以通过设置batch_size来让其支持批量操作。
举个例子，要批量删除某表中的对象，如“delete Account”，打出来的语句，HIBERNATE找出了所有ACCOUNT的ID，再进行删除，这主要是为了维护二