并发问题中的乐观锁和悲观锁

最新推荐文章于 2023-08-02 10:32:35 发布

Z_Juliet

最新推荐文章于 2023-08-02 10:32:35 发布

阅读量944

点赞数 1

分类专栏： java并发问题文章标签： java

本文链接：https://blog.csdn.net/weixin_48429905/article/details/123937405

版权

java并发问题专栏收录该内容

1 篇文章 0 订阅

订阅专栏

本文详细介绍了乐观锁与悲观锁的概念及其在并发控制中的作用。悲观锁在读取数据时立即加锁，防止数据冲突，常用于写操作频繁的场景；而乐观锁则假设不会发生冲突，仅在提交时检查，通过版本号或CAS算法实现，适用于写操作较少的情况。在案例中，乐观锁通过版本号机制防止了操作员间的更新冲突。此外，还简单提到了CAS算法，这是一种非阻塞的乐观锁实现，用于无锁编程，确保在多线程环境下数据的一致性。

摘要由CSDN通过智能技术生成

悲观锁：如果发生并发冲突，屏蔽一切可能破坏数据完整性的操作。在查询完数据就把事务锁起来，直到提交事务。实现方式：使用数据库的锁机制。悲观锁一般多用于写比较多的场景。
乐观锁：假设不发生冲突，只在提交的时候检查是否违反数据的完整性。在修改数据的时候把书屋锁起来，通过version版本号的方式进行锁定。实现方式：一般会使用version或者cas算法实现。乐观锁一般多用于写操作比较少的场景。

乐观锁——version的使用方式：版本号机制：一般是在数据库的表中加版本号version字段，用来表示数据被修改的次数，当数据被修改时，version的值会加一。当线程A要更新数据时，在读取数据的同时也会读取version的值，在提交更新时，若刚才读取到的version值作为当前数据库中version，当相同时才更新，否则重试更新的操作直到更新成功。

操作员 A 此时将其读出（ version=1 ），并从其帐户余额中扣除 $50（ $100-$50 ）。
在操作员 A 操作的过程中，操作员B 也读入此用户信息（ version=1 ），并从其帐户余额中扣除 $20 （ $100-$20 ）。
操作员 A 完成了修改工作，将数据版本号加一（ version=2 ），连同帐户扣除后余额（ balance=$50 ），提交至数据库更新，此时由于提交数据版本大于数据库记录当前版本，数据被更新，数据库记录 version 更新为 2 。
操作员 B 完成了操作，也将版本号加一（ version=2 ）试图向数据库提交数据（ balance=$80 ），但此时比对数据库记录版本时发现，操作员 B 提交的数据版本号为 2 ，数据库记录当前版本也为 2 ，不满足 “ 当前最后更新的version与操作员第一次的版本号相等 “ 的乐观锁策略，因此，操作员 B 的提交被驳回。
这样，就避免了操作员 B 用基于 version=1 的旧数据修改的结果覆盖操作员A 的操作结果的可能。
2、乐观锁——cas算法：

一个线程失败或挂起并不会导致其他线程也失败或挂起，那么这种算法就被称为非阻塞算法。而CAS就是一种非阻塞算法实现，也是一种乐观锁技术，它能在不使用锁的情况下实现多线程安全，所以CAS也是一种无锁算法。

CAS 比较并交换，是一种实现并发算法时常用到的技术，Java并发包中的很多类都使用了CAS技术。CAS具体包括三个参数：当前内存值V、旧的预期值A、即将更新的值B，当且仅当预期值A和内存值V相同时，将内存值修改为B并返回true，否则什么都不做，并返回false。CAS 有效地说明了“ 我认为位置 V 应该包含值 A，如果真的包含A值，则将 B 放到这个位置，否则，不要更改该位置，只告诉我这个位置现在的值(A)即可。 ”整个比较并交换的操作是原子操作。