JavaCAS（Compare-And-Swap）操作 - 智猿学院-前后端，数据库，人工智能，云计算等领域前沿技术讲座

Java CAS：一场原子性的华尔兹，舞动并发世界的优雅

各位观众老爷，晚上好！欢迎来到今晚的并发编程脱口秀，我是你们的老朋友，人称“并发小王子”的码农老王。今天，咱们不聊高并发架构，也不谈微服务拆分，咱们就聊聊并发世界里一颗闪耀的原子：Java CAS（Compare-And-Swap）。

提起并发，那绝对是一场惊心动魄的冒险。多线程就像一群精力旺盛的孩子，在一个共享的玩具箱（内存）里抢玩具，一不小心就会发生碰撞，导致数据错乱，程序崩溃。为了维持秩序，我们需要一些“交通规则”，而 CAS，就是并发世界里最重要的交通规则之一。

第一幕：锁的困境——爱恨交织的“交通警察”

在并发编程的早期，为了保证数据的一致性，人们祭出了“锁”这把利器。锁，就像一位尽职尽责的交通警察，每次只允许一个线程进入临界区（共享资源），其他线程乖乖排队等待。

锁的好处显而易见：安全可靠，简单易懂。但是，锁也有它的局限性，就像交通警察也有下班的时候一样。

性能瓶颈： 线程在获取锁的时候，需要进行上下文切换，这是一个非常耗时的操作。就好比你开车去上班，每次都要在收费站排队，效率可想而知。
死锁风险： 多个线程互相持有对方需要的锁，导致所有线程都无法继续执行，形成死锁。这就像几辆车在十字路口互相堵住，谁也走不了。
饥饿现象： 某个线程总是无法获取到锁，导致一直处于等待状态。这就像你去餐馆吃饭，每次都排在最后，眼巴巴地看着别人吃饱喝足。

因此，我们需要一种更轻量级、更高效的并发控制机制，来打破锁的困境。这个时候，我们的主角——CAS，闪亮登场了！

第二幕：CAS的登场——轻盈优雅的“舞者”

CAS，全称Compare-And-Swap，翻译过来就是“比较并交换”。它是一种基于硬件指令实现的原子操作，无需加锁，即可实现对共享变量的原子更新。

你可以把CAS想象成一个熟练的舞者，在并发的世界里，优雅地旋转、跳跃，完成各种高难度动作，而这一切，都在瞬间完成，没有任何阻塞。

CAS的工作原理可以用以下伪代码来表示：

// 假设我们要更新变量value，期望值为expectedValue，新值为newValue
boolean compareAndSwap(value, expectedValue, newValue) {
  // 1. 读取当前value的值
  int currentValue = value;

  // 2. 比较当前值和期望值是否相等
  if (currentValue == expectedValue) {
    // 3. 如果相等，则将value更新为newValue，并返回true
    value = newValue;
    return true;
  } else {
    // 4. 如果不相等，则说明value已经被其他线程修改，更新失败，返回false
    return false;
  }
}

简单来说，CAS操作包含三个操作数：

V（Value）： 要更新的变量的内存地址。
E（Expected）： 期望的值。
N（New）： 新的值。

CAS操作会原子性地执行以下步骤：

将V的当前值与E进行比较。
如果V的当前值等于E，则将V的值更新为N。
如果V的当前值不等于E，则不进行任何操作。

CAS操作会返回一个布尔值，表示更新是否成功。如果返回true，则表示更新成功；如果返回false，则表示更新失败。

用一个生动的例子来解释：

假设你和你的朋友同时想给一个罐子里放糖果。罐子当前有5颗糖果，你们都想放3颗进去，最终罐子里应该有8颗糖果。

使用锁： 你们需要先竞争锁，谁抢到锁，谁才能放糖果。另一个朋友只能等待。
使用CAS： 你们同时检查罐子里的糖果数量是不是5颗。如果都是5颗，你们就同时尝试把糖果放进去。但是，只有一个人的操作会成功，另一个人的操作会失败。失败的朋友需要重新读取罐子里的糖果数量，再次尝试。

用表格来总结锁和CAS的优缺点：

特性	锁	CAS
实现方式	基于操作系统内核提供的互斥机制	基于硬件指令实现的原子操作
性能	竞争激烈时性能较低，存在上下文切换开销	竞争不激烈时性能较高，无上下文切换开销
阻塞	阻塞	非阻塞
使用难度	简单易懂	相对复杂，需要理解CAS的原理和使用场景
适用场景	临界区代码执行时间较长，竞争激烈的场景	临界区代码执行时间较短，竞争不激烈的场景

第三幕：CAS的应用——并发世界的百变金刚

CAS的应用非常广泛，几乎所有高性能的并发工具类都离不开CAS的身影。

AtomicInteger： Java并发包（java.util.concurrent）提供了一系列原子类，例如AtomicInteger、AtomicLong、AtomicBoolean等。这些原子类都是基于CAS实现的，可以保证对单个变量的原子操作。例如：

AtomicInteger atomicInteger = new AtomicInteger(0);

// 使用CAS原子性地增加1
atomicInteger.compareAndSet(atomicInteger.get(), atomicInteger.get() + 1);

ConcurrentHashMap： ConcurrentHashMap是Java并发包中提供的一个线程安全的HashMap。它的实现也大量使用了CAS操作，例如在添加新的键值对时，会使用CAS来保证原子性。
AQS（AbstractQueuedSynchronizer）： AQS是Java并发包中一个重要的同步器框架，ReentrantLock、Semaphore、CountDownLatch等都是基于AQS实现的。AQS内部也使用了CAS操作来管理同步状态。

举个例子：使用CAS实现一个简单的计数器

public class Counter {
    private volatile int count = 0;

    public int getCount() {
        return count;
    }

    public void increment() {
        int expectedValue;
        int newValue;
        do {
            expectedValue = getCount();
            newValue = expectedValue + 1;
        } while (!compareAndSet(expectedValue, newValue));
    }

    private synchronized boolean compareAndSet(int expectedValue, int newValue) {
        if (count == expectedValue) {
            count = newValue;
            return true;
        } else {
            return false;
        }
    }

    public static void main(String[] args) throws InterruptedException {
        Counter counter = new Counter();
        int threadCount = 10;
        int incrementCount = 1000;

        Thread[] threads = new Thread[threadCount];
        for (int i = 0; i < threadCount; i++) {
            threads[i] = new Thread(() -> {
                for (int j = 0; j < incrementCount; j++) {
                    counter.increment();
                }
            });
            threads[i].start();
        }

        for (Thread thread : threads) {
            thread.join();
        }

        System.out.println("最终计数结果：" + counter.getCount());
    }
}

在这个例子中，increment()方法使用了CAS操作来原子性地增加计数器的值。compareAndSet()方法模拟了CAS操作，它首先读取当前的计数器值，然后比较当前值和期望值是否相等。如果相等，则将计数器值更新为新值，并返回true；否则，返回false。increment()方法会不断循环，直到CAS操作成功为止。

第四幕：ABA问题——隐藏在优雅背后的陷阱

CAS虽然优雅高效，但它也存在一个著名的缺陷：ABA问题。

什么是ABA问题？

假设有两个线程同时操作一个变量V，初始值为A。

线程1读取V的值为A。
线程2将V的值修改为B。
线程2又将V的值修改回A。
线程1尝试使用CAS将V的值从A修改为C，由于V的值仍然是A，CAS操作成功。

虽然线程1的CAS操作成功了，但是V的值实际上已经被修改过了。这就像你借了一辆自行车给朋友，朋友骑出去溜了一圈又还回来了，虽然自行车还是那辆自行车，但是它可能已经被换过零件了。

如何解决ABA问题？

解决ABA问题的常用方法是引入版本号（Version）。每次修改变量的值时，都将版本号加1。这样，即使变量的值又变回了原来的值，版本号也已经发生了变化，CAS操作就可以检测到这种变化。

例如，我们可以使用AtomicStampedReference来解决ABA问题：

AtomicStampedReference<Integer> atomicStampedReference = new AtomicStampedReference<>(100, 1);

int expectedValue = atomicStampedReference.getReference();
int expectedStamp = atomicStampedReference.getStamp();

// 线程尝试将值从100修改为200，版本号加1
boolean success = atomicStampedReference.compareAndSet(expectedValue, 200, expectedStamp, expectedStamp + 1);

if (success) {
    System.out.println("修改成功");
} else {
    System.out.println("修改失败");
}

在这个例子中，AtomicStampedReference维护了一个值和一个版本号。compareAndSet()方法会同时比较值和版本号，只有当值和版本号都与期望值相等时，才会更新值和版本号。

第五幕：CAS的适用场景——并非万能钥匙

虽然CAS在某些场景下可以替代锁，提高并发性能，但它并非万能钥匙。

竞争不激烈： CAS适用于竞争不激烈的场景，因为如果竞争激烈，CAS操作会频繁失败，导致线程不断重试，反而降低性能。
临界区代码简单： CAS适用于临界区代码简单的场景，因为如果临界区代码复杂，CAS操作的逻辑也会变得复杂，容易出错。
ABA问题可控： CAS适用于ABA问题可控的场景，或者可以使用AtomicStampedReference来解决ABA问题。

总结：

CAS是一种轻量级、高效的并发控制机制，它可以替代锁，提高并发性能。但是，CAS也存在ABA问题，并且并非适用于所有场景。在实际应用中，我们需要根据具体情况选择合适的并发控制机制。

最后，用一句名言来结束今天的脱口秀：

“并发编程就像一场优雅的华尔兹，CAS是舞池里最灵动的舞者，但是，只有掌握了正确的舞步，才能舞出并发世界的精彩！”

谢谢大家！我们下期再见！ 🎤✨

Java CAS：一场原子性的华尔兹，舞动并发世界的优雅

发表回复 取消回复

发表回复取消回复