Join fetching : Hibernate取关联数据或集合是通过OUTER JOIN的方式，通过同一条select 语句来实现。

Select fetching:在没有指定了lazy = "false"（既延迟加载有效）的情况下，通过另一条select 语句来获得与已经获得的实体相关的实体或集合。当然
这种情况发生在用户真正要获得关联对象的时候。

Subselect fetching:在没有指定了lazy = "false"（既延迟加载有效）的情况下，先通过一条查询语句获得了一个实体集，  然后对这个实体集中的每一个对象通过另一条select 语句来获得与它相关的实体或集合。
当然这种情况发生在用户真正要获得关联对象的时候。

Batch fetching ：它是为查询数据提供的一种优化策略。通过指定主键或外键的列表的方式来实现一条select 语句获得一批实体或集合。

从另一个角度来看，hibernate的fetching 分成以下几种。

Immediate fetching: 如果实体已经被加载了，他的关联对象，关联集合，属性也要及时加栽。

lazy collection fetching: 只有应用程序真正使用这个集合的时候，才加栽这个集合。

"Extra-lazy" collection fetching : hibernate 不加载一个集合的所有对象到内存里，需要哪个个体，加载哪个。

Proxy fetching :当前对象的单值相关对象只有在调用它的主键外的其他属性的get方法时才加载它。

"NO-proxy"fetching :当前对象的单值相关对象在它的实体变量被访问的时候就被加载。相对于Proxy fetching来说，Proxy fetching更延迟。
（因为"NO-proxy"fetching即使是访问关联对象的主健，关联对象都要被加载）。"NO-proxy"fetching对于应用来说更条理清晰。因为在应用
中没有一个可见的proxy.
  　个人认为可以这样理解上述情况，假如在数据库中存在两张表　A,B.表A中有一个指向表B主健的外键。如果想知道A表中的某条
    数据对应B表中的那条记录的主键。完全不用访问B表，A表中的此条数据的外键值就是B表中对应数据的主键。所有只有访问B表中
    对应数据的主键外其他属性时，才需要加载B表中的这条数据。

Lazy attribute fetching ：当前对象的某个属性或单值相关对象只有在与它对应的实体变量被访问的时候才加载。

Working with lazy associations
默认的情况下，Hibernate3 在获取关联对象集合的时候使用的是lazy策略，获得单值关联对象的时候使用的是lazy proxy策略。这样的策略
几乎适用所有的应用。

如果你设置了hibernate.default_batch_fetch_size,Hibernate就会通过批量获取来优化lazy fetching.

lazy fetching 会引起一个问题。就是关闭了hibernate　session以后加载延迟加载的对象。这样会引起异常。如下：

s = sessions.openSession();
Transaction tx = s.beginTransaction();
User u = (User) s.createQuery("from User u where u.name=:userName")
.setString("userName", userName).uniqueResult();
Map permissions = u.getPermissions();
tx.commit();
s.close();
Integer accessLevel = (Integer) permissions.get("accounts"); // Error!

由于在session被关闭之前，permissions 没有被初始化，所以它的数据没有被加载。hibernate不支持已经被分离的对象
的延迟加载。修改的方法是把相关代码移到tx.commit()之前。

或者我们可以在配置文件里通过在关联对象那里指定 lazy="false"来使关联集合或对象不被延迟加载。但是如果你定义太多的
非延迟加载对象，hibernate 在一次事务中可以需要把整个数据库加载到内存中。

从另一个角度来说，在一次事务中，我们经常使用joint fetching 这种方式（它天生就不是延迟加载）来代替select fetching 这种方式。
下边我们就要看到怎么自定义 取策略。在hibernate3中,单值和集合关联对象的取策略的指定方式是一致的。

Tuning fetch strategies
默认的select fetching 这种取策略很容器导致N+1次select 操作这样的问题。所以我们可以在配置文件里指定join fetching 策略。如下：
Cat对应的配置文件：
<set name="permissions"
fetch="join">
<key column="userId"/>
<one-to-many class="Permission"/>
</set>
Permission对应的配置文件：
<many-to-one name="mother" class="Cat" fetch="join"/>
在映射文件里定义的取策略会影响如下操作：
　由 get() 或load()执行的取操作。
　操作关联对象而引发的取操作。
　Criteria查询。
　如果使用了subselect 这种取策略还会影响HQL这种查询方式。

