hibernate4二级缓存
⑴ 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二级缓存设置问题
<property
name="hibernate.cache.use_second_level_cache">true</property>
<property
name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property>
前一句是打开二级缓存，后一句是启用第三方缓存产品（可改变，上面eache是hibernate官方默认的第三方缓存产品）
缓存是否实用，要看你的需求，
如果你的系统，浏览的人数比较多，但是增删的比较少，缓存的功劳非常大
如果你的系统即时性非常强，那么缓存的命中率就比较低，同时更新数据时，hibernate需要额外提供资源维护缓存与数据的一致
⑶ 如何用redis做hibernate4的二级缓存，求实践过的人解答
在向大家详细介绍Hibernate二级缓存之前，首先让大家了解下一级缓存，然后全面介绍Hibernate二级缓存。 Hibernate中提供了两级Cache，第一级别的缓存是Session级别的缓存，它是属于事务范围的缓存。
⑷ 什么是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二级缓存的问题
<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的一级缓存与二级缓存的区别
一级缓存就是Session级别的缓存，一个Session做了一个查询操作，它会把这个操作的结果放在一级缓存中，如果短时间内这个session（一定要同一个session）又做了同一个操作，那么hibernate直接从一级缓存中拿，而不会再去连数据库，取数据。
二级缓存就是SessionFactory级别的缓存，顾名思义，就是查询的时候会把查询结果缓存到二级缓存中，如果同一个sessionFactory创建的某个session执行了相同的操作，hibernate就会从二级缓存中拿结果，而不会再去连接数据库。
⑺ hibernate 二级缓存和查询缓存有什么区别
一级缓存为session级别的缓存，为hibernate内置缓存，你从数据库load或get数据的时候会先去一级缓存上找。如果找到，则不会从数据库中存，否则从数据库中取。一级缓存会在session关闭时自动清除。
二级缓存为SessionFactory级别的缓存，要使用第三方二级缓存组件，不同session可以共享二级缓存中的数据！
查询缓存就是hql或sql语句要相同，否则无法命中数据
⑻ Hibernate二级缓存的作用是什么
使用缓存，是需要对应用系统进行性能优化而常采用的一种重要手段。合理地运用缓存，可以极大的提高应用系统的运行效率。
Hibernate中应用缓存：因为应用程序访问数据库，读写数据的代价非常高，而利用持久层的缓存可以减少应用程序与数据库之间的交互，即把访问过的数据保存到缓存中，应用程序再次访问已经访问过的数据，这些数据就可以从缓存中获取，而不必再从数据库中获取。同时如果数据库中的数据被修改或者删除，那么是、该数据所对应的缓存数据，也会被同步修改或删除，进而保持缓存数据的一致性。
Hibernate的二级缓存由SessionFactory对象管理，是应用级别的缓存。它可以缓存整个应用的持久化对象，所以又称为“SessionFactory缓存”。
hibernate二级缓存中的缓存对象可以被整个应用的Session对象共享，即使关闭当前Session对象，新建的Session对象仍可使用。使用Hibernate的二级缓存之后查询数据，Session对象会首先在以及缓存中查找有无缓存数据被命中。如果没有，则查找二级缓存。如果有，则直接返回所命中的数据；否则查询数据库。
⑼ hibernate一级缓存和二级缓存的区别
一级缓存：
就是Session级别的缓存。一个Session做了一个查询操作，它会把这个操作的结果放在一级缓存中。
如果短时间内这个session（一定要同一个session）又做了同一个操作，那么hibernate直接从一级缓存中拿，而不会再去连数据库，取数据。
它是内置的事务范围的缓存，不能被卸载。
二级缓存：
就是SessionFactory级别的缓存。顾名思义，就是查询的时候会把查询结果缓存到二级缓存中。
如果同一个sessionFactory创建的某个session执行了相同的操作，hibernate就会从二级缓存中拿结果，而不会再去连接数据库。
这是可选的插件式的缓存，在默认情况下，SessionFactory不会启用这个插件。
可以在每个类或每个集合的粒度上配置。缓存适配器用于把具体的缓存实现软件与Hibernate集成。
严格意义上说，SessionFactory缓存分为两类：内置缓存和外置缓存。我们通常意义上说的二级缓存是指外置缓存。
内置缓存与session级别缓存实现方式相似。前者是SessionFactory对象的一些集合属性包含的数据，后者是指Session的一些集合属性包含的数据
SessionFactory的内置缓存中存放了映射元数据和预定义SQL语句。
映射元数据是映射文件中数据的拷贝；
而预定义SQL语句是在Hibernate初始化阶段根据映射元数据推导出来。
SessionFactory的内置缓存是只读的，应用程序不能修改缓存中的映射元数据和预定义SQL语句，因此SessionFactory不需要进行内置缓存与映射文件的同步。
Hibernate的这两级缓存都位于持久化层，存放的都是数据库数据的拷贝。
缓存的两个特性：
缓存的范围
缓存的并发访问策略
1、缓存的范围
决定了缓存的生命周期以及可以被谁访问。缓存的范围分为三类。
事务范围
进程范围
集群范围
注：
对大多数应用来说，应该慎重地考虑是否需要使用集群范围的缓存，因为访问的速度不一定会比直接访问数据库数据的速度快多少。
事务范围的缓存是持久化层的第一级缓存，通常它是必需的；进程范围或集群范围的缓存是持久化层的第二级缓存，通常是可选的。
2、缓存的并发访问策略
当多个并发的事务同时访问持久化层的缓存的相同数据时，会引起并发问题，必须采用必要的事务隔离措施。
在进程范围或集群范围的缓存，即第二级缓存，会出现并发问题。
因此可以设定以下四种类型的并发访问策略，每一种策略对应一种事务隔离级别。
事务型并发访问策略是事务隔离级别最高，只读型的隔离级别最低。事务隔离级别越高，并发性能就越低。
A 事务型：仅仅在受管理环境中适用。它提供了Repeatable Read事务隔离级别。
对于经常被读但很少修改的数据，可以采用这种隔离类型，因为它可以防止脏读和不可重复读这类的并发问题。
B 读写型：提供了Read Committed事务隔离级别。仅仅在非集群的环境中适用。
对于经常被读但很少修改的数据，可以采用这种隔离类型，因为它可以防止脏读这类的并发问题。
C 非严格读写型：不保证缓存与数据库中数据的一致性。
如果存在两个事务同时访问缓存中相同数据的可能，必须为该数据配置一个很短的数据过期时间，从而尽量避免脏读。
对于极少被修改，并且允许偶尔脏读的数据，可以采用这种并发访问策略。
D 只读型：对于从来不会修改的数据，如参考数据，可以使用这种并发访问策略。
什么样的数据适合存放到第二级缓存中？
1、很少被修改的数据
2、不是很重要的数据，允许出现偶尔并发的数据
3、不会被并发访问的数据
4、参考数据
不适合存放到第二级缓存的数据？
1、经常被修改的数据
2、财务数据，绝对不允许出现并发
3、与其他应用共享的数据。
Hibernate的二级缓存策略的一般过程如下：
1) 条件查询的时候，总是发出一条select * from table_name where …. （选择所有字段）这样的SQL语句查询数据库，一次获得所有的数据对象。
2) 把获得的所有数据对象根据ID放入到第二级缓存中。
3) 当Hibernate根据ID访问数据对象的时候，首先从Session一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照ID放入到缓存。
4) 删除、更新、增加数据的时候，同时更新缓存。
注：
Hibernate的二级缓存策略，是针对于ID查询的缓存策略，对于条件查询则毫无作用。为此，Hibernate提供了针对条件查询的Query缓存。
Query缓存策略的过程如下：
1) Hibernate首先根据这些信息组成一个Query Key，Query Key包括条件查询的请求一般信息：SQL, SQL需要的参数，记录范围（起始位置rowStart，最大记录个数maxRows)，等。
2) Hibernate根据这个Query Key到Query缓存中查找对应的结果列表。如果存在，那么返回这个结果列表；如果不存在，查询数据库，获取结果列表，把整个结果列表根据Query Key放入到Query缓存中。
3) Query Key中的SQL涉及到一些表名，如果这些表的任何数据发生修改、删除、增加等操作，这些相关的Query Key都要从缓存中清空。
⑽ hibernate缓存机制的二级缓存
Hibernate提供了两级缓存，第一级是Session的缓存。由于Session对象的生命周期通常对应一个数据库事务或者一个应用事务，因此它的缓存是事务范围的缓存。第一级缓存是必需的，不允许而且事实上也无法卸除。在第一级缓存中，持久化类的每个实例都具有唯一的OID。
第二级缓存是一个可插拔的的缓存插件，它是由SessionFactory负责管理。由于SessionFactory对象的生命周期和应用程序的整个过程对应，因此第二级缓存是进程范围或者集群范围的缓存。这个缓存中存放的对象的松散数据。第二级对象有可能出现并发问题，因此需要采用适当的并发访问策略，该策略为被缓存的数据提供了事务隔离级别。缓存适配器用于把具体的缓存实现软件与Hibernate集成。第二级缓存是可选的，可以在每个类或每个集合的粒度上配置第二级缓存。 适合存放到第二级缓存中的数据
1 很少被修改的数据
2 不是很重要的数据，允许出现偶尔并发的数据
3 不会被并发访问的数据
4 参考数据
不适合存放到第二级缓存的数据
1 经常被修改的数据
2 财务数据，绝对不允许出现并发
3 与其他应用共享的数据。 1) 条件查询的时候，总是发出一条select * from table_name where …. （选择所有字段）这样的SQL语句查询数据库，一次获得所有的数据对象。
2) 把获得的所有数据对象根据ID放入到第二级缓存中。
3) 当Hibernate根据ID访问数据对象的时候，首先从Session一级缓存中查；查不到，如果配置了二级缓存，那么从二级缓存中查；查不到，再查询数据库，把结果按照ID放入到缓存。
4) 删除、更新、增加数据的时候，同时更新缓存。
Hibernate的二级缓存策略，是针对于ID查询的缓存策略，对于条件查询则毫无作用。为此，Hibernate提供了针对条件查询的Query缓存。
Hibernate的Query缓存策略的过程如下：
1) Hibernate首先根据这些信息组成一个Query Key，Query Key包括条件查询的请求一般信息：SQL, SQL需要的参数，记录范围（起始位置rowStart，最大记录个数maxRows)，等。
2) Hibernate根据这个Query Key到Query缓存中查找对应的结果列表。如果存在，那么返回这个结果列表；如果不存在，查询数据库，获取结果列表，把整个结果列表根据Query Key放入到Query缓存中。
3) Query Key中的SQL涉及到一些表名，如果这些表的任何数据发生修改、删除、增加等操作，这些相关的Query Key都要从缓存中清空。