乐观锁思想在JAVA中的实现——CAS

青旅半醒 2023-09-26 17:41 135阅读 0赞

### 前言 ###

生活中我们看待一个事物总有不同的态度，比如半瓶水，悲观的人会觉得**只有**半瓶水了，而乐观的人则会认为**还有**半瓶水呢。很多技术思想往往源于生活，因此在多个线程并发访问数据的时候，有了悲观锁和乐观锁。

*  **悲观锁**认为这个数据肯定会被其他线程给修改了，那我就给它上锁，只能自己访问，要等我访问完，其他人才能访问，我上锁、解锁都得花费我时间。
 *  **乐观锁**认为这个数据不会被修改，我就直接访问，当我发现数据真的修改了，那我也“礼貌的”让自己访问失败。

悲观锁和乐观锁其实本质都是一种思想，在JAVA中对于悲观锁的实现大家可能都很了解，可以通过`synchronized`、`ReentrantLock`加锁实现，本文不展开讲解了。那么乐观锁在JAVA中是如何实现的呢？底层的实现机制又是什么呢？

### 问题引入 ###

我们用一个账户取钱的例子来说明乐观锁和悲观锁的问题。

public class AccountUnsafe {
         // 余额
         private Integer balance;
        
         public AccountUnsafe(Integer balance) {
         	this.balance = balance;
         }
        
        @Override
         public Integer getBalance() {
         	return balance;
         }
        
         @Override
         public void withdraw(Integer amount) {
         	balance -= amount;
         }
    }
    复制代码

*  账户类，`withdraw()`方法是取钱方法。

