hibernate缓存：一级缓存和二级缓存
1.什么是缓存？
缓存是介于物理数据源与应用程序之间，是对数据库中的数据复制一份临时放在内存中的容器，其作用是为了减少应用程序对物理数据源访问的次数，从而提高了应用程序的运行性能。Hibernate在进行读取数据的时候，根据缓存机制在相应的缓存中查询，如果在缓存中找到了需要的数据(我们把这称做“缓存命 中")，则就直接把命中的数据作为结果加以利用，避免了大量发送SQL语句到数据库查询的性能损耗。
缓存策略提供商：
提供了HashTable缓存，EHCache，OSCache，SwarmCache，jBoss Cathe2，这些缓存机制，其中EHCache，OSCache是不能用于集群环境（Cluster Safe）的，而SwarmCache，jBoss Cathe2是可以的。HashTable缓存主要是用来测试的，只能把对象放在内存中，EHCache，OSCache可以把对象放在内存（memory）中，也可以把对象放在硬盘（disk）上（为什么放到硬盘上？上面解释了）。
Hibernate缓存分类：
一、Session缓存（又称作事务缓存）：Hibernate内置的，不能卸除。
缓存范围：缓存只能被当前Session对象访问。缓存的生命周期依赖于Session的生命周期，当Session被关闭后，缓存也就结束生命周期。
二、SessionFactory缓存（又称作应用缓存）：使用第三方插件，可插拔。
缓存范围：缓存被应用范围内的所有session共享,不同的Session可以共享。这些session有可能是并发访问缓存，因此必须对缓存进行更新。缓存的生命周期依赖于应用的生命周期，应用结束时，缓存也就结束了生命周期，二级缓存存在于应用程序范围。
一级缓存：
Hibernate一些与一级缓存相关的操作（时间点）：
数据放入缓存：
1. save()。当session对象调用save()方法保存一个对象后，该对象会被放入到session的缓存中。
2. get()和load()。当session对象调用get()或load()方法从数据库取出一个对象后，该对象也会被放入到session的缓存中。
3. 使用HQL和QBC等从数据库中查询数据。
例如：数据库有一张表如下：
使用get()或load()证明缓存的存在：
程序控制台输出结果：
Hibernate:
select
customer0_.id as id0_0_,
customer0_.username as username0_0_,
customer0_.balance as balance0_0_
from
customer customer0_
where
customer0_.id=?
customer.getUsername islisi
-------------------------------------
customer2.getUsername islisi
-------------------------------------
customer1 == customer2 result is true
其原理是：在同一个Session里面，第一次调用get()方法， Hibernate先检索缓存中是否有该查找对象，发现没有，Hibernate发送SELECT语句到数据库中取出相应的对象，然后将该对象放入缓存中，以便下次使用，第二次调用get()方法，Hibernate先检索缓存中是否有该查找对象，发现正好有该查找对象，就从缓存中取出来，不再去数据库中检索，没有再次发送select语句。
数据从缓存中清除：
1. evit()将指定的持久化对象从缓存中清除，释放对象所占用的内存资源，指定对象从持久化状态变为脱管状态，从而成为游离对象。
2. clear()将缓存中的所有持久化对象清除，释放其占用的内存资源。
其他缓存操作：
1. contains()判断指定的对象是否存在于缓存中。
2. flush()刷新缓存区的内容，使之与数据库数据保持同步。
二级缓存：
当我们重启一个Session，第二次调用load或者get方法检索同一个对象的时候会重新查找数据库，会发select语句信息。
原因：一个session不能取另一个session中的缓存。
性能上的问题：假如是多线程同时去取Category这个对象，load一个对象，这个对像本来可以放到内存中的，可是由于是多线程，是分布在不同的session当中的，所以每次都要从数据库中取，这样会带来查询性能较低的问题。
解决方案：使用二级缓存。
1.什么是二级缓存？
SessionFactory级别的缓存，可以跨越Session存在，可以被多个Session所共享。
2.适合放到二级缓存中：
（1）经常被访问
（2）改动不大
（3）数量有限
（4）不是很重要的数据，允许出现偶尔并发的数据。
这样的数据非常适合放到二级缓存中的。
用户的权限：用户的数量不大，权限不多，不会经常被改动，经常被访问。
例如组织机构。
思考：什么样的类，里面的对象才适合放到二级缓存中？
改动频繁，类里面对象特别多，BBS好多帖子，这些帖子20000多条，哪些放到缓存中，不能确定。除非你确定有一些经常被访问的，数据量并不大，改动非常少，这样的数据非常适合放到二级缓存中的。
3.二级缓存实现原理：
Hibernate如何将数据库中的数据放入到二级缓存中？注意，你可以把缓存看做是一个Map对象，它的Key用于存储对象OID，Value用于存储POJO。首先，当我们使用Hibernate从数据库中查询出数据，获取检索的数据后，Hibernate将检索出来的对象的OID放入缓存中key 中，然后将具体的POJO放入value中，等待下一次再次向数据查询数据时，Hibernate根据你提供的OID先检索一级缓存，若有且配置了二级缓存，则检索二级缓存，如果还没有则才向数据库发送SQL语句，然后将查询出来的对象放入缓存中。
4使用二级缓存
（1）打开二级缓存：
为Hibernate配置二级缓存：
在主配置文件中hibernate.cfg.xml ：
（2）配置ehcache.xml
（3）使用二级缓存需要在实体类中加入注解：
需要ehcache-1.2.jar包:
还需要 commons_loging1.1.1.jar包
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
Load默认使用二级缓存，就是当查一个对象的时候，它先会去二级缓存里面去找，如果找到了就不去数据库中查了。
Iterator默认的也会使用二级缓存，有的话就不去数据库里面查了，不发送select语句了。
List默认的往二级缓存中加数据，假如有一个query，把数据拿出来之后会放到二级缓存，但是执行查询的时候不会到二级缓存中查，会在数据库中查。原因每个query中查询条件不一样。
（4）也可以在需要被缓存的对象中hbm文件中的<class>标签下添加一个<cache>子标签:
存在一对多的关系，想要在在获取一方的时候将关联的多方缓存起来，需要再集合属性下添加<cache>子标签，这里需要将关联的对象的 hbm文件中必须在存在<class>标签下也添加<cache>标签，不然Hibernate只会缓存OID。
二级缓存和查询缓存都相当于一个map。
二级缓存缓存的key为id，value为实体对象。一般load（），iterate（）使用到二级缓存，list()需要结合查询缓存使用。iterate（）和list（）区别如下：
iterate()不需要开启查询缓存，它首先发出一个sql如”select s.id from Student s”去数据库把id属性列表取出来，然后再根据id列表一个一个load（），如果缓存有从缓存取，如果缓存没有就从数据库取：select s.id,s.name,s.classid from Student s where s.id=?,取出后再存入二级缓存。Iterate总会发出取id列表的语句。
List（）需要开启查询缓存，它首先发出一个sql如”select s.id,s.name,s.classid from Student s…”去数据库取出所有相关实体，并将这些实体存入二级缓存，将此sql语句及一些相关信息作为key，id列表作为值，第二次查询这条语句时就会去根据sql语句及相关信息去key里找，如果有就会把id列表取出一个一个load（），接下来就和iterate一样了。List一般只有第一次发发出取实体列表的语句，以后的id列表就会去查询缓存取id列表，不会再发出sql语句。
前提：执行同一hql语句，如：select s from Student s
1.关闭查询缓存，开启二级缓存时:
第二次查询属性时iterate只会发出获取id列表的sql，list会发出和第一次一样的请求实体的sql。
2.开启查询缓存，开启二级缓存
第二次查询属性时iterate只会发出获取id列表的sql，list不发sql。
以上说明iterate只和二级缓存有关，list和二级缓存和查询缓存都有关。
list 不会使用二级缓存，但是会填充二级缓存，还会使用查询缓存
一、hibernate的二级缓存
如果开启了二级缓存，hibernate在执行任何一次查询的之后，都会把得到的结果集放到缓存中，缓存结构可以看作是一个hash table，key是数据库记录的id，value是id对应的pojo对象。当用户根据id查询对象的时候（load、iterator方法），会首先在缓存中查找，如果没有找到再发起数据库查询。但是如果使用hql发起查询（find, query方法）则不会利用二级缓存，而是直接从数据库获得数据，但是它会把得到的数据放到二级缓存备用。也就是说，基于hql的查询，对二级缓存是只写不读的。
针对二级缓存的工作原理，采用iterator取代list来提高二级缓存命中率的想法是不可行的。Iterator的工作方式是根据检索条件从数据库中选取所有目标数据的id，然后用这些id一个一个的到二级缓存里面做检索，如果找到就直接加载，找不到就向数据库做查询。因此假如iterator检索100条数据的话，最好情况是100%全部命中，最坏情况是0%命中，执行101条sql把所有数据选出来。而list虽然不利用缓存，但是它只会发起1条sql取得所有数据。在合理利用分页查询的情况下，list整体效率高于iterator。
二级缓存的失效机制由hibernate控制，当某条数据被修改之后，hibernate会根据它的id去做缓存失效操作。基于此机制，如果数据表不是被hibernate独占（比如同时使用JDBC或者ado等），那么二级缓存无法得到有效控制。
由于hibernate的缓存接口很灵活，cache provider可以方便的切换，因此支持cluster环境不是大问题，通过使用swarmcache、jboss cache等支持分布式的缓存方案，可以实现。但是问题在于:
1、 分布式缓存本身成本偏高（比如使用同步复制模式的jboss cache）
2、 分布式环境通常对事务控制有较高要求，而目前的开源缓存方案对事务缓存（transaction cache）支持得不够好。当jta事务发生会滚，缓存的最后更新结果很难预料。这一点会带来很大的部署成本，甚至得不偿失。
结论：不应把hibernate二级缓存作为优化的主要手段，一般情况下建议不要使用。
原因如下：
1、 由于hibernate批量操作的性能不如sql，而且为了兼容1.0的dao类，所以项目中有保留了sql操作。哪些数据表是单纯被hibernate独占无法统计，而且随着将来业务的发展可能会有很大变数。因此不宜采用二级缓存。
2、 针对系统业务来说，基于id检索的二级缓存命中率极为有限，hql被大量采用，二级缓存对性能的提升很有限。
3、 hibernate 3.0在做批量修改、批量更新的时候，是不会同步更新二级缓存的，该问题在hibernate 3.2中是否仍然存在尚不确定。
二、hibernate的查询缓存
查询缓存的实现机制与二级缓存基本一致，最大的差异在于放入缓存中的key是查询的语句，value是查询之后得到的结果集的id列表。表面看来这样的方案似乎能解决hql利用缓存的问题，但是需要注意的是，构成key的是：hql生成的sql、sql的参数、排序、分页信息等。也就是说如果你的hql有小小的差异，比如第一条hql取1-50条数据，第二条hql取20-60条数据，那么hibernate会认为这是两个完全不同的key，无法重复利用缓存。因此利用率也不高。
另外一个需要注意的问题是，查询缓存和二级缓存是有关联关系的，他们不是完全独立的两套东西。假如一个查询条件hql_1，第一次被执行的时候，它会从数据库取得数据，然后把查询条件作为key，把返回数据的所有id列表作为value（请注意仅仅是id）放到查询缓存中，同时整个结果集放到class缓存（也就是二级缓存），key是id，value是pojo对象。当你再次执行hql_1，它会从缓存中得到id列表，然后根据这些列表一个一个的到class缓存里面去找pojo对象，如果找不到就向数据库发起查询。也就是说，如果二级缓存配置了超时时间（或者发呆时间），就有可能出现查询缓存命中了，获得了id列表，但是class里面相应的pojo已经因为超时(或发呆)被失效，hibernate就会根据id清单，一个一个的去向数据库查询，有多少个id，就执行多少个sql。该情况将导致性能下降严重。
查询缓存的失效机制也由hibernate控制，数据进入缓存时会有一个timestamp，它和数据表的timestamp对应。当hibernate环境内发生save、update等操作时，会更新被操作数据表的timestamp。用户在获取缓存的时候，一旦命中就会检查它的timestamp是否和数据表的timestamp匹配，如果不，缓存会被失效。因此查询缓存的失效控制是以数据表为粒度的，只要数据表中任何一条记录发生一点修改，整个表相关的所有查询缓存就都无效了。因此查询缓存的命中率可能会很低。
结论：不应把hibernate二级缓存作为优化的主要手段，一般情况下建议不要使用。
原因如下：
1、 项目上层业务中检索条件都比较复杂，尤其是涉及多表操作的地方。很少出现重复执行一个排序、分页、参数一致的查询，因此命中率很难提高。
2、 查询缓存必须配合二级缓存一起使用，否则极易出现1+N的情况，否则性能不升反降
3、 使用查询缓存必须在执行查询之前显示调用Query.setCacheable(true)才能激活缓存，这势必会对已有的hibernate封装类带来问题。
总结
详细分析hibernate的二级缓存和查询缓存之后，在底层使用通用缓存方案的想法基本上是不可取的。比较好的做法是在高层次中（业务逻辑层面），针对具体的业务逻辑状况手动使用数据缓存，不仅可以完全控制缓存的生命周期，还可以针对业务具体调整缓存方案提交命中率。Cluster中的缓存同步可以完全交给缓存本身的同步机制来完成。比如开源缓存swarmcache采用invalidate的机制，可以根据用户指定的策略，在需要的时候向网络中的其他swarmcache节点发送失效消息，建议采用。
1.什么是缓存？
缓存是介于物理数据源与应用程序之间，是对数据库中的数据复制一份临时放在内存中的容器，其作用是为了减少应用程序对物理数据源访问的次数，从而提高了应用程序的运行性能。Hibernate在进行读取数据的时候，根据缓存机制在相应的缓存中查询，如果在缓存中找到了需要的数据(我们把这称做“缓存命 中")，则就直接把命中的数据作为结果加以利用，避免了大量发送SQL语句到数据库查询的性能损耗。
缓存策略提供商：
提供了HashTable缓存，EHCache，OSCache，SwarmCache，jBoss Cathe2，这些缓存机制，其中EHCache，OSCache是不能用于集群环境（Cluster Safe）的，而SwarmCache，jBoss Cathe2是可以的。HashTable缓存主要是用来测试的，只能把对象放在内存中，EHCache，OSCache可以把对象放在内存（memory）中，也可以把对象放在硬盘（disk）上（为什么放到硬盘上？上面解释了）。
Hibernate缓存分类：
一、Session缓存（又称作事务缓存）：Hibernate内置的，不能卸除。
缓存范围：缓存只能被当前Session对象访问。缓存的生命周期依赖于Session的生命周期，当Session被关闭后，缓存也就结束生命周期。
二、SessionFactory缓存（又称作应用缓存）：使用第三方插件，可插拔。
缓存范围：缓存被应用范围内的所有session共享,不同的Session可以共享。这些session有可能是并发访问缓存，因此必须对缓存进行更新。缓存的生命周期依赖于应用的生命周期，应用结束时，缓存也就结束了生命周期，二级缓存存在于应用程序范围。
一级缓存：
Hibernate一些与一级缓存相关的操作（时间点）：
数据放入缓存：
1. save()。当session对象调用save()方法保存一个对象后，该对象会被放入到session的缓存中。
2. get()和load()。当session对象调用get()或load()方法从数据库取出一个对象后，该对象也会被放入到session的缓存中。
3. 使用HQL和QBC等从数据库中查询数据。
例如：数据库有一张表如下：
使用get()或load()证明缓存的存在：
public class Client
{
public static void main(String[] args)
{
Session session = HibernateUtil.getSessionFactory().openSession();
Transaction tx = null;
try
{
/*开启一个事务*/
tx = session.beginTransaction();
/*从数据库中获取id="402881e534fa5a440134fa5a45340002"的Customer对象*/
Customer customer1 = (Customer)session.get(Customer.class, "402881e534fa5a440134fa5a45340002");
System.out.println("customer.getUsername is"+customer1.getUsername());
/*事务提交*/
tx.commit();
System.out.println("-------------------------------------");
/*开启一个新事务*/
tx = session.beginTransaction();
/*从数据库中获取id="402881e534fa5a440134fa5a45340002"的Customer对象*/
Customer customer2 = (Customer)session.get(Customer.class, "402881e534fa5a440134fa5a45340002");
System.out.println("customer2.getUsername is"+customer2.getUsername());
/*事务提交*/
tx.commit();
System.out.println("-------------------------------------");
/*比较两个get()方法获取的对象是否是同一个对象*/
System.out.println("customer1 == customer2 result is "+(customer1==customer2));
}
catch (Exception e)
{
if(tx!=null)
{
tx.rollback();
}
}
finally
{
session.close();
}
}
}
程序控制台输出结果：
Hibernate:
select
customer0_.id as id0_0_,
customer0_.username as username0_0_,
customer0_.balance as balance0_0_
from
customer customer0_
where
customer0_.id=?
customer.getUsername islisi
-------------------------------------
customer2.getUsername islisi
-------------------------------------
customer1 == customer2 result is true
其原理是：在同一个Session里面，第一次调用get()方法， Hibernate先检索缓存中是否有该查找对象，发现没有，Hibernate发送SELECT语句到数据库中取出相应的对象，然后将该对象放入缓存中，以便下次使用，第二次调用get()方法，Hibernate先检索缓存中是否有该查找对象，发现正好有该查找对象，就从缓存中取出来，不再去数据库中检索，没有再次发送select语句。
数据从缓存中清除：
1. evit()将指定的持久化对象从缓存中清除，释放对象所占用的内存资源，指定对象从持久化状态变为脱管状态，从而成为游离对象。
2. clear()将缓存中的所有持久化对象清除，释放其占用的内存资源。
其他缓存操作：
1. contains()判断指定的对象是否存在于缓存中。
2. flush()刷新缓存区的内容，使之与数据库数据保持同步。
二级缓存：
@Test
public void testCache2() {
Session session1 = sf.openSession();//获得Session1
session1.beginTransaction();
Category c = (Category)session1.load(Category.class, 1);
System.out.println(c.getName());
session1.getTransaction().commit();
session1.close();
Session session2 = sf.openSession();//获得Session2
session2.beginTransaction();
Category c2 = (Category)session2.load(Category.class, 1);
System.out.println(c2.getName());
session2.getTransaction().commit();
session2.close();
}
当我们重启一个Session，第二次调用load或者get方法检索同一个对象的时候会重新查找数据库，会发select语句信息。
原因：一个session不能取另一个session中的缓存。
性能上的问题：假如是多线程同时去取Category这个对象，load一个对象，这个对像本来可以放到内存中的，可是由于是多线程，是分布在不同的session当中的，所以每次都要从数据库中取，这样会带来查询性能较低的问题。
解决方案：使用二级缓存。
1.什么是二级缓存？
SessionFactory级别的缓存，可以跨越Session存在，可以被多个Session所共享。
2.适合放到二级缓存中：
（1）经常被访问
（2）改动不大
（3）数量有限
（4）不是很重要的数据，允许出现偶尔并发的数据。
这样的数据非常适合放到二级缓存中的。
用户的权限：用户的数量不大，权限不多，不会经常被改动，经常被访问。
例如组织机构。
思考：什么样的类，里面的对象才适合放到二级缓存中？
改动频繁，类里面对象特别多，BBS好多帖子，这些帖子20000多条，哪些放到缓存中，不能确定。除非你确定有一些经常被访问的，数据量并不大，改动非常少，这样的数据非常适合放到二级缓存中的。
3.二级缓存实现原理：
Hibernate如何将数据库中的数据放入到二级缓存中？注意，你可以把缓存看做是一个Map对象，它的Key用于存储对象OID，Value用于存储POJO。首先，当我们使用Hibernate从数据库中查询出数据，获取检索的数据后，Hibernate将检索出来的对象的OID放入缓存中key 中，然后将具体的POJO放入value中，等待下一次再次向数据查询数据时，Hibernate根据你提供的OID先检索一级缓存，若有且配置了二级缓存，则检索二级缓存，如果还没有则才向数据库发送SQL语句，然后将查询出来的对象放入缓存中。
4使用二级缓存
（1）打开二级缓存：
为Hibernate配置二级缓存：
在主配置文件中hibernate.cfg.xml ：
<!-- 使用二级缓存 -->
<property name="cache.use_second_level_cache">true</property>
<!--设置缓存的类型，设置缓存的提供商-->
<property
name="cache.provider_class">org.hibernate.cache.EhCacheProvider
</property>
（2）配置ehcache.xml
<ehcache>
<!--
缓存到硬盘的路径
-->
<diskStore path="d:/ehcache"/>
<defaultCache
maxElementsInMemory="200"<!-- 最多缓存多少个对象 -->
eternal="false"<!-- 内存中的对象是否永远不变 -->
timeToIdleSeconds="50"<!--发呆了多长时间，没有人访问它，这么长时间清除 -->
timeToLiveSeconds="60"<!--活了多长时间，活了1200秒后就可以拿走，一般Live要比Idle设置的时间长 -->
overflowToDisk="true"<!--内存中溢出就放到硬盘上 -->
/>
<!--
指定缓存的对象，缓存哪一个实体类
下面出现的的属性覆盖上面出现的，没出现的继承上面的。
-->
<cache name="com.suxiaolei.hibernate.pojos.Order"
maxElementsInMemory="200"
eternal="true"
timeToIdleSeconds="0"
timeToLiveSeconds="0"
overflowToDisk="false"
/>
</ehcache>
（3）使用二级缓存需要在实体类中加入注解：
需要ehcache-1.2.jar包:
还需要 commons_loging1.1.1.jar包
@Cache(usage = CacheConcurrencyStrategy.READ_WRITE)
Load默认使用二级缓存，就是当查一个对象的时候，它先会去二级缓存里面去找，如果找到了就不去数据库中查了。
Iterator默认的也会使用二级缓存，有的话就不去数据库里面查了，不发送select语句了。
List默认的往二级缓存中加数据，假如有一个query，把数据拿出来之后会放到二级缓存，但是执行查询的时候不会到二级缓存中查，会在数据库中查。原因每个query中查询条件不一样。
（4）也可以在需要被缓存的对象中hbm文件中的<class>标签下添加一个<cache>子标签:
<hibernate-mapping>
<class name="com.suxiaolei.hibernate.pojos.Order" table="orders">
<cache usage="read-only"/>
<id name="id" type="string">
<column name="id"></column>
<generator class="uuid"></generator>
</id>
<property name="orderNumber" column="orderNumber" type="string"></property>
<property name="cost" column="cost" type="integer"></property>
<many-to-one name="customer" class="com.suxiaolei.hibernate.pojos.Customer"
column="customer_id" cascade="save-update">
</many-to-one>
</class>
</hibernate-mapping>
存在一对多的关系，想要在在获取一方的时候将关联的多方缓存起来，需要再集合属性下添加<cache>子标签，这里需要将关联的对象的 hbm文件中必须在存在<class>标签下也添加<cache>标签，不然Hibernate只会缓存OID。
<hibernate-mapping>
<class name="com.suxiaolei.hibernate.pojos.Customer" table="customer">
<!-- 主键设置 -->
<id name="id" type="string">
<column name="id"></column>
<generator class="uuid"></generator>
</id>
<!-- 属性设置 -->
<property name="username" column="username" type="string"></property>
<property name="balance" column="balance" type="integer"></property>
<set name="orders" inverse="true" cascade="all" lazy="false" fetch="join">
<cache usage="read-only"/>
<key column="customer_id" ></key>
<one-to-many class="com.suxiaolei.hibernate.pojos.Order"/>
</set>
</class>
</hibernate-mapping>
二级缓存和查询缓存都相当于一个map。
二级缓存缓存的key为id，value为实体对象。一般load（），iterate（）使用到二级缓存，list()需要结合查询缓存使用。iterate（）和list（）区别如下：
iterate()不需要开启查询缓存，它首先发出一个sql如”select s.id from Student s”去数据库把id属性列表取出来，然后再根据id列表一个一个load（），如果缓存有从缓存取，如果缓存没有就从数据库取：select s.id,s.name,s.classid from Student s where s.id=?,取出后再存入二级缓存。Iterate总会发出取id列表的语句。
List（）需要开启查询缓存，它首先发出一个sql如”select s.id,s.name,s.classid from Student s…”去数据库取出所有相关实体，并将这些实体存入二级缓存，将此sql语句及一些相关信息作为key，id列表作为值，第二次查询这条语句时就会去根据sql语句及相关信息去key里找，如果有就会把id列表取出一个一个load（），接下来就和iterate一样了。List一般只有第一次发发出取实体列表的语句，以后的id列表就会去查询缓存取id列表，不会再发出sql语句。
前提：执行同一hql语句，如：select s from Student s
1.关闭查询缓存，开启二级缓存时:
第二次查询属性时iterate只会发出获取id列表的sql，list会发出和第一次一样的请求实体的sql。
2.开启查询缓存，开启二级缓存
第二次查询属性时iterate只会发出获取id列表的sql，list不发sql。
以上说明iterate只和二级缓存有关，list和二级缓存和查询缓存都有关。
list 不会使用二级缓存，但是会填充二级缓存，还会使用查询缓存
一、hibernate的二级缓存
如果开启了二级缓存，hibernate在执行任何一次查询的之后，都会把得到的结果集放到缓存中，缓存结构可以看作是一个hash table，key是数据库记录的id，value是id对应的pojo对象。当用户根据id查询对象的时候（load、iterator方法），会首先在缓存中查找，如果没有找到再发起数据库查询。但是如果使用hql发起查询（find, query方法）则不会利用二级缓存，而是直接从数据库获得数据，但是它会把得到的数据放到二级缓存备用。也就是说，基于hql的查询，对二级缓存是只写不读的。
针对二级缓存的工作原理，采用iterator取代list来提高二级缓存命中率的想法是不可行的。Iterator的工作方式是根据检索条件从数据库中选取所有目标数据的id，然后用这些id一个一个的到二级缓存里面做检索，如果找到就直接加载，找不到就向数据库做查询。因此假如iterator检索100条数据的话，最好情况是100%全部命中，最坏情况是0%命中，执行101条sql把所有数据选出来。而list虽然不利用缓存，但是它只会发起1条sql取得所有数据。在合理利用分页查询的情况下，list整体效率高于iterator。
二级缓存的失效机制由hibernate控制，当某条数据被修改之后，hibernate会根据它的id去做缓存失效操作。基于此机制，如果数据表不是被hibernate独占（比如同时使用JDBC或者ado等），那么二级缓存无法得到有效控制。
由于hibernate的缓存接口很灵活，cache provider可以方便的切换，因此支持cluster环境不是大问题，通过使用swarmcache、jboss cache等支持分布式的缓存方案，可以实现。但是问题在于:
1、 分布式缓存本身成本偏高（比如使用同步复制模式的jboss cache）
2、 分布式环境通常对事务控制有较高要求，而目前的开源缓存方案对事务缓存（transaction cache）支持得不够好。当jta事务发生会滚，缓存的最后更新结果很难预料。这一点会带来很大的部署成本，甚至得不偿失。
结论：不应把hibernate二级缓存作为优化的主要手段，一般情况下建议不要使用。
原因如下：
1、 由于hibernate批量操作的性能不如sql，而且为了兼容1.0的dao类，所以项目中有保留了sql操作。哪些数据表是单纯被hibernate独占无法统计，而且随着将来业务的发展可能会有很大变数。因此不宜采用二级缓存。
2、 针对系统业务来说，基于id检索的二级缓存命中率极为有限，hql被大量采用，二级缓存对性能的提升很有限。
3、 hibernate 3.0在做批量修改、批量更新的时候，是不会同步更新二级缓存的，该问题在hibernate 3.2中是否仍然存在尚不确定。
二、hibernate的查询缓存
查询缓存的实现机制与二级缓存基本一致，最大的差异在于放入缓存中的key是查询的语句，value是查询之后得到的结果集的id列表。表面看来这样的方案似乎能解决hql利用缓存的问题，但是需要注意的是，构成key的是：hql生成的sql、sql的参数、排序、分页信息等。也就是说如果你的hql有小小的差异，比如第一条hql取1-50条数据，第二条hql取20-60条数据，那么hibernate会认为这是两个完全不同的key，无法重复利用缓存。因此利用率也不高。
另外一个需要注意的问题是，查询缓存和二级缓存是有关联关系的，他们不是完全独立的两套东西。假如一个查询条件hql_1，第一次被执行的时候，它会从数据库取得数据，然后把查询条件作为key，把返回数据的所有id列表作为value（请注意仅仅是id）放到查询缓存中，同时整个结果集放到class缓存（也就是二级缓存），key是id，value是pojo对象。当你再次执行hql_1，它会从缓存中得到id列表，然后根据这些列表一个一个的到class缓存里面去找pojo对象，如果找不到就向数据库发起查询。也就是说，如果二级缓存配置了超时时间（或者发呆时间），就有可能出现查询缓存命中了，获得了id列表，但是class里面相应的pojo已经因为超时(或发呆)被失效，hibernate就会根据id清单，一个一个的去向数据库查询，有多少个id，就执行多少个sql。该情况将导致性能下降严重。
查询缓存的失效机制也由hibernate控制，数据进入缓存时会有一个timestamp，它和数据表的timestamp对应。当hibernate环境内发生save、update等操作时，会更新被操作数据表的timestamp。用户在获取缓存的时候，一旦命中就会检查它的timestamp是否和数据表的timestamp匹配，如果不，缓存会被失效。因此查询缓存的失效控制是以数据表为粒度的，只要数据表中任何一条记录发生一点修改，整个表相关的所有查询缓存就都无效了。因此查询缓存的命中率可能会很低。
结论：不应把hibernate二级缓存作为优化的主要手段，一般情况下建议不要使用。
原因如下：
1、 项目上层业务中检索条件都比较复杂，尤其是涉及多表操作的地方。很少出现重复执行一个排序、分页、参数一致的查询，因此命中率很难提高。
2、 查询缓存必须配合二级缓存一起使用，否则极易出现1+N的情况，否则性能不升反降
3、 使用查询缓存必须在执行查询之前显示调用Query.setCacheable(true)才能激活缓存，这势必会对已有的hibernate封装类带来问题。
总结
详细分析hibernate的二级缓存和查询缓存之后，在底层使用通用缓存方案的想法基本上是不可取的。比较好的做法是在高层次中（业务逻辑层面），针对具体的业务逻辑状况手动使用数据缓存，不仅可以完全控制缓存的生命周期，还可以针对业务具体调整缓存方案提交命中率。Cluster中的缓存同步可以完全交给缓存本身的同步机制来完成。比如开源缓存swarmcache采用invalidate的机制，可以根据用户指定的策略，在需要的时候向网络中的其他swarmcache节点发送失效消息，建议采用。
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
