乐观锁悲观锁，这一篇就够了！

Posted 2022-09-25

1. 乐观锁

乐观锁顾名思义就是在操作时很乐观，认为操作不会产生并发问题(不会有其他线程对数据进行修改)，因此不会上锁。但是在更新时会判断其他线程在这之前有没有对数据进行修改，一般会使用​​版本号机制​​​或​​CAS(compare and swap)算法​​​实现。
简单理解：这里的数据，别想太多，你尽管用，出问题了算我怂，即操作失败后事务回滚、提示。版本号、CAS这2种方法本质上是一样的：假如满足条件，做你想做的事，条件判断是原子的或者是快速的，耗时几乎不计。

1.1 版本号机制

1.1.1 实现套路：

• 取出记录时，获取当前​​version​​
• 更新时，带上这个​​version​​
• 执行更新时，​​set version = newVersion where version = oldVersion​​
• 如果​​version​​不对，就更新失败

核心SQL：

update table set name = Aron, version = version + 1 where id = #id and version = #version;

1.1.2 实例-Mybatis-plus 乐观锁实现

原文查看请点击 ​​Mybatis-plus 乐观锁实现​​

1.2 CAS算法

乐观锁的另一种技术技术，当多个线程尝试使用CAS同时更新同一个变量时，只有其中一个线程能更新变量的值，而其它线程都失败，失败的线程并不会被挂起，而是被告知这次竞争中失败，并可以再次尝试。

​​CAS​​ 操作中包含三个操作数 :

• 需要读写的内存位置​​V​​
• 进行比较的预期原值​​A​​
• 拟写入的新值​​B​​

如果内存位置​​V​​​的值与预期原值​​A​​​相匹配，那么处理器会自动将该位置值更新为新值​​B​​​。否则处理器不做任何操作。无论哪种情况，它都会在 ​​CAS​​​ 指令之前返回该位置的值（在 ​​CAS​​​ 的一些特殊情况下将仅返回 ​​CAS​​​ 是否成功，而不提取当前值）。​​CAS​​​ 有效地说明了“ 我认为位置 ​​V​​​ 应该包含值 ​​A​​​；如果包含该值，则将 ​​B​​ 放到这个位置；否则，不要更改该位置，只告诉我这个位置现在的值即可。 ”这其实和乐观锁的冲突检查+数据更新的原理是一样的。

1.2.1 实例-concurrent包的实现

由于​​java​​​的​​CAS​​​同时具有 ​​volatile​​​ 读和​​volatile​​​写的内存语义，因此​​Java​​线程之间的通信现在有了下面四种方式：

1. ​​A​​​线程写​​volatile​​​变量，随后​​B​​​线程读这个​​volatile​​变量。
2. ​​A​​​线程写​​volatile​​​变量，随后​​B​​​线程用​​CAS​​​更新这个​​volatile​​变量。
3. ​​A​​​线程用​​CAS​​​更新一个​​volatile​​​变量，随后​​B​​​线程用​​CAS​​​更新这个​​volatile​​变量。
4. ​​A​​​线程用​​CAS​​​更新一个​​volatile​​​变量，随后​​B​​​线程读这个​​volatile​​变量。

​​Java​​​的​​CAS​​​会使用现代处理器上提供的高效机器级别原子指令，这些原子指令以原子方式对内存执行读-改-写操作，这是在多处理器中实现同步的关键（从本质上来说，能够支持原子性读-改-写指令的计算机器，是顺序计算图灵机的异步等价机器，因此任何现代的多处理器都会去支持某种能对内存执行原子性读-改-写操作的原子指令）。同时，​​volatile​​​变量的读/写和​​CAS​​​可以实现线程之间的通信。把这些特性整合在一起，就形成了整个​​concurrent​​包得以实现的基石。

仔细分析​​concurrent​​包的源代码实现，会发现一个通用化的实现模式：

1. 首先，声明共享变量为​​volatile​​；
2. 然后，使用CAS的原子条件更新来实现线程之间的同步；
3. 同时，配合以​​volatile​​​的读/写和​​CAS​​​所具有的​​volatile​​读和写的内存语义来实现线程

1.2.2 缺点

• ​​ABA​​问题

比如说一个线程​​T1​​​从内存位置​​V​​​中取出​​A​​​，这时候另一个线程​​T2​​​也从内存中取出​​A​​​，并且​​T2​​​进行了一些操作变成了​​B​​​，然后​​T2​​​又将​​V​​​位置的数据变成​​A​​​，这时候线程​​T1​​​进行​​CAS​​​操作发现内存中仍然是​​A​​​，然后​​T1​​​操作成功。尽管线程​​T1​​​的​​CAS​​操作成功，但可能存在潜藏的问题。

• 循环时间长开销大

自旋​​CAS​​​（不成功，就一直循环执行，直到成功）如果长时间不成功，会给CPU带来非常大的执行开销。如果​​JVM​​​能支持处理器提供的​​pause​​​指令那么效率会有一定的提升，​​pause​​​指令有两个作用，第一它可以延迟流水线执行指令（​​de-pipeline​​​）,使​​CPU​​​不会消耗过多的执行资源，延迟的时间取决于具体实现的版本，在一些处理器上延迟时间是零。第二它可以避免在退出循环的时候因内存顺序冲突（​​memory order violation​​​）而引起CPU流水线被清空（​​CPU pipeline flush​​​），从而提高​​CPU​​的执行效率。

• 只能保证一个共享变量的原子操作

当对一个共享变量执行操作时，我们可以使用循环CAS的方式来保证原子操作，但是对多个共享变量操作时，循环CAS就无法保证操作的原子性，这个时候就可以用锁，或者有一个取巧的办法，就是把多个共享变量合并成一个共享变量来操作。比如有两个共享变量​​i ＝ 2,j = a​​​，合并一下​​ij = 2a​​​，然后用​​CAS​​​来操作ij。从​​Java 1.5​​​开始JDK提供了​​AtomicReference​​​类来保证引用对象之间的原子性，你可以把多个变量放在一个对象里来进行​​CAS​​操作。

2. 悲观锁

总是假设最坏的情况（想法很悲观），每次取数据时都认为其他线程会修改，所以都会加（悲观）锁。一旦加锁，不同线程同时执行时,只能有一个线程执行，其他的线程在入口处等待，直到锁被释放。

悲观锁在​​mysql​​​、​​Java​​有广泛的使用

• ​​MySQL​​的读锁、写锁、行锁等
• ​​Java​​​的​​synchronized​​关键字

3. 总结

读的多，冲突几率小，乐观锁。
写的多，冲突几率大，悲观锁。

 

​

作者：sunsky303