前言

生活中我們看待一個(gè)事物總有不同的態(tài)度，比如半瓶水，悲觀的人會(huì)覺(jué)得只有半瓶水了，而樂(lè)觀的人則會(huì)認(rèn)為還有半瓶水呢。很多技術(shù)思想往往源于生活，因此在多個(gè)線程并發(fā)訪問(wèn)數(shù)據(jù)的時(shí)候，有了悲觀鎖和樂(lè)觀鎖。

• 悲觀鎖認(rèn)為這個(gè)數(shù)據(jù)肯定會(huì)被其他線程給修改了，那我就給它上鎖，只能自己訪問(wèn)，要等我訪問(wèn)完，其他人才能訪問(wèn)，我上鎖、解鎖都得花費(fèi)我時(shí)間。
• 樂(lè)觀鎖認(rèn)為這個(gè)數(shù)據(jù)不會(huì)被修改，我就直接訪問(wèn)，當(dāng)我發(fā)現(xiàn)數(shù)據(jù)真的修改了，那我也“禮貌的”讓自己訪問(wèn)失敗。

悲觀鎖和樂(lè)觀鎖其實(shí)本質(zhì)都是一種思想，在JAVA中對(duì)于悲觀鎖的實(shí)現(xiàn)大家可能都很了解，可以通過(guò)synchronized、ReentrantLock加鎖實(shí)現(xiàn)，本文不展開(kāi)講解了。那么樂(lè)觀鎖在JAVA中是如何實(shí)現(xiàn)的呢？底層的實(shí)現(xiàn)機(jī)制又是什么呢？

問(wèn)題引入

我們用一個(gè)賬戶取錢的例子來(lái)說(shuō)明樂(lè)觀鎖和悲觀鎖的問(wèn)題。

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個(gè)線程，每次取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();
        // 打印賬戶余額和花費(fèi)時(shí)間
        log.info("賬戶余額：{}, 花費(fèi)時(shí)間: {}", account.getBalance(), (end-start)/1000_000 + " ms");
    }

賬戶默認(rèn)有10000元，1000個(gè)線程取錢，每次取10元，最后賬戶應(yīng)該還有多少錢呢？

運(yùn)行結(jié)果：

運(yùn)行結(jié)果顯示余額還有150元，顯然出現(xiàn)并發(fā)問(wèn)題。

原因分析:

原因也很簡(jiǎn)單，取錢方法withdraw()的操作balance -= amount;看著就一行代碼，實(shí)際上會(huì)生成多條指令，如下圖所示：

多個(gè)線程運(yùn)行的時(shí)候會(huì)進(jìn)行線程切換，導(dǎo)致這個(gè)操作不是原子性，所以不是線程安全的。

悲觀鎖解決

最簡(jiǎn)單的方法，我想大家都能想到吧，給withdraw()方法加鎖，保證同一時(shí)刻只有一個(gè)線程能夠執(zhí)行這個(gè)方法，保證了原子性。

通過(guò)synchronized關(guān)鍵字加鎖。

運(yùn)行結(jié)果：

運(yùn)行結(jié)果正常，但是花費(fèi)時(shí)間稍微多了一點(diǎn)

樂(lè)觀鎖解決

關(guān)鍵來(lái)了，如果用樂(lè)觀鎖的思想在JAVA中該如何實(shí)現(xiàn)呢？

大致思路就是我默認(rèn)不加任何鎖，我先把余額減掉10元，最后更新余額的時(shí)候，發(fā)現(xiàn)余額和我一開(kāi)始不一樣了，我就丟棄當(dāng)前更新操作，重新讀取余額的值，直到更新成功。

找啊找，最終發(fā)現(xiàn)JDK中的Unsafe方法提供了這樣的方法compareAndSwapInt。

• 先獲取老的余額oldBalance，計(jì)算出新的余額newBalance
• 調(diào)用 unsafe.compareAndSwapInt()方法，如果內(nèi)存中余額屬性的偏移量BALANCE_OFFSET對(duì)應(yīng)的值等于老的余額，說(shuō)明的確沒(méi)有被其他線程訪問(wèn)修改過(guò)，我就大膽的更新為newBalance，退出方法
• 否則的話，我就要進(jìn)入下一次循環(huán)，重新獲取余額計(jì)算。

那么是如何獲取unsafe呢?

靜態(tài)方法中通過(guò)反射的方法獲取，因?yàn)?code>Unsafe類太底層了，它一般不建議程序員直接使用。

