ehcache 是线程安全的吗？以及缓存使用上的问题

Question

ehcache FAQ中提到

Remember that a value in a cache element is globally accessible from multiple threads. [color=red][b]It is inherently not thread safe to modify the value[/b][/color] . It is safer to retrieve a value, delete the cache element and then reinsert the value.

The UpdatingCacheEntryFactory does work by modifying the contents of values in place in the cache. This is outside of the core of ehcache and is targeted at high performance CacheEntryFactories for SelfPopulatingCaches.

ehcache 是线程安全的吗？
如果一个频繁修改的表，会涉及到多线程，适合放入ehcache吗？(目前就是因为数据库IO压力过大，才想放入缓存)

ehcache查找时key:ID，那么如果我不是以ID为查询条件的话，是否就没有使用到缓存，
例如：我用电话号码来查询用户，发现缓存似乎没有用到，如何才能解决此问题？

Answer 1

关于缓存的话题，在坛子里已经有很多讨论，简单的来说，如果一个应用中80%的时间内都在访问20%的数据，那么，这时候就应该使用缓存了。这个和长尾理论正好相悖，其实也不是相悖，只是不同的理论使用的场景不同。在80/20原则生效的地方，我们都应该考虑是否可以使用缓存。但即使是这样，缓存也有不同的用法，举个例子，一个网站的首页估计是被访问的次数最多的，我们可以考虑给首页做一个页面缓存，而如果在某个页面上，比如说javaeye的java版区只有前几个页面是访问最频繁的，（假设javaeye是使用hibernate，当然这只是假设，我们都知道javaeye是使用ror开发的）那么我们就可以考虑给java版区的record做二级缓存了，因为二级缓存中是按照对象的id来保存的，所以应该来说这前面几页使用的对象会一直存在于缓存之中（如何使用hibernate的二级缓存坛子上也有介绍）。由此可见不同的页面的缓存策略有可能有天壤之别。

ehcache就是一个非常轻量级的缓存实现。

ehcache 是线程安全的吗？
我觉得，不是线程安全，因为ehcache 可作为进程范围的缓存，存放数据的物理介质可以是内存或硬盘。

如果一个频繁修改的表，会涉及到多线程，适合放入ehcache吗？
不适合，什么样的数据适合存放到第二级缓存中？ 1 很少被修改的数据 2 不是很重要的数据，允许出现偶尔并发的数据 3 不会被并发访问的数据 4 参考数据,指的是供应用参考的常量数据，它的实例数目有限，它的实例会被许多其他类的实例引用，实例极少或者从来不会被修改。

ehcache查找时key:ID，那么如果我不是以ID为查询条件的话，是否就没有使用到缓存。
这个问题是这样的一个流程，根据ID访问数据对象的时候，首先从Session一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照ID放入到缓存。