Hibernate的悲观锁和乐观锁

原文：https://www.w3cschool.cn/hibernate_articles/6qzu1ioy.html

悲观锁

悲观锁（ Pessimistic Locking ），正如其名，它指的是对数据被外界（包括本系统当前的其他事务，以及来自外部系统的事务处理）修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制（也只有数据库层提供的锁机制才能真正保证数据访问的排他性，否则，即使在本系统中实现了加锁机制，也无法保证外部系统不会修改数据）。

• 一个典型的依赖数据库的悲观锁调用：

select * from account where name=”Erica” for update

解释：这条 sql 语句锁定了 account 表中所有符合检索条件（name=”Erica”）的记录。本次事务提交之前（事务提交时会释放事务过程中的锁），外界无法修改这些记录。Hibernate 的悲观锁，也是基于数据库的锁机制实现。

• 代码实现了对查询记录的加锁：

String hqlStr ="from TUser as user where user.name='Erica'";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE); // 加锁
List userList = query.list();// 执行查询，获取数据

解释：query.setLockMode对查询语句中，特定别名所对应的记录进行加锁（我们为TUser 类指定了一个别名 “user” ），这里也就是对返回的所有 user 记录进行加锁。

• Hibernate 的加锁模式有：

LockMode.NONE ： 无锁机制。
LockMode.WRITE ： Hibernate 在 Insert 和 Update 记录的时候会自动获取。
LockMode.READ ： Hibernate 在读取记录的时候会自动获取。
以上这三种锁机制一般由 Hibernate 内部使用，如 Hibernate 为了保证 Update过程中对象不会被外界修改，会在 save 方法实现中自动为目标对象加上 WRITE 锁。
LockMode.UPGRADE ：利用数据库的 for update 子句加锁。
LockMode. UPGRADE_NOWAIT ： Oracle 的特定实现，利用 Oracle 的 for update nowait 子句实现加锁。

注意：只有在查询开始之前（也就是 Hiberate 生成 SQL 之前）设定加锁，才会真正通过数据库的锁机制进行加锁处理，否则，数据已经通过不包含 for update 子句的 Select SQL 加载进来，所谓数据库加锁也就无从谈起。

 

乐观锁

相对悲观锁而言，乐观锁（ Optimistic Locking ）机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销，特别是对长事务而言，这样的开销往往无法承受。

实现方式：即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时，将此版本号一同读出，之后更新时，对此版本号加一。此时，将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。

（1）首先为 TUser 的 class 描述符添加 optimistic-lock 属性：

<hibernate-mapping>
<class name="org.hibernate.sample.TUser" table="t_user" dynamic-update="true"
dynamic-insert="true" optimistic-lock="version">
……
</class>
</hibernate-mapping>

• optimistic-lock 属性有如下可选取值：

none：无乐观锁
version：通过版本机制实现乐观锁
dirty：通过检查发生变动过的属性实现乐观锁
all：通过检查所有属性实现乐观锁

其中通过 version 实现的乐观锁机制是 Hibernate 官方推荐的乐观锁实现，同时也是 Hibernate 中，目前唯一在数据对象脱离 Session 发生修改的情况下依然有效的锁机制。因此，一般情况下，我们都选择 version 方式作为 Hibernate 乐观锁实现机制。

（2）添加一个 Version 属性描述符

<hibernate-mapping>
<class name="org.hibernate.sample.TUser" table="t_user" dynamic-update="true" dynamic-insert="true"
optimistic-lock="version">
<id name="id" column="id" type="java.lang.Integer">
<generator class="native">
</generator>
</id>
<version column="version" name="version" type="java.lang.Integer"/>
……
</class>
</hibernate-mapping>

注意：version 节点必须出现在 ID 节点之后。这里我们声明了一个 version 属性，用于存放用户的版本信息，保存在 TUser 表的version 字段中。

• 测试1：

Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
List userList = criteria.list();
TUser user =(TUser)userList.get(0);
Transaction tx = session.beginTransaction();
user.setUserType(1); // 更新 UserType 字段
tx.commit();

可以发现，每次对 TUser 进行更新的时候，数据库中的 version 都在递增。

• 测试2：

Session session= getSession();
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
Session session2 = getSession();
Criteria criteria2 = session2.createCriteria(TUser.class);
criteria2.add(Expression.eq("name","Erica"));
List userList = criteria.list();
List userList2 = criteria2.list();TUser user =(TUser)userList.get(0);
TUser user2 =(TUser)userList2.get(0);
Transaction tx = session.beginTransaction();
Transaction tx2 = session2.beginTransaction();
user2.setUserType(99);
tx2.commit();
user.setUserType(1);
tx.commit();

解释：在 tx.commit 之前，启动另外一个 Session ，对名为 Erica 的用户进行操作，以模拟并发更新时的情形。

执行以上代码，代码将在 tx.commit() 处抛出 StaleObjectStateException 异常，并指出版本检查失败，当前事务正在试图提交一个过期数据。通过捕捉这个异常，我们就可以在乐观锁校验失败时进行相应处理。

 

总结：

悲观锁和乐观锁都各有优缺点，推荐读取频繁使用乐观锁，写入频繁使用悲观锁。