第 14 章 性能提升（Improving performance）
14.1. 理解集合的性能
我们已经花了很长时间在讨论集合(collections)了。在本章，我们会特别关注一些关于集合在运行时如何运作的问题。
14.1.1. 分类
Hibernate定义了三种基本类型的集合：
值集合
一对多关联
多对多关联
这个分类是按照不同的表和外键关系类型来区分的，但是没有告诉我们关于关系模型的一切。要完全理解他们的关系结构和性能特点，我们必须思考用于更新或删除集合行的主键的结构。这得到了如下的分类：
有序集合类
集合（sets）
包（bags）
有序集合类（maps, lists, arrays)有一个包含有<key>和<index>字段的主键。这种情况下集合类更新是特别高效的——主键会有效索引，当Hibernate试图更新或删除一行时，可以迅速找到这一行。
集合(sets)的主键包含有 <key> 和元素字段。对于有些元素类型来说，这会变得低效，特别是组合元素或者大文本、大二进制字段；数据库可能无法有效对复杂的主键进行索引。另一方面，对于一对多或多对多关联，特别是合成的标识符来说，它会达到同样的高效。（附注：如果你希望SchemaExport为你的<set>创建主键，你必须把所有的字段都声明为not-null="true"。）
Bag是最差的。因为bag允许重复的元素值，也没有索引字段，不可能定义主键。Hibernate没有办法来判断出重复的行。每当这种集合被更改，Hibernate会完整地移除（通过一个DELETE）,再重建整个集合。这会非常低效。
请注意对一对多关联来说，“主键”可能是数据库表的物理主键——但就算在这种情况下，上面的分类仍然是有用的。（它会反映Hibernate是如何在集合的各个行中“定位”的。）
14.1.2. Lists, maps 和sets用于更新效率最高
根据我们上面的讨论，显然有序类型和大多数set可以在增加/删除/修改元素的时候得到最好的性能。
但是，在多对多关联，或者对值元素而言，有序集合类比集合(set)有一个好处。因为Set的结构，如果“改变”了一个元素,Hibernate并不会UPDATE这一行。对Set来说，只有INSERT和DELETE才有效。注意这一段描述对一对多关联并不适用。
注意到数组无法延迟转载，我们可以得出结论，list, map和set是最高效的集合类型。（当然，我们警告过了，由于集合中的值的关系，set可能性能下降。）
Set可以被看作是Hibernate程序中最普遍的集合类型。
这个版本的Hibernate有一个没有写在文档中的功能。<idbag>可以对值集合和多对多关联实现bag语义，并且性能比上面任何类型都高！
14.1.3. Bag和list是反向集合类中效率最高的
好了，在你把bag扔到水沟里面再踩上一只脚之前要了解，有一种情况下bag(包括list)要比set性能高得多。对于指明了inverse="true"的集合类（比如说，标准的双向一对多关联），我们可以在不初始化(fetch)包元素的情况下就增加新元素！这是因为Collection.add()或者Collection.addAll()对bag或者List总是返回true的（与Set不同）。对于下面的代码来说，速度会快得多。
Parent p = (Parent) sess.load(Parent.class, id);
Child c = new Child();
c.setParent(p);
p.getChildren().add(c); //no need to fetch the collection!
sess.flush();
14.1.4. 一次性删除(One shot delete)
有时候，一个一个的删除集合类中的元素是极度低效的。Hibernate没那么笨，如果你想要把整个集合都删除（比如说调用list.clear()），Hibernate只需要一个DELETE就搞定了。
假设我们在一个长度为20的集合类中新增加了一个元素，然后删除了两个。Hibernate会安排一个INSERT语句和两条DELETE语句（除非集合类是一个bag)。这当然是可以想见的。
但是，如果假设我们删除了18个元素，只剩下2个，然后新增3个。有两种处理方式：
把这18个元素一个一个的干掉，再新增三个
把整个集合类都咔嚓掉（只用一句DELETE语句），然后增加5个元素。
Hibernate还没那么聪明，知道第二种选择可能会比较快。（也许让Hibernate不要这么聪明也是好事，否则可能会引发意外的数据库触发器什么的。）
幸运的是，你可以强制使用第二种策略。你需要把原来的整个集合类都取消（取消其引用），然后返回一个新实例化的集合类，只包含需要的元素。有些时候这是非常有用的。
我们已经为您展示了如何在对集合持久化时使用延迟装载（lazy initialization）。对于通常的对象引用，使用CGLIB代理可以达到类似的效果。我们也提到过Hibernate在Session级别缓存持久化对象。还有更多先进的缓存策略，你可以为每一个类单独配置。
这本章里，我们来教你如何使用这些特性，在必要的时候得到高得多的性能。
14.2. 用于延迟装载的代理
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。
