hibernateehcache缓存
① hibernate缓存的详细配置
很多人对二级缓存都不太了解，或者是有错误的认识，我一直想写一篇文章介绍一下hibernate的二级缓存的，今天终于忍不住了。
我的经验主要来自hibernate2.1版本，基本原理和3.0、3.1是一样的，请原谅我的顽固不化。
hibernate的session提供了一级缓存，每个session，对同一个id进行两次load，不会发送两条sql给数据库，但是session关闭的时候，一级缓存就失效了。
二级缓存是SessionFactory级别的全局缓存，它底下可以使用不同的缓存类库，比如ehcache、oscache等，需要设置hibernate.cache.provider_class，我们这里用ehcache，在2.1中就是
hibernate.cache.provider_class=net.sf.hibernate.cache.EhCacheProvider
如果使用查询缓存，加上
hibernate.cache.use_query_cache=true
缓存可以简单的看成一个Map，通过key在缓存里面找value。
Class的缓存
对于一条记录，也就是一个PO来说，是根据ID来找的，缓存的key就是ID，value是POJO。无论list，load还是iterate，只要读出一个对象，都会填充缓存。但是list不会使用缓存，而iterate会先取数据库select id出来，然后一个id一个id的load，如果在缓存里面有，就从缓存取，没有的话就去数据库load。假设是读写缓存，需要设置：
<cache usage="read-write"/>
如果你使用的二级缓存实现是ehcache的话，需要配置ehcache.xml
<cache name="com.xxx.pojo.Foo" maxElementsInMemory="500" eternal="false" timeToLiveSeconds="7200" timeToIdleSeconds="3600" overflowToDisk="true" />
其中eternal表示缓存是不是永远不超时，timeToLiveSeconds是缓存中每个元素（这里也就是一个POJO）的超时时间，如果eternal="false"，超过指定的时间，这个元素就被移走了。timeToIdleSeconds是发呆时间，是可选的。当往缓存里面put的元素超过500个时，如果overflowToDisk="true"，就会把缓存中的部分数据保存在硬盘上的临时文件里面。
每个需要缓存的class都要这样配置。如果你没有配置，hibernate会在启动的时候警告你，然后使用defaultCache的配置，这样多个class会共享一个配置。
当某个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只select id比较好，但是大型查询总是要分页查的，谁也不会真的把整个结果集装进来，假如一页20条的话，iterate共需要执行21条语句，list虽然选择若干字段，比iterate第一条select id语句慢一些，但只有一条语句，不装入整个结果集hibernate还会根据数据库方言做优化，比如使用mysql的limit，整体看来应该还是list快。）
如果想要对list或者iterate查询的结果缓存，就要用到查询缓存了
查询缓存
首先需要配置hibernate.cache.use_query_cache=true
如果用ehcache，配置ehcache.xml，注意hibernate3.0以后不是net.sf的包名了
<cache name="net.sf.hibernate.cache.StandardQueryCache"
maxElementsInMemory="50" eternal="false" timeToIdleSeconds="3600"
timeToLiveSeconds="7200" overflowToDisk="true"/>
<cache name="net.sf.hibernate.cache.UpdateTimestampsCache"
maxElementsInMemory="5000" eternal="true" overflowToDisk="true"/>
然后
query.setCacheable(true);//激活查询缓存
query.setCacheRegion("myCacheRegion");//指定要使用的cacheRegion，可选
第二行指定要使用的cacheRegion是myCacheRegion，即你可以给每个查询缓存做一个单独的配置，使用setCacheRegion来做这个指定，需要在ehcache.xml里面配置它：
<cache name="myCacheRegion" maxElementsInMemory="10" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200" overflowToDisk="true" />
如果省略第二行，不设置cacheRegion的话，那么会使用上面提到的标准查询缓存的配置，也就是net.sf.hibernate.cache.StandardQueryCache
对于查询缓存来说，缓存的key是根据hql生成的sql，再加上参数，分页等信息（可以通过日志输出看到，不过它的输出不是很可读，最好改一下它的代码）。
比如hql：
from Cat c where c.name like ?
生成大致如下的sql：
select * from cat c where c.name like ?
参数是"tiger%"，那么查询缓存的key*大约*是这样的字符串（我是凭记忆写的，并不精确，不过看了也该明白了）：
select * from cat c where c.name like ? , parameter:tiger%
这样，保证了同样的查询、同样的参数等条件下具有一样的key。
现在说说缓存的value，如果是list方式的话，value在这里并不是整个结果集，而是查询出来的这一串ID。也就是说，不管是list方法还是iterate方法，第一次查询的时候，它们的查询方式很它们平时的方式是一样的，list执行一条sql，iterate执行1+N条，多出来的行为是它们填充了缓存。但是到同样条件第二次查询的时候，就都和iterate的行为一样了，根据缓存的key去缓存里面查到了value，value是一串id，然后在到class的缓存里面去一个一个的load出来。这样做是为了节约内存。
可以看出来，查询缓存需要打开相关类的class缓存。list和iterate方法第一次执行的时候，都是既填充查询缓存又填充class缓存的。
这里还有一个很容易被忽视的重要问题，即打开查询缓存以后，即使是list方法也可能遇到1+N的问题！相同条件第一次list的时候，因为查询缓存中找不到，不管class缓存是否存在数据，总是发送一条sql语句到数据库获取全部数据，然后填充查询缓存和class缓存。但是第二次执行的时候，问题就来了，如果你的class缓存的超时时间比较短，现在class缓存都超时了，但是查询缓存还在，那么list方法在获取id串以后，将会一个一个去数据库load！因此，class缓存的超时时间一定不能短于查询缓存设置的超时时间！如果还设置了发呆时间的话，保证class缓存的发呆时间也大于查询的缓存的生存时间。这里还有其他情况，比如class缓存被程序强制evict了，这种情况就请自己注意了。
另外，如果hql查询包含select字句，那么查询缓存里面的value就是整个结果集了。
当hibernate更新数据库的时候，它怎么知道更新哪些查询缓存呢？
hibernate在一个地方维护每个表的最后更新时间，其实也就是放在上面net.sf.hibernate.cache.UpdateTimestampsCache所指定的缓存配置里面。
当通过hibernate更新的时候，hibernate会知道这次更新影响了哪些表。然后它更新这些表的最后更新时间。每个缓存都有一个生成时间和这个缓存所查询的表，当hibernate查询一个缓存是否存在的时候，如果缓存存在，它还要取出缓存的生成时间和这个缓存所查询的表，然后去查找这些表的最后更新时间，如果有一个表在生成时间后更新过了，那么这个缓存是无效的。
可以看出，只要更新过一个表，那么凡是涉及到这个表的查询缓存就失效了，因此查询缓存的命中率可能会比较低。
Collection缓存
需要在hbm的collection里面设置
<cache usage="read-write"/>
假如class是Cat，collection叫children，那么ehcache里面配置
<cache name="com.xxx.pojo.Cat.children"
maxElementsInMemory="20" eternal="false" timeToIdleSeconds="3600" timeToLiveSeconds="7200"
overflowToDisk="true" />
Collection的缓存和前面查询缓存的list一样，也是只保持一串id，但它不会因为这个表更新过就失效，一个collection缓存仅在这个collection里面的元素有增删时才失效。
这样有一个问题，如果你的collection是根据某个字段排序的，当其中一个元素更新了该字段时，导致顺序改变时，collection缓存里面的顺序没有做更新。
缓存策略
只读缓存（read-only）：没有什么好说的
读/写缓存（read-write）:程序可能要的更新数据
不严格的读/写缓存（nonstrict-read-write）：需要更新数据，但是两个事务更新同一条记录的可能性很小，性能比读写缓存好
事务缓存（transactional）：缓存支持事务，发生异常的时候，缓存也能够回滚，只支持jta环境，这个我没有怎么研究过
读写缓存和不严格读写缓存在实现上的区别在于，读写缓存更新缓存的时候会把缓存里面的数据换成一个锁，其他事务如果去取相应的缓存数据，发现被锁住了，然后就直接取数据库查询。
在hibernate2.1的ehcache实现中，如果锁住部分缓存的事务发生了异常，那么缓存会一直被锁住，直到60秒后超时。
不严格读写缓存不锁定缓存中的数据。
使用二级缓存的前置条件
你的hibernate程序对数据库有独占的写访问权，其他的进程更新了数据库，hibernate是不可能知道的。你操作数据库必需直接通过hibernate，如果你调用存储过程，或者自己使用jdbc更新数据库，hibernate也是不知道的。hibernate3.0的大批量更新和删除是不更新二级缓存的，但是据说3.1已经解决了这个问题。
这个限制相当的棘手，有时候hibernate做批量更新、删除很慢，但是你却不能自己写jdbc来优化，很郁闷吧。
SessionFactory也提供了移除缓存的方法，你一定要自己写一些JDBC的话，可以调用这些方法移除缓存，这些方法是：
void evict(Class persistentClass)
Evict all entries from the second-level cache.
void evict(Class persistentClass, Serializable id)
Evict an entry from the second-level cache.
void evictCollection(String roleName)
Evict all entries from the second-level cache.
void evictCollection(String roleName, Serializable id)
Evict an entry from the second-level cache.
void evictQueries()
Evict any query result sets cached in the default query cache region.
void evictQueries(String cacheRegion)
Evict any query result sets cached in the named query cache region.
不过我不建议这样做，因为这样很难维护。比如你现在用JDBC批量更新了某个表，有3个查询缓存会用到这个表，用evictQueries(String cacheRegion)移除了3个查询缓存，然后用evict(Class persistentClass)移除了class缓存，看上去好像完整了。不过哪天你添加了一个相关查询缓存，可能会忘记更新这里的移除代码。如果你的jdbc代码到处都是，在你添加一个查询缓存的时候，还知道其他什么地方也要做相应的改动吗？
----------------------------------------------------
总结：
不要想当然的以为缓存一定能提高性能，仅仅在你能够驾驭它并且条件合适的情况下才是这样的。hibernate的二级缓存限制还是比较多的，不方便用jdbc可能会大大的降低更新性能。在不了解原理的情况下乱用，可能会有1+N的问题。不当的使用还可能导致读出脏数据。
如果受不了hibernate的诸多限制，那么还是自己在应用程序的层面上做缓存吧。
在越高的层面上做缓存，效果就会越好。就好像尽管磁盘有缓存，数据库还是要实现自己的缓存，尽管数据库有缓存，咱们的应用程序还是要做缓存。因为底层的缓存它并不知道高层要用这些数据干什么，只能做的比较通用，而高层可以有针对性的实现缓存，所以在更高的级别上做缓存，效果也要好些吧。
② 什么是hibernate中的二级缓存
第一级别的缓存是Session级别的缓存，是属于事务范围的缓存，由Hibernate管理，一般无需进行干预。第二级别的缓存是SessionFactory级别的缓存，是属于进程范围的缓存。
二级缓存也分为了两种
内置缓存：Hibernate自带的，不可卸载，通常在Hibernate的初始化阶段，Hibernate会把映射元数据和预定义的SQL语句放置到SessionFactory的缓存中。该内置缓存是只读的。
外置缓存：通常说的二级缓存也就是外置缓存，在默认情况下SessionFactory不会启用这个缓存插件，外置缓存中的数据是数据库数据的复制，外置缓存的物理介质可以是内存或者硬盘。
hibernate二级缓存的结构
2.并发访问策略
transactional
（事务型）
仅在受管理的环境中适用
提供Repeatable Read事务隔离级别
适用经常被读，很少修改的数据
可以防止脏读和不可重复读的并发问题
缓存支持事务，发生异常的时候，缓存也能够回滚
read-write
（读写型）
提供Read Committed事务隔离级别
在非集群的环境中适用
适用经常被读，很少修改的数据
可以防止脏读
更新缓存的时候会锁定缓存中的数据
nonstrict-read-write
（非严格读写型）
适用极少被修改，偶尔允许脏读的数据（两个事务同时修改数据的情况很少见）
不保证缓存和数据库中数据的一致性
为缓存数据设置很短的过期时间，从而尽量避免脏读
不锁定缓存中的数据
read-only
（只读型）
适用从来不会被修改的数据（如参考数据）
在此模式下，如果对数据进行更新操作，会有异常
事务隔离级别低，并发性能高
在集群环境中也能完美运作
分析：通过上述表格分析如下
适合放入二级缓存中数据
很少被修改
不是很重要的数据，允许出现偶尔的并发问题
不适合放入二级缓存中的数据
经常被修改
财务数据，绝对不允许出现并发问题
与其他应用数据共享的数据
③ hibernate二级缓存什么时候用
Hibernate缓存何时使用和如何使用？
Hibernate缓存分为二级，第一级存放于session中称为一级缓存，默认带有且不能卸载。第二级是由sessionFactory控制的进程级缓存。是全局共享的缓存，凡是会调用二级缓存的查询方法 都会从中受益。
1. 关于hibernate缓存的问题：
1.1. 基本的缓存原理
Hibernate缓存分为二级，
第一级存放于session中称为一级缓存，默认带有且不能卸载。
第二级是由sessionFactory控制的进程级缓存。是全局共享的缓存，凡是会调用二级缓存的查询方法 都会从中受益。只有经正确的配置后二级缓存才会发挥作用。同时在进行条件查询时必须使用相应的方法才能从缓存中获取数据。比如 Query.iterate()方法、load、get方法等。必须注意的是session.find方法永远是从数据库中获取数据，不会从二级缓存中获 取数据，即便其中有其所需要的数据也是如此。
查询时使用缓存的实现过程为：首先查询一级缓存中是否具有需要的数据，如果没有，查询二级缓存，如果二级缓存中也没有，此时再执行查询数据库的工作。要注意的是：此3种方式的查询速度是依次降低的。
1.2. 存在的问题
1.2.1. 一级缓存的问题以及使用二级缓存的原因
因为Session的生命期往往很短，存在于Session内部的第一级最快缓存的生命期当然也很短，所以第一级缓存的命中率是很低的。其对系统性 能的改善也是很有限的。当然，这个Session内部缓存的主要作用是保持Session内部数据状态同步。并非是hibernate为了大幅提高系统性 能所提供的。
为了提高使用hibernate的性能，除了常规的一些需要注意的方法比如：
使用延迟加载、迫切外连接、查询过滤等以外，还需要配置hibernate的二级缓存。其对系统整体性能的改善往往具有立竿见影的效果！
（经过自己以前作项目的经验，一般会有3~4倍的性能提高）
1.2.2. N+1次查询的问题
1.2.2.1 什么时候会遇到1+N的问题？
前提：Hibernate默认表与表的关联方法是fetch="select"，不是fetch="join",这都是为了懒加载而准备的。
1）一对多(<set><list>) ，在1的这方，通过1条sql查找得到了1个对象，由于关联的存在 ，那么又需要将这个对象关联的集合取出，所以合集数量是n还要发出n条sql，于是本来的1条sql查询变成了1 +n条 。
2）多对一<many-to-one> ，在多的这方，通过1条sql查询得到了n个对象，由于关联的存在,也会将这n个对象对应的1 方的对象取出， 于是本来的1条sql查询变成了1 +n条 。
3）iterator 查询时,一定先去缓存中找（1条sql查集合,只查出ID），在没命中时，会再按ID到库中逐一查找， 产生1+n条SQL
1.2.2.2 怎么解决1+N 问题？
1 ）lazy=true， hibernate3开始已经默认是lazy=true了；lazy=true时不会立刻查询关联对象，只有当需要关联对象（访问其属性，非id字段）时才会发生查询动作。
2）使用二级缓存， 二级缓存的应用将不怕1+N 问题，因为即使第一次查询很慢（未命中），以后查询直接缓存命中也是很快的。刚好又利用了1+N 。
3) 当然你也可以设定fetch="join"，一次关联表全查出来，但失去了懒加载的特性。
执行条件查询时，iterate（）方法具有着名的 “n+1”次查询的问题，也就是说在第一次查询时iterate方法会执行满足条件的查询结果数再加一次（n+1）的查询。但是此问题只存在于第一次查询 时，在后面执行相同查询时性能会得到极大的改善。此方法适合于查询数据量较大的业务数据。
但是注意：当数据量特别大时（比如流水线数据等）需要针对此持久化对象配置其具体的缓存策略，比如设置其存在于缓存中的最大记录数、缓存存在的时间等参数，以避免系统将大量的数据同时装载入内存中引起内存资源的迅速耗尽，反而降低系统的性能！！！
1.3. 使用hibernate二级缓存的其他注意事项：
1.3.1. 关于数据的有效性
另外，hibernate会自行维护二级缓存中的数据，以保证缓存中的数据和数据库中的真实数据的一致性！无论何时，当你调用save()、 update()或 saveOrUpdate()方法传递一个对象时，或使用load()、 get()、list()、iterate() 或scroll()方法获得一个对象时, 该对象都将被加入到Session的内部缓存中。 当随后flush()方法被调用时，对象的状态会和数据库取得同步。
也就是说删除、更新、增加数据的时候，同时更新缓存。当然这也包括二级缓存！
只要是调用hibernate API执行数据库相关的工作。hibernate都会为你自动保证 缓存数据的有效性！！
但是，如果你使用了JDBC绕过hibernate直接执行对数据库的操作。此时，Hibernate不会/也不可能自行感知到数据库被进行的变化改动，也就不能再保证缓存中数据的有效性！！
这也是所有的ORM产品共同具有的问题。幸运的是，Hibernate为我们暴露了Cache的清除方法，这给我们提供了一个手动保证数据有效性的机会！！
一级缓存，二级缓存都有相应的清除方法。
其中二级缓存提供的清除方法为：
按对象class清空缓存
按对象class和对象的主键id清空缓存
清空对象的集合中的缓存数据等。
1.3.2. 适合使用的情况
并非所有的情况都适合于使用二级缓存，需要根据具体情况来决定。同时可以针对某一个持久化对象配置其具体的缓存策略。
适合于使用二级缓存的情况：
1、数据不会被第三方修改；
一般情况下，会被hibernate以外修改的数据最好不要配置二级缓存，以免引起不一致的数据。但是如果此数据因为性能的原因需要被缓存，同时又 有可能被第3方比如SQL修改，也可以为其配置二级缓存。只是此时需要在sql执行修改后手动调用cache的清除方法。以保证数据的一致性
2、数据大小在可接收范围之内；
如果数据表数据量特别巨大，此时不适合于二级缓存。原因是缓存的数据量过大可能会引起内存资源紧张，反而降低性能。
如果数据表数据量特别巨大，但是经常使用的往往只是较新的那部分数据。此时，也可为其配置二级缓存。但是必须单独配置其持久化类的缓存策略，比如最大缓存数、缓存过期时间等，将这些参数降低至一个合理的范围（太高会引起内存资源紧张，太低了缓存的意义不大）。
3、数据更新频率低；
对于数据更新频率过高的数据，频繁同步缓存中数据的代价可能和 查询缓存中的数据从中获得的好处相当，坏处益处相抵消。此时缓存的意义也不大。
4、非关键数据（不是财务数据等）
财务数据等是非常重要的数据，绝对不允许出现或使用无效的数据，所以此时为了安全起见最好不要使用二级缓存。
因为此时 “正确性”的重要性远远大于 “高性能”的重要性。
2. 目前系统中使用hibernate缓存的建议
2.1. 目前情况
一般系统中有三种情况会绕开hibernate执行数据库操作：
1、多个应用系统同时访问一个数据库
此种情况使用hibernate二级缓存会不可避免的造成数据不一致的问题，此时要进行详细的设计。比如在设计上避免对同一数据表的同时的写入操作，
使用数据库各种级别的锁定机制等。
2、动态表相关
所谓“动态表”是指在系统运行时根据用户的操作系统自动建立的数据表。
比如“自定义表单”等属于用户自定义扩展开发性质的功能模块，因为此时数据表是运行时建立的，所以不能进行hibernate的映射。因此对它的操作只能是绕开hibernate的直接数据库JDBC操作。
如果此时动态表中的数据没有设计缓存，就不存在数据不一致的问题。
如果此时自行设计了缓存机制，则调用自己的缓存同步方法即可。
3、使用sql对hibernate持久化对象表进行批量删除时
此时执行批量删除后，缓存中会存在已被删除的数据。
分析：
当执行了第3条（sql批量删除）后，后续的查询只可能是以下三种方式：
a. session.find（）方法：
根据前面的总结，find方法不会查询二级缓存的数据，而是直接查询数据库。
所以不存在数据有效性的问题。
b. 调用iterate方法执行条件查询时：
根据iterate查询方法的执行方式，其每次都会到数据库中查询满足条件的id值，然后再根据此id 到缓存中获取数据，当缓存中没有此id的数据才会执行数据库查询；
如果此记录已被sql直接删除，则iterate在执行id查询时不会将此id查询出来。所以，即便缓存中有此条记录也不会被客户获得，也就不存在不一致的情况。（此情况经过测试验证）
c. 用get或load方法按id执行查询：
客观上此时会查询得到已过期的数据。但是又因为系统中执行sql批量删除一般是针对中间关联数据表，对于中间关联表的查询一般都是采用条件查询 ,按id来查询某一条关联关系的几率很低,所以此问题也不存在!
如果某个值对象确实需要按id查询一条关联关系,同时又因为数据量大使用 了sql执行批量删除。当满足此两个条件时,为了保证按id 的查询得到正确的结果,可以使用手动清楚二级缓存中此对象的数据的方法!!(此种情况出现的可能性较小)
2.2. 建 议
1、建议不要使用sql直接执行数据持久化对象的数据的更新，但是可以执行 批量删除。（系统中需要批量更新的地方也较少）
2、如果必须使用sql执行数据的更新，必须清空此对象的缓存数据。调用
SessionFactory.evict(class)
SessionFactory.evict(class,id)等方法。
3、在批量删除数据量不大的时候可以直接采用hibernate的批量删除，这样就不存在绕开hibernate执行sql产生的缓存数据一致性的问题。
4、不推荐采用hibernate的批量删除方法来删除大批量的记录数据。
原因是hibernate的批量删除会执行1条查询语句外加 满足条件的n条删除语句。而不是一次执行一条条件删除语句！！
当待删除的数据很多时会有很大的性能瓶颈！！！如果批量删除数据量较大,比如超过50条,可以采用JDBC直接删除。这样作的好处是只执行一条sql删除语句,性能会有很大的改善。同时，缓存数据同步的问题,可以采用 hibernate清除二级缓存中的相关数据的方法。
调 用
SessionFactory.evict(class) ;
SessionFactory.evict(class,id)等方法。
所以说，对于一般的应用系统开发而言（不涉及到集群，分布式数据同步问题等），因为只在中间关联表执行批量删除时调用了sql执行，同时中间关联表 一般是执行条件查询不太可能执行按id查询。所以，此时可以直接执行sql删除，甚至不需要调用缓存的清除方法。这样做不会导致以后配置了二级缓存引起数 据有效性的问题。
退一步说，即使以后真的调用了按id查询中间表对象的方法，也可以通过调用清除缓存的方法来解决。
3、具体的配置方法
根据我了解的很多hibernate的使用者在调用其相应方法时都迷信的相信“hibernate会自行为我们处理性能的问题”，或者 “hibernate 会自动为我们的所有操作调用缓存”,实际的情况是hibernate虽然为我们提供了很好的缓存机制和扩展缓存框架的支持，但是必须经过正确的调用其才有 可能发挥作用！！所以造成很多使用hibernate的系统的性能问题，实际上并不是hibernate不行或者不好，而是因为使用者没有正确的了解其使 用方法造成的。相反，如果配置得当hibernate的性能表现会让你有相当“惊喜的”发现。下面我讲解具体的配置方法。
ibernate提供了二级缓存的接口：
net.sf.hibernate.cache.Provider,
同时提供了一个默认的 实现net.sf.hibernate.cache.HashtableCacheProvider，
也可以配置 其他的实现 比如ehcache,jbosscache等。
具体的配置位置位于hibernate.cfg.xml文件中
<propertyname="hibernate.cache.use_query_cache">true</property>
<propertyname="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvider</property>
<hibernate-mapping>
<classname="com.sobey.sbm.model.entitySystem.vo.DataTypeVO"table="dcm_datatype">
<cacheusage="read-write"/>
<idname="id"column="TYPEID"type="java.lang.Long">
<generatorclass="sequence"/>
</id>
<propertyname="name"column="NAME"type="java.lang.String"/>
<propertyname="dbType"column="DBTYPE"type="java.lang.String"/>
</class>
</hibernate-mapping>
很多的hibernate使用者在 配置到 这一步 就以为 完事了，
注意：其实光这样配，根本就没有使用hibernate的二级缓存。同时因为他们在使用hibernate时大多时候是马上关闭session，所 以，一级缓存也没有起到任何作用。结果就是没有使用任何缓存，所有的hibernate操作都是直接操作的数据库！！性能可以想见。
正确的办法是除了以上的配置外还应该配置每一个vo对象的具体缓存策略，在影射文件中配置。例如：
关键就是这个<cache usage="read-write"/>，其有几个选择read-only,read-write,transactional,等
然后在执行查询时 注意了 ，如果是条件查询，或者返回所有结果的查询，此时session.find()方法 不会获取缓存中的数据。只有调用query.iterate()方法时才会调缓存的数据。
同时 get 和 load方法 是都会查询缓存中的数据
④ Hibernate中使用的缓存引擎Ehcache和OSCache各自有什么优缺点
ehcache主要是对数据库访问的缓存,相同的查询语句只需查询一次数据库,从而提高了查询的速度
oscache 主要是对页面的缓存,可以整页或者指定网页某一部分缓存,同时指定他的过期时间,这样在此时间段里面访问的数据都是一样的
hibernate2以前提倡用ehcache
hibernate3后提倡oscache,
⑤ 在配置Hibernate二级缓存的时候，在ehcache.xml中 有这么一句 <diskStore path="D:\cache"/>
你的理解基本上是正确的，但还要结合overflowToDisk参数来用。
另外cache文件不需要手动创建。
下面是一些说明：
由于配置文件中只能指定maxElementsInMemory，这就会有可能存入的对象太多而超出VM的heap大小，当然你可以通过jvm参数增大heap大小，但这总还是有可能溢出。这里可以把maxElementsInMemory值设置到一个比较安全的大小，自己预先测试一下最好。如果内存仍然存不下你需要存的对象个数，那么可以开启overflowToDisk来增加可以存储的Element个数。这里要注意一下，EHCache不会自动帮助你去把内存对象写入到磁盘，当超过maxElementsInMemory程序会自动把更多的部分开始往硬盘写，但是内存的对象其实并没有清出去，这时需要手动使用Cache.flush()方法来把内存对象
重建上一次运行的缓存：这个需求肯定比较普遍，我们当然不希望一旦程序退出，整个缓存就要重建了。开启diskPersistent功能，只要使用的是CacheManager单例模式，下一次启动的时候就会调用上一次运行的缓存。比较麻烦的是写入磁盘的时间还是要自己调用Cache.flush()方法。如果仅仅考虑到程序重启的话，我建议这里把diskStore写入到一个ramfs，这样性能就更高了，但重启电脑的话就不得不重建缓存了。
⑥ hibernate二级缓存配置，系统提示找不到ehcache.xml的配置文件
你的jar包都没有，肯定解析不了啊！！！
⑦ 怎么开启hibernate的缓存
1 缓存的概念，以及用途
1） 缓存：（hibernate单独用来保存数据，开辟一块内存）
缓存就是数据库中的数据在内存中的临时的容器，包含
了数据库表中的数据，位于数据库和访问层之间
2）缓存优点： hibernate做查询的时候，首先去缓存中
查询要找的数据，有直接使用，没有再发sql语句去数据库
中真实查询
把用户经常访问的数据，放入缓存当中，这样每次
就不需要去数据库中访问这些常用信息，可以提高系统的
性能。
3）缓存的分类：
a） 一级缓存
b） 二级缓存
c） 查询缓存
2 一级缓存
1）内部结构：一级缓存的内部结构就是一个map<id,object>
map的key就是id，map的value就是实体对象，该结构
导致一级缓存不能缓存属性
2）一级缓存的生命周期：
一级缓存的生命周期与session有关，session创建并
维护一级缓存，session关闭，一级缓存销毁
3）hibernate中API使用缓存：
a） 可以读写一级缓存的： get , load，Iterate
b） 可以写入一级缓存的： save ,list
4）hibernate一级缓存无法禁用：
5）一级缓存的管理：session管理一级缓存（把一级缓存
数据清空clear）
3 二级缓存
1）二级缓存也叫进程级缓存或SessionFactory级缓存，
二级缓存可以让所有的session所共享
2）二级缓存的生命周期跟SessionFactory一致，
SessionFactory管理二级缓存
3）二级缓存的结构是Hashtable，只能保持实体对象，
不能保存属性，开发当中需要使用第3方提供的缓存组件
4）ehcache.xml
//在该二级缓存中，最多可以缓存对象的数量
maxElementsInMemory="1000"
//缓存在二级缓存中的对象是否永远都有效，一般配置为false
eternal="true"
//"钝化"：两次访问该二级缓存中对象的，间隔时间
timeToIdleSeconds="120"
//二级缓存中的对象从创建到消亡的时间
timeToLiveSeconds="120"
//如果超过缓存的访问，可以写入到硬盘上的
overflowToDisk="true"
5）如何使用二级缓存
a）导入第3方ehcache-1.2.3.jar
b）导入ehcache.xml 配置文件，放入src目录下
c）修改hibernate.cfg.xml
（一）指明二级缓存的提供商
<!-- 指明二级缓存的提供商 -->
<property name="cache.provider_class">
org.hibernate.cache.EhCacheProvider
</property>
（二）开启二级缓存
<!-- 是否开启二级缓存，true开启二级缓存，false关闭二级缓存 -->
<property name="cache.use_second_level_cache">true</property>
d）指明那个对象放入二级缓存中
<!-- 指定把那个对象放入二级缓存当中 -->
<class-cache class="com.tarena.po.Student" usage="read-only"/>
6） 使用二级缓存
能够读写二级缓存： get load iterate
能够写入而不能读取二级缓存： list
7） 二级缓存的管理
使用SessionFactory来管理我们的二级缓存
首先修改HibernateUtil，添加获得SessionFactory的方法
SessionFactory factory = HibernateUtil2.getSessionFactory();
//factory.evict(Student.class, 1):去掉二级缓存中
//id为1的student对象
//factory.evict(Student.class,1);
//factory.evict(Student.class):去掉二级缓存中所有的
//student对象
4 查询缓存
1）查询用来保存属性的，对实体对象的结果集只保存id
2）查询缓存的生命周期，只有当前的表发生改变，查询
缓存的生命周期结束
3）如何使用查询缓存：
a）修改hibernate.cfg.xml文件，开启查询缓存
<!-- 是否开启查询缓存,true开启查询缓存，false关闭查询缓存 -->
<property name="cache.use_query_cache">true</property>
b）在Query对象中必须手动开启查询缓存
⑧ 关于Hibernate二级缓存的问题
<property
name="hibernate.cache.use_second_level_cache">true</property>
<property
name="hibernate.cache.provider_class">org.hibernate.cache.ehcacheprovider</property>
前一句是打开二级缓存，后一句是启用第三方缓存产品（可改变，上面eache是hibernate官方默认的第三方缓存产品）
缓存是否实用，要看你的需求，
如果你的系统，浏览的人数比较多，但是增删的比较少，缓存的功劳非常大
如果你的系统即时性非常强，那么缓存的命中率就比较低，同时更新数据时，hibernate需要额外提供资源维护缓存与数据的一致
⑨ hibernate二级缓存，ehcache.xml文件在哪
合理的缓存应用可以极大地提高系统性能，最简单的是在应用层面做缓存（越高层面做缓存，效果往往越好），直接将数据缓存到服务器中，以全局map方式存储。在使用的时候直接从缓存的map中取，而不用连接数据库，从而提升性能。这种方式简单易行，但是map常驻服务器内存，并且在数据变更（增删改）的时候要手动更新map。还有一种方式比较通用，就是使用Hibernate二级缓存（SessionFactory级别的全局缓存，进程或集群级别），是一种通用缓存（一级缓存就不说了,Session级别缓存，hibernate自己管理），hibernate二级缓存多应用在多读少写的实体对象中，比如组织机构和系统字典。本文使用hibernate注解方式使用二级缓存，做一个说明（使用Ehcache）。1、添加ehcache.xml配置文件2、hibernate配置文件中，配置Ehcache相关属性hibernate.cache.use_second_level_cache=truehibernate.cache.use_query_cache=truehibernate.cache.provider_class=org.hibernate.cache.EhCacheProviderhibernate.generate_statistics=true调试的时候，可以设置log4j的log4j.logger.org.hibernate.cache=debug（记录二级缓存的活动），实际发布的时候，注释掉，以免影响性能。3、pom文件中引入相应jar包（Maven项目，如果还在手动添加jar包的，可以尝试使用maven）org.hibernatehibernate-ehcache3.6.9.Final4、注解方式配置实体配置了二级缓存后，并不是对所有的实体使用，而是需要指定哪些实体需要用到。如果不配置查询缓存（查询缓存会在下面讲到），则只会在根据id查询的操作中，缓存对象。在实体上配置@Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)并指定缓存并发策略。@Entity@Cache(usage=CacheConcurrencyStrategy.NONSTRICT_READ_WRITE)@Table(name="base_dict")@JsonIgnoreProperties(value={"hibernateLazyInitializer","handler","fieldHandler","parentDict"}){/****/=5569761987303812150L;@Id@Column(name="id",length=36)@GeneratedValue(generator="uuid")@GenericGenerator(name="uuid",strategy="org.hibernate.id.UUIDGenerator")@JsonProperty("id")privateStringid;/**字典名称*/@ForeignShow@Column(name="name",length=200)privateStringname;5、查询缓存的使用Queryquery=session.createQuery(hql);query.setCacheable(true);//启用查询缓存query.setCacheRegion(“queryCacheRegion”);//设置查询缓存区域（数据过期策略）QueryCache只是在特定的条件下才会发挥作用，而且要求相当严格：(1)完全相同的HQL重复执行。（注意，只有hql）(2)重复执行期间，QueryCache对应的数据表不能有数据变动（比如添、删、改操作）绝大多数的查询并不能从查询缓存中受益，所以Hibernate默认是不进行查询缓存的。查询缓存适用于以下场合：（1）在应用程序运行时经常使用的查询语句（参数相同）（2）很少对与查询语句检索到的数据进行插入、删除或更新操作query.list();
⑩ ehcache java 对象缓存怎么实现
1.技术背景：
系统缓存是位于应用程序与物理数据源之间，用于临时存放复制数据的内存区域，目的是为减少应用程序对物理数据源访问的次数，从而提高应用程序的运行性能。缓存设想内存是有限的，缓存的时效性也是有限的，所以可以设定内存数量的大小可以执行失效算法，可以在内存满了的情况下，按照最少访问等算法将缓存直接移除或切换到硬盘上。
Ehcache从Hibernate发展而来，逐渐涵盖了Cache界的全部功能，是目前发展势头最好的一个项目，具有快速、简单、低消耗、扩展性强、支持对象或序列化缓存，支持缓存或元素的失效，提供LRU、LFU和FIFO缓存策略，支持内存缓存和硬盘缓存和分布式缓存机制等特点。其中Cache的存储方式为内存或磁盘（ps：无须担心容量问题）
2.EhCahe的类层次介绍：
主要分为三层，最上层是CacheManager，它是操作Ehcache的入口。可以通过CacheManager.getInstance()获得一个单子的CacheManager，或者通过CacheManager的构造函数创建一个新的CacheManager。每个CacheManger都管理多个Cache。每个Cache都以一种类Hash的方式，关联多个Element。Element就是我们用于存放缓存内容的地方。
3.环境搭建：
很简单只需要将ehcache-2.1.0-distribution.tar.gz和ehcache-web-2.0.2-distribution.tar.gz挤压的jar包放入WEB-INF/lib下。
再创建一个重要的配置文件ehcache.xml，可以从ehcache组件包中拷贝一个，也可以自己建立一个，需要放到classpath下，一般放于/WEB-INF/classed/ehcache.xml；具体的配置文件可以网上搜一下
4.实际运用
一个网站的首页估计是被访问次数最多的，我们可以考虑给首页做一个页面缓存；
缓存策略：应该是某个固定时间之内不变的，比如说2分钟更新一次，以应用结构page-filter-action-service--db为例。
位置：页面缓存做到尽量靠近客户的地方，就是在page和filter之间，这样的优点就是第一个用户请求后，页面被缓存，第二个用户在请求，走到filter这个请求就结束了，需要在走到action-service--db，好处当然是服务器压力大大降低和客户端页面响应速度加快。
首页页面缓存存活时间定为2分钟，也就是参数timeToLiveSeconds（缓存的存活时间）应该设置为120，同时timeToIdleSeconds（多长时间不访问缓存，就清楚该缓存）最好也设为2分钟或者小于2分钟。
接着我们来看一下SimplePageCachingFilter的配置，
<filter>
<filter-name>indexCacheFilterfilter-name>
<filter-class>
net.sf.ehcache.constructs.web.filter.SimplePageCachingFilter
<filter-class>
<filter>
<filter-mapping>
<filter-name>indexCacheFilterfilter-name>
<url-pattern>*index.actionurl-pattern>
<filter-mapping>
将上述代码加入到web.xml，那么当打开首页时，你会发现2分钟才会有一堆sql语句出现在控制台，也可以调整为5分钟，总之一切尽在掌控之中。
当然，如果你像缓存首页的部分内容时，你需要使用这个filter，我看一下：
<filter>
<filter-name>indexCacheFilterfilter-name>
<filter-class>
net.sf.ehcache.constructs.web.filter.
<filter-class>
filter>
<filter-mapping>
<filter-name>indexCacheFilterfilter-name>
<url-pattern>*/index_right.jsp<url-pattern>
<filter-mapping>
如此我们将jsp页面通过jsp：include到其他页面，这样就做到了页面局部缓存的效果，这一点貌似没有oscache的tag好用。
此外cachefilter中还有一个特性，就是gzip，也就是缓存中的元素是被压缩过的，如果客户端浏览器支持压缩的话，filter会直接返回压缩过的流，这样节省了带宽，把解压的工作交给了客户端浏览即可，当然如果客户端不支持gzip，那么filter会把缓存的元素拿出来解压后在返回给客户端浏览器（大多数爬虫是不支持gzip的，所以filter也会解压后在返回流）。
总之，Ehcache是一个非常轻量级的缓存实现，而且从1.2之后支持了集群，而且是hibernate默认的缓存provider，本文主要介绍Ehcahe对页面缓存的支持，但是它的功能远不止如此，要用好缓存，对J2ee中缓存的原理、适用范围、适用场景等等都需要比较深刻的理解，这样才能用好用对缓存。
为了大家通过实际例子加深了解与场景运用，在奉献一个实例：
*在Spring中运用EhCache
适用任意一个现有开源CacheFramework，要求可以Cache系统中service或者DAO层的get/find等方法返回结果，如果数据更新（适用了Create/update/delete），则刷新cache中相应的内容。
根据需求，计划适用SpringAOP+enCache来实现这个功能，采用ehCache原因之一就是Spring提供了enCache的支持，至于为何仅仅支持ehcache而不支持oscache和jbosscache就无从得知了。
AOP少不了拦截器，先创建一个实现了MethodInterceptor接口的拦截器，用来拦截Service/DAO的方法调用，拦截到方法后，搜索该方法的结果在cache中是否存在，如果存在，返回cache中结果，如果不存在返回数据库查询结果，并将结果返回到缓存。
,InitializingBean
{
privatestaticfinalLoglogger=LogFactory.getLog(MethodCacheInterceptor.class);
privateCachecache;
publicvoidsetCache(Cachecache){
this.cache=cache;
}
publicMethodCacheInterceptor(){
super();
}
/**
*拦截Service/DAO的方法，并查找该结果是否存在，如果存在就返回cache中的值，
*否则，返回数据库查询结果，并将查询结果放入cache
*/
publicObjectinvoke(MethodInvocationinvocation)throwsThrowable{
StringtargetName=invocation.getThis().getClass().getName();
StringmethodName=invocation.getMethod().getName();
Object[]arguments=invocation.getArguments();
Objectresult;
logger.debug("Findobjectfromcacheis"+cache.getName());
StringcacheKey=getCacheKey(targetName,methodName,arguments);
Elementelement=cache.get(cacheKey);
Page13of26
if(element==null){
logger.debug("Holpmethod,Getmethodresultandcreatecache........!");
result=invocation.proceed();
element=newElement(cacheKey,(Serializable)result);
cache.put(element);
}
returnelement.getValue();
}
/**
*获得cachekey的方法，cachekey是Cache中一个Element的唯一标识
*cachekey包括包名+类名+方法名，如com.co.cache.service.UserServiceImpl.getAllUser
*/
privateStringgetCacheKey(StringtargetName,StringmethodName,Object[]arguments){
StringBuffersb=newStringBuffer();
sb.append(targetName).append(".").append(methodName);
if((arguments!=null)&&(arguments.length!=0)){
for(inti=0;i<arguments.length;i++){
sb.append(".").append(arguments[i]);
}
}
returnsb.toString();
}
/**
*implementInitializingBean，检查cache是否为空
*/
publicvoidafterPropertiesSet()throwsException{
Assert.notNull(cache,"Needacache.PleaseusesetCache(Cache)createit.");
}
}
上面的代码可以看到，在方法invoke中，完成了搜索cache/新建cache的功能
随后，再建立一个拦截器MethodCacheAfterAdvice，作用是在用户进行create/update/delete操作时来刷新、remove相关cache内容，这个拦截器需要实现AfterRetruningAdvice接口，将会在所拦截的方法执行后执行在afterReturning（objectarg0，Methodarg1，Object[]arg2,objectarg3)方法中所预定的操作
,InitializingBean
{
privatestaticfinalLoglogger=LogFactory.getLog(MethodCacheAfterAdvice.class);
privateCachecache;
Page15of26
publicvoidsetCache(Cachecache){
this.cache=cache;
}
publicMethodCacheAfterAdvice(){
super();
}
publicvoidafterReturning(Objectarg0,Methodarg1,Object[]arg2,Objectarg3)throws
Throwable{
StringclassName=arg3.getClass().getName();
Listlist=cache.getKeys();
for(inti=0;i<list.size();i++){
StringcacheKey=String.valueOf(list.get(i));
if(cacheKey.startsWith(className)){
cache.remove(cacheKey);
logger.debug("removecache"+cacheKey);
}
}
}
publicvoidafterPropertiesSet()throwsException{
Assert.notNull(cache,"Needacache.PleaseusesetCache(Cache)createit.");
}
}
该方法获取目标class的全名，如：com.co.cache.test.TestServiceImpl，然后循环cache的keylist，刷新/removecache中所有和该class相关的element。
接着就是配置encache的属性，如最大缓存数量、cache刷新的时间等等。
<ehcache>
<diskStorepath="c:\myapp\cache"/>
<defaultCache
maxElementsInMemory="1000"
eternal="false"
timeToIdleSeconds="120"
timeToLiveSeconds="120"
overflowToDisk="true"
/>
<cachename="DEFAULT_CACHE"
maxElementsInMemory="10000"
eternal="false"
timeToIdleSeconds="300000"
timeToLiveSeconds="600000"
overflowToDisk="true"
/>
</ehcache>
这里需要注意的是defaultCache定义了一个默认的cache，这个Cache不能删除，否则会抛出Nodefaultcacheisconfigured异常。另外由于使用拦截器来刷新Cache内容，因此在定义cache生命周期时可以定义较大的数值，timeToIdleSeconds="30000000",timeToLiveSeconds="6000000"，好像还不够大？
然后再将Cache和两个拦截器配置到Spring的配置文件cache.xml中即可，需要创建两个“切入点”，分别用于拦截不同方法名的方法。在配置application.xml并且导入cache.xml。这样一个简单的Spring+Encache框架就搭建完成。