一般来说，我们不是通过在映射配置文件自定义取策略，而是通过在一个事务里，通过在特定的HQL里使用 left join 来覆盖默认的取
策略。对于Criteria 来说，提供了setFetchMode(FetchMode.JOIN) API.如下：

User user = (User) session.createCriteria(User.class)
.setFetchMode("permissions", FetchMode.JOIN)
.add( Restrictions.idEq(userId) )
.uniqueResult();

另一种完全不同的避免N+1次selects 的方式是使用second-level cache.

Single-ended association proxies
集合的延迟加载是通过Hibernate自己的持久化集合实现的,但是对于单个相关对象的延迟加载
需要一个不同的机制.相关的对象必须被代理.Hibernate 对持久化对象的代理的延迟加载是通过
对运行时字节的动态注入实现的(通过CGLIB实现).

默认的情况下,Hibernate3为所有的持久化类生成代理,通过这些代理来完成 many-to-one 和
one-to-one 关联对象的延迟加载.

在映射文件中可以为类声明一个接口做为它的代理接口,通过proxy属性指定。实际上,hibernate真正代理的是
这个类的子类。需要注意的是，被代理的类必须实现一个默认的构造函数（此构造函数的范围至少是包内可见的）。
推荐所有的持久化类使用这种构造函数。我们现在可以看到的是在类的多态的时候会采用这种方式：

<class name="Cat" proxy="Cat">
......
<subclass name="DomesticCat">
.....
</subclass>
</class>

首先要注意的是，Cat的实例不能当作DomesticCat实例使用。即使Cat和DomesticCat对应的是同一条数据。
Cat cat = (Cat) session.load(Cat.class, id); // instantiate a proxy (does not hit the db)
if ( cat.isDomesticCat() ) { // hit the db to initialize the proxy
DomesticCat dc = (DomesticCat) cat; // Error!
....
}

其次，两者之间不能使用==
Cat cat = (Cat) session.load(Cat.class, id); // instantiate a Cat proxy
DomesticCat dc =
(DomesticCat) session.load(DomesticCat.class, id); // acquire new DomesticCat proxy!
System.out.println(cat==dc);

实际情况并非如我们看到的那么糟糕。即使我们引用了两个不同的代理对象，实际的对象却是相同的。
cat.setWeight(11.0); // hit the db to initialize the proxy
System.out.println( dc.getWeight() ); // 11.0

还需注意的是如果一个类是final class,或者它有final方法。我们就不能使用CGLIB代理.

最后，如果你的持久化对象在实例化的过程中获得的任何资源(例如 在initializers或者默认的构造函数里),这些
资源也将被proxy获得.实际上代理的是这个类的子类。

这些问题的根源是java不能多重继承.如果你想避免这些问题,你应该让每一个类(子类和父类)实现一个声明了业务方法的接口.
在你的映射文件中指定这些接口,如下:
<class name="CatImpl" proxy="Cat">
......
<subclass name="DomesticCatImpl" proxy="DomesticCat">
.....
</subclass>
</class>
CatImpl实现了接口Cat,DomesticCatImpl实现了接口DomesticCat.Cat和DomesticCat实例的代理可以
被load()或iterator()方法返回.(list()方法一般不返回代理).

Cat cat = (Cat) session.load(CatImpl.class, catid);
Iterator iter = session.iterate("from CatImpl as cat where cat.name='fritz'");
Cat fritz = (Cat) iter.next();
关系也被延迟加载.这意味这你必须在Cat中声明所有的属性，而不仅仅是CatImpl.

以下方法不需要代理的初始值。
equals()  此方法没有被覆盖的时候。
hashCode() 此方法没有被覆盖的时候。
主键对应的get方法。

Initializing collections and proxies
如果在session的外边访问一个没有初始化的集合或代理，会抛出一个LazyInitializationException异常。例如在分离的
状态下（session 已经close的情况下）访问一个实体的延迟加载的集合或代理对象。

有时候我们需要在session关闭之前确保一个代理或集合被初始化。当然我们可以通过cat.getSex()或cat.getKittents().size()
这种方式来强迫初试化。但是这样会使代码阅读者迷茫而且不是一种通用的方便的编码格式。

