文档章节

悲观锁,乐观锁

恋空御月
 恋空御月
发布于 2017/07/25 17:06
字数 2931
阅读 11
收藏 0

悲观锁(Pessimistic Lock), 顾名思义,就是很悲观,每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。

 

乐观锁(Optimistic Lock), 顾名思义,就是很乐观,每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,像数据库如果提供类似于write_condition机制的其实都是提供的乐观锁

 

两种锁各有优缺点,不可认为一种好于另一种,像乐观锁适用于写比较少的情况下,即冲突真的很少发生的时候,这样可以省去了锁的开销,加大了系统的整个吞吐量。但如果经常产生冲突,上层应用会不断的进行retry,这样反倒是降低了性能,所以这种情况下用悲观锁就比较合适。

 

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

数据库事务隔离级别:

1        未提交读(read uncommitted)

2        提交读(read committed)

3        重复读(repeatable read)

4        序列化(serializable)

锁机制:

   共享锁:其他事务可以读,但不能修改。

   排他锁:其他事务不能读取。

锁粒度 (lock granularity):一般分为:行锁、表锁、库锁

解释:

 1 未提交读(read uncommitted)

         一个更新数据库的事务A在未commit的情况下,另一个事务B正在读取事务A更新的记录,会产生脏读现象,这是因为A事务在开启 DB Transaction后,做一些DML操作时,记录会保存在内存中,这时B事务读取了A事务提交在内存中的数据,产生了脏读。

2 提交读(read committed)

        数据的修改只有在commit之后,才回被读取。和1 相反。

3 重复读(repeatable read)

      当数据库隔离级别设置成 repeatable read后,事务A中的select 的过程中事务B可以修改A读取部分的数据,当A第2次执行同样的sql时,返回和上次相同的数据 ,消除不可重复读。

    注:个人认为只是应为A事务采用这种隔离级别后,读取的是数据库在事务开始时间点的映象,在这个时间点后的所有操作都不会对A事务中的查询产生影响,依据是本文后续的实验,如果有疑问,请指出。

4 序列化(serializable)

      当数据库隔离级别设置成Serializeable后,事务A中的select 会以共享锁锁定相关的数据(在select 返回的数据结果集),这些数据不可以被修改(可以被读取),若事务B对这些数据做UPDATE操作,会处于等待状态,消除幻读。

     注:事务B可以UPDATE 事务A中为锁定的数据,后面的实验可以证明。

 

 

2、乐观锁( Optimistic Locking ) 相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库 性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。 而乐观锁机制在一定程度上解决了这个问题。乐观锁,大多是基于数据版本( Version )记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。此时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如 果提交的数据版本号大于数据库表当前版本号,则予以更新,否则认为是过期数据。

 

 

hibernate 乐观锁与悲观锁使用

 原文地址 :http://www.blogjava.net/baoyaer/articles/203445.html

Hibernate支持两种锁机制: 
即通常所说的“悲观锁(Pessimistic Locking)”和 “乐观锁(OptimisticLocking)”。 

悲观锁的实现,往往依靠数据库提供的锁机制(也只有数据库层提供的锁机制才能真正保证数据访问的排他性,否则,即使在本系统中实现了加锁机制,也无法保证外部系统不会修改数据)。 

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子句实现加锁。 

 Hibernate的悲观锁,也是基于数据库的锁机制实现。 下面的代码实现了对查询记录的加锁:

1  String hqlStr  =   " from TUser as user where user.name=’Erica’ " ; 
2 Query query  =  session.createQuery(hqlStr); 
3 query.setLockMode( " user " ,LockMode.UPGRADE);  // 加锁  
4  List userList  =  query.list(); // 执行查询,

获取数据 query.setLockMode 对查询语句中特定别名所对应的记录进行加锁(我们为 TUser类指定了一个别名“user”),这里也就是对返回的所有user记录进行加锁。 观察运行期Hibernate生成的SQL语句: 

