Hibernate 性能之隔离机制
1. 前言
事务有 4 大特性,其隔离性尤其重要,没有良好的隔离性就相当于你可以随意出入邻居家。不能保证数据的完整性。
每一种隔离机制都有自己使用的真实场景。
本节课探讨一下 Hibernate 中是如何进行隔离设置的。通过本节课程的学习,你将了解到:
- Hibernate 中如何设置隔离级别;
- 悲观锁和乐观锁的比较。
2. Hibernate 中的隔离机制
如前面课程所述,隔离机制能保证事务之间的良好秩序,但是,太严格的隔离机制会让事务之间产生时间上的等待或延迟,也就是说并发性弱。
太松散的隔离机制,虽然可以增加并发性,但可能会产生事务之间的数据脏读等一系列不希望出现的事情。
有时,纯粹地依靠 JDBC 提供的 4 种隔离机制很难做到隔离的优雅性,所以,一般采用 读取已提交 或者 更低的事务隔离级别,再配合各种并发访问控制策略来达到并发事务控制的目的。
Hibernate 中如何设置隔离机制?
这个问题很简单,你要做的就是在 Hibernate 主配置文件中添加如下信息:
<property name="connection.isolation">2</property>
这里的 2 是什么意思?
是这样的,Hibernate 使用 1 、2 、4 、8 这几个数字分别代表 4 种隔离机制。
- 8 - Serializable 串行化;
- 4 - Repeatable Read 可重复读;
- 2 - Read Commited 可读已提交;
- 1 - Read Uncommited 可读未提交。
使用数字有几个好处,毕竟不用记那么一长串字符串,最主要的是,这几个数字可以换算成 二进制中的 0001、0010、0100、1000。可以直接通过二进制位运算的方式进行权限控制。
设置就是这么简单,但是,这还不够。
刚说过, 最好再配合并发控制策略。
那么, Hibernate 提供了怎样的 策略,告诉你,有 2 种 “锁” 机制:
- 乐观锁;
- 悲观锁。
你是喜欢先苦后甜还是先甜后苦了,我喜欢先苦后甜。好吧,先讲解什么是悲观锁。
3. 悲观锁 Pessimistic Locking
悲观地认为并发的事务时时会发生,总是担心隔离机制不能很好的保证事务之间的安全性。
- 基本思想就是当一个事务读取某一条记录后,就会把这条记录锁住,如果其它的事务要想更新,必须等以前的事务提交或者回滚解除锁;
- 悲观锁的实现,一般依靠数据库提供的锁机制。
只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在系统中实现了加锁机制,也无法保证外部系统不会修改数据。
SQL 的 select 语句中有一个 for 语法关键字:
SELECT * from student where stuName='Hibernate' for UPDATE
其作用就是锁定这条记录,当前事务没有结束之前,其它的事务不能在这条记录上进行数据更新操作。
Hiberntae 实现悲观锁
前面我们使用过 Session 的 get()方法,大家还记得是怎么用的吗?
stu = (Student) session.get(Student.class, new Integer(1));
其实这个方法还可以传递第三个参数,好吧,先看一下方法的原型:
public Object get(Class clazz, Serializable id, LockOptions lockOptions);
LockOptions 类本质是对 LockMode 枚举类型的高级封装,提供了几种锁的使用:
- 无锁的机制,Transaction 结束时,切换到此模式;
hibernate 内部使用。
public static final LockOptions NONE = new LockOptions(LockMode.NONE);
- 查询的时候,Hibernate 自动获取锁;
hibernate 内部使用。
public static final LockOptions READ = new LockOptions(LockMode.READ);
- 利用数据库的 for update 子句加锁(Select * from 表 for update),通过此选项实现悲观锁。
public static final LockOptions UPGRADE = new LockOptions(LockMode.UPGRADE);
悲观锁在实际生产环境中使用频率并不高,限制了并发的发生率,降低了程序的响应速度。
编写一个简单的测试实例:
- 第一个事务,查询加锁,使用 Thread.sleep()模拟事务操作时长;
模拟时间不要太长,如果长时间不释放锁,其它等待事务会抛出等待超时异常。
stu = (Student) session.get(Student.class, new Integer(1), LockOptions.UPGRADE);
Thread.sleep(30000);
transaction.commit();
System.out.println("-----------第一个事务结束-----------");
执行此实例,查看控制台输出信息,查询语句上添加了 for update,在模拟时长内事务没有结束。
Hibernate:
select
student0_.stuId as stuId1_1_0_,
student0_.classRoomId as classRoo5_1_0_,
student0_.stuName as stuName2_1_0_,
student0_.stuPassword as stuPassw3_1_0_,
student0_.stuSex as stuSex4_1_0_
from
Student student0_
where
student0_.stuId=? for update
- 第二个事务,进行查询、更新操作,此事务并不能马上更新成功,只有等待第一个事务结束后才能成功。
stu = (Student) session.get(Student.class, new Integer(1));
System.out.println("-------------更新-------------");
stu.setStuName("Hibernate 01");
transaction.commit();
System.out.println("--------------更新成功-----------");
悲观锁的实现很简单,也很好理解,无非就是我用时你不能用的问题。
4. 乐观锁
乐观是一种积极的解决问题的态度。
所谓乐观锁认为系统中的事务并发更新不会很频繁,即使冲突了也没事,大不了重新再来一次。
- 基本思想:
每次提交一个事务更新时,查看要修改的数据从上次读取以后有没有被其它事务修改过,如果修改过,那么更新就会失败。
- 实现方案:
在实体中增加一个版本控制字段,每次事务更新后就将版本 (Version) 字段的值加 1。
Tips: 乐观锁本质就是版本控制管理的实现,记录的每一次更新操作都会以版本递增的方式进行记录。
一个事务在更新之前,先获取记录的当前版本号,更新时,如果版本还是最新的则可以更新,否则说明有事务比你先更新,则需要放弃。或者重新查询到最新版本信息后再更新。
所以,在乐观锁的实现中,冲突是常态。
- 实现过程:
在学生实体类中添加新属性,用来记录每次更新的版本号。
public class Student implements Serializable {
//省略……
@Version
private Long version;
//省略……
}
stu = (Student) session.get(Student.class, new Integer(1));
System.out.println("当前版本号:"+stu.getVersion);
//模拟延迟,如果在这个时间内有其它事务进行了更新操作,此事务的更新不会成功
Thread.sleep(30000);
stu.setStuName("Hibernate");
transaction.commit();
好了,悲观也好,乐观也好,只是一种解决问题的态度。对于这两种态度,咱们要总结一下。
乐观锁:
优势:性能好,并发性高。
缺点:用户体验不好,可能会出现高高兴兴去更新,却告知已经有人捷足先登了。
悲观锁:
优势:锁住记录为我所用,没修改完成之前,其他事务只能瞪眼瞧着,时间虽然延迟,至少心里有底。
缺点:并发性不好,性能不高。
Hibernate 的其它性能优化:
-
随时使用 Session.clear()及时清除 Session 缓存区的内容;
-
1+N 问题 ( 一条 SQL 语句能解决的问题用了很多条 SQL 语句来实现) ;
-
使用 Criteria 查询可以解决这个问题;
-
Lazy 加载:需要时,使用 get() 方法发出 SQL 语句。
-
使用类似于 from Student s left join s.classRoom c 的关联查询语句。
-
-
缓存使用:在对象更新、删除、添加相对于查询要少得多时, 二级缓存的应用将不怕 n+1 问题,因为即使第一次查询很慢,之后直接缓存命中也是很快的,刚好又利用了 n+1。
5. 小结
性能优化显然是一个不轻松、但又绝对不能忽视的话题。本节课程和大家讲解了在 Hibernate 是如何处理事务隔离的,在隔离机制的基础上,结合乐观锁或悲观锁更好地解决这个问题。
希望我们以乐观的态度看待我们的生活、学习以及未来!