另外一个需要注意的问题是，查询缓存和二级缓存是有关联关系的，他们不是完全独立的两套东西。假如一个查询条件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匹配，如果不，缓存会被失效。因此查询缓存的失效控制是以数据表为粒度的，只要数据表中任何一条记录发生一点修改，整个表相关的所有查询缓存就都无效了。因此查询缓存的命中率可能会很低。
结论：XXXX不应把hibernate二级缓存作为优化的主要手段，一般情况下建议不要使用。
原因如下：
1、 XXXX的上层业务中检索条件都比较复杂，尤其是涉及多表操作的地方。很少出现重复执行一个排序、分页、参数一致的查询，因此命中率很难提高。
2、 查询缓存必须配合二级缓存一起使用，否则极易出现1+N的情况，否则性能不升反降
3、 使用查询缓存必须在执行查询之前显示调用Query.setCacheable（true）才能激活缓存，这势必会对已有的hibernate封装类带来问题。
总结
详细分析hibernate的二级缓存和查询缓存之后，针对XXXX项目的具体情况做出结论，在底层使用通用缓存方案的想法基本上是不可取的。比较好的做法是在高层次中（业务逻辑层面），针对具体的业务逻辑状况手动使用数据缓存，不仅可以完全控制缓存的生命周期，还可以针对业务具体调整缓存方案提交命中率。Cluster中的缓存同步可以完全交给缓存本身的同步机制来完成。比如开源缓存swarmcache采用invalidate的机制，可以根据用户指定的策略，在需要的时候向网络中的其他swarmcache节点发送失效消息，这一机制和XXXX1.0中已经采用的MappingCache的同步方案基本一致。建议采用。 |
