8.Hibernate性能优化

Posted 2020-10-03 白日梦想家12138

性能优化

　　1.注意session.clear() 的运用，尤其在不断分页的时候

　　　　a) 在一个大集合中进行遍历，遍历msg，取出其中额含有敏感字样的对象

　　　　b) 另外一种形式的内存泄漏（ //面试题：Java有内存泄漏吗？语法级别没有，但是可由java引起，例如：连接池不关闭，或io读取后不关闭）

　　2.1+N 问题（典型的面试题）

　　　　举例：当存在多对一关系时，多的一方默认是可以取出一的一方的

　　　　　　@ManyToOne 中 默认为fetch=FetchType.Eager

　　　　　　当load多的一方时，也会加载一的哪一方，会造成执行不必要的SQL语句

　　　　解决办法，以下几种：

　　　　　　a) @ManyToOne(fetch=FetchType.LAZY) 

　　　　　　//当多对一(@ManyToOne)已经设定属性" fetch=FetchType.LAZY "时 

　　　　　　//只有当需要时(如:t.getCategory().getName()时)才会去获取关联表中数据 可以解决N+1问题

　　　　　　b) @BatchSize

　　　　　　//在与查询表(此例中为Topic类)关联的表类(此例中为Category类)头处加@BatchSize(size=5)

　　　　　　//表示每次可查出5条记录 从而减少了select语句的个数　

　　　　　　c) join fetch　　

　　　　　　//修改hql语句为--"  from Topic t left join fetch t.category c　

　　　　　　d) QBC

　　　　　　//原理和上面那条是一样的，使用QBC的 createCriteria(*.class)执行查询 也可避免N+1问题

　　

　　3.list 和 iterate 不同之处（ //主要为了面试）

　　　　a) list 取出表中所有数据构成对象

　　　　b) iterate 先取ID，等用到的时候再根据ID 来取对象

　　　　c) session 中list 第二次发出，仍回到数据库查询

　　　　d）iterate 第二次，会先去找 session 缓存

 

Hibernate 缓存机制

前面Hibernate中持久化对象的三种状态有提到，处于Persistent状态的对象的标志是 缓存中也有这个对象

缓存中类似于一个一个的键值对，key 为 id，然后value为这个缓存的对象

当想要对该对象进行读写时，会先去查缓存，

/*一级缓存和二级缓存和查询缓存*/

　　一级缓存：session级的缓存，每个session拥有自己的session缓存，不同session的session缓存不能共享

　　二级缓存：sessionFactory级的缓存，所有的session都可以去访问二级缓存

　　查询缓存：相同的SQL语句只执行一次

　　当缓存的对象  1.经常被访问  2.不会经常改动  3.数量不大  时使用二级缓存

　　打开二级缓存（两步）：

　　　　1.在 hibernate.cfg.xml中设定：

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

　　　　[email protected] 注解 （由hibernate扩展提供）

　　　　 @Cache (usage=CacheConcurrencyStrategy.READ_WRITE)  

　　　　（为某个类开启二级缓存，针对该类的对象进行的 读写操作，会创建二级缓存）

　　　　注：使用EhCache 二级缓存需要导入 ehcache-1.2.3.jar 及 commons-logging-1.0.4.jar 包   

　注：　

　　1.load 默认使用二级缓存，iterate 默认使用二级缓存

　　2.list 默认往二级缓存加数据，但是查询的时候不使用

　　意思是：session.createQuery("from Category").list();  会将查出来的数据加到缓存中，但是不会去缓存中查询

　　3.可以使用<property name="hibernate.cache.use_query_cache">true</property>来打开查询缓存，默认为关闭，

　　查询缓存来标识某个查询使用缓存，当执行同一条SQL语句时，就不会再去数据库找，也是从缓存中去找该语句 

　　在打开了查询缓存之后，需要注意，调用query.list()操作之前，必须显示调用query.setCacheable(true)

