💐个人主页:初晴~
📚相关专栏:多线程 / javaEE初阶
一、CAS概述
CAS(Compare and Swap),中文译为 “比较并交换” ,是一种无锁算法中常用的原子操作。CAS通常用于实现线程之间的同步,特别是在多线程环境下需要保证原子性的场景下。
compareAndSwap(V, A, B)
CAS操作涉及三个操作数:内存位置(V)、预期原值(A)和新值(B)。如果内存位置的值与预期原值相匹配,那么处理器会自动将该位置的值更新为新值。否则,操作失败,处理器不做任何事情。
简单来说就是以下三步:
1. ⽐较 A 与 V 是否相等。(⽐较)2. 如果⽐较相等,将 B 写⼊ V。(交换)3. 返回操作是否成功。
优点:
- 无需锁:CAS操作本身就是一个原子操作,因此可以在不使用锁的情况下实现多线程环境下的同步。
- 减少上下文切换:相比于传统的锁机制,使用CAS可以减少线程上下文切换的次数,提高性能。
- 易于实现:CAS的实现相对简单,可以方便地在多线程环境中使用。
- 循环时间长的问题:在并发量较大的情况下,CAS操作可能因为一直获取不到正确的预期值而陷入无限循环,导致CPU使用率上升。
- 只能保证一个共享变量的原子性:如果需要对多个共享变量进行原子操作,则CAS无法直接实现,需要结合其他手段,如使用
AtomicReference
或者其他同步机制。- ABA问题:如果一个值在两次比较之间被修改回原来的值,那么CAS操作将会成功,但实际上中间发生过更改。这被称为ABA问题,在后文我们会再进行详细叙述的。
二、CAS的实现
CAS(Compare and Swap)操作是一种硬件级别的原子操作,用于实现无锁编程模式中的原子更新。在Java中,CAS操作主要通过Unsafe
类来实现,并被广泛应用于java.util.concurrent
包下的原子类中,如AtomicInteger
、AtomicLong
等。
CAS的硬件支持
CAS操作依赖于现代处理器提供的原子指令,例如Intel x86架构中的CMPXCHG
(Compare and Exchange)指令,ARM架构中的LDREX
/STREX
(Load Exclusive / Store Exclusive)指令等。这些指令能够保证比较和交换操作的原子性,即使在多处理器环境下也不会被中断。
Java中CAS的实现
在Java中,Unsafe
类提供了访问底层硬件的能力,包括执行CAS操作。Unsafe
类并不是公开的API,它位于sun.misc
包中,并且是隐藏的,不允许直接实例化。但是,Java的原子类(如AtomicInteger
)通过反射等方式间接使用了Unsafe
类来实现CAS操作。
Unsafe
类中有几个关键方法用于实现CAS操作:
- compareAndSwapInt:用于整型变量的CAS操作。
- compareAndSwapLong:用于长整型变量的CAS操作。
- compareAndSwapObject:用于引用类型的CAS操作。
这些方法接受的对象参数是目标对象、预期旧值、新值以及一个表示目标字段偏移量的整数。偏移量通常是通过反射获取的。
不过直接使用Unsafe
类通常是不推荐的,因为它涉及到底层操作,容易出现安全性问题。通常我们会使用更高层次的API,如AtomicInteger
等。
三、CAS简单应用
(1)实现原子类
标准库中提供了 java.util.concurrent.atomic 包, ⾥⾯的类都是基于这种⽅式来实现的.
典型的就是 AtomicInteger 类。以下是其中一些重要的方法:
- get():获取当前的整数值。
- set(int newValue):设置整数值。
- getAndIncrement():返回当前值,然后将值加一,相当于i++。
- getAndDecrement():返回当前值,然后将值减一,相当于i--。
- incrementAndGet():将值加一,然后返回新的值,相当于++i。
- decrementAndGet():将值减一,然后返回新的值,相当于--i。
- addAndGet(int delta):将当前值加上一个增量,然后返回新的值,相当于+=delta。
- getAndAdd(int delta):返回当前值,然后将当前值加上一个增量,相当于-=delta。
- compareAndSet(int expect, int update):如果当前值等于预期值,则原子地将值设置为新值;返回一个布尔值指示是否成功。
让我们看看下面这个伪代码:
接着通过CAS(value,oldValue,oldValue+1)来对比寄存器中的数据与内存数据是否相等来保证执行的准确性:
- 若相等,就通过将oldValue+1赋值给内存数据oldValue,并返回true退出while循环, 实现安全的修改变量操作
- 若不相等,则说明在 上方的赋值 与 此处的 CAS 操作之间有其它的线程穿插执行改变了内存数据,这时就返回false给while循环,重新执行“oldVlue = value”,从而重新加载内存中的值到寄存器中
过去的++操作需要三个指令,不具备原子性,就容易出现线程安全问题:
而通过CAS就能解决这一问题,将原来的add指令改为CAS,在真正执行++操作时会判断寄存器的值与内存中的值是否相等,若相等,则近似等价于数据未发生改变,则正常执行++操作并赋值。若发现值不同,则说明该操作被其他线程给插入了,就会重新从load指令开始重新执行操作,从而避免了线程问题的产生:
这样我们就可以利用原子类 AtomicInteger 来实现一个线程安全的计时器:
public class AtomicIntegerCounterExample {public static void main(String[] args) throws InterruptedException {//创建一个原子类AtomicInteger counter = new AtomicInteger(0);int threadCount = 10;CountDownLatch latch = new CountDownLatch(threadCount);//创建了一个线程池ExecutorService executor = Executors.newFixedThreadPool(threadCount);for (int i = 0; i < threadCount; i++) {executor.execute(() -> {for (int j = 0; j < 1000; j++) {//相当于++操作counter.incrementAndGet();}latch.countDown();});}latch.await(); // 等待所有线程完成executor.shutdown();System.out.println("Final count: " + counter.get());}
}
在上述代码中,我们就创建了一个 AtomicInteger
对象counter
,并通过一个线程池创建了多个线程来对计数器进行递增操作。每个线程递增计数器1000次,最终打印出计数器的最终值。由于AtomicInteger
的原子性,即使在多线程环境下,计数器的值也是准确的。
(2)实现自旋锁
自旋锁是一种同步机制,当一个线程试图获取已经被其他线程持有的锁时,它不会立即放弃CPU,而是继续循环尝试获取锁,直到成功为止。在 常见锁策略 一文中曾介绍过这一机制。
基于CAS实现自旋锁的步骤:
- 初始化锁标志:定义一个标志位来表示锁的状态,通常是一个整型变量。
- 获取锁:当一个线程想要获取锁时,它会使用CAS操作尝试将锁标志设置为已锁定状态。
- 释放锁:当线程完成其临界区操作后,它会将锁标志恢复为未锁定状态,以便其他线程可以获取锁。
- 自旋等待:如果CAS操作失败(即锁已被其他线程占用),当前线程将在一个循环中继续尝试获取锁,直到成功为止。
import java.util.concurrent.atomic.AtomicInteger;public class SpinLock {private final AtomicInteger lock = new AtomicInteger(0); // 0 表示未锁定,1 表示已锁定/*** 尝试获取锁。*/public void lock() {while (!lock.compareAndSet(0, 1)) {// CAS操作失败,说明锁已被占用,继续循环尝试}}/*** 释放锁。*/public void unlock() {lock.compareAndSet(1, 0); // 释放锁}public static void main(String[] args) {SpinLock spinLock = new SpinLock();// 模拟两个线程对共享资源的访问Thread t1 = new Thread(() -> {spinLock.lock();try {System.out.println(Thread.currentThread().getName() + " acquired the lock.");Thread.sleep(2000);} catch (InterruptedException e) {e.printStackTrace();} finally {System.out.println(Thread.currentThread().getName() + " released the lock.");spinLock.unlock();}});Thread t2 = new Thread(() -> {spinLock.lock();try {System.out.println(Thread.currentThread().getName() + " acquired the lock.");Thread.sleep(2000);} catch (InterruptedException e) {e.printStackTrace();} finally {System.out.println(Thread.currentThread().getName() + " released the lock.");spinLock.unlock();}});t1.start();t2.start();}
}
在上述代码中,我们定义了一个SpinLock
类,它使用AtomicInteger
来实现自旋锁的逻辑。lock()
方法使用CAS操作尝试获取锁,如果获取失败,则进入自旋等待。unlock()
方法则用于释放锁。
注意:
- 自旋次数:在高并发环境下,自旋锁可能会导致CPU利用率较高。可以考虑在自旋一定次数后让线程挂起,然后再尝试获取锁。
- 公平性:默认情况下,上述实现的自旋锁是非公平的,即先等待的线程不一定能先获取锁。如果需要公平性,可以考虑实现一个公平的自旋锁。
- 性能考量:自旋锁适合于锁的持有时间较短的情况。如果锁的持有时间较长,应该考虑使用传统的阻塞锁机制。
通过这种方式实现的自旋锁可以在一定程度上提高并发性能,特别是在锁的持有时间较短的情况下。然而,对于长时间持有的锁,还是建议使用传统的锁机制来避免不必要的CPU开销。
四、ABA问题
概述
假设有一个变量V
,它的初始值为A
。现在有以下过程:
- 线程T1读取
V
的值为A
。 - 线程T2修改
V
的值为B
。 - 线程T2再次修改
V
的值为A
。 - 线程T1尝试使用CAS操作将
V
的值从A
修改为C
。
在这个过程中,尽管线程T1的CAS操作成功了(因为V
的当前值确实为A
),但实际上V
曾经被修改过,这可能会导致不正确的结果。这就是所谓的ABA问题。
这时候有人可能就会有疑问了,就从结果上来看对于t1线程的执行似乎也没啥问题呀?的确在大多数应用场景下ABA问题并不会带来bug,但在下面这个场景中就不一定了:
比如通过CAS方法来实现ATM的转账功能。
jay有100的存款,想从 ATM 取 50 块钱. 取款机创建了两个线程, 并发的来执⾏ -50 操作。我们期望⼀个线程执⾏ -50 成功, 另⼀个线程 -50 失败。如果使⽤ CAS 的⽅式来完成这个扣款过程就可能出现问题
1. 存款 100. 线程1 获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期望更新为 50.2. 线程1 执⾏扣款成功, 存款被改成 50. 线程2 阻塞等待中.3. 轮到线程2 执⾏了, 发现当前存款为 50, 和之前读到的 100 不相同, 执⾏失败.
1. 存款 100. 线程1 获取到当前存款值为 100, 期望更新为 50; 线程2 获取到当前存款值为 100, 期望更新为 50.2. 线程1 执⾏扣款成功, 存款被改成 50. 线程2 阻塞等待中.3. 在线程2 执⾏之前, jay的朋友正好给jay转账 50, 账⼾余额变成 100 !!4. 轮到线程2 执⾏了, 发现当前存款为 100, 和之前读到的 100 相同, 再次执⾏扣款操作
解决方案
(1)引用“版本号”
引起 ABA 问题的主要原因就是 CAS 能加也能减,导致CAS无法正确判断当前数据是否已经经过修改。但由于上述场景中的余额本身就是能加能减的,这时我们就可以引入新的概念“版本号”。
使用带有版本号的原子引用类型,如 AtomicStampedReference
。这种类型的引用不仅包含了引用本身,还包含了一个版本号或标记。每次修改引用的同时也会更新版本号,这样即使引用值回到原来的值,版本号也会发生变化,从而避免了ABA问题。
import java.util.concurrent.atomic.AtomicStampedReference;public class ABASolutionExample {public static void main(String[] args) {AtomicStampedReference<Integer> ref = new AtomicStampedReference<>(0, 0);// 修改引用值int stamp = ref.getStamp();int reference = ref.getReference();reference = 1; // 修改引用值ref.compareAndSet(reference, reference, stamp, stamp + 1);// 回滚引用值reference = 0;ref.compareAndSet(reference, reference, stamp + 1, stamp + 2);// 尝试修改引用值boolean success = ref.compareAndSet(0, 2, stamp + 2, stamp + 3);System.out.println("CAS operation result: " + success);System.out.println("Current value: " + ref.getReference());}
}
上述代码中,我们创建了一个AtomicStampedReference
,它包含了值0
和版本号0
。通过修改引用值和版本号,我们模拟了ABA问题。在尝试修改引用值时,由于版本号已经发生了变化,所以CAS操作会失败,从而避免了ABA问题的发生
(2)使用带有标记的指针:
- 对于特定的应用场景,可以使用带有标记的指针来解决ABA问题。标记可以是一个额外的字段,用来记录值的版本信息。这种方法类似于使用
AtomicStampedReference
,但需要手动维护标记字段。
(2)使用条件变量:
- 在某些情况下,可以通过引入条件变量来解决ABA问题。条件变量可以帮助线程等待某个条件成立,从而确保在进行CAS操作之前,值确实没有被修改过。
小结
在实际开发中,选择哪种方法来解决ABA问题取决于具体的应用场景和需求。如果ABA问题导致的后果不是特别严重,可以接受ABA问题的存在,因为引入版本号或标记字段会增加系统的复杂性。然而,在需要严格保证一致性的情况下,应该使用带有版本号的原子引用或其他适当的解决方案。
总的来说,解决ABA问题的关键在于引入某种形式的版本控制或标记机制,以确保即使值回到了原来的状态,也能识别出它曾经被修改过。这样可以有效地防止由于ABA问题导致的数据一致性问题。
总结
CAS作为一种高效的原子操作,对于并发编程有着重要的意义。它可以提高程序的并发性能,减少锁带来的开销。然而,它也存在一些固有的局限性,比如ABA问题、循环重试导致的CPU消耗等问题。在实际应用中,应根据具体的使用场景和需求来权衡是否使用CAS,以及如何合理地使用CAS来实现高效、可靠的并发控制。同时,可以结合其他同步机制来弥补CAS的不足,以达到更好的并发效果。
那么本篇文章就到此为止了,如果觉得这篇文章对你有帮助的话,可以点一下关注和点赞来支持作者哦。作者还是一个萌新,如果有什么讲的不对的地方欢迎在评论区指出,希望能够和你们一起进步✊