Thinking

1、查询缓存

  首先需要配置hibernate.cache.use_query_cache=true

如果用ehcache，配置ehcache.xml，注意hibernate3.0以后不是net.sf的包名了

  然后

query.setCacheable(true);//激活查询缓存

query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion，可选

第二行指定要使用的cacheRegion是myCacheRegion，即你可以给每个查询缓存做一个单独的配置，

使用setCacheRegion来做这个指定，需要在ehcache.xml里面配置它：

1 < cache  name ="myCacheRegion"  maxElementsInMemory ="10"  eternal ="false"
2
3 timeToIdleSeconds ="3600"  timeToLiveSeconds ="7200"  overflowToDisk ="true"   />
4
5

如果省略第二行，不设置cacheRegion的话，那么会使用上面提到的标准查询缓存的配置，也就是

net.sf.hibernate.cache.StandardQueryCache

  问题：当hibernate更新数据库的时候，它怎么知道更新哪些查询缓存呢？

    hibernate在一个地方维护每个表的最后更新时间，其实也就是放在上面

net.sf.hibernate.cache.UpdateTimestampsCache所指定的缓存配置里面。

当通过hibernate更新的时候，hibernate会知道这次更新影响了哪些表。然后它更新这些表的最后更新时间。每个缓存都有一个生成时间和这个缓存所查询的表，当hibernate查询一个缓存是否存在的时候，如果缓存存在，它还要取出缓存的生成时间和这个缓存所查询的表，然后去查找这些表的最后更新时间，如果有一个表在生成时间后更新过了，那么这个缓存是无效的。可以看出，只要更新过一个表，那么凡是涉及到这个表的查询缓存就失效了，因此查询缓存的命中率可能会比较低。

  注意：

    放入缓存中的key是查询的语句，value是查询之后得到的结果集的id列表。

表面看来这样的方案似乎能解决hql利用缓存的问题，但是需要注意的是，构成key的是：

hql生成的sql、sql的参数、排序、分页信息等。也就是说如果你的hql有小小的差异，

比如第一条hql取1-50条数据，第二条hql取20-60条数据，那么hibernate会认为这是两个

完全不同的key，无法重复利用缓存。因此利用率也不高。

   查询缓存必须配合二级缓存一起使用，否则极易出现1+N的情况

   如果不设置"查询缓存"，那么hibernate只会缓存使用load()方法获得的单个持久化对象，

如果想缓存使用findall()、list()、Iterator()、createCriteria()、createQuery()等方法

获得的数据结果集的话，就需要设置hibernate.cache.use_query_cache true才行，如果需要"查询缓存"，需要在使用Query或Criteria()时设置其setCacheable(true);属性。 
2、Collection缓存

  需要在hbm的collection里面设置

< cache  usage ="read-write" />

假如class是Cat，collection叫children，那么ehcache里面配置

1 < cache  name ="com.xxx.pojo.Cat.children"
2
3 maxElementsInMemory ="20"  eternal ="false"  timeToIdleSeconds ="3600"
4
5 timeToLiveSeconds ="7200"
6
7 overflowToDisk ="true"   />
8

Collection的缓存和前面查询缓存的list一样，也是只保持一串id，但它不会因为这个表更新过就

失效，一个collection缓存仅在这个collection里面的元素有增删时才失效。

这样有一个问题，如果你的collection是根据某个字段排序的，当其中一个元素更新了该字段时，

导致顺序改变时，collection缓存里面的顺序没有做更新 
3、Class缓存（也称二级缓存）

   可由Hibernate提供的二级缓存实现，它存在于SessionFactory级别,

缓存结构可以看作是一个hash table，key是数据库记录的id，value是id对应的pojo对象。

当用户根据id查询对象的时候（load、iterator方法），会首先在缓存中查找，

如果没有找到再发起数据库查询。但是如果使用hql发起查询（find, query方法）

则不会利用二级缓存，而是直接从数据库获得数据，但是它会把得到的数据放到二级缓存备用。也就是说，基于hql的查询，对二级缓存是只写不读的。 
在hibernate.cfg.xml配置：

< property  name ="hibernate.cache.provider_class" >

       org.hibernate.cache.EhCacheProvider

</ property >

hibernate3支持

Hashtable Cache（org.hibernate.cache.HashtableCacheProvider）

EhCache(org.hibernate.cache.EhCacheProvider)

OSCache(org.hibernate.cache.OSCacheProvider)

SwarmCache(org.hibernate.cache.SwarmCacheProvider)

JBossCache(org.hibernate.cache.TreeCacheProvider)

在相应的POJO配置文件中增加:

<!--

指定缓存同步策略:

read-write                           读写型

nonstrict-read-write             非严格读写型

read-only                            只读型

transactional                        事务型

-->

