性能优化
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.乐观锁比较乐观，不着急加锁，而是先判断是否出现了并发访问的情况，如果出现了，再做相应的处理