悲观锁的实现方式java_并发编程--锁--悲观锁和乐观锁
悲观锁和乐观锁并不是某个具体的“锁”而是一种并发编程的基本概念,是根据看待并发同步的角度。乐观锁和悲观锁最早出现在数据库的设计当中,后来逐渐被 Java 的并发包所引入。
悲观锁
悲观锁认为对于同一个数据的并发操作一定是会发生修改的,采取加锁的形式,悲观地认为,不加锁的并发操作一定会出问题。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁。Java中Synchronized和ReentrantLock等独占锁就是悲观锁思想实现的。
乐观锁
乐观锁正好和悲观锁相反,它获取数据的时候,并不担心数据被修改,每次获取数据的时候也不会加锁,只是在更新数据的时候,通过判断现有的数据是否和原数据一致来判断数据是否被其他线程操作,如果没被其他线程修改则进行数据更新,如果被其他线程修改则不进行数据更新。Lock 是乐观锁的典型实现案例。
典型案例
(1)悲观锁:synchronized 关键字和 Lock 接口相关类
Java 中悲观锁的实现包括 synchronized 关键字和 Lock 相关类等,我们以 Lock 接口为例,例如 Lock 的实现类 ReentrantLock,类中的 lock() 等方法就是执行加锁,而 unlock() 方法是执行解锁。处理资源之前必须要先加锁并拿到锁,等到处理完了之后再解开锁,这就是非常典型的悲观锁思想。
(2)乐观锁:原子类
乐观锁的典型案例就是原子类,例如 AtomicInteger 在更新数据时,就使用了乐观锁的思想,多个线程可以同时操作同一个原子变量。
(3)大喜大悲:数据库
数据库中同时拥有悲观锁和乐观锁的思想。例如,我们如果在 MySQL 选择 select for update 语句,那就是悲观锁,在提交之前不允许第三方来修改该数据,这当然会造成一定的性能损耗,在高并发的情况下是不可取的。相反,我们可以利用一个版本 version 字段在数据库中实现乐观锁。在获取及修改数据时都不需要加锁,但是我们在获取完数据并计算完毕,准备更新数据时,会检查版本号和获取数据时的版本号是否一致,如果一致就直接更新,如果不一致,说明计算期间已经有其他线程修改过这个数据了,那我就可以选择重新获取数据,重新计算,然后再次尝试更新数据。
数据库的悲观锁示例:
select * from account where name="Erica" for update
这条 sql 语句锁定了 account 表中所有符合检索条件( name="Erica" )的记录。本次事务提交之前(事务提交时会释放事务过程中的锁),外界无法修改这些记录.。
数据库的乐观锁示例:
假设取出数据的时候 version 为1
UPDATE student
SET
name=‘小李’,
version= 2WHERE id= 100AND version= 1
CAS介绍
Java中的乐观锁大部分都是通过CAS(CompareAndSwap,比较并交换)操作实现的,CAS是一个多线程同步的原子指令,CAS操作包含三个重要的信息,即内存位置、预期原值和新值。如果内存位置的值和预期的原值相等的话,那么就可以把该位置的值更新为新值,否则不做任何修改。
补充说明: 虽然ReentrantLock也是通过CAS实现的,但是是悲观锁。
缺点:ABA问题.
CAS可能会造成ABA的问题,ABA问题指的是,线程拿到了最初的预期原值A,然而在将要进行CAS的时候,被其他线程抢占了执行权,把此值从A变成了B,然后其他线程又把此值从B变成A,然而此时的 A 值已经并非原来的 A 值了,但最初的线程并不知道这个情况,在它进行 CAS 的时候,就会误认为它从来没有被修改过,只对比了预期原值为 A 就进行了修改,这就造成了 ABA 的问题。
以警匪剧为例,假如某人把装了100W现金的箱子放在了家里,几分钟之后要拿它去赎人,然而在趁他不注意的时候,进来了一个小偷,用空箱子换走了装满钱的箱子,当某人进来之后看到箱子还是一模一样的,他会以为这就是原来的箱子,就拿着它去赎人了,这种情况肯定有问题,因为箱子已经是空的了,这就是 ABA 的问题。
JDK在1.5时提供了AtomicStampedReference类也可以解决ABA的问题,此类维护了一个“版本号”Stamp,每次在比较时不止比较当前值还比较版本号,这样就解决了 ABA 的问题。
综合分析实例:
如一个金融系统,当某个操作员读取用户的数据,并在读出的用户数据的基础上进行修改时(如更改用户帐户余额),如果采用悲观锁机制,也就意味着整个操作过程中(从操作员读出数据、开始修改直至提交修改结果的全过程,甚至还包括操作 员中途去煮咖啡的时间),数据库记录始终处于加锁状态,可见,如果面对几百上千个并发,这样的情况将导致怎样的后果。乐观锁机制在一定程度上解决了这个问题。
乐观锁,大多是基于数据版本( version )记录机制实现。何谓数据版本?即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表增加一个 “version” 字段来实现。读取出数据时,将此版本号一同读出,之后更新时,对此版本号加一。同时,将提交数据的版本数据与数据库表对应记录的当前版本信息进行比对,如果提交的数据版本号等于数据库表当前版本号,则予以更新,否则认为是过期数据。
对于上面修改用户帐户信息的例子而言,假设数据库中帐户信息表中有一个 version 字段,当前值为 1 ;而当前帐户余额字段( balance )为 $100 。
1 操作员 A 此时将其读出( version=1 ),并从其帐户余额中扣除 $50( $100-$50 )。
2 在操作员 A 操作的过程中,操作员B 也读入此用户信息( version=1 ),并从其帐户余额中扣除 $20 ( $100-$20 )。
3 操作员 A 完成了修改工作,将 version=1 的数据连同帐户扣除后余额( balance=$50 ),提交至数据库更新,此时由于提交数据版本等于数据库记录当前版本,数据被更新,同时数据库记录 version 更新为 2(set version=version+1 where version=1) 。
4 操作员 B 完成了数据录入操作,也将 version=1 的数据试图向数据库提交( balance=$80 ),但此时比对数据库记录版本时发现,操作员 B 提交的数据版本号为 1 ,数据库记录当前版本也为 2 ,不满足 “ 提交版本必须等于记录当前版本才能执行更新 “ 的乐观锁策略,因此,操作员 B 的提交被驳回。
这样,就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。
悲观锁乐观锁优缺点:
优点:
悲观锁大多数情况下依靠数据库的锁机制实现,以保证操作最大程度的独占性。但随之而来的就是数据库性能的大量开销,特别是对长事务而言,这样的开销往往无法承受。而乐观锁机制避免了长事务中的数据库加锁开销,大大提升了大并发量下的系统整体性能表现。
缺点:
需要注意的是,乐观锁机制往往基于系统中的数据存储逻辑,因此也具备一定的局限性,如在上例中,由于乐观锁机制是在我们的系统中实现,来自外部系统的用户余额更新操作不受我们系统的控制,因此可能会造成脏数据被更新到数据库中。在系统设计阶段,我们应该充分考虑到这些情况出现的可能性,并进行相应调整(如将乐观锁策略在数据库存储过程中实现,对外只开放基于此存储过程的数据更新途径,而不是将数据库表直接对外公开)。
使用场景
有一种说法认为,悲观锁由于它的操作比较重量级,不能多个线程并行执行,而且还会有上下文切换等动作,所以悲观锁的性能不如乐观锁好,应该尽量避免用悲观锁,这种说法是不正确的。因为虽然悲观锁确实会让得不到锁的线程阻塞,但是这种开销是固定的。悲观锁的原始开销确实要高于乐观锁,但是特点是一劳永逸,就算一直拿不到锁,也不会对开销造成额外的影响。反观乐观锁虽然一开始的开销比悲观锁小,但是如果一直拿不到锁,或者并发量大,竞争激烈,导致不停重试,那么消耗的资源也会越来越多,甚至开销会超过悲观锁。所以,同样是悲观锁,在不同的场景下,效果可能完全不同。
(1) 悲观锁适合用于并发写入多、临界区代码复杂、竞争激烈等场景,这种场景下悲观锁可以避免大量的无用的反复尝试等消耗。
(2) 乐观锁适用于大部分是读取,少部分是修改的场景,也适合虽然读写都很多,但是并发并不激烈的场景。在这些场景下,乐观锁不加锁的特点能让性能大幅提高。
参考好文:
百度百科 --悲观锁
百度百科 --乐观锁
拉钩 -- java面试真题及源码
面试必备之悲观锁与乐观锁 --
https://blog.51cto.com/14230003/2385473
http://www.matools.com/blog/190417157
悲观锁的实现方式java_并发编程--锁--悲观锁和乐观锁相关推荐
- JAVA并发编程:悲观锁与乐观锁
生活 晴. 悲观与乐观的情绪概念 本篇来了解一下悲观锁和乐观锁,在了解这两个锁之前,我们首先有必要把悲观和乐观这两个词搞清楚: 悲观:对世事怀有消极的看法,认为事物总往糟糕的方向发展. 乐观:对世事怀 ...
- 读Java并发编程实践记录_原子性_锁_同步容器详解_任务执行
原子性: 单独的,不可分割的操作 不要使用过期状态值来决策当下的状态, 一定要先检查再执行(不检查, 将引发数据修改,丢失) 避免延迟初始化(懒加载: 先查看对象 == null, 然后new), 有 ...
- python并发编程之semaphore(信号量)_python 之 并发编程(守护进程、互斥锁、IPC通信机制)...
9.5 守护进程 主进程创建守护进程 其一:守护进程会在主进程代码执行结束后就立即终止 其二:守护进程内无法再开启子进程,否则抛出异常:AssertionError: daemonic process ...
- 并发编程的悲观锁和乐观锁
悲观锁和乐观锁 是并发情境下的两种设计思想, 它们的主要区别在于: 悲观锁则认为肯定会发生并发问题, 要么我等着, 要么就让别人等; 乐观锁认为当前发生并发的可能性不大, 我先试试, 不行的话再说. ...
- Java并发编程—Synchronized底层优化(偏向锁、轻量级锁)
原文作者:Matrix海 子 原文地址:Java并发编程:Synchronized底层优化(偏向锁.轻量级锁) 目录 一.重量级锁 二.轻量级锁 三.偏向锁 四.其他优化 五.总结 一.重量级锁 上篇 ...
- 并发编程中,你加的锁未必安全
摘要:在编写多线程并发程序时,我明明对共享资源加锁了啊?为什么还是出问题呢?问题到底出在哪里呢?其实,我想说的是:你的加锁姿势正确吗? 本文分享自华为云社区<[高并发]高并发环境下诡异的加锁问题 ...
- java公平锁和非公平锁_java并发编程学习之再谈公平锁和非公平锁
在java并发编程学习之显示锁Lock里有提过公平锁和非公平锁,我们知道他的使用方式,以及非公平锁的性能较高,在AQS源码分析的基础上,我们看看NonfairSync和FairSync的区别在什么地方 ...
- Java 并发编程必须知道的七种锁类型以及应用
锁是解决并发冲突的重要工具.在开发中我们会用到很多类型的锁,每种锁都有其自身的特点和适用范围. 需要深刻理解锁的理念和区别,才能正确.合理地使用锁. 常用锁类型 乐观锁与悲观锁 悲观锁对并发冲突持悲观 ...
- python锁机制_Python并发编程之谈谈线程中的“锁机制”(三)
大家好,并发编程 进入第三篇. 今天我们来讲讲,线程里的锁机制. 本文目录 何为Lock( 锁 )?如何使用Lock( 锁 )?为何要使用锁?可重入锁(RLock)防止死锁的加锁机制饱受争议的GIL( ...
最新文章
- window平台下 Eclipse Ndk开发中的Method 'NewStringUTF' could not be resolved问题
- VSCode + Latex 配置
- 通信电子线路期末复习第四章 振幅调制、解调和混频
- 亲测有效的网易云音乐歌单转换到apple music 的方法!
- 测试面试题集锦(五)| 自动化测试与性能测试篇(附答案)
- lostash Timeout executing grok 问题排查
- Linux —— 常用命令集合
- 上半年全国游戏市场销售收入近1400亿元 用户规模近6.6亿人
- python dict批量选择_用python实现word内容批量替换
- 指利用计算机技术实现对文本篇章的理解,行业发展|人工智能的自然语言处理技术已经到了这一步...
- 通用技术和信息技术合格考知识点_高二信息与通用技术会考知识点.doc
- 解决win10更新,笔记本连手机热点网页部分图片、百度网盘验证码显示不出来问题。
- AliOS Things学习笔记(5)——ESP8266对接天猫精灵下篇(设备端)
- 手脱FSG压缩壳及问题处理
- Unity技术手册 - 鼠标键和常用name字符串和KeyCode枚举
- 软件测试学习书籍推荐【乐搏TestPRO】
- JavaScript高级第02天笔记
- 上课笔记--商法(上)
- OSChina 周日乱弹 —— 妹子是国家战略资源啊
- go-micro 在linux下安装出现service auth not found
热门文章
- 计算机的基本结构以真值函数,离散数学N元真值函数问题
- C语言实现天气获取 + HTML页面
- Linux性能之CPU使用率
- 可视化实例(三)Tableau基础绘图介绍——横向条形图、双轴折线图、直方图
- 马化腾公开信:腾讯将推智慧零售解决方案丨用友前三季度财报营收增长24.4%【软件网每日新闻播报│第10-30期】
- 在 44186 款开源软件中搜索 前端开发者不得不知的 ECMAScript 6 十大特性 oschina 2016年03月16日 前端开发者不得不知的 ECMAScript 6 十大特性
- 分享一个铁死亡数据库
- scss混合器实现全局更换主题以及相关背景图
- Mybatis Plus ${ew.sqlSegment} 与 ${ew.customSqlSegment}
- 上岸滴滴暑期实习总结