乐观锁与悲观锁

转载 2011年01月11日 10:46:00

文章转自网上好像是玉米田的,忘记了

锁(
locking
业务逻辑的实现过程中,往往需要保证数据访问的排他性。如在金融系统的日终结算
处理中,我们希望针对某个 cut-off 时间点的数据进行处理,而不希望在结算进行过程中
(可能是几秒种,也可能是几个小时),数据再发生变化。此时,我们就需要通过一些机
制来保证这些数据在某个操作过程中不会被外界修改,这样的机制,在这里,也就是所谓
,即给我们选定的目标数据上锁,使其无法被其他程序修改。
Hibernate
支持两种锁机制:即通常所说的 悲观锁( Pessimistic Locking
乐观锁( Optimistic Locking
悲观锁( 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 生成的 SQL 语句:
select tuser0_.id as id, tuser0_.name as name, tuser0_.group_id
as group_id, tuser0_.user_type as user_type, tuser0_.sex as sex
from t_user tuser0_ where (tuser0_.name='Erica' ) for update
这里 Hibernate 通过使用数据库的 for update 子句实现了悲观锁机制。
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
子句实现加锁。
上面这两种锁机制是我们在应用层较为常用的,加锁一般通过以下方法实现:
Criteria.setLockMode
Query.setLockMode
Session.lock
注意,只有在查询开始之前(也就是 Hiberate 生成 SQL 之前)设定加锁,才会
真正通过数据库的锁机制进行加锁处理,否则,数据已经通过不包含 for update
子句的 Select SQL 加载进来,所谓数据库加锁也就无从谈起。
乐观锁( Optimistic Locking
相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依
靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库
性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。
如一个金融系统,当某个操作员读取用户的数据,并在读出的用户数据的基础上进
行修改时(如更改用户帐户余额),如果采用悲观锁机制,也就意味着整个操作过
程中(从操作员读出数据、开始修改直至提交修改结果的全过程,甚至还包括操作
员中途去煮咖啡的时间),数据库记录始终处于加锁状态,可以想见,如果面对几

百上千个并发,这样的情况将导致怎样的后果。
乐观锁机制在一定程度上解决了这个问题。乐观锁,大多是基于数据版本
Version )记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于
数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来
实现。
读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提
交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据
版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。
对于上面修改用户帐户信息的例子而言,假设数据库中帐户信息表中有一个
version
字段,当前值为 1 ;而当前帐户余额字段( balance )为 $100
1
操作员 A 此时将其读出( version=1 ),并从其帐户余额中扣除 $50
$100-$50 )。
2
在操作员 A 操作的过程中,操作员 B 也读入此用户信息( version=1 ),并
从其帐户余额中扣除 $20 $100-$20 )。
3
操作员 A 完成了修改工作,将数据版本号加一( version=2 ),连同帐户扣
除后余额( balance=$50 ),提交至数据库更新,此时由于提交数据版本大
于数据库记录当前版本,数据被更新,数据库记录 version 更新为 2
4
操作员 B 完成了操作,也将版本号加一( version=2 )试图向数据库提交数
据( balance=$80 ),但此时比对数据库记录版本时发现,操作员 B 提交的
数据版本号为 2 ,数据库记录当前版本也为 2 ,不满足 提交版本必须大于记
录当前版本才能执行更新 的乐观锁策略,因此,操作员 B 的提交被驳回。
这样,就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作
A 的操作结果的可能。
从上面的例子可以看出,乐观锁机制避免了长事务中的数据库加锁开销(操作员 A
和操作员 B 操作过程中,都没有对数据库数据加锁),大大提升了大并发量下的系
统整体性能表现。
需要注意的是,乐观锁机制往往基于系统中的数据存储逻辑,因此也具备一定的局
限性,如在上例中,由于乐观锁机制是在我们的系统中实现,来自外部系统的用户
余额更新操作不受我们系统的控制,因此可能会造成脏数据被更新到数据库中。在
系统设计阶段,我们应该充分考虑到这些情况出现的可能性,并进行相应调整(如
将乐观锁策略在数据库存储过程中实现,对外只开放基于此存储过程的数据更新途
径,而不是将数据库表直接对外公开)。
Hibernate
在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数
据库的更新操作,利用 Hibernate 提供的透明化乐观锁实现,将大大提升我们的
生产力。
Hibernate
中可以通过 class 描述符的 optimistic-lock 属性结合 version
描述符指定。
现在,我们为之前示例中的 TUser 加上乐观锁机制。

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
字段中。
此时如果我们尝试编写一段代码,更新 TUser 表中记录数据,如:
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 都在递增。
而如果我们尝试在 tx.commit 之前,启动另外一个 Session ,对名为 Erica 的用
户进行操作,以模拟并发更新时的情形:
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() 处抛出 StaleObjectStateException
常,并指出版本检查失败,当前事务正在试图提交一个过期数据。通过捕捉这个异常,我
们就可以在乐观锁校验失败时进行相应处理

一分钟教你知道乐观锁和悲观锁的区别

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据...
  • hongchangfirst
  • hongchangfirst
  • 2014年07月08日 14:06
  • 222084

深入理解乐观锁与悲观锁

在数据库的锁机制中介绍过,数据库管理系统(DBMS)中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。乐观并发控制(乐观锁)和悲观并发控制(悲观...
  • zhangwj0101
  • zhangwj0101
  • 2016年03月21日 14:06
  • 5599

悲观锁和乐观锁的区别及应用场景

数据的锁定分为两种,第一种叫作悲观锁,第二种叫作乐观锁。 1、悲观锁,就是对数据的冲突采取一种悲观的态度,也就是说假设数据肯定会冲突,所以在数据开始读取的时候就把数据锁定住。【数据锁定:数据将暂时不...
  • php_younger
  • php_younger
  • 2016年09月23日 09:28
  • 996

线程同步(2)——悲观锁和乐观锁

上一篇博客介绍了什么是线程同步,介绍了synchronized的常用用法,这一篇博客总结一下悲观锁和乐观锁。 悲观锁,它假设只要有数据访问就会产生冲突,当一个线程读取数据时就一定要上锁,其他用户无法操...
  • suneqing
  • suneqing
  • 2015年05月08日 20:53
  • 1613

乐观锁和悲观锁的区别(最全面的分析)

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据...
  • rexct392358928
  • rexct392358928
  • 2016年08月17日 14:49
  • 6407

悲观锁与乐观锁简单介绍

1、悲观锁,正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机...
  • lixiaoxiong55
  • lixiaoxiong55
  • 2016年05月26日 22:04
  • 1032

乐观锁 悲观锁实例

引言 为什么需要锁(并发控制)?   在多用户环境中,在同一时间可能会有多个用户更新相同的记录,这会产生冲突。这就是著名的并发性问题。 典型的冲突有: 丢失更新:一个事务的更新覆盖...
  • cws1214
  • cws1214
  • 2016年09月07日 10:33
  • 1384

乐观锁和悲观锁的实例讲解

悲观锁:正如其名,它指的是对数据被外界(包括本系统当前的其他事务,以及来自外部系统的事务处理)的修改持保守态度,因此,在整个数据处理过程中,将数据处于锁定状态。悲观锁的实现,往往依靠数据库提供的锁机制...
  • u010014162
  • u010014162
  • 2017年03月22日 17:16
  • 434

数据库事务隔离级别与锁 悲观锁 乐观锁

一,事务的4个基本特征  Atomic(原子性):  事务中包含的操作被看做一个逻辑单元,这个逻辑单元中的操作要  么全部成功,要么全部失败。  Consistency(一致性):  ...
  • sunny243788557
  • sunny243788557
  • 2014年06月27日 08:38
  • 1340

mysql隔离级别与悲观锁、乐观锁

1、什么是悲观锁,乐观锁 悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。而乐观锁机制在一定程度...
  • lingzhm
  • lingzhm
  • 2015年04月14日 21:59
  • 4907
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:乐观锁与悲观锁
举报原因:
原因补充:

(最多只允许输入30个字)