乐观锁与悲观锁
悲观锁(多写)
假设最坏的情况,每次别人都拿到数据都会修改,所以每次拿数据都会进行上锁,只有拿到锁可以用。(共享资源每次只给一个线程用,并将其它线程阻塞,直到使用完毕)
传统的关系型数据库就会用到这样的锁,行级锁,表锁,读锁,写锁等,Java中的synchronized 和 ReentrantLock都是悲观锁
乐观锁(多读)
默认别人拿到数据不会修改,所以不会上锁。但是在更新的时候判断一下在此期间别人有没有取更新这个数据,可以使用版本号机制和CAS算法 乐观锁用于多读的应用类型,像数据库提供write_condition机制都是乐观锁,Java中java.util.concurrent.atomic 源自变量类都是乐观锁
乐观锁的实现方式
版本号机制
一般是在数据表中加上一个版本号version字段,表示数据被修改次数,当数据被修改时,version会+1,当线程A要更新时,读取数据和版本号,版本号与当前版本号一致,就更新。 这样做的好处就是避免脏读,两个线程同时进行,避免交易未扣费就读取
CAS算法
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的使用场景
CAS适用于多读场景,写较少的情况,线程冲突多的时候会增加自旋概率,浪费资源
synchronized 使用与多写,悲观锁 底层实现主要由lock-free队列,基本思路是自选后阻塞,竞争切换继续竞争锁,稍微兴盛公平性,增加吞吐量。优先推荐