　　例如：session.createQuery("from Category").setCacheable(true).list();

　　注：查询缓存只对query.list()起作用，query.iterate不起作用，也就是query.iterate不使用

　　

　　4.缓存算法（新的缓存对象要进来，怎么替换）：（面试）

　　LRU LFU FIFO

　　1.Least Recently Used  最近最少使用的被替换

　　2.Least Frequently Used  命中率高低  使用频率最低的被替换

　　3.First In First Out  按顺序替换

　　在ehcache.xml中配置   memoryStoreEvictionPolicy="LRU"

 

事务并发处理

a) 事务：ACID
　　Atomic Consistency Itegrity Durability

b) 事务并发时可能出现的问题：

　　1.脏读  (读到了另一个事务在处理中还未提交的数据)

　　2.不可重复读 (在事务A的执行过程中，事务B进行了开启，对列中的数据进行修改和提交，

　　导致事务A在事务B执行前读取的数据和事务B执行后读取的数据不一致)

　　3.虚读 (在查询某一条件的数据时，开始查询后，别人又加入或删除某些数据，再读取时与原来的数据不一样了，

　　和 不可重复读 类似，不过不可重复读针对的列里面数据的修改，而幻读针对的是列整体的增删)

c) 数据库事务的隔离级别

　　1------read-uncommitted

　　2------read-committed

　　4------repeatable read 

　　8------serializable

　　前面的数字为Hibernate的事务隔离级别对应的数字

　　为什么要使用1 2 4 8 而不是 1 2 3 4

　　1=0000  2=0010  4=0100  8=1000  位运算效率高

　　

　　read-uncommitted(允许读取未提交的数据) 会出现dirty read, phantom-read, non-repeatable read 问题

　　read-commited(读取已提交的数据 项目中一般都使用这个)不会出现dirty read,

　　因为只有另一个事务提交才会读出来结果，但仍然会出现 non-repeatable read 和 phantom-read

　　/*使用read-commited机制可用悲观锁 乐观锁来解决non-repeatable read 和 phantom-read问题*/

　　repeatable read(事务执行中其他事务无法执行修改或插入操作     较安全)

　　serializable  解决一切问题(顺序执行事务 不并发，实际中很少用)

 

　　如何设定Hibernate 的事务隔离级别（使用hibernate.connection.isolation配置 取值1、2、4、8）

　　　　1.hibernate.connection.isolation = 2 （如果不设 默认依赖数据库本身的级别）

　　　　2.用悲观锁解决repeatable read的问题（依赖于数据库的锁（select... for update））

　　　　hibernate使用Load进行悲观锁加锁    session.load(Inventory.class, 1, LockMode.UPGRADE);   在生成select语句时，会加上for update 进行使用悲观锁

　　　　　　a)LockMode.None   无锁的机制，Transaction结束时，切换到此模式

　　　　　　b)LockMode.read   在査询的时候hibernate会自动获取锁

　　　　　　c)LockMode.write  insert  update hibernate 会自动获取锁

　　　　　　d)以上3种锁的模式，是hibernate内部使用的(不需要设)

　　　　　　e)LockMode.UPGRADE_NOWAIT   是 ORACLE 支持的锁的方式

 

　　3.乐观锁（其实不是锁，是一种冲突检测机制）

　　实体类中增加version属性 （数据库也会对应生成该字段初始值为0），并在其get方法前加入 @Version 注解

　　则在操作的过程中每更新一次该行数据则version值 加 1，即可在事务提交前判断该数据是否被其他事务修改过

　　（提交事务时，通过对比内存中的version值和数据库中的version值）

 

　　注：乐观和悲观的区别：

　　1.悲观锁比较悲观，觉得会有并发的情况发生，所以提前加了一把锁，

　　2.乐观锁比较乐观，不着急加锁，而是先判断是否出现了并发访问的情况，如果出现了，再做相应的处理