Hibernate缓存
缓存在Hibernate中主要有三个方面：一级缓存、二级缓存和查询缓存
①一级缓存在Hibernate中对应的为session范围的缓存，也就是当session关闭时缓存即被清除，一级缓存在Hibernate中是不可配置的
②二级缓存在Hibernate中对应的为SessionFactory范围的缓存，通常来讲SessionFactory的生命周期和应用的生命周期相同，所以可以看成是进程缓存或集群缓存，二级缓存在Hibernate中是可以配置的，可以通过class-cache配置类粒度级别的缓存(class-cache在class中数据发生任何变化的情况下自动更新)，同时也可通过collection-cache配置集合粒度级别的缓存(collection-cache仅在collection中增加了元素或者删除了元素的情况下才自动更新，也就是当collection中元素发生值的变化的情况下它是不会自动更新的)，跨session的缓存自然会带来并发的访问题，这个时候相应的就要根据应用来设置缓存所采用的事务隔离级别，和数据库的事务隔离级别概念基本一样，没什么多介绍的
③查询缓存在Hibernate同样是可配置的，默认是关闭的，可以通过设置cache.use_ query_cache为true来打开查询缓存。
根据缓存的通常实现策略，我们可以来理解Hibernate的这三种缓存，缓存的实现通过是通过key/value的Map方式来实现，在Hibernate的一级、二级和查询缓存也同样如此。一级、二级缓存使用的key均为po的主键ID，value即为po实例对象，查询缓存使用的则为查询的条件(hql转化而成的sql语句)、查询的参数、查询的页数，value有两种情况，如果采用的是select po.property这样的方式那么value为整个结果集，如采用的是from这样的方式那么value为获取的结果集中各po对象的主键ID，这样的作用很明显，节省内存。
简单介绍完Hibernate的缓存后，再结合Hibernate的获取数据方式来说明缓存的具体使用方式，在Hibernate中获取数据常用的方式主要有四种：Session.load、Session.get、Query.list、Query.iterator。
1、Session.load
在执行session.load时，Hibernate首先从当前session的一级缓存中获取id对应的值，在获取不到的情况下，将根据该对象是否配置了二级缓存来做相应的处理，如配置了二级缓存，则从二级缓存中获取id对应的值，如仍然获取不到则还需要根据是否配置了延迟加载来决定如何执行，如未配置延迟加载则从数据库中直接获取，在从数据库获取到数据的情况下，Hibernate会相应的填充一级缓存和二级缓存，如配置了延迟加载则直接返回一个代理类，只有在触发代理类的调用时才进行数据库查询的操作。
备注 load方法过程：一级缓存 ---> 二级缓存 ----> DB访问 ---> 填充一级缓存[、二级缓存] / 返回一个代理类
在这样的情况下我们就可以看到，在session一直打开的情况下，要注意在适当的时候对一级缓存进行刷新操作，通常是在该对象具有单向关联维护的时候，在Hibernate中可以使用象session.clear、session.evict的方式来强制刷新一级缓存。 二级缓存则在数据发生任何变化(新增、更新、删除)的情况下都会自动的被更新。
备注：由于一级缓存是位于物理内存空间的，毕竟大小有限。过多的对象缓存在这里会造成较大的压力。适当的时候刷新缓存除了可以保证数据库和内存的状态同步外，还可以移除不再用的对象，腾出空间来给后面的对象缓存使用。
2、Session.get
在执行Session.get时，和Session.load不同的就是在当从缓存中获取不到时，直接从数据库中获取id对应的值。
备注：load和get方法的另外一个区别就是：当对象在DB中找不到时，load会抛出异常，而get仅仅返回null
3、Query.list
在执行Query.list时，Hibernate的做法是首先检查是否配置了查询缓存，如配置了则从查询缓存中查找key为查询语句+查询参数+分页条件的值，如获取不到则从数据库中进行获取，从数据库获取到后Hibernate将会相应的填充一级、二级和查询缓存，如获取到的为直接的结果集，则直接返回，如获取到的为一堆id的值，则再根据id获取相应的值(Session.load)，最后形成结果集返回，可以看到，在这样的情况下，list也是有可能造成N次的查询的。
查询缓存在数据发生任何变化的情况下都会被自动的清空。
备注：list()方法的SQL成本
①没有配置查询缓存或者缓存匹配不到时，发出一次SQL查询
②缓存的值为一组对象ID，则每个ID执行一次Session.load操作。视乎缓存对象是否还在会再发出0~N次SQL查询
③缓存的值为一组集合对象，则直接返回。此时不需要发出SQL查询
由此可见list()方法的SQL成本从0~N次不等，具体的次数和一、二级缓存的对象生命周期时间设置、SQL语句写法有关。如果采用select po.value写法，那么SQL成本最低(0)，如果采用from po写法，那么SQL成本从0~N不等。
虽然表明看采用select po.value的写法好像会更加高效，但是考虑到对象的大小，但一次性读入时会造成大量的内存空间浪费。但是缓存ID又可能带来N次额外的查询消耗，应该怎么办呢？最好的方法就是设置一、二级缓存的对象生命周期时间比查询缓存的生命周期长，这样不至于在Hibernate对每个ID执行Session.load方法时实体缓存都过期而被清空了。
另外一个要注意的是：如果查询缓存引用的表在查询后被修改了，那么不管缓存的数据是否有变，该查询都会被清空而重新获取。因为Hibernate是靠比较每个表的修改时间和查询缓存的填入时间来判断表是否被修改了，它不会去判断具体的内容
4、Query.iterator
在执行Query.iterator时，和Query.list的不同的在于从数据库获取的处理上，Query.iterator向数据库发起的是select id from这样的语句，也就是它是先获取符合查询条件的id，之后在进行iterator.next调用时才再次发起session.load的调用获取实际的数据。
可见，在拥有二级缓存并且查询参数多变的情况下，Query.iterator会比Query.list更为高效。
备注：iterator的SQL成本
①最佳情况下，只有一次SQL查询(ID查询)，其它的通过一、二级缓存可以得到
②最坏情况下，变成1+N次查询(ID查询 + 实体查询)
这四种获取数据的方式都各有适用的场合，要根据实际情况做相应的决定，最好的方式无疑就是打开show_sql选项看看执行的情况来做分析，系统结构上只用保证这种调整是容易实现的就好了，在cache这个方面的调整自然是非常的容易，只需要调整配置文件里的设置，而查询的方式则可对外部进行屏蔽，这样要根据实际情况调整也非常容易。
备注：关于list()和iterator()的查询成本比较
※没有配置查询缓存，或者缓存中没有对应的key ：
list()：执行一次SQL查询全部取出
iterator()：执行一次SQL语句先取出符合条件的所有对象ID，在迭代期间通过Session.load方法查询(额外的0~N次查询)
※缓存值是一组对象ID：
list()：执行Session.load方法查询(额外的0~N次查询)
iterator()：执行Session.load方法查询(额外的0~N次查询)
※缓存值是一组集合：
list()：直接返回，没有SQL查询
iterator()：直接返回，没有SQL查询
可见最大的区别在于从数据库读取数据的地方，list虽然只有1次SQL查询，但它是直接从物理数据文件中读取。而iterator虽然是1+N次查询，但后面的N次可能是从缓存中拿数据，所以SQL语句次数相同，兼之iterator只取id，在缓存配置得当的情况下，iterator确实高效。但是如果缓存配置不当，那么iterator的后续next操作将不得不发出一次又一次的SQL查询，反而大大比不上list。
从分页查询的情况来看，用iterator()的效率反而不及list()：因为每页的对象的id都是不同的。iterator()使用Session.load时总是读取不到实体缓存(一级、二级缓存)的值，只能再发出一次SQL查询。
1. 关于hibernate缓存的问题：
Hibernate缓存分为二级，第一级存放于session中称为一级缓存，默认带有且不能卸载。
第二级是由sessionFactory控制的进程级缓存。是全局共享的缓存，凡是会调用二级缓存的查询方法 都会从中受益。只有经正确的配置后二级缓存才会发挥作用。同时在进行条件查询时必须使用相应的方法才能从缓存中获取数据。比如Query.iterate()方法、load、get方法等。必须注意的是session.find方法永远是从数据库中获取数据，不会从二级缓存中获取数据，即便其中有其所需要的数据也是如此。
查询时使用缓存的实现过程为：首先查询一级缓存中是否具有需要的数据，如果没有，查询二级缓存，如果二级缓存中也没有，此时再执行查询数据库的工作。要注意的是：此3种方式的查询速度是依次降低的。
因为Session的生命期往往很短，存在于Session内部的第一级最快缓存的生命期当然也很短，所以第一级缓存的命中率是很低的。其对系统性能的改善也是很有限的。当然，这个Session内部缓存的主要作用是保持Session内部数据状态同步。并非是hibernate为了大幅提高系统性能所提供的。
为了提高使用hibernate的性能，除了常规的一些需要注意的方法比如：
使用延迟加载、迫切外连接、查询过滤等以外，还需要配置hibernate的二级缓存。其对系统整体性能的改善往往具有立竿见影的效果！
（经过自己以前作项目的经验，一般会有3~4倍的性能提高）
1.2.2. N+1次查询的问题
执行条件查询时，iterate（）方法具有著名的 “n+1”次查询的问题，也就是说在第一次查询时iterate方法会执行满足条件的查询结果数再加一次（n+1）的查询。但是此问题只存在于第一次查询时，在后面执行相同查询时性能会得到极大的改善。此方法适合于查询数据量较大的业务数据。
但是注意：当数据量特别大时（比如流水线数据等）需要针对此持久化对象配置其具体的缓存策略，比如设置其存在于缓存中的最大记录数、缓存存在的时间等参数，以避免系统将大量的数据同时装载入内存中引起内存资源的迅速耗尽，反而降低系统的性能！！！
1.3. 使用hibernate二级缓存的其他注意事项：
另外，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缓存的建议
一般系统中有三种情况会绕开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 的查询得到正确的结果,可以使用手动清楚二级缓存中此对象的数据的方法!!
(此种情况出现的可能性较小)
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查询中间表对象的方法，也可以通过调用清除缓存的方法来解决。
4、具体的配置方法
根据我了解的很多hibernate的使用者在调用其相应方法时都迷信的相信“hibernate会自行为我们处理性能的问题”，或者“hibernate会自动为我们的所有操作调用缓存”,实际的情况是hibernate虽然为我们提供了很好的缓存机制和扩展缓存框架的支持，但是必须经过正确的调用其才有可能发挥作用！！所以造成很多使用hibernate的系统的性能问题，实际上并不是hibernate不行或者不好，而是因为使用者没有正确的了解其使用方法造成的。相反，如果配置得当hibernate的性能表现会让你有相当“惊喜的”发现。下面我讲解具体的配置方法.
ibernate提供了二级缓存的接口：
net.sf.hibernate.cache.Provider,
同时提供了一个默认的 实现net.sf.hibernate.cache.HashtableCacheProvider，
也可以配置 其他的实现 比如ehcache,jbosscache等。
具体的配置位置位于hibernate.cfg.xml文件中
<property name="hibernate.cache.use_query_cache">true</property>
<property name="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvider</property>
很多的hibernate使用者在 配置到 这一步 就以为 完事了，
注意：其实光这样配，根本 就没有使用hibernate的二级缓存。同时因为他们在使用hibernate时大多时候是马上关闭session，所以，一级缓存也没有起到任何作用。结果就是没有使用任何缓存，所有的hibernate操作都是直接操作的数据库！！性能可以想见。
正确的办法是除了以上的配置外还应该配置每一个vo对象的具体缓存策略，在影射文件中配置。例如：
<hibernate-mapping>
<class name="com.sobey.sbm.model.entitySystem.vo.DataTypeVO" table="dcm_datatype">
<cache usage="read-write"/>
<id name="id" column="TYPEID" type="java.lang.Long">
<generator class="sequence"/>
</id>
<property name="name" column="NAME" type="java.lang.String"/>
<property name="dbType" column="DBTYPE" type="java.lang.String"/>
</class>
</hibernate-mapping>
关键就是这个<cache usage="read-write"/>，其有几个选择
read-only,read-write,transactional,等
然后在执行查询时 注意了 ，如果是条件查询，或者返回所有结果的查询，此时session.find()方法 不会获取缓存中的数据。只有调用query.iterate()方法时才会调缓存的数据。
同时 get 和 load方法 是都会查询缓存中的数据 .
对于不同的缓存框架具体的配置方法会有不同，但是大体是以上的配置
（另外，对于支持事务型，以及支持集群的环境的配置我会争取在后续的文章中中 发表出来）