1  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子句实现了悲观锁机制。 

上面这两种锁机制是我们在应用层较为常用的,加锁一般通过以下方法实现: 
Criteria.setLockMode 
Query.setLockMode 
Session.lock 
注意,只有在查询开始之前(也就是Hiberate 生成SQL 之前)设定加锁,才会 真正通过数据库的锁机制进行加锁处理,否则,数据已经通过不包含for update 子句的Select SQL加载进来,所谓数据库加锁也就无从谈起。






乐观锁,大多是基于数据版本(Version)记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于 数据库表的版本解决方案中,一般是通过为数据库表增加一个“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 >  

 

 添加一个Version属性描述符 
代码内容

 1  < hibernate - mapping >   
 2  < class   
 3 name = " org.hibernate.sample.TUser "   
 4 table = " t_user "   
 5 dynamic - update = " true "   
 6 dynamic - insert = " true "   
 7 optimistic - lock = " version "   
 8  >   
 9  < id  
10 name = " id "   
11 column = " id "   
12 type = " java.lang.Integer "   
13  >   
14  < generator  class = " native " >   
15  </ generator >   
16  </ id >   
17  < version  
18 column = " version "   
19 name = " version "   
20 type = " java.lang.Integer "   
21  />   
22 ……  
23  </ class >   
24  </ hibernate - mapping >   
25 


 

 

注意version 节点必须出现在ID 节点之后。
 这里我们声明了一个version属性,用于存放用户的版本信息,保存在TUser表的 version字段中。 此时如果我们尝试编写一段代码,更新TUser表中记录数据,如: 
代码内容

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

 

每次对TUser进行更新的时候,我们可以发现,数据库中的version都在递增。 而如果我们尝试在tx.commit 之前,启动另外一个Session,对名为Erica 的用 户进行操作,以模拟并发更新时的情形: 
代码内容

 1  Session session =  getSession();  
 2 Criteria criteria  =  session.createCriteria(TUser. class );  
 3 criteria.add(Expression.eq( " name " , " Erica " ));  
 4 Session session2  =  getSession();  
 5 Criteria criteria2  =  session2.createCriteria(TUser. class );  
 6 criteria2.add(Expression.eq( " name " , " Erica " ));  
 7 List userList  =  criteria.list();  
 8 List userList2  =  criteria2.list();TUser user  = (TUser)userList.get( 0 );  
 9 TUser user2  = (TUser)userList2.get( 0 );  
10 Transaction tx  =  session.beginTransaction();  
11 Transaction tx2  =  session2.beginTransaction();  
12 user2.setUserType( 99 );  
13 tx2.commit();  
14 user.setUserType( 1 );  
15 tx.commit();  
16 

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




悲观锁与乐观锁的比较: 
悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受; 
相对悲观锁而言,乐观锁机制采取了更加宽松的加锁机制。乐观锁机制往往基于系统中的数据存储逻辑,因此也具备一定的局限性,如在上例中,由于乐观锁机制是在我们的系统中实现,来自外部系统的更新操作不受我们系统的控制,因此可能会造成脏数据被更新到数据库中。在 
系统设计阶段,我们应该充分考虑到这些情况出现的可能性,并进行相应调整(如将乐观锁策略在数据库存储过程中实现,对外只开放基于此存储过程的数据更新途径,而不是将数据库表直接对外公开)。 
Hibernate 在其数据访问引擎中内置了乐观锁实现。如果不用考虑外部系统对数据库的更新操作,利用Hibernate提供的透明化乐观锁实现,将大大提升我们的生产力。 
Hibernate中可以通过class描述符的optimistic-lock属性结合version描述符指定。 
optimistic-lock属性有如下可选取值: 
Ø none 
无乐观锁 
Ø version 
通过版本机制实现乐观锁 
Ø dirty 
通过检查发生变动过的属性实现乐观锁 
Ø all 
通过检查所有属性实现乐观锁 
其 中通过version实现的乐观锁机制是Hibernate官方推荐的乐观锁实现,同时也是Hibernate中,目前唯一在数据对象脱离Session 发生修改的情况下依然有效的锁机制。因此,一般情况下,我们都选择version方式作为Hibernate乐观锁实现机制。