這個(gè)Unsafe類的名稱并不是說(shuō)線程不安全的意思，只是這個(gè)類太底層了，不要亂用，對(duì)程序員來(lái)說(shuō)不大安全。

最后別忘了余額balance要加volatile修飾。

主要為了保證可見(jiàn)性，讓線程能夠獲取到其他線程修改的結(jié)果。

運(yùn)行結(jié)果：

余額也為0，正常，而且運(yùn)行速度稍微快了一丟丟

完成代碼：

@Slf4j(topic = "a.AccountCAS")
public class AccountCAS {
    // 余額
    private volatile int balance;
    // Unsafe對(duì)象
    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 對(duì)象中的偏移量，用于 Unsafe 直接訪問(wèn)該屬性
            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更新失敗，繼續(xù)更新
            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個(gè)線程，每次取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();
        // 打印賬戶余額和花費(fèi)時(shí)間
        log.info("賬戶余額：{}, 花費(fèi)時(shí)間: {}", account.getBalance(), (end-start)/1000_000 + " ms");
    }
}

樂(lè)觀鎖改進(jìn)

好麻煩呀，我們自己調(diào)用原生的UnSafe類實(shí)現(xiàn)樂(lè)觀鎖，有什么更好的方式嗎？

當(dāng)然有，其實(shí)JDK給我們封裝了很多基于UnSafe樂(lè)觀鎖實(shí)現(xiàn)的原子類，比如AtomicInteger、AtomicReference等等。我們用AtomicInteger改寫(xiě)下上面的實(shí)現(xiàn)。

• 使用JDK中的原子類AtomicInteger作為余額的類型
• 取錢邏輯直接調(diào)用addAndGet方法

運(yùn)行結(jié)果：

原理：

查看源碼最終也是調(diào)用的Unsafe方法。

CAS機(jī)制

前面的一個(gè)取錢的例子，大家是不是對(duì)樂(lè)觀鎖的思想以及在JAVA中的實(shí)現(xiàn)更深入的認(rèn)識(shí)。

在JAVA中對(duì)這種實(shí)現(xiàn)起了一個(gè)名字，叫做CAS, 全稱Compare And Swap，是不是很形象，先比較，然后再替換。

那CAS的本質(zhì)是什么？

CAS先比較然后再替換，感覺(jué)是有2步，比較和替換，不像是原子性操作，如果不是原子性操作問(wèn)題就可大了。實(shí)際上，CAS本質(zhì)對(duì)應(yīng)的是一條指令，是原子操作。

CAS 的底層是 lock cmpxchg 指令（X86 架構(gòu)），在單核 CPU 和多核 CPU 下都能夠保證【比較-交換】的原子性。

強(qiáng)調(diào)一點(diǎn)，CAS 必須借助 volatile 才能讀取到共享變量的最新值來(lái)實(shí)現(xiàn)【比較并交換】的效果，因?yàn)?code>volatile會(huì)保證變量的可見(jiàn)性。

總結(jié)

結(jié)合 CAS 和 volatile 可以實(shí)現(xiàn)無(wú)鎖并發(fā)，適用于線程數(shù)少、多核 CPU 的場(chǎng)景或者讀多寫(xiě)少的場(chǎng)景。

CAS 是基于樂(lè)觀鎖的思想：最樂(lè)觀的估計(jì)，不怕別的線程來(lái)修改共享變量，就算改了也沒(méi)關(guān)系，我吃虧點(diǎn)再重試唄。

synchronized 是基于悲觀鎖的思想：最悲觀的估計(jì)，得防著其它線程來(lái)修改共享變量，我上了鎖你們都別想改，我改完了解開(kāi)鎖，你們才有機(jī)會(huì)。

CAS 體現(xiàn)的是無(wú)鎖并發(fā)、無(wú)阻塞并發(fā)，請(qǐng)仔細(xì)體會(huì)這兩句話的意思

因?yàn)闆](méi)有使用 synchronized，所以線程不會(huì)陷入阻塞，這是效率提升的因素之一

但如果競(jìng)爭(zhēng)激烈，可以想到重試必然頻繁發(fā)生，反而效率會(huì)受影響

到此這篇關(guān)于詳解JAVA如何實(shí)現(xiàn)樂(lè)觀鎖以及CAS機(jī)制的文章就介紹到這了,更多相關(guān)JAVA樂(lè)觀鎖 CAS機(jī)制內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論