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

2. 第二个事务，进行查询、更新操作，此事务并不能马上更新成功，只有等待第一个事务结束后才能成功。

 stu = (Student) session.get(Student.class, new Integer(1));
 System.out.println("-------------更新-------------");
 stu.setStuName("Hibernate 01");
 transaction.commit();
 System.out.println("--------------更新成功-----------");

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

4. 乐观锁

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

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

1. 基本思想：

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

2. 实现方案：

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

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

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

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

3. 实现过程：

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

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 是如何处理事务隔离的，在隔离机制的基础上，结合乐观锁或悲观锁更好地解决这个问题。

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