一文彻底理解乐观锁与悲观锁

简介: 一文彻底理解乐观锁与悲观锁

通过阅读本文可以获得什么

1、什么是乐观锁?
2、乐观锁实现方式都有什么?
3、乐观锁优缺点有哪些?
4、乐观锁适用场景?
5、什么是悲观锁?
6、悲观锁实现方式有哪几种?
7、悲观锁优缺点?
8、悲观锁的适用场景?

首先,我们先看一下什么是乐观锁,在我个人理解,乐观锁可以抽象为去银行取钱,假如银行没有人排队,所以不需要取号,直接去柜台A就可以办理业务。反之悲观锁就是假如去银行取钱,每次去都好巧不巧的都有人在柜台A排队,所以此时需要取号,然后等叫号在去柜台A办理业务。(假设银行只有一个柜台A,不是很形象,只是说明这个问题,乐观锁干啥都是乐观看待,悲观锁都是悲观看待),下面跟我一起看下标准解释是怎么说的,首先看下什么是乐观锁?

乐观锁

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

读完上面这一段,我们应该已经知道乐观锁的意思了,也就是说大部分乐观锁其实就是加了版本号version字段,根据这个字段实现的乐观锁机制,那么还有什么方式可以实现乐观锁呢,聪明的你肯定已经想到了CAS,对的,CAS(compare and swap)比较并修改,CAS需要三个参数,内存地址V,旧的预期值A和新值B,只有当V的值等于A时,才会将V的值改为B。

好了,目前乐观锁的实现方式上我们知道了有版本号机制和CAS机制,那么这两种机制会带来什么问题呢?下面跟我一起来看看

首先就是CAS会有ABA问题的出现,什么是ABA问题呢,ABA问题就是张三放桌子100块钱,中间李四拿100块钱用了,用完之后又放了100块到桌子上,等张三回来,发现还是100块,就以为还是他的100块,其实,这个100块钱已经发生了变化,这就是经典的ABA问题。这种问题怎么解决了,也就是上面我们所说的版本号机制,加入版本号(版本号必须是顺序递增的)之后,判断版本,只有当版本号相同时才更改值,然后版本号+1;在更新值的时候如果发现版本号不匹配也就不再进行更改了,这样就可以避免ABA问题了

但是CAS自旋会一直尝试获取锁,如果一直获取不到锁的情况下,此时CPU就会爆表,带来非常大的开销。所以综上所述,乐观锁比较适合读多写少的场景,这样冲突就真的很少发生,也就降低了加锁的成本;但是如果经常产生冲突,应用不断的尝试加锁,反而会影响系统性能,此时就不如使用悲观锁了

悲观锁

悲观锁是什么呢,其实看完上面的乐观锁,对悲观锁的概念自己内心应该也有了一定的概念,是的,你想的没错,悲观锁就是很悲观,不管做啥,都假设是冲突的场景,拿我们上面去银行取钱的例子来说的话就是每次去取钱都有大量的人在柜台A取钱,都在排队等待,等轮到我取钱的时候,相应的其他人也都要等待。对应的我们的场景也就是不管谁来获取资源,都要先拿到锁,这也就是通俗点讲悲观锁的概念了,下面还是按照惯例看下正统说法:

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

那么,既然如此的话悲观锁又都有什么优缺点呢,首先优点就是,保证多线程下顺序读写,防止脏数据产生,缺点就是并发场景下性能显著下降。

所以与乐观锁相对应的悲观锁的适用场景就是读少写多 的场景,这种场景下,冲突多,所以悲观锁很适合。目前我了解的悲观锁实现方式有Lock和Synchronized,其次就是MySQL的for update语句,MySQL中查询语句,select ...... for update 此时就是对数据加了排它锁,排它锁也是一种悲观锁。所以我们对该数据的访问会对该数据进行加锁,后面来的对该数据的操作都会排队等侯,直到拿到锁

除了MySql中查询语句使用的悲观锁,工作中还有好多地方用到了乐观锁悲观锁,比如说,java.util.concurrent.Atomic下的原子变量是使用CAS机制,Elasticsearch是使用了version的乐观锁机制

总结

乐观锁的实现方式有Version(顺序递增)版本号机制和CAS机制。悲观锁的实现方式有Synchronized和Lock,数据库有for update 拍它锁。适用场景就是,乐观锁适合读多写少的场景,悲观锁适合读少写多的场景

好了本篇文章到这就结束了,简单概述下乐观锁与悲观锁的概念,如果描述不对的欢迎指正,一起进步


目录
相关文章
|
消息中间件 安全 Java
什么是乐观锁、在哪用过乐观锁
什么是乐观锁、在哪用过乐观锁
386 0
|
存储 算法 NoSQL
还分不清 Cookie、Session、Token、JWT?看这一篇就够了
Cookie、Session、Token 和 JWT(JSON Web Token)都是用于在网络应用中进行身份验证和状态管理的机制。虽然它们有一些相似之处,但在实际应用中有着不同的作用和特点,接下来就让我们一起看看吧,本文转载至http://juejin.im/post/5e055d9ef265da33997a42cc
47029 13
|
SQL 数据处理 数据库
乐观锁和悲观锁
乐观锁和悲观锁
168 0
|
存储 缓存 NoSQL
MySQL索引详解(一文搞懂)
索引是对数据库表中一列或多列的值进行排序的一种结构,使用索引可快速访问数据库表中的特定信息。
49194 17
MySQL索引详解(一文搞懂)
|
关系型数据库 MySQL 数据库
深入探讨MySQL中的幻读现象:原因、影响及解决方案
**导言:** 在数据库领域中,幻读(Phantom Read)是一个常见但容易被忽视的问题。它可能会导致事务的隔离级别无法满足预期,从而引发数据一致性问题。MySQL作为广泛使用的关系型数据库,也不免遇到幻读问题。本文将深入解析MySQL中的幻读现象,探讨其原因、影响以及可能的解决方案。
2311 0
|
SQL XML Java
乐观锁与悲观锁是什么?
本文详细分析了悲观锁和乐观锁的原理、区别、实现方式及应用场景。悲观锁假设冲突频繁,通过加锁保护数据一致性,适用于高并发冲突场景;乐观锁假设冲突较少,通过版本号或时间戳检测冲突,适用于读多写少场景。文章通过具体示例展示了两种锁机制的实现过程,并总结了其优缺点和适用场景,帮助读者根据实际需求选择合适的并发控制机制。
886 4
|
10月前
|
架构师 数据库
大厂面试高频:数据库乐观锁的实现原理、以及应用场景
数据库乐观锁是必知必会的技术栈,也是大厂面试高频,十分重要,本文解析数据库乐观锁。关注【mikechen的互联网架构】,10年+BAT架构经验分享。
大厂面试高频:数据库乐观锁的实现原理、以及应用场景
|
10月前
|
存储 缓存 安全
ConcurrentHashMap的实现原理,非常详细,一文吃透!
本文详细解析了ConcurrentHashMap的实现原理,深入探讨了分段锁、CAS操作和红黑树等关键技术,帮助全面理解ConcurrentHashMap的并发机制。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
ConcurrentHashMap的实现原理,非常详细,一文吃透!
|
10月前
|
NoSQL Java API
分布式锁的实现原理与应用场景,5 分钟彻底搞懂!
本文详细解析了分布式锁的实现原理与应用场景,包括线程锁、进程锁和分布式锁的区别,以及分布式锁的四种要求和三种实现方式(数据库乐观锁、ZooKeeper、Redis)。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
分布式锁的实现原理与应用场景,5 分钟彻底搞懂!