public static void main(String[] args) {
            // 账户10000元
            AccountUnsafe account = new AccountUnsafe(10000);
            List<Thread> ts = new ArrayList<>();
            long start = System.nanoTime();
            // 1000个线程，每次取10元
            for (int i = 0; i < 1000; i++) {
                ts.add(new Thread(() -> {
                    account.withdraw(10);
                }));
            }
            ts.forEach(Thread::start);
            ts.forEach(t -> {
                try {
                    t.join();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
            long end = System.nanoTime();
            // 打印账户余额和花费时间
            log.info("账户余额：{}, 花费时间: {}", account.getBalance(), (end-start)/1000_000 + " ms");
        }
    复制代码

*  账户默认有10000元，1000个线程取钱，每次取10元，最后账户应该还有多少钱呢？

**运行结果：**

![format_png][]

*  运行结果显示余额还有150元，显然**出现并发问题**。

**原因分析:**

原因也很简单，取钱方法`withdraw()`的操作`balance -= amount;`看着就一行代码，实际上会生成多条指令，如下图所示：

![format_png 1][]

多个线程运行的时候会进行线程切换，导致这个操作不是**原子性**，所以不是线程安全的。

#### 悲观锁解决 ####

最简单的方法，我想大家都能想到吧，给`withdraw()`方法加锁，保证同一时刻只有一个线程能够执行这个方法，保证了原子性。

![format_png 2][]

*  通过`synchronized`关键字加锁。

**运行结果：**

![format_png 3][]

*  运行结果正常，但是花费时间稍微多了一点

#### 乐观锁解决 ####

关键来了，如果用乐观锁的思想在JAVA中该如何实现呢？

大致思路就是我默认不加任何锁，我先把余额减掉10元，最后更新余额的时候，发现余额和我一开始不一样了，我就丢弃当前更新操作，重新读取余额的值，直到更新成功。

找啊找，最终发现JDK中的`Unsafe`方法提供了这样的方法`compareAndSwapInt`。

![format_png 4][]

*  先获取老的余额`oldBalance`，计算出新的余额`newBalance`
 *  调用 `unsafe.compareAndSwapInt()`方法，如果内存中余额属性的偏移量`BALANCE_OFFSET`对应的值等于老的余额，说明的确没有被其他线程访问修改过，我就大胆的更新为`newBalance`，退出方法
 *  否则的话，我就要进入下一次循环，重新获取余额计算。

**那么是如何获取**`unsafe`**呢?**

![format_png 5][]

*  静态方法中通过反射的方法获取，因为`Unsafe`类太底层了，它一般不建议程序员直接使用。

这个Unsafe类的名称并不是说线程不安全的意思，只是这个类太底层了，不要乱用，对程序员来说不大安全。

**最后别忘了余额**`balance`**要加volatile修饰。**

![format_png 6][]

*  主要为了保证可见性，让线程能够获取到其他线程修改的结果。

**运行结果：**

![format_png 7][]

*  余额也为0，正常，而且运行速度稍微快了一丢丢

**完成代码：**

@Slf4j(topic = "a.AccountCAS")
    public class AccountCAS {
        // 余额
        private volatile int balance;
        // Unsafe对象
        static final Unsafe unsafe;
        // balance 字段的偏移量
        static final long BALANCE_OFFSET;
        static {
            try {
                Field theUnsafe = Unsafe.class.getDeclaredField("theUnsafe");
                theUnsafe.setAccessible(true);
                unsafe = (Unsafe) theUnsafe.get(null);
                // balance 属性在 AccountCAS 对象中的偏移量，用于 Unsafe 直接访问该属性
                BALANCE_OFFSET = unsafe.objectFieldOffset(AccountCAS.class.getDeclaredField("balance"));
            } catch (NoSuchFieldException | IllegalAccessException e) {
                throw new Error(e);
            }
        }
    
        public AccountCAS(Integer balance) {
            this.balance = balance;
        }
    
        public int getBalance() {
            return balance;
        }
    
        public void withdraw(Integer amount) {
            // 自旋
            while (true) {
                // 获取老的余额
                int oldBalance = balance;
                // 获取新的余额
                int newBalance = oldBalance - amount;
                // 更新余额，BALANCE_OFFSET表示balance属性的偏移量， 返回true表示更新成功， false更新失败，继续更新
                if(unsafe.compareAndSwapInt(this, BALANCE_OFFSET, oldBalance, newBalance)) {
                    return;
                }
            }
        }
    
        public static void main(String[] args) {
            // 账户10000元
            AccountCAS account = new AccountCAS(10000);
            List<Thread> ts = new ArrayList<>();
            long start = System.nanoTime();
            // 1000个线程，每次取10元
            for (int i = 0; i < 1000; i++) {
                ts.add(new Thread(() -> {
                    account.withdraw(10);
                }));
            }
            ts.forEach(Thread::start);
            ts.forEach(t -> {
                try {
                    t.join();
                } catch (InterruptedException e) {
                    e.printStackTrace();
                }
            });
            long end = System.nanoTime();
            // 打印账户余额和花费时间
            log.info("账户余额：{}, 花费时间: {}", account.getBalance(), (end-start)/1000_000 + " ms");
        }
    }
    复制代码

#### 乐观锁改进 ####

好麻烦呀，我们自己调用原生的`UnSafe`类实现乐观锁，有什么更好的方式吗？

当然有，其实JDK给我们封装了很多基于`UnSafe`乐观锁实现的原子类，比如`AtomicInteger`、`AtomicReference`等等。我们用`AtomicInteger`改写下上面的实现。

![format_png 8][]

*  使用JDK中的原子类`AtomicInteger`作为余额的类型
 *  取钱逻辑直接调用`addAndGet`方法

**运行结果：**

![format_png 9][]

**原理：**

![format_png 10][]

查看源码最终也是调用的`Unsafe`方法。

### CAS机制 ###

前面的一个取钱的例子，大家是不是对乐观锁的思想以及在JAVA中的实现更深入的认识。

在JAVA中对这种实现起了一个名字，叫做CAS, 全称`Compare And Swap`，是不是很形象，先比较，然后再替换。

**那CAS的本质是什么？**

CAS先比较然后再替换，感觉是有2步，比较和替换，不像是原子性操作，如果不是原子性操作问题就可大了。实际上，CAS本质对应的是一条指令，是**原子操作**。

> CAS 的底层是 lock cmpxchg 指令（X86 架构），在单核 CPU 和多核 CPU 下都能够保证【比较-交换】的原子性。

强调一点，CAS 必须借助 `volatile` 才能读取到共享变量的最新值来实现【比较并交换】的效果，因为`volatile`会保证变量的可见性。

### 总结 ###

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

*  CAS 是基于乐观锁的思想：最乐观的估计，不怕别的线程来修改共享变量，就算改了也没关系，我吃亏点再重试呗。
 *  `synchronized` 是基于悲观锁的思想：最悲观的估计，得防着其它线程来修改共享变量，我上了锁你们都别想改，我改完了解开锁，你们才有机会。
 *  CAS 体现的是无锁并发、无阻塞并发，请仔细体会这两句话的意思

*   *  因为没有使用 `synchronized`，所以线程不会陷入阻塞，这是效率提升的因素之一
     *  但如果竞争激烈，可以想到重试必然频繁发生，反而效率会受影响

[format_png]: https://img-blog.csdnimg.cn/img_convert/feb59f6e1e8c12771c6d4b53a33451ff.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/3da191676b3a5e5af38481cb19b04b1c.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/5524369974d8ba0f30d469cd6583143d.webp?x-oss-process=image/format,png
[format_png 3]: https://img-blog.csdnimg.cn/img_convert/871064700a01dbb44ca8ace801f93a45.webp?x-oss-process=image/format,png
[format_png 4]: https://img-blog.csdnimg.cn/img_convert/1ccceeeb1c21fb0dca3775f9c84538f4.webp?x-oss-process=image/format,png
[format_png 5]: https://img-blog.csdnimg.cn/img_convert/757eddbf4b8de5e90bd14240400ec6d7.webp?x-oss-process=image/format,png
[format_png 6]: https://img-blog.csdnimg.cn/img_convert/e5f83d5d766eb5112d46f3058700530e.webp?x-oss-process=image/format,png
[format_png 7]: https://img-blog.csdnimg.cn/img_convert/dccc19f0dfb269391a35851763775224.webp?x-oss-process=image/format,png
[format_png 8]: https://img-blog.csdnimg.cn/img_convert/eff91405f8da484e8455c6a1506b22de.webp?x-oss-process=image/format,png
[format_png 9]: https://img-blog.csdnimg.cn/img_convert/6865b2b0bee1053bd65d8bd54dc2eede.webp?x-oss-process=image/format,png
[format_png 10]: https://img-blog.csdnimg.cn/img_convert/17af3eb656f8f29cc2097d79455dafd4.webp?x-oss-process=image/format,png