💐个人主页：初晴~
📚相关专栏：多线程 / 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的不足，以达到更好的并发效果。
那么本篇文章就到此为止了，如果觉得这篇文章对你有帮助的话，可以点一下关注和点赞来支持作者哦。作者还是一个萌新，如果有什么讲的不对的地方欢迎在评论区指出，希望能够和你们一起进步✊