<cache usage="read-write"/> 

     对于一条记录，也就是一个PO来说，是根据ID来找的，缓存的key就是ID，value是POJO。无论

list，load还是iterate，只要读出一个对象，都会填充缓存。但是list不会使用缓存，而iterate

会先取数据库select id出来，然后一个id一个id的load，如果在缓存里面有，就从缓存取，没有

的话就去数据库load。

   当某个ID通过hibernate修改时，hibernate会知道，于是移除缓存。

这样大家可能会想，同样的查询条件，第一次先list，第二次再iterate，就可以使用到缓存了。

实际上这是很难的，因为你无法判断什么时候是第一次，而且每次查询的条件通常是不一样的，假

如数据库里面有100条记录，id从1到100，第一次list的时候出了前50个id，第二次iterate的时候

却查询到30至70号id，那么30-50是从缓存里面取的，51到70是从数据库取的，共发送1+20条sql。

所以我一直认为iterate没有什么用，总是会有1+N的问题。 如果想要对list或者iterate查询的结

果缓存，就要用到查询缓存了。 
  注意:

   对于one-to-many的关联关系，如果对one应用缓存，则应同时对many应用。

   二级缓存的失效机制由hibernate控制，当某条数据被修改之后，hibernate会根据它的id去做

缓存失效操作。基于此机制，如果数据表不是被hibernate独占，那么二级缓存无法得到有效控制

。

   hibernate 3.0在做批量修改、批量更新的时候，是不会同步更新二级缓存的

   查询缓存和二级缓存是有关联关系的，他们不是完全独立的两套东西。假如一个查询条件hql_1

，第一次被执行的时候，它会从数据库取得数据，然后把查询条件作为key，把返回数据的所有id

列表作为value（请注意仅仅是id）放到查询缓存中，同时整个结果集放到二级缓存，key是id，

value是pojo对象。当你再次执行hql_1，它会从缓存中得到id列表，然后根据这些列表一个一个的

到二级缓存里面去找pojo对象，如果找不到就向数据库发起查询。也就是说，如果二级缓存配置了

超时时间，就有可能出现查询缓存命中了，获得了id列表，但是class里面相应的pojo已经因为超

时被失效，hibernate就会根据id清单，一个一个的去向数据库查询，有多少个id，就执行多少个

sql。该情况将导致性能下降严重。

   查询缓存的失效机制也由hibernate控制，数据进入缓存时会有一个timestamp，它和数据表的

timestamp对应。当hibernate环境内发生save、update等操作时，会更新被操作数据表的

timestamp。用户在获取缓存的时候，一旦命中就会检查它的timestamp是否和数据表的timestamp

匹配，如果不，缓存会被失效。因此查询缓存的失效控制是以数据表为粒度的，只要数据表中任何

一条记录发生一点修改，整个表相关的所有查询缓存就都无效了。因此查询缓存的命中率可能会很

低。 
4、对方法的缓存

  对于调用频率较高的查询类方法，我们希望缓存方法结果

在spring中可利用拦截器（Interceptor）实现，可能如下面的配置：

 1 < beans >
 2
 3      < bean  id ="cacheInterceptor"
 4
 5 class ="org.springframework.aop.interceptor.cache.OSCacheInterceptor" >
 6
 7         <! - 默认刷新时间（秒）- >
 8
 9         < property  name ="defaultRefreshPeriod" >
10
11             < value > 60 </ value >
12
13         </ property >
14
15         < property  name ="identifiers" >
16
17             < props >
18
19                < prop  key ="java.util.Map" > toString </ prop >
20
21             </ props >
22
23         </ property >
24
25      </ bean >
26
27      <! - 正则表达式匹配 - >
28
29      < bean  id ="searcherAdvisor"
30
31 class ="org.springframework.aop.support.RegexpMethodPointcutAdvisor" >
32
33         < property  name ="advice" >
34
35             < ref  local ="cacheInterceptor"   />
36
37         </ property >
38
39         < property  name ="patterns" >
40
41             < list >
42
43                < value > .get. </ value >
44
45             </ list >
46
47         </ property >
48
49      </ bean >
50
51      <! - 自动代理 - >
52
53      < bean  id ="proxyCreator1"
54
55 class ="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator" >
56
57         < property  name ="beanNames" >
58
59            <!--  需截获方法的bean列表  -->
60
61             < list >
62
63                < value > commonSelect </ value >
64
65             </ list >
66
67         </ property >
68
69         < property  name ="interceptorNames" >
70
71            <!--  截获器列表  -->
72
73             < list >
74
75                < value > searcherAdvisor </ value >
76
77             </ list >
78
79         </ property >
80
81      </ bean >
82
83 < beans >
84
85

 这里通过自动代理创建bean，并指定作用其上的interceptor列表，在commonSelect存在searchAdvisor，

而searchAdvisor对匹配*get*模式的方法调用将通过cacheInterceptor进行处理。