詳解JAVA如何實現(xiàn)樂觀鎖以及CAS機制
前言
生活中我們看待一個事物總有不同的態(tài)度,比如半瓶水,悲觀的人會覺得只有半瓶水了,而樂觀的人則會認為還有半瓶水呢。很多技術(shù)思想往往源于生活,因此在多個線程并發(fā)訪問數(shù)據(jù)的時候,有了悲觀鎖和樂觀鎖。
- 悲觀鎖認為這個數(shù)據(jù)肯定會被其他線程給修改了,那我就給它上鎖,只能自己訪問,要等我訪問完,其他人才能訪問,我上鎖、解鎖都得花費我時間。
- 樂觀鎖認為這個數(shù)據(jù)不會被修改,我就直接訪問,當我發(fā)現(xiàn)數(shù)據(jù)真的修改了,那我也“禮貌的”讓自己訪問失敗。
悲觀鎖和樂觀鎖其實本質(zhì)都是一種思想,在JAVA中對于悲觀鎖的實現(xiàn)大家可能都很了解,可以通過synchronized
、ReentrantLock
加鎖實現(xiàn),本文不展開講解了。那么樂觀鎖在JAVA中是如何實現(xiàn)的呢?底層的實現(xià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個線程,每次取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元,最后賬戶應(yīng)該還有多少錢呢?
運行結(jié)果:
運行結(jié)果顯示余額還有150元,顯然出現(xiàn)并發(fā)問題。
原因分析:
原因也很簡單,取錢方法withdraw()
的操作balance -= amount;
看著就一行代碼,實際上會生成多條指令,如下圖所示:
多個線程運行的時候會進行線程切換,導(dǎo)致這個操作不是原子性,所以不是線程安全的。
悲觀鎖解決
最簡單的方法,我想大家都能想到吧,給withdraw()
方法加鎖,保證同一時刻只有一個線程能夠執(zhí)行這個方法,保證了原子性。
通過synchronized
關(guān)鍵字加鎖。
運行結(jié)果:
運行結(jié)果正常,但是花費時間稍微多了一點
樂觀鎖解決
關(guān)鍵來了,如果用樂觀鎖的思想在JAVA中該如何實現(xiàn)呢?
大致思路就是我默認不加任何鎖,我先把余額減掉10元,最后更新余額的時候,發(fā)現(xiàn)余額和我一開始不一樣了,我就丟棄當前更新操作,重新讀取余額的值,直到更新成功。
找啊找,最終發(fā)現(xiàn)JDK中的Unsafe
方法提供了這樣的方法compareAndSwapInt
。
- 先獲取老的余額
oldBalance
,計算出新的余額newBalance
- 調(diào)用
unsafe.compareAndSwapInt()
方法,如果內(nèi)存中余額屬性的偏移量BALANCE_OFFSET
對應(yīng)的值等于老的余額,說明的確沒有被其他線程訪問修改過,我就大膽的更新為newBalance
,退出方法 - 否則的話,我就要進入下一次循環(huán),重新獲取余額計算。
那么是如何獲取unsafe
呢?
靜態(tài)方法中通過反射的方法獲取,因為Unsafe
類太底層了,它一般不建議程序員直接使用。
這個Unsafe類的名稱并不是說線程不安全的意思,只是這個類太底層了,不要亂用,對程序員來說不大安全。
最后別忘了余額balance
要加volatile修飾。
主要為了保證可見性,讓線程能夠獲取到其他線程修改的結(jié)果。
運行結(jié)果:
余額也為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更新失敗,繼續(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個線程,每次取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"); } }
樂觀鎖改進
好麻煩呀,我們自己調(diào)用原生的UnSafe
類實現(xiàn)樂觀鎖,有什么更好的方式嗎?
當然有,其實JDK給我們封裝了很多基于UnSafe
樂觀鎖實現(xiàn)的原子類,比如AtomicInteger
、AtomicReference
等等。我們用AtomicInteger
改寫下上面的實現(xiàn)。
- 使用JDK中的原子類
AtomicInteger
作為余額的類型 - 取錢邏輯直接調(diào)用
addAndGet
方法
運行結(jié)果:
原理:
查看源碼最終也是調(diào)用的Unsafe
方法。
CAS機制
前面的一個取錢的例子,大家是不是對樂觀鎖的思想以及在JAVA中的實現(xiàn)更深入的認識。
在JAVA中對這種實現(xiàn)起了一個名字,叫做CAS, 全稱Compare And Swap
,是不是很形象,先比較,然后再替換。
那CAS的本質(zhì)是什么?
CAS先比較然后再替換,感覺是有2步,比較和替換,不像是原子性操作,如果不是原子性操作問題就可大了。實際上,CAS本質(zhì)對應(yīng)的是一條指令,是原子操作。
CAS 的底層是 lock cmpxchg 指令(X86 架構(gòu)),在單核 CPU 和多核 CPU 下都能夠保證【比較-交換】的原子性。
強調(diào)一點,CAS 必須借助 volatile
才能讀取到共享變量的最新值來實現(xiàn)【比較并交換】的效果,因為volatile
會保證變量的可見性。
總結(jié)
結(jié)合 CAS 和 volatile 可以實現(xiàn)無鎖并發(fā),適用于線程數(shù)少、多核 CPU 的場景或者讀多寫少的場景。
CAS 是基于樂觀鎖的思想:最樂觀的估計,不怕別的線程來修改共享變量,就算改了也沒關(guān)系,我吃虧點再重試唄。
synchronized
是基于悲觀鎖的思想:最悲觀的估計,得防著其它線程來修改共享變量,我上了鎖你們都別想改,我改完了解開鎖,你們才有機會。
CAS 體現(xiàn)的是無鎖并發(fā)、無阻塞并發(fā),請仔細體會這兩句話的意思
因為沒有使用 synchronized
,所以線程不會陷入阻塞,這是效率提升的因素之一
但如果競爭激烈,可以想到重試必然頻繁發(fā)生,反而效率會受影響
到此這篇關(guān)于詳解JAVA如何實現(xiàn)樂觀鎖以及CAS機制的文章就介紹到這了,更多相關(guān)JAVA樂觀鎖 CAS機制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
使用Java實現(xiàn)類似Comet風(fēng)格的web app
這篇文章主要介紹了使用Java實現(xiàn)類似Comet風(fēng)格的web app的方法,包括客戶端的響應(yīng)和XML解析等功能,需要的朋友可以參考下2015-11-11Shiro整合Springboot和redis,jwt過程中的錯誤shiroFilterChainDefinition問
這篇文章主要介紹了Shiro整合Springboot和redis,jwt過程中的錯誤shiroFilterChainDefinition問題,具有很好的參考價值,希望對大家有所幫助,如有錯誤或未考慮完全的地方,望不吝賜教2024-04-04