© 著作权归作者所有

恋空御月
粉丝 8
博文 137
码字总数 91979
作品 0
浦东
程序员
私信 提问
StampedLock悲观锁乐观锁

StampedLock java1.8提供的, 性能比ReadWriteLock好. 语法 StampedLock提供的乐观读,是允许一个线程获取写锁的,也就是说不是所有的写操作都是被阻塞的。 乐观读和乐观锁是不一样的,乐观读...

刘一草
09/24
18
0
.NET:处理数据库事务中的并发

转载链接:http://c.jinhusns.com/u/%E7%94%9F%E6%B4%BB/b-183 概述 几乎所有的企业应用程序都有多个用户和后台线程,它们可以同时更新数据库。两个数据库处理事务同时访问同一份数据的情形很...

whp610
2013/09/02
6
0
.NET:处理数据库事务中的并发

原帖地址:http://c.jinhusns.com/u/%E7%94%9F%E6%B4%BB/b-183 概述 几乎所有的企业应用程序都有多个用户和后台线程,它们可以同时更新数据库。两个数据库处理事务同时访问同一份数据的情形很...

whp610
2013/09/02
525
0
MySQL数据库的锁机制

在并发访问情况下,很有可能出现不可重复读等等读现象。为了更好的应对高并发,封锁、时间戳、乐观并发控制(乐观锁)、悲观并发控制(悲观锁)都是并发控制采用的主要技术方式。 锁分类 ①、按操...

Javahih
2018/01/02
0
0
深入理解乐观锁与悲观锁

在数据库的锁机制中介绍过,数据库管理系统(DBMS)中的并发控制的任务是确保在多个事务同时存取数据库中同一数据时不破坏事务的隔离性和统一性以及数据库的统一性。 乐观并发控制(乐观锁)和...

Hosee
2016/06/01
491
0

没有更多内容

加载失败,请刷新页面

加载更多

视频如何加水印?

很多视频制作者的视频都被他人盗用过,为了防止自己的劳动成果被他人窃取,给视频加水印对于视频制作者来说,是一件非常重要的事情。那么下面分享一个手机给视频加水印的方法,一起来看看吧!...

白米稀饭2019
18分钟前
3
0
004-Envelop-基于Blockstack的文件传输dapp

本篇文章主要介绍基于Blockstack的文件传输工具; ####A-链接地址 官网地址:https://envelop.app/ Github地址:https://github.com/envelop-app ####B-特性: 1: Share private files easil...

Riverzhou
21分钟前
5
0
SpringCloud——声明式调用Feign

Feign声明式调用 一、Feign简介 使用Ribbon和RestTemplate消费服务的时候,有一个最麻烦的点在于,每次都要拼接URL,组织参数,所以有了Feign声明式调用,Feign的首要目标是将Java HTTP客户端...

devils_os
27分钟前
5
0
《JAVA核心知识》学习笔记 (22. 数据结构)

22.1.1. 栈(stack) 栈( stack)是限制插入和删除只能在一个位置上进行的表,该位置是表的末端,叫做栈顶 (top)。它是后进先出(LIFO)的。对栈的基本操作只有 push(进栈)和 pop(出栈...

Shingfi
32分钟前
5
0
你对AJAX认知有多少(1)?

AJAX(一) AJAX技术对于前段或者后端工程师来说,都是必不可缺的 那我们这几期都来细细品味一下AJAX的相关知识,直接上干货喽~ 1、什么是AJAX,为什么要使用Ajax(请谈一下你对Ajax的认识) 什么...

理性思考
40分钟前
12
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部