zoukankan      html  css  js  c++  java

  • Hibernate缓存

    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文件中

    1. <property name="hibernate.cache.use_query_cache">true</property> 
    2.  
    3. <property name="hibernate.cache.provider_class">net.sf.hibernate.cache.HashtableCacheProvider</property> 

    很多的hibernate使用者在 配置到 这一步 就以为 完事了，

    注意：其实光这样配，根本就没有使用hibernate的二级缓存。同时因为他们在使用hibernate时大多时候是马上关闭session，所以，一级缓存也没有起到任何作用。结果就是没有使用任何缓存，所有的hibernate操作都是直接操作的数据库！！性能可以想见。

    正确的办法是除了以上的配置外还应该配置每一个vo对象的具体缓存策略，在影射文件中配置。例如：

    1. <hibernate-mapping> 
    2. <class name="com.sobey.sbm.model.entitySystem.vo.DataTypeVO" table="dcm_datatype"> 
    3. <cache usage="read-write"/> 
    4. <id name="id" column="TYPEID" type="java.lang.Long"> 
    5. <generator class="sequence"/> 
    6. </id> 
    7. <property name="name" column="NAME" type="java.lang.String"/> 
    8. <property name="dbType" column="DBTYPE" type="java.lang.String"/> 
    9. </class> 
    10. </hibernate-mapping> 

    关键就是这个<cache usage="read-write"/>，其有几个选择read-only,read-write,transactional,等

    然后在执行查询时 注意了 ，如果是条件查询，或者返回所有结果的查询，此时session.find()方法 不会获取缓存中的数据。只有调用query.iterate()方法时才会调缓存的数据。

    同时 get 和 load方法 是都会查询缓存中的数据

    缓存是介于物理数据源与应用程序之间，是对数据库中的数据复制一份临时放在内存中的容器，其作用是为了减少应用程序对物理数据源访问的次数，从而提高了应用的运行性能。Hibernate在进行读取数据的时候，根据缓存机制在相应的缓存中查询，如果在缓存中找到了需要的数据(我们把这称做“缓存命中")，则就直接把命中的数据作为结果加以利用，避免了大量发送SQL语句到数据库查询的性能损耗。

    Hibernate缓存分类：

    一、Session缓存（又称作事务缓存）：Hibernate内置的，不能卸除。

    缓存范围：缓存只能被当前Session对象访问。缓存的生命周期依赖于Session的生命周期，当Session被关闭后，缓存也就结束生命周期。

    二、SessionFactory缓存（又称作应用缓存）：使用第三方插件，可插拔。

    缓存范围：缓存被应用范围内的所有session共享。这些session有可能是并发访问缓存，因此必须对缓存进行更新。缓存的生命周期依赖于应用的生命周期，应用结束时，缓存也就结束了生命周期，二级缓存存在于应用程序范围。

    Hibernate一些与一级缓存相关的操作（时间点）：

    数据放入缓存：

    1. save()。当session对象调用save()方法保存一个对象后，该对象会被放入到session的缓存中。

    2. get()和load()。当session对象调用get()或load()方法从数据库取出一个对象后，该对象也会被放入到session的缓存中。

    3. 使用HQL和QBC等从数据库中查询数据。

    例如：数据库有一张表如下：

    使用get()或load()证明缓存的存在：

    1. public class Client  
    2. {  
    3.     public static void main(String[] args)  
    4.     {  
    5.         Session session = HibernateUtil.getSessionFactory().openSession();  
    6.         Transaction tx = null;  
    7.         try 
    8.         {  
    9.             /*开启一个事务*/ 
    10.             tx = session.beginTransaction();  
    11.             /*从数据库中获取id="402881e534fa5a440134fa5a45340002"的Customer对象*/ 
    12.             Customer customer1 = (Customer)session.get(Customer.class, "402881e534fa5a440134fa5a45340002");  
    13.             System.out.println("customer.getUsername is"+customer1.getUsername());  
    14.             /*事务提交*/ 
    15.             tx.commit();  
    16.               
    17.             System.out.println("-------------------------------------");  
    18.               
    19.             /*开启一个新事务*/ 
    20.             tx = session.beginTransaction();  
    21.             /*从数据库中获取id="402881e534fa5a440134fa5a45340002"的Customer对象*/ 
    22.             Customer customer2 = (Customer)session.get(Customer.class, "402881e534fa5a440134fa5a45340002");  
    23.             System.out.println("customer2.getUsername is"+customer2.getUsername());  
    24.             /*事务提交*/ 
    25.             tx.commit();  
    26.               
    27.             System.out.println("-------------------------------------");  
    28.               
    29.             /*比较两个get()方法获取的对象是否是同一个对象*/ 
    30.             System.out.println("customer1 == customer2 result is "+(customer1==customer2));  
    31.         }  
    32.         catch (Exception e)  
    33.         {  
    34.             if(tx!=null)  
    35.             {  
    36.                 tx.rollback();  
    37.             }  
    38.         }  
    39.         finally 
    40.         {  
    41.             session.close();  
    42.         }  
    43.     }  
    44. } 

    程序控制台输出结果：

    1. Hibernate:   
    2.     select  
    3.         customer0_.id as id0_0_,  
    4.         customer0_.username as username0_0_,  
    5.         customer0_.balance as balance0_0_   
    6.     from  
    7.         customer customer0_   
    8.     where  
    9.         customer0_.id=?  
    10. customer.getUsername islisi  
    11. -------------------------------------  
    12. customer2.getUsername islisi  
    13. -------------------------------------  
    14. customer1 == customer2 result is true 

    输出结果中只包含了一条SELECT SQL语句，而且customer1 == customer2 result is true说明两个取出来的对象是同一个对象。其原理是：第一次调用get()方法， Hibernate先检索缓存中是否有该查找对象，发现没有，Hibernate发送SELECT语句到数据库中取出相应的对象，然后将该对象放入缓存中，以便下次使用，第二次调用get()方法，Hibernate先检索缓存中是否有该查找对象，发现正好有该查找对象，就从缓存中取出来，不再去数据库中检索。

    数据从缓存中清除：

    1. evit()将指定的持久化对象从缓存中清除，释放对象所占用的内存资源，指定对象从持久化状态变为脱管状态，从而成为游离对象。

    2. clear()将缓存中的所有持久化对象清除，释放其占用的内存资源。

    其他缓存操作：

    1. contains()判断指定的对象是否存在于缓存中。

    2. flush()刷新缓存区的内容，使之与数据库数据保持同步。

    Hibernate使用二级缓存

    适合存放到第二级缓存中的数据：

    1. 很少被修改的数据。

    2. 不是很重要的数据，允许出现偶尔并发的数据。

    3. 不会被并发访问的数据。

    4. 参考数据,指的是供应用参考的常量数据，它的实例数目有限，它的实例会被许多其他类的实例引用，实例极少或者从来不会被修改。

    不适合存放到第二级缓存的数据：

    1. 经常被修改的数据。

    2. 财务数据，绝对不允许出现并发。

    3. 与其他应用共享的数据。

    Hibernate如何将数据库中的数据放入到二级缓存中？注意，你可以把缓存看做是一个Map对象，它的Key用于存储对象OID，Value用于存储POJO。首先，当我们使用Hibernate从数据库中查询出数据，获取检索的数据后，Hibernate将检索出来的对象的OID放入缓存中key中，然后将具体的POJO放入value中，等待下一次再次向数据查询数据时，Hibernate根据你提供的OID先检索一级缓存，若没有且配置了二级缓存，则检索二级缓存，如果还没有则才向数据库发送SQL语句，然后将查询出来的对象放入缓存中。

    为Hibernate配置二级缓存：

    在主配置文件中hibernate.cfg.xml

    1. <property name="hibernate.cache.use_second_level_cache">true</property> 
    2. <property name="hibernate.cache.provider_class">org.hibernate.cache.EhCacheProvider</property> 

    配置ehcache.xml

    1. <?xml version="1.0" encoding="UTF-8"?> 
    2. <ehcache> 
    3.     <!--  
    4.         缓存到硬盘的路径  
    5.     --> 
    6.     <diskStore path="d:/ehcache"></diskStore> 
    7.       
    8.     <!--  
    9.         默认设置  
    10.         maxElementsInMemory : 在內存中最大緩存的对象数量。  
    11.         eternal : 缓存的对象是否永远不变。  
    12.         timeToIdleSeconds ：可以操作对象的时间。  
    13.         timeToLiveSeconds ：缓存中对象的生命周期，时间到后查询数据会从数据库中读取。  
    14.         overflowToDisk ：内存满了，是否要缓存到硬盘。  
    15.     --> 
    16.     <defaultCache maxElementsInMemory="200" eternal="false"   
    17.         timeToIdleSeconds="50" timeToLiveSeconds="60" overflowToDisk="true"></defaultCache> 
    18.           
    19.     <!--  
    20.         指定缓存的对象。  
    21.         下面出现的的属性覆盖上面出现的，没出现的继承上面的。  
    22.     --> 
    23.     <cache name="com.suxiaolei.hibernate.pojos.Order" maxElementsInMemory="200" eternal="false"   
    24.         timeToIdleSeconds="50" timeToLiveSeconds="60" overflowToDisk="true"></cache> 
    25.  
    26. </ehcache> 

    在需要被缓存的对象中hbm文件中的<class>标签下添加一个<cache>子标签

    1. <hibernate-mapping> 
    2.     <class name="com.suxiaolei.hibernate.pojos.Order" table="orders"> 
    3.         <cache usage="read-only"/> 
    4.           
    5.         <id name="id" type="string"> 
    6.             <column name="id"></column> 
    7.             <generator class="uuid"></generator> 
    8.         </id> 
    9.           
    10.         <property name="orderNumber" column="orderNumber" type="string"></property> 
    11.         <property name="cost" column="cost" type="integer"></property> 
    12.           
    13.         <many-to-one name="customer" class="com.suxiaolei.hibernate.pojos.Customer"   
    14.                      column="customer_id" cascade="save-update"> 
    15.         </many-to-one>          
    16.     </class> 
    17. </hibernate-mapping> 

    若存在一对多的关系，想要在在获取一方的时候将关联的多方缓存起来，需要再集合属性下添加<cache>子标签，这里需要将关联的对象的hbm文件中必须在存在<class>标签下也添加<cache>标签，不然Hibernate只会缓存OID。

      1. <hibernate-mapping> 
      2.         <class name="com.suxiaolei.hibernate.pojos.Customer" table="customer"> 
      3.             <!-- 主键设置 --> 
      4.             <id name="id" type="string"> 
      5.                 <column name="id"></column> 
      6.                 <generator class="uuid"></generator> 
      7.             </id> 
      8.               
      9.             <!-- 属性设置 --> 
      10.             <property name="username" column="username" type="string"></property> 
      11.             <property name="balance" column="balance" type="integer"></property> 
      12.               
      13.             <set name="orders" inverse="true" cascade="all" lazy="false" fetch="join"> 
      14.                 <cache usage="read-only"/> 
      15.                 <key column="customer_id" ></key> 
      16.                 <one-to-many class="com.suxiaolei.hibernate.pojos.Order"/> 
      17.             </set> 
      18.               
      19.         </class> 
      20.     </hibernate-mapping> 
  • 相关阅读:
    mysql中事务隔离级别可重复读说明
    Zookeeper安装与启动
    PHP闭包之bind和bindTo
    使用WebPack打包
    用Python下载momentum中的精美壁纸
    supervisor使用
    Shell脚本：RedisKey批量删除
    使用Certbot配置站点的https
    PHPfmt代码格式化
    创建用私钥签名的证书
  • 原文地址：https://www.cnblogs.com/zhangxiaopeng/p/4979696.html
Copyright © 2011-2022 走看看