悲观锁是什么?
悲观锁它总是假设最坏的情况,它会认为共享资源在每次被访问的时候就会出现线程安全问题,所以每次在获取资源的时候都会上锁,以避免线程安全问题发生。
也就是说,共享资源每次只给一个线程使用,而其他的线程则会阻塞住,当占据锁的线程用完后才会把共享资源释放掉,让给其它线程来进行竞争。
这样就会导致在高并发的场景下容易造成死锁、以及线程阻塞等,增加系统的开销。
乐观锁是什么?
乐观锁总是假设最好的情况,它认为共享资源每次被访问的时不会出现线程问题,所以也就不用加锁去保证线程安全,因此线程可以不停地执行,只有当提交修改的时候去验证对应的共享资源是否被其它线程修改。
高并发的场景下,乐观锁不存在锁竞争造成线程阻塞,也不会有死锁的问题,在性能上往往会更胜一筹。
但是,如果写操作的冲突频繁发生,会频繁失败和重试,这样同样会非常影响性能。
如何实现乐观锁?
什么是CAS
CAS是Compare-And-Swap
(比较并交换)的缩写,是一种轻量级的同步机制,主要用于实现多线程环境下的无锁算法和数据结构,保证了并发安全性。它可以在不使用锁的情况下,对共享数据进行线程安全的操作。
它就是用一个预期值和要更新的变量值进行比较,两值相等才会进行更新。CAS 操作是一个原子操作,它在执行期间不会被其他线程中断。因此,它能够提供一种乐观并发控制机制,避免了传统锁机制的开销和可能的线程阻塞。
它的其实主要就是两个步骤:冲突检测以及数据更新。
通常包含三个参数:内存位置(或称为变量)、期望值和新值。它的执行步骤如下:
1. 读取内存位置的当前值。
2. 检查当前值是否与期望值相等。如果相等,则进行步骤4;如果不相等,则说明其他线程已经修改了该值,操作失败。
3. 如果当前值与期望值相等,则将新值写入内存位置。
4. 返回操作是否成功的标志。
class AccountSafe implements Account {
private AtomicInteger balance; // 原子整数类型
public AccountSafe(Integer balance) {
this.balance = new AtomicInteger(balance);
}
@Override
public Integer getBalance() {
return balance.get();
}
@Override
public void withdraw(Integer amount) {
while (true) {
// 没同步到主存 因为是局部变量,只在线程的工作内存之中
int prev = balance.get(); // 获取余额最新值
int next = prev - amount; // 修改后的余额
// 真正修改
if (balance.compareAndSet(prev, next)) {
// 成功为true;失败false,继续循环
break;
}
}
}
}
我们再来仔细看一下withdraw
方法
public void withdraw(Integer amount) {
// 需要不断尝试,直到成功为止
while (true) {
// 比如拿到了旧值 1000
int prev = balance.get();
// 在这个基础上 1000-10 = 990
int next = prev - amount;
/*
compareAndSet 正是做这个检查,在 set 前,先比较 prev 与 当前值!!!
当不一致时,next 作废,返回 false 表示失败
比如,别的线程已经做了减法,当前值已经被减成了990
那么本线程的这次 990 就作废了,进入 while 下次循环重试
直到一致,以 next 设置为新值,返回 true 表示成功
*/
if (balance.compareAndSet(prev, next)) {
break;
}
}
}
在并发环境中,多个线程可以同时执行CAS操作来更新同一个内存位置的值。如果多个线程同时执行CAS操作,只有一个线程的CAS操作会成功,其他线程的操作将失败。在失败的情况下,可以选择重试CAS操作。
应用
- JVM创建对象的过程中分配内存【堆中 因为这个是共享 所以要保证安全】
syn
轻量级锁的时候,JVM尝试使用CAS操作,将对象头的Mark Word
更新为指向锁记录的指针。ReentrantLock
中的非公平锁,也使用CAS来管理锁的状态。比如,尝试获取锁时会使用CAS来检查并更新锁的状态。- 并发集合:如
ConcurrentHashMap
等,并发集合的实现中也大量使用了CAS操作,以实现高效的线程安全访问。 - 原子类:如
AtomicInteger
、AtomicLong
、AtomicReference
等,这些类提供了一组原子操作,允许你在单个操作中安全地读取、写入和更新变量。这些操作背后就是通过CAS来实现的。
局限性
- 只能保证对单个共享变量的操作是原子性的,无法保证对多行代码实现原子性
- 高并发场景下,竞争激烈,CAS 失败重试会频繁发生,自旋时间过长,而线程又不阻塞,抢占 CPU 资源,导致 CPU 使用率飙升,反而影响了性能
a. 指定 CAS 一共循环多少次,如果超过这个次数,直接失败或将线程挂起(参考 synchronized 中的自旋锁) .
b. 可以通过分段的思想减少竞争,使用原子累加器 LongAdder,当有竞争时设置多个累加单元,最后将结果汇总 - ABA问题
ABA问题是什么?
先看例子:
假设你在银行的查看账户余额。第一次查看时,余额显示为100
元(状态A)。然后打算取出50元,但在操作之前,出于确认目的,再次检查余额,发现还是100元,似乎没有变化(仍然是状态A)。
但实际情况可能是,在两次查看之间,有人往你的账户存入了50
元(状态变为B:150元),然后又立即取出了50
元(状态再次回到A:100元)。尽管最终余额回到了初始查看的数值,但实际上账户经历了存取的变化(A->B->A)。
在并发编程的上下文中,这就是“ABA问题
”。当你CAS
操作来确保数据一致性时,如果仅比较前后值是否相同(都是A),就可能会忽略掉中间发生的改变(B状态),误以为数据从未被改动过,从而可能导致逻辑错误或数据不一致性!
如何解决?
解决ABA问题的一种常见方法是引入版本号或者时间戳,每次修改变量时不仅更新其值,还增加版本号或时间戳。这样,即便值回到了最初的状态,通过检查版本号或时间戳的不同,也可以察觉到变量曾经被修改过。
AtomicStampedReference(维护版本号)
AtomicStampedReference
通过捆绑一个引用及其关联的stamp
(印记,可以视为版本号或时间戳)来工作,以此增强传统的比较并交换(CAS)操作。
它允许线程在执行 CAS 操作时,不仅检查引用是否发生了变化,还要检查时间戳是否发生了变化。这样,即使一个变量的值被修改后又改回原值,由于时间戳的存在,线程仍然可以检测到这中间的变化。
public class AtomicStampedReferenceDemo {
private static final Logger log = LoggerFactory.getLogger(AtomicStampedReferenceDemo.class);
static AtomicStampedReference<String> ref = new AtomicStampedReference<>("A", 0);
public static void main(String[] args) throws InterruptedException {
log.debug("main start...");
// 获取值 A
String prev = ref.getReference();
// 获取版本号
int stamp = ref.getStamp();
log.debug("版本 {}", stamp);
// 如果中间有其它线程干扰,发生了 ABA 现象
other();
TimeUnit.MILLISECONDS.sleep(1); // 使用TimeUnit使代码更具可读性
// 尝试改为 C
log.debug("change A->C {}", ref.compareAndSet(prev, "C", stamp, stamp + 1));
}
private static void other() {
new Thread(() -> { // 更新如果成功,版本号加1
log.debug("change A->B {}", ref.compareAndSet(ref.getReference(), "B",
ref.getStamp(), ref.getStamp() + 1));
log.debug("更新版本为 {}", ref.getStamp());
}, "t1").start();
TimeUnit.MILLISECONDS.sleep(500); // 确保t1先启动
new Thread(() -> {
log.debug("change B->A {}", ref.compareAndSet(ref.getReference(), "A",
ref.getStamp(), ref.getStamp() + 1));
log.debug("更新版本为 {}", ref.getStamp());
}, "t2").start();
}
private static void sleep(long millis) {
try {
Thread.sleep(millis);
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
throw new RuntimeException(e);
}
}
}
AtomicMarkableReference(仅维护是否修改过)
与AtomicStampedReference
不同,它通过一个布尔标记(mark),来简单指示引用的对象是否曾被修改过。
这个类在执行CAS
时,不仅关注引用本身的比较,还会检查这个伴随的标记状态。即,哪怕对象的值在一段时间内经历了A->B->A
,由于标记的存在,线程也能够感知到该对象曾经发生过变化。
// GarbageBag类定义
class GarbageBag {
private String desc;
public GarbageBag(String desc) {
this.desc = desc;
}
public void setDesc(String desc) {
this.desc = desc;
}
@Override
public String toString() {
return "GarbageBag{" +
"desc='" + desc + '\'' +
'}';
}
}
public class TestABAAtomicMarkableReference {
private static final Logger log = LoggerFactory.getLogger(TestABAAtomicMarkableReference.class);
public static void main(String[] args) throws InterruptedException {
GarbageBag bag = new GarbageBag("装满了垃圾");
// 参数2 mark 可以看作一个标记,表示垃圾袋是否已满
AtomicMarkableReference<GarbageBag> ref = new AtomicMarkableReference<>(bag, true);
log.debug("主线程 start...");
GarbageBag prev = ref.getReference();
log.debug(prev.toString());
new Thread(() -> {
log.debug("打扫卫生的线程 start...");
bag.setDesc("空垃圾袋"); // 假设这里清理了垃圾袋
// 尝试将标记从true改为false,表示垃圾袋已清空
while (!ref.compareAndSet(bag, bag, true, false)) {}
log.debug(bag.toString());
}).start();
TimeUnit.SECONDS.sleep(1); // 等待打扫卫生的线程执行
log.debug("主线程想换一只新垃圾袋?");
boolean success = ref.compareAndSet(prev, new GarbageBag("空垃圾袋"), true, false);
log.debug("换了么?" + success);
log.debug(ref.getReference().toString());
}
}
其他文章
【强烈推荐!】从底层源码剖析AQS的来龙去脉!(通俗易懂)
最后
如果小伙伴们觉得我写的文章不错的话,那么请给我点点关注,我们下次见!