静态方法Hibernate.initialize() 和Hibernate.isInitialized()为应用提供了处理延迟加载集合或代理的一种便捷方式。
Hibernate.initialize(Cat) 会强制加载代理 cat. Hibernate.initialize(cat.getKittens())初始化kittens集合。当然这些方法要在
session关闭之前执行。

另一种方式是在所有需要的集合和代理对象都被加载之后再关闭session. 在一些应用中，尤其是当应用使用hibernate来获取
数据，却在其他的应用层处理这些数据。或是这些数据是在其他的处理过程中使用。为了确保这些集合在初始化的时候session
还处于打开状态，可以通过以下两种方式：

1 基于 web 的应用可以通过filter 在一次请求的最后关闭session.当然这样做是基于你的应用可以正确处理异常。非常重要的一点是要确保把信息返回给用户之前把事务结束和把session关掉，即使是在你的页面处理发生异常的情况下。(spring 的OpenSessionInViewFilter就是基于此开发出来的)

2 如果你的应用有一个单独的业务层。在业务逻辑这里要保证在返回给web 层信息之前完成所有的集合初始化工作。这意味着你的
业务层需要加载所有的数据并且把这些包括延迟加载的数据传给与一个特定的用户请求的相关呈现部分。一般来说这是通过在session
关闭之前针对相关的集合调用Hibernate.initialize()方法或者是采用Criteria 的FetchMode.JOIN 方式。采用命令模式往往比采用session
Facade容易一些。

3 你也可以在访问没有初试化的集合（或代理）之前把先前加载的一个对象通过merge()或lock()放到新的Session里。但是hibernate 不
会也不应该自动完成这样的工作，因为这样需要使用特殊的事务处理语法。

有时候，你需要获得集合中数据的个数，或者集合数据的一部分就不需要初始话整个集合。你可以通过Collection filter来获得集合中数据
的个数（不需要初始化整个集合）
( (Integer) s.createFilter( collection, "select count(*)" ).list().get(0) ).intValue()。
当然Collection filter也可以获取集合的一部分数据
s.createFilter( lazyCollection, "").setFirstResult(0).setMaxResults(10).list();

Using batch fetching
批量获取数据可以提高Hibernate的效率.批量获取是延迟select fetching策略的一种优化.我们可以对类或者集合两个角度采用批量取数据.

批量获取类/实体容易理解，假设有如下情况：
      在你的session里加载了25个Cat实例。每一个Cat都有一个own的引用指向一个person.在这里这个关联的person是通过代理的方式延迟加载
 （单值关联对象）。如果你现在要通过循环调用所有cat的getOwner()方法。hibernate会默认的执行25个select 语句来获得被代理的owner对象。
我们可以通过在Person这个表的映射文件中指定batch-size来实现批量取数据。
<class name="Person" batch-size="10">...</class>
Hibernate 现在会执行三条查询语句来完成查询，模式是10,10,5.

你也可以对集合进行批量取操作.例如,每一个person都有一个被延迟加载的集合Cats.现在在session中已经加载了10个 person实例.循环调用
所有的person的getCats()方法会产生10条select 语句.如果你在person的映射文件中定义了批量获取模式:
<class name="Person">
<set name="cats" batch-size="3">
...
</set>
</class>
通过设置batch-size设为3，Hibernate 会以3,3,3,1的模式通过四条select语句加载集合。

Using subselect fetching
如果要加载一个延迟加载的集合或一个单值的代理，Hibernate通过一个subselect 运行原来的查询语句，这种情况和batch-fetching是异曲同工的。

Using lazy property fetching
Hibernate支持对单个属性的延迟加载。这个优化技术也被 称为fetch groups. 需要注意的是，这个技术还处于推销阶段。因为在实际中，对行的读取
优化比对列的优化更重要。然而在一些特殊情况下，加载一个类的部分属性还是有必要的，比如一个继承的表有几百列而且数据模型还不能改变。

为了使某个属性被延迟加载，只需要在这个属性的影射文件中加上lazy属性即可。

<class name="Document">
<id name="id">
<generator class="native"/>
</id>
<property name="name" not-null="true" length="50"/>
<property name="summary" not-null="true" length="200" lazy="true"/>
<property name="text" not-null="true" length="2000" lazy="true"/>
</class>

