乐观锁与悲观锁

最新推荐文章于 2022-07-18 14:49:27 发布

皮的皮卡丘

最新推荐文章于 2022-07-18 14:49:27 发布

阅读量68

点赞数

本文链接：https://blog.csdn.net/weixin_42291052/article/details/110440850

版权

假设最坏的情况，每次别人都拿到数据都会修改，所以每次拿数据都会进行上锁，只有拿到锁可以用。（共享资源每次只给一个线程用，并将其它线程阻塞，直到使用完毕）

传统的关系型数据库就会用到这样的锁，行级锁，表锁，读锁，写锁等，Java中的synchronized 和 ReentrantLock都是悲观锁

默认别人拿到数据不会修改，所以不会上锁。但是在更新的时候判断一下在此期间别人有没有取更新这个数据，可以使用版本号机制和CAS算法乐观锁用于多读的应用类型，像数据库提供write_condition机制都是乐观锁，Java中java.util.concurrent.atomic 源自变量类都是乐观锁

一般是在数据表中加上一个版本号version字段，表示数据被修改次数，当数据被修改时，version会+1，当线程A要更新时，读取数据和版本号，版本号与当前版本号一致，就更新。 这样做的好处就是避免脏读，两个线程同时进行，避免交易未扣费就读取

compare and swap 有名的无锁算法，非阻塞同步。
需要读写的内存值 V
进行比较的值 A
拟写入的新值 B
当且仅当A=V时，用B的值更新,否则不执行操作

1、ABA问题

V除此读取是A值，准备赋值校验还是A值，但是中间过程可能改为B值，JDK1.5之后会检查预期引用

2、循环时间长开销大

因为CAS的自旋锁机制，不成功一直循环，长时间不成功就会占用CPU执行，JVM提供pause指令，一个是延长流水线执行指令，第二，避免因为内存顺序冲突导致CPU流水线清空

3、只能保证共享变量的原子性操作

JDK1.5之后提供一个类把多个共享变量合并成一个共享变量

CAS适用于多读场景，写较少的情况，线程冲突多的时候会增加自旋概率，浪费资源

synchronized 使用与多写，悲观锁底层实现主要由lock-free队列，基本思路是自选后阻塞，竞争切换继续竞争锁，稍微兴盛公平性，增加吞吐量。优先推荐

关注