关于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的二级缓存。其对系统整体性能的改善往往具有立竿见影的效果！

 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）的查询。但是此问题只存在于第一次查询时，在后面执行相同查询时性能会得到极大的改善。此方法适合于查询数据量较大的业务数据。

   但是注意：当数据量特别大时（比如流水线数据等）需要针对此持久化对象配置其具体的缓存策略，比如设置其存在于缓存中的最大记录数、缓存存在的时间等参数，以避免系统将大量的数据同时装载入内存中引起内存资源的迅速耗尽，反而降低系统的性能！！！