属性的延迟加载需要使用运行时的字节设备来处理。如果你的持久化类还没有被这个设备处理。hibernate 会忽略这个设置
采用及时加载的方式。

要想使用此字节设备处理持久化类，使用如下的Ant 任务。

<target name="instrument" depends="compile">
<taskdef name="instrument" classname="org.hibernate.tool.instrument.InstrumentTask">
<classpath path="${jar.path}"/>
<classpath path="${classes.dir}"/>
<classpath refid="lib.class.path"/>
</taskdef>
<instrument verbose="true">
<fileset dir="${testclasses.dir}/org/hibernate/auction/model">
<include name="*.class"/>
</fileset>
</instrument>
</target>

另一种避免加载不需要的列的方式，至少在只读事务中，是通过使用HQL或Criteria查询属性。这样可以避免使用字节
处理工具。

你可以通过在HQL指定fetch all properties 来加载全部属性。

　　 缓存的介质一般是内存，所以读写速度很快。但如果缓存中存放的数据量非常大时，也会用硬盘作为缓存介质。缓存的实现不仅仅要考虑存储的介质，还要考虑到管理缓存的并发访问和缓存数据的生命周期。

　　Hibernate 的缓存包括 Session 的缓存和 SessionFactory 的缓存，其中 SessionFactory 的缓存又可以分为两类：内置缓存和外置缓存。 Session 的缓存是内置的，不能被卸载，也被称为 Hibernate 的第一级缓存。 SessionFactory 的内置缓存和 Session 的缓存在实现方式上比较相似，前者是 SessionFactory 对象的一些集合属性包含的数据，后者是指 Session 的一些集合属性包含的数据。 SessionFactory 的内置缓存中存放了映射元数据和预定义 SQL 语句，映射元数据是映射文件中数据的拷贝，而预定义 SQL 语句是在 Hibernate 初始化阶段根据映射元数据推导出来， SessionFactory 的内置缓存是只读的，应用程序不能修改缓存中的映射元数据和预定义 SQL 语句，因此 SessionFactory 不需要进行内置缓存与映射文件的同步。 SessionFactory 的外置缓存是一个可配置的插件。在默认情况下， SessionFactory 不会启用这个插件。外置缓存的数据是数据库数据的拷贝，外置缓存的介质可以是内存或者硬盘。 SessionFactory 的外置缓存也被称为 Hibernate 的第二级缓存。

　　Hibernate 的这两级缓存都位于持久化层，存放的都是数据库数据的拷贝，那么它们之间的区别是什么呢？为了理解二者的区别，需要深入理解持久化层的缓存的两个特性：缓存的范围和缓存的并发访问策略。

持久化层的缓存的范围

　　 缓存的范围决定了缓存的生命周期以及可以被谁访问。缓存的范围分为三类。

　　1 事务范围：缓存只能被当前事务访问。缓存的生命周期依赖于事务的生命周期，当事务结束时，缓存也就结束生命周期。在此范围下，缓存的介质是内存。事务可以是数据库事务或者应用事务，每个事务都有独自的缓存，缓存内的数据通常采用相互关联的的对象形式。

　　2 进程范围：缓存被进程内的所有事务共享。这些事务有可能是并发访问缓存，因此必须对缓存采取必要的事务隔离机制。缓存的生命周期依赖于进程的生命周期，进程结束时，缓存也就结束了生命周期。进程范围的缓存可能会存放大量的数据，所以存放的介质可以是内存或硬盘。缓存内的数据既可以是相互关联的对象形式也可以是对象的松散数据形式。松散的对象数据形式有点类似于对象的序列化数据，但是对象分解为松散的算法比对象序列化的算法要求更快。

　　3 集群范围：在集群环境中，缓存被一个机器或者多个机器的进程共享。缓存中的数据被复制到集群环境中的每个进程节点，进程间通过远程通信来保证缓存中的数据的一致性，缓存中的数据通常采用对象的松散数据形式。

　　 对大多数应用来说，应该慎重地考虑是否需要使用集群范围的缓存，因为访问的速度不一定会比直接访问数据库数据的速度快多少。

