Hibernate使用动态字节码增强技术来实现持久化对象的延迟装载代理（使用优秀的CGLIB库）。

映射文件为每一个类声明一个类或者接口作为代理接口。建议使用这个类自身：

<class name="eg.Order" proxy="eg.Order">

运行时的代理应该是Order的子类。注意被代理的类必须实现一个默认的构造器，并且至少在包内可见。

在扩展这种方法来对应多形的类时，要注意一些细节,比如：

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

首先，Cat永远不能被强制转换为DomesticCat,即使实际上该实例就是一个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);  // required new DomesticCat proxy!
System.out.println(cat==dc);                            // false

虽然如此，这种情况并不像看上去得那么糟。虽然我们现在有两个不同的引用来指向不同的代理对象，实际上底层的实例应该是同一个对象：

cat.setWeight(11.0);  // hit the db to initialize the proxy
System.out.println( dc.getWeight() );  // 11.0

第三，你不能对final的类或者具有final方法的类使用CGLIB代理。

最后,假如你的持久化对象在实例化的时候需要某些资源（比如，在实例化方法或者默认构造方法中），这些资源也会被代理需要。代理类实际上是持久化类的子类。

这些问题都来源于Java的单根继承模型的天生限制。如果你希望避免这些问题，你的每个持久化类必须抽象出一个接口，声明商业逻辑方法。你应该在映射文件中指定这些接口，比如：

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

这里Cat实现ICat接口，并且DomesticCat实现IDomesticCat接口。于是 load()或者iterate()就会返回Cat和DomesticCat的实例的代理。(注意find()不会返回代理。)

ICat cat = (ICat) session.load(Cat.class, catid);
Iterator iter = session.iterate("from cat in class eg.Cat where cat.name='fritz'");
ICat fritz = (ICat) iter.next();

关系也是延迟装载的。这意味着你必须把任何属性声明为ICat类型，而非Cat。

某些特定操作不需要初始化代理

Hibernate会识别出重载了equals() 或者 hashCode()方法的持久化类。

在初始化代理的时候发生的异常会被包装成LazyInitializationException。

有时候我们需要保证在Session关闭前某个代理或者集合已经被初始化了。当然，我们总是可以通过调用cat.getSex()或者 cat.getKittens().size()之类的方法来确保这一点。但是这样程序可读性不佳，也不符合通常的代码规范。静态方法Hibernate.initialize()和Hibernate.isInitialized()给你的应用程序一个正常的途径来加载集合或代理。Hibernate.initialize(cat) 会强制初始化一个代理,cat,只要它的Session仍然打开。Hibernate.initialize( cat.getKittens() )对kittens的集合具有同样的功能。

HibernateSession是事务级别的持久化数据缓存。再为每个类或者每个集合配置一个集群或者JVM级别(SessionFactory级别)的缓存也是有可能的。你甚至可以插入一个集群的缓存。要小心，缓存永远不会知道其他进程可能对持久化仓库（数据库）进行的修改（即使他们可能设定为经常对缓存的数据进行失效）。

Hibernate uses Apache Turbine's JCS for factory-level caching. Please see the JCS documentation for information on how to configure data expiry, in-memory caching, disk caching, etc.

默认情况下，Hibernate使用EHCache进行JVM级别的缓存。但是，对JCS的支持现在已经被废弃了，未来版本的Hibernate将会去掉它。通过hibernate.cache.provider_class属性，你也可以指定其他缓存，只要其实现了net.sf.hibernate.cache.CacheProvider接口。

12.2.1. 映射(Mapping)

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

<cache                                                      
                usage="transactional|read-write|nonstrict-read-write|read-only" />

usage 指定了缓存策略： transactional, read-write, nonstrict-read-write 或者 read-only

另外 (推荐首选?), 你可以在hibernate.cfg.xml中指定<class-cache> 和 <collection-cache> 元素。

usage属性指明了缓存并发策略（cache concurrency strategy）。

<class name="eg.Immutable" mutable="false">
    ....
    <jcs-cache usage="read-only"/>
</class>

<class name="eg.Cat" .... >
    <jcs-cache usage="read-write"/>
    ....
    <set name="kittens" ... >
        <jcs-cache usage="read-write"/>
        ....
    </set>
</class>

None of the cache providers support all of the cache concurrency strategies. The following table shows which providers are compatible with which concurrency strategies. 没有一种缓存提供器能够支持所有的缓存并发策略。下面的表列出每种提供器与各种并发策略的兼容性。

不管何时你传递一个对象给save(), update()或者 saveOrUpdate() ,或者不管何时你使用load(), find(), iterate()或者filter()取得一个对象的时候,该对象被加入到Session的内部缓存中。当后继的flush()被调用时，对象的状态会和数据库进行同步。如果你在处理大量对象并且需要有效的管理内存的时候，你可能不希望发生这种同步，evict()方法可以从缓存中去掉对象和它的集合。

Iterator cats = sess.iterate("from eg.Cat as cat"); //a huge result set
while ( cats.hasNext() ) {
    Cat cat = (Cat) iter.next();
    doSomethingWithACat(cat);
    sess.evict(cat);
}

Session也提供了一个contains()方法来判断是否一个实例处于这个session的缓存中。

要把所有的对象从session缓存中完全清除，请调用Session.clear()。

For the JVM-level JCS cache, there are methods defined on SessionFactory for evicting the cached state of an instance, entire class, collection instance or entire collection role.

对于第二层缓存来说，在SessionFactory中定义了一些方法来从缓存中清除一个实例、整个类、集合实例或者整个集合。

查询结果集也可以被缓存。只有当经常使用同样的参数进行查询时，这才会有些用处。要使用查询缓存，首先你要打开它，设置hibernate.cache.use_query_cache=true这个属性。这样会创建两个缓存区域——一个保存查询结果集(net.sf.hibernate.cache.QueryCache),另一个保存最近查询的表的时间戳(net.sf.hibernate.cache.UpdateTimestampsCache)。请注意查询缓存并不缓存结果集中包含实体的状态；它只缓存标识符属性的值和值类型的结果。所以查询缓存通常会和第二层缓存一起使用。

Most queries do not benefit from caching, so by default queries are not cached. To enable caching, call Query.setCacheable(true). This call allows the query to look for existing cache results or add its results to the cache when it is executed. 大多数查询并不会从缓存中获得什么好处，所以默认查询是不进行缓存的。要进行缓存，调用 Query.setCacheable(true)。这个调用会让查询在执行时去从缓存中查找结果，或者把结果集放到缓存去。

如果你要对查询缓存的失效政策进行精确的控制，你必须调用Query.setCacheRegion()来为每个查询指定一个命名的缓存区域。

List blogs = sess.createQuery("from Blog blog where blog.blogger = :blogger order by blog.datetime desc")
    .setEntity("blogger", blogger)
    .setMaxResults(15)
    .setCacheable(true)
    .setCacheRegion("frontpages")
    .list();