使用EhCache1.1与Hibernate所吃的亏

“偶们的系统越来越慢了！”，这是最近一直在我耳边萦绕的一句话，向公司里搞数据库的大牛咨询，发现是一些做汇总的语句在作怪，于是决定将这些数据做缓存。

办法想出来后，做起来也容易了。首先入我“法眼”的是ehcache，我们用hibernate，这个家伙是hibernate默认自带的(我们之前做的缓存是自己写的HashTable)。由于我们没有用spring，否则用EhCacheFactoryBean和EhCacheManagerFactoryBean就方便了，偶自己写的缓存接口也是基于这个的，但现在是奢望了，于是自己写cache的初始化。由于论坛的“代码”功能好像用不了，我简单说一下碰到的问题：

我所有的初始化代码都是老老实实按着ehcache官网上的例子写的，唯一的不同在于我们的ehcache是1.1版的，CacheManager的创建必须要用createCacheManager才可以，而不能用new CacheManager();由于我没有换jar包的权力，于是将就了一下。当我准备好一切并且去调试的时候，发现我总是无法找到自己设置的cache，但是初始化cache的xml时没有任何异常。最后通过debug ehcache1.1的src发现，其CacheManager是sington的，有人在我之前初始化过了ehcache，于是我的初始化动作根本没有做。问题很简单了，是hibernate干的，在初始化时，我们先初始化了hibernate，然后初始化自定义的ehcache缓存，导致了问题， 把初始化的顺序改变一下，问题就解决了。

此时方明白Spring中EhCacheManagerFactoryBean注释中的含义：Note: As of Spring 2.0, this FactoryBean will by default create an independent CacheManager instance, which requires EHCache 1.2 or higher. Set the "shared" flag to "true" to create a CacheManager instance that is shared at the VM level (which is also compatible with EHCache 1.1).

发此文以做提醒自己之用。

hibernate已经开了缓存，为什么还要自己建呢？

自己建的缓存不是为了Hibernate而建的,而是为了一些与Hibernate无关的对象做缓存.只是利用了Ehcache罢了.问题在于Ehcache1.1只能有一个CacheManager而且是singlton的,如果你之前用Hibernate的默认初始化,那么之后你再怎么指定ehcache的配置文件让它被初始化也无济于事了.

的确是这样，所以在这种情况下，一般会选择一个另外一个不同的缓存策略，比如OSCache。

在持久层实现缓存实际上没必要
  缓存这一层可以往前挪
  在view,action层实现好一些
  前端控制，这样通用性更好，而且更容易控制，更易实现
 

很多地方都有EHCache 1.2 和EHCache 1.1之间带来的问题.

持久层实现缓存为什么没必要?
hibernate在上面花的功夫可不少!

view等前端缓存是有必要
但我认为在代码中控制始终不当,(想想gc)
前端缓存的优秀方案其实也很多,如oscache标签直接缓存其页面,也可另开线程单独缓存

缓存是应用层的事，
  缓存内容，缓存时间，缓存策略，缓存刷新等都可以交给应用层去解决
  hibernate的缓存是一刀切，控制粒度是粗放型的
  缓存这个东西不能滥用，要用在关键的地方
  系统设计人员应该找出性能瓶颈，做出相应的缓存策略
   而不是不管37二十一，啥东西都缓存一把
  
   缓存不要滥用





  
  
  
  

hibernate的二级缓存其实还是很有用的，尤其对于一些字典表，配置表。这些表几乎不改动，却要经常查询。这种情况下比较好的一个方式就是在系统初始化的时候做一次全表的loadAll。此时hibernate会填充其二级缓存。在这之后，无论是关联到这些表的查询，或者load,iterate,都会从缓存中拿数据，效率会很高。

当然，我也承认缓存所在的层次越高，其作用越明显，这也就是OSCache比较受到青睐的原因。

  这个属于hibernate系统级的缓存，
   我们讨论的缓存肯定是针对应用级的