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

2022-12-05
浙江
本文字数：3449 字
阅读完需：约 11 分钟

欢迎关注专栏【JAVA并发】
更多技术干活尽在个人公众号——JAVA 旭阳

前言

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

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

悲观锁和乐观锁其实本质都是一种思想，在 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 元，最后账户应该还有多少钱呢？

运行结果：

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

原因分析:

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

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

悲观锁解决

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

通过synchronized关键字加锁。

运行结果：

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

乐观锁解决

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

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

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

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

那么是如何获取unsafe呢?

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

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

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

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

运行结果：

余额也为 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改写下上面的实现。

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

运行结果：

原理：

查看源码最终也是调用的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，所以线程不会陷入阻塞，这是效率提升的因素之一
但如果竞争激烈，可以想到重试必然频繁发生，反而效率会受影响

如果本文对你有帮助的话，请留下一个赞吧

发布于: 刚刚阅读数: 4

原文链接:【http://xie.infoq.cn/article/1e2ccfa6998172d29a26a3562】。文章转载请联系作者。

JAVA旭阳

关注

欢迎关注个人公众号—— JAVA旭阳 2018-07-18 加入

旭阳，希望自己能像初升的太阳一样，对任何事情充满希望~~

发布

暂无评论

创作场景

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

前言

问题引入

悲观锁解决

乐观锁解决

乐观锁改进

CAS 机制

总结

JAVA旭阳

评论