乐观锁
- 认为自己在处理操作的时候不会有其他线程阿里干扰,所以并不会锁住被操作对象
- 在更新的时候,去对比在我修改的期间数据有没有被其他人改变过,如果没有被改变过,就说明真的是只有我自己在操作,那我就正常去修改数据;如果数据和我一开始拿到的不一样了,说明其他人在这段时间内修改过数据,那么我就不能继续刚才的更新数据过程了,我会选择放弃、报错、重试等
- 乐观锁的实现一般都是利用CAS算法来实现的
典型例子
- 悲观锁:synchronized和Lock相关的类
- 乐观锁的典型例子就是原子类、并发容器等
- Git:Git就是乐观锁的典型例子,当我们往远程仓库push的时候,git会检查远程仓库的版本是不是领先于我们现在的版本,如果远程仓库的版本号和本地的不一样,就表示有其他人修改了远端代码,那么我们这次提交就失败,如果远端和本地的版本号一致,我们就可以顺利提交版本到远端仓库
- 数据库:select for update就是悲观锁;使用version控制数据库的数据,那么就是乐观锁
package lock.lock;
import java.util.concurrent.atomic.AtomicInteger;
public class PessimismOptimismLock {
int a;
public static void main(String[] args) {
AtomicInteger atomicInteger = new AtomicInteger();
atomicInteger.incrementAndGet();
}
public synchronized void testMethod() {
a++;
}
}
悲观锁和乐观锁开销对比
- 悲观锁的开始开销要高于乐观锁,但是特点是一劳永逸,临界区持锁时间就算越来越差,也不会对互斥锁的开销造成影响
- 相反,虽然乐观锁一开始的开销比悲观锁小,但是如果自旋时间很长或者不停重试,那么消耗的资源也会越来越多
悲观锁和乐观锁的使用场景
- 悲观锁:适合并发写入多的情况,适用于临界区持锁时间比较长的情况,悲观锁可以避免大量的无用自旋等消耗,典型情况:
- 临界区有I/O操作
- 临界区代码复杂或循环量大
- 临界区竞争非常激烈
- 乐观锁:适合并发写入少,大部分是读取的场景,不加锁能让读取性能大幅提高