　　 持久化层可以提供多种范围的缓存。如果在事务范围的缓存中没有查到相应的数据，还可以到进程范围或集群范围的缓存内查询，如果还是没有查到，那么只有到数据库中查询。事务范围的缓存是持久化层的第一级缓存，通常它是必需的；进程范围或集群范围的缓存是持久化层的第二级缓存，通常是可选的。

持久化层的缓存的并发访问策略

　　 当多个并发的事务同时访问持久化层的缓存的相同数据时，会引起并发问题，必须采用必要的事务隔离措施。

　　 在进程范围或集群范围的缓存，即第二级缓存，会出现并发问题。因此可以设定以下四种类型的并发访问策略，每一种策略对应一种事务隔离级别。

　　 事务型：仅仅在受管理环境中适用。它提供了 Repeatable Read 事务隔离级别。对于经常被读但很少修改的数据，可以采用这种隔离类型，因为它可以防止脏读和不可重复读这类的并发问题。

　　 读写型：提供了 Read Committed 事务隔离级别。仅仅在非集群的环境中适用。对于经常被读但很少修改的数据，可以采用这种隔离类型，因为它可以防止脏读这类的并发问题。

　　 非严格读写型：不保证缓存与数据库中数据的一致性。如果存在两个事务同时访问缓存中相同数据的可能，必须为该数据配置一个很短的数据过期时间，从而尽量避免脏读。对于极少被修改，并且允许偶尔脏读的数据，可以采用这种并发访问策略。

　　 只读型：对于从来不会修改的数据，如参考数据，可以使用这种并发访问策略。

　　 事务型并发访问策略是事务隔离级别最高，只读型的隔离级别最低。事务隔离级别越高，并发性能就越低。

什么样的数据适合存放到第二级缓存中？

1 很少被修改的数据

2 不是很重要的数据，允许出现偶尔并发的数据

3 不会被并发访问的数据

4 参考数据

不适合存放到第二级缓存的数据？

1 经常被修改的数据

2 财务数据，绝对不允许出现并发

3 与其他应用共享的数据。

Hibernate 的二级缓存

　　 如前所述， Hibernate 提供了两级缓存，第一级是 Session 的缓存。由于 Session 对象的生命周期通常对应一个数据库事务或者一个应用事务，因此它的缓存是事务范围的缓存。第一级缓存是必需的，不允许而且事实上也无法比卸除。在第一级缓存中，持久化类的每个实例都具有唯一的 OID 。

　　 第二级缓存是一个可插拔的的缓存插件，它是由 SessionFactory 负责管理。由于 SessionFactory 对象的生命周期和应用程序的整个过程对应，因此第二级缓存是进程范围或者集群范围的缓存。这个缓存中存放的对象的松散数据。第二级对象有可能出现并发问题，因此需要采用适当的并发访问策略，该策略为被缓存的数据提供了事务隔离级别。缓存适配器用于把具体的缓存实现软件与 Hibernate 集成。第二级缓存是可选的，可以在每个类或每个集合的粒度上配置第二级缓存。

Hibernate 的二级缓存策略的一般过程如下：

1) 条件查询的时候，总是发出一条 select * from table_name where …. （选择所有字段）这样的 SQL 语句查询数据库，一次获得所有的数据对象。

2) 把获得的所有数据对象根据 ID 放入到第二级缓存中。

3) 当 Hibernate 根据 ID 访问数据对象的时候，首先从 Session 一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照 ID 放入到缓存。

4) 删除、更新、增加数据的时候，同时更新缓存。

　　Hibernate 的二级缓存策略，是针对于 ID 查询的缓存策略，对于条件查询则毫无作用。为此， Hibernate 提供了针对条件查询的 Query 缓存。

Hibernate 的 Query 缓存策略的过程如下：

1) Hibernate 首先根据这些信息组成一个 Query Key ， Query Key 包括条件查询的请求一般信息： SQL, SQL 需要的参数，记录范围（起始位置 rowStart ，最大记录个数 maxRows) ，等。

2) Hibernate 根据这个 Query Key 到 Query 缓存中查找对应的结果列表。如果存在，那么返回这个结果列表；如果不存在，查询数据库，获取结果列表，把整个结果列表根据 Query Key 放入到 Query 缓存中。

3) Query Key 中的 SQL 涉及到一些表名，如果这些表的任何数据发生修改、删除、增加等操作，这些相关的 Query Key 都要从缓存中清空。