性能优化

  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中设定:

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

    2.@Cache 注解 (由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.乐观锁比较乐观,不着急加锁,而是先判断是否出现了并发访问的情况,如果出现了,再做相应的处理

          

05-08 08:10