快来，一起复习一下乐观锁悲观锁

背景

工作也有四年了，基础的东西许久不看有些遗忘。一起来复习一下吧

前引

不管是乐观锁，还是悲观锁。更像是一种思想。
乐观锁比较适用于读多写少的情况(多读场景)，悲观锁比较适用于写多读少的情况(多写场景)。

乐观锁

1.CAS 实现：Java 中java.util.concurrent.atomic包下面的原子变量使用了乐观锁的一种 CAS 实现方式。
2.版本号控制：一般是在数据表中加上一个数据版本号 version 字段，表示数据被修改的次数。当数据被修改时，version 值会 +1。当线程 A 要更新数据时，在读取数据的同时也会读取 version 值，在提交更新时，若刚才读取到的 version 值与当前数据库中的 version 值相等时才更新，否则重试更新操作，直到更新成功。

悲观锁

1.在对记录进行修改前，先尝试为该记录加上排他锁(exclusive locks)。
2.如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。具体响应方式由开发者根据实际需要决定。
3.如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。
4.期间如果有其他对该记录做修改或加排他锁的操作，都会等待解锁或直接抛出异常

for update 就是典型的数据库悲观锁
jdk提供的synchronized关键字也是悲观锁。

二者区别以及选择

1️⃣响应效率：如果需要非常高的响应速度，建议采用乐观锁方案，成功就执行，不成功就失败，不需要等待其他并发去释放锁。乐观锁并未真正加锁，效率高。一旦锁的粒度掌握不好，更新失败的概率就会比较高，容易发生业务失败。
2️⃣冲突频率：如果冲突频率非常高，建议采用悲观锁，保证成功率。冲突频率大，选择乐观锁会需要多次重试才能成功，代价比较大。
3️⃣重试代价：如果重试代价大，建议采用悲观锁。悲观锁依赖数据库锁，效率低。更新失败的概率比较低。
4️⃣乐观锁如果有人在你之前更新了，你的更新应当是被拒绝的，可以让用户从新操作。悲观锁则会等待前一个更新完成。这也是区别。

总结

乐观锁和悲观锁 只是用来形容并发的侧重程度，并不是具体到某个具体的锁。更侧重于一种思想

参考
https://zhuanlan.zhihu.com/p/399912518