单一数据加载：Session.get/load
均可以根据指定的实体类和id从数据库中读取记录，并返回与之对应的实体对象。
区别：
1.如果未能发现符合条件的记录，get方法返回null,而load方法会抛出一个ObjectNotFoundException。
2.Load方法可返回实体的代理类实例，而get方法永远直接返回实体类。
3.load方法可以充分利用内部缓存和二级缓存中的现有数据，而get方法仅在内部缓存中查找，如果没有发现对应的数据，将越过二级缓存，直接调用SQL完成数据读取。
数据加载的过程：
1.在一级缓存中，根据实体类型和id进行查找，如果在第一级缓存中命中，且数据状态合法，则直接返回。
2.Session会在当前"NonExists"记录中进行查找，如果在"NonExists"记录中存在同样的条件，返回null。
3.对load方法而言，如果内部缓存中没法现有效数据，查询二级缓存，命中则返回。
4.如果缓存中无有效数据，发起数据库查询操作(Select SQL)，如果经过查询未发现对应记录，将此次查询的信息在"NonExists"中加以记录，返回null.
5.根据映射配置和Select SQL查询得到的ResultSet，创建对应的数据对象。
6.将对象纳入一级缓存。
7.执行Interceptor.onLoad方法(如果有对应的Interceptor)
8.将数据纳入二级缓存
9.如果数据对象实现了LifeCycle接口，则调用数据对象的onLoad方法。
10.返回数据对象。

批量查询：Session.find/iterate
查询性能往往是系统性能表现的一个重要方面，查询机制的优劣很大程度上决定了系统的整体性能。这个领域往往也存在最大的性能调整空间。

hibernate2中Session.find()对应于3中的session.createQuery().list();
hibernate2中Session.iterate()对应于3中的session.createQuery().iterate();
find和iterate区别：
find方法通过一条Select SQL实现了查询操作，而iterate方法要执行多条Select SQL.
iterate第一次查询获取所有符合条件的记录的id，然后再根据各个id从库表中读取对应的记录，这是一个典型的N+1次的查询问题，如果符合条件记录有10000条，就需要执行10001条Select SQL，可想性能会如何的差。

那为什么要提供iterator方法，而不只是提供高效率的find方法？

原因1.与hibernate缓存机制密切相关
find方法实际上是无法利用缓存的，它对缓存只写不读。
find方法只执行一次SQL查询，它无法判断缓存中什么样的数据是符合条件的，也无法保证查询结果的完整性。而iterate方法，会首先查询所有符合条件记录的id，然后根据id去缓存中找，如果缓存中有该id，就返回，没有可以根据id再去数据库查询。
String hql = "from TUser where age > ?";
List userList = session.find(hql, new Integer(18), Hibernate.INTEGER);
Iterator it = session.iterate(hql, new Integer(18), Hibernate.INTEGER);
顺序执行，iterate方法只会执行一次SQL查询，就是查找id，然后根据id就可以从缓存中获得数据。

String hql = "from TUser where age > ?";
List userList = session.find(hql, new Integer(18), Hibernate.INTEGER);
userList = session.find(hql, new Integer(18), Hibernate.INTEGER);
缓存是不起作用的。
如果目标数据读取相对较为频繁，通过iterate这种机制，会减少性能损耗。

原因2.内存使用上的考虑
find方法将一次获得的所有记录并将其读入内存。如果数据量太大，可能会触发OutOfMemoryError，从而导致系统异常。解决方案之一就是结合iterate方法和evict方法逐条对记录进行处理，将内存消化保持在一个可以接受的范围之内。如：
String hql = "from TUser where age > ?";
Iterator it = session.iterate(hql, new Integer(18), Hibernate.INTEGER);
while(it.hasNext()) {
    TUser user = (TUser)it.next();
   
    //将对象从一级缓存中删除
    session.evict(user);

    //二级缓存可以设定最大缓存量,达到后自动对较老数据进行废除,但也可以通过编
    //码移除,这样有助于保持数据有效性。
    sessionFactory.evict(TUser.class, user.getID());
}


批量数据处理的缓存同步问题
1.hibernate 2:
session.delete("from TUser");
会先查询出id，然后逐个id执行 delete from T_User where id = ?;
这样造成效率低下。
为什么不直接采用一条Delete SQL？是因为ORM要自动维持其内部状态属性，必须知道用户作了什么操作。必须先从数据库中获得待删除对象，然后根据这些对象对内部缓存和二级缓存的数据进行整理，以保持内存状态与数据库的一致性。
单执行一条删除语句，删除了什么数据，只有数据库知道，ORM无法得知。下次用户从缓存中读出的数据，很可能就是被删除的数据，从而导致逻辑错误。当然，如果ORM可以根据DELETE SQL对缓存中数据进行处理，将缓存中符合条件的对象废除，然后再执行DELETE SQL
，但是这样导致缓存的管理复杂性大大增加(实际相当于实现了一个支持SQL的内存数据库)，这对于轻量级的ORM实现而言太苛刻了。
2.hibernate 3
性能提高。
但无法解决缓存同步上的问题，无法保证缓存数据的一致有效性。
Tuser user = (TUser)session.load(TUser.class, new Integer(1));

//通过Bulk delete/update 删除id=1的用户记录
Transaction tx = session.beginTransaction();
String hql = "delete TUser where id=1";
Query query = session.createQuery(hql);
query.executeUpdate();
tx.commit();

//再次尝试加载
user = (TUser)session.load(TUser.class, new Integer(1));
可以看到第二次加载是成功的。