章节索引 :

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);

悲观锁在实际生产环境中使用频率并不高,限制了并发的发生率,降低了程序的响应速度。

编写一个简单的测试实例:

  1. 第一个事务,查询加锁,使用 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
  1. 第二个事务,进行查询、更新操作,此事务并不能马上更新成功,只有等待第一个事务结束后才能成功。
 stu = (Student) session.get(Student.class, new Integer(1));
 System.out.println("-------------更新-------------");
 stu.setStuName("Hibernate 01");
 transaction.commit();
 System.out.println("--------------更新成功-----------");

悲观锁的实现很简单,也很好理解,无非就是我用时你不能用的问题。

4. 乐观锁

乐观是一种积极的解决问题的态度。

所谓乐观锁认为系统中的事务并发更新不会很频繁,即使冲突了也没事,大不了重新再来一次。

  1. 基本思想:

每次提交一个事务更新时,查看要修改的数据从上次读取以后有没有被其它事务修改过,如果修改过,那么更新就会失败。

  1. 实现方案:

在实体中增加一个版本控制字段,每次事务更新后就将版本 (Version) 字段的值加 1。

Tips: 乐观锁本质就是版本控制管理的实现,记录的每一次更新操作都会以版本递增的方式进行记录。

一个事务在更新之前,先获取记录的当前版本号,更新时,如果版本还是最新的则可以更新,否则说明有事务比你先更新,则需要放弃。或者重新查询到最新版本信息后再更新。

所以,在乐观锁的实现中,冲突是常态。

  1. 实现过程:

在学生实体类中添加新属性,用来记录每次更新的版本号。

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 的其它性能优化:

  1. 随时使用 Session.clear()及时清除 Session 缓存区的内容;

  2. 1+N 问题 ( 一条 SQL 语句能解决的问题用了很多条 SQL 语句来实现) ;

    • 使用 Criteria 查询可以解决这个问题;

    • Lazy 加载:需要时,使用 get() 方法发出 SQL 语句。

    • 使用类似于 from Student s left join s.classRoom c 的关联查询语句。

  3. 缓存使用:在对象更新、删除、添加相对于查询要少得多时, 二级缓存的应用将不怕 n+1 问题,因为即使第一次查询很慢,之后直接缓存命中也是很快的,刚好又利用了 n+1。

5. 小结

性能优化显然是一个不轻松、但又绝对不能忽视的话题。本节课程和大家讲解了在 Hibernate 是如何处理事务隔离的,在隔离机制的基础上,结合乐观锁或悲观锁更好地解决这个问题。

希望我们以乐观的态度看待我们的生活、学习以及未来!