【Java多线程学习5】什么是悲观锁,什么是乐观锁?如何实现乐观锁、乐观锁存在哪些问题
一、什么是悲观锁
概述
悲观锁总是假设最坏的情况,认为共享资源每次被访问的时候就会出现问题(比如共享数据被修改),所以每次在获取资源操作的时候都会上锁,这样其他线程想拿到这个资源就会阻塞直到锁被上一个持有者释放。也就是说,共享资源每次只给一个线程使用,其它线程阻塞,用完后再把资源转让给其它线程。
像Java中synchronized和ReentrantLock等独占锁就是悲观锁的思想。
- synchronized示例如下:
public void deal() {
synchronized (this) {
//需要同步的操作
}
}
- ReentrantLock示例如下:
private Lock lock = new ReentrantLock();
public void deal() {
//上锁
lock.lock();
try {
//需要同步的操作
} finally {
//释放锁
lock.unlock();
}
}
高并发的场景下,激烈的锁竞争会造成线程阻塞,大量阻塞线程会导致系统的上下文切换,增加系统的性能开销。并且,若未及时释放锁,悲观锁还可能会存在死锁问题,影响代码的正常运行。
二、什么是乐观锁
概述
乐观锁总是假设最好的情况,认为共享资源每次被访问的时候不会出现问题,线程可以不停地执行,无需加锁也无需等待,只是在提交修改的时候去验证对应的资源(也就是数据)是否被其它线程修改了
乐观锁的实现方式:版本号机制 或 CAS算法
总体来说:
- 悲观锁通常多用于写比较多的情况下(多写场景,竞争激烈),这样可以避免频繁失败和重试影响性能,悲观锁的开销是固定的。不过,如果乐观锁解决了频繁失败和重试这个问题的话(比如LongAdder),也是可以考虑使用乐观锁的,要视实际情况而定。
- 乐观锁通常多于写比较少的情况下(多读场景,竞争较少),这样可以避免频繁加锁影响性能。不过,乐观锁主要针对的对象是单个共享变量(参考java.util.concurrent.atomic包下面的原子变量类)。
乐观锁的实现方式
乐观锁一般会使用版本号机制 或 CAS算法。CAS算法相对多一些。
方式一:版本号机制
一般是在数据表中加上一个数据版本号 version 字段,表示数据被修改的次数。当数据被修改时,version 值会加一。当线程 A 要更新数据值时,在读取数据的同时也会读取 version 值,在提交更新时,若刚才读取到的 version 值为当前数据库中的 version 值相等时才更新,否则重试更新操作,直到更新成功。
举一个例子:
有一个账户金额表 ,当前账户金额100,表中有一个version字段当前值为1。
线程a,向账户中存100,线程a读取version为1,此时线程b也读取了version的数据为1,并要取20。
线程a,将version=1和金额200一同提交到数据库更新,由于线程a的提交版本等于当前数据库的版本,更新成功。
线程b,也将version=1,金额80提交到数据库更新,由于线程b的提交版本1不等于当前数据库的版本2,操作b的提交被驳回。
方式二:CAS算法
CAS 的全称是 Compare And Swap(比较与交换)算法 ,用于实现乐观锁的一种技术。
CAS算法的思想简单,核心思路是:比较内存中的当前变量的值与预期值是否相等,如果相等则将其值改为新值,如果不相等则当前线程放弃更新,CAS操作失败。
CAS操作设计的三个操作数:
- V:要更新的变量值(Var)
- E:预期值(Expected)
- N:拟写入的新值(New)
当且仅当 V 的值等于 E 时,CAS 通过原子方式用新值 N 来更新 V 的值。如果不等,说明已经有其它线程更新了 V,则当前线程放弃更新。
举一个简单的例子:
线程 a 要修改变量 i 的值为 10,i 原值为 1(V = 1,E=1,N=10,假设不存在 ABA 问题)。
i 与 1 进行比较,如果相等, 则说明没被其他线程修改,可以被设置为 6 。
i 与 1 进行比较,如果不相等,则说明被其他线程修改,当前线程放弃更新,CAS 操作失败。
当多个线程同时使用 CAS 操作一个变量时,只有一个会胜出,并成功更新,其余均会失败,但失败的线程并不会被挂起,仅是被告知失败,并且允许再次尝试,当然也允许失败的线程放弃操作。
乐观锁存在的问题
1、ABA 问题
ABA 问题是乐观锁最常见的问题。
如果一个变量 V 初次读取的时候是 A 值,并且在准备赋值的时候检查到它仍然是 A 值,那我们就能说明它的值没有被其他线程修改过了吗?很明显是不能的,因为在这段时间它的值可能被改为其他值,然后又改回 A,那 CAS 操作就会误认为它从来没有被修改过。这个问题被称为 CAS 操作的 "ABA"问题。
ABA 问题的解决思路是在变量前面追加上版本号或者时间戳。
JDK 1.5 以后的 AtomicStampedReference 类就是用来解决 ABA 问题的,其中的 compareAndSet() 方法就是首先检查当前引用是否等于预期引用,并且当前标志是否等于预期标志,如果全部相等,则以原子方式将该引用和该标志的值设置为给定的更新值
2、只能保证一个共享变量的原子操作
CAS 只对单个共享变量有效,当操作涉及跨多个共享变量时 CAS 无效 ,也无法实现对代码块或是方法进行原子操作。
3、循环时间开销大
CAS 经常会用到自旋操作来进行重试,也就是不成功就一直循环执行直到成功。如果长时间不成功,会给 CPU 带来非常大的执行开销。