JUC：CAS（比较并交换）解析

CAS

compareAndSet 比较和换行。

方法内部是原子的（指令级别）。

修改失败会返回false，用原值和最新值进行比较，如果原值被他人修改了返回false，若原值没有被人修改，进行交换，返回true。

当然这里会出现aba问题，加上版本号就可以很好的解决。

while循环直到交换成功。

public void withdraw(Integer amount) {

    while (true) {

        int prev = balance.get();
        int next = prev - amount;
        if (balance.compareAndSet(prev, next)) {
            break;
        }
    }
}     

• CAS 的底层是 lock cmpxchg 指令（X86 架构），在单核 CPU 和多核 CPU 下都能够保证【比较-交换】的原子性。
• 在多核状态下，某个核执行到带 lock 的指令时，CPU 会让总线锁住，当这个核把此指令执行完毕，再开启总线。这个过程中不会被线程的调度机制所打断，保证了多个线程对内存操作的准确性，是原子的。

与volatile关系

cas需要volatile支持，因为我们比较时，需要利用最新值进行比较。
来看看AtomicInteger源码

为什么 cas 比 加锁 效率高

• 无锁情况下，即使重试失败，线程始终在高速运行，没有停歇，而 synchronized 会让线程在没有获得锁的时候，发生上下文切换，进入阻塞。
• 无锁情况下，因为线程要保持运行，需要额外 CPU 的支持，虽然不会进入阻塞，但由于没有分到时间片，仍然会进入可运行状态，还是会导致上下文切换。
• 从阻塞机制变成了非阻塞机制，减少了线程之间等待的时间。
• 所以需要多核cpu才能发挥cas的作用。

cas的特点

结合 CAS 和 volatile 可以实现无锁并发，适用于线程数少、多核 CPU 的场景下。

• CAS 是基于乐观锁的思想：最乐观的估计，不怕别的线程来修改共享变量，就算改了也没关系，我吃亏点再重试呗。
• synchronized 是基于悲观锁的思想：最悲观的估计，得防着其它线程来修改共享变量，我上了锁你们都别想改，我改完了解开锁，你们才有机会。

CAS 体现的是无锁并发、无阻塞并发。

• 因为没有使用 synchronized，所以线程不会陷入阻塞，这是效率提升的因素之一
• 但如果竞争激烈，可以想到重试必然频繁发生，反而效率会受影响。你想想，如果有一堆线程再不断的自旋重试，肯定会造成cpu的浪费。