詳解JAVA如何實現(xiàn)樂觀鎖以及CAS機制
前言
生活中我們看待一個事物總有不同的態(tài)度,比如半瓶水,悲觀的人會覺得只有半瓶水了,而樂觀的人則會認(rèn)為還有半瓶水呢。很多技術(shù)思想往往源于生活,因此在多個線程并發(fā)訪問數(shù)據(jù)的時候,有了悲觀鎖和樂觀鎖。
- 悲觀鎖認(rèn)為這個數(shù)據(jù)肯定會被其他線程給修改了,那我就給它上鎖,只能自己訪問,要等我訪問完,其他人才能訪問,我上鎖、解鎖都得花費我時間。
- 樂觀鎖認(rèn)為這個數(shù)據(jù)不會被修改,我就直接訪問,當(dāng)我發(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");
}賬戶默認(rèn)有10000元,1000個線程取錢,每次取10元,最后賬戶應(yīng)該還有多少錢呢?
運行結(jié)果:

運行結(jié)果顯示余額還有150元,顯然出現(xiàn)并發(fā)問題。
原因分析:
原因也很簡單,取錢方法withdraw()的操作balance -= amount;看著就一行代碼,實際上會生成多條指令,如下圖所示:

多個線程運行的時候會進(jìn)行線程切換,導(dǎo)致這個操作不是原子性,所以不是線程安全的。
悲觀鎖解決
最簡單的方法,我想大家都能想到吧,給withdraw()方法加鎖,保證同一時刻只有一個線程能夠執(zhí)行這個方法,保證了原子性。

通過synchronized關(guān)鍵字加鎖。
運行結(jié)果:

運行結(jié)果正常,但是花費時間稍微多了一點
樂觀鎖解決
關(guān)鍵來了,如果用樂觀鎖的思想在JAVA中該如何實現(xiàn)呢?
大致思路就是我默認(rèn)不加任何鎖,我先把余額減掉10元,最后更新余額的時候,發(fā)現(xiàn)余額和我一開始不一樣了,我就丟棄當(dāng)前更新操作,重新讀取余額的值,直到更新成功。
找啊找,最終發(fā)現(xiàn)JDK中的Unsafe方法提供了這樣的方法compareAndSwapInt。

- 先獲取老的余額
oldBalance,計算出新的余額newBalance - 調(diào)用
unsafe.compareAndSwapInt()方法,如果內(nèi)存中余額屬性的偏移量BALANCE_OFFSET對應(yīng)的值等于老的余額,說明的確沒有被其他線程訪問修改過,我就大膽的更新為newBalance,退出方法 - 否則的話,我就要進(jìn)入下一次循環(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");
}
}樂觀鎖改進(jìn)
好麻煩呀,我們自己調(diào)用原生的UnSafe類實現(xiàn)樂觀鎖,有什么更好的方式嗎?
當(dāng)然有,其實JDK給我們封裝了很多基于UnSafe樂觀鎖實現(xiàn)的原子類,比如AtomicInteger、AtomicReference等等。我們用AtomicInteger改寫下上面的實現(xiàn)。

- 使用JDK中的原子類
AtomicInteger作為余額的類型 - 取錢邏輯直接調(diào)用
addAndGet方法
運行結(jié)果:

原理:

查看源碼最終也是調(diào)用的Unsafe方法。
CAS機制
前面的一個取錢的例子,大家是不是對樂觀鎖的思想以及在JAVA中的實現(xiàn)更深入的認(rè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ā),請仔細(xì)體會這兩句話的意思
因為沒有使用 synchronized,所以線程不會陷入阻塞,這是效率提升的因素之一
但如果競爭激烈,可以想到重試必然頻繁發(fā)生,反而效率會受影響
到此這篇關(guān)于詳解JAVA如何實現(xiàn)樂觀鎖以及CAS機制的文章就介紹到這了,更多相關(guān)JAVA樂觀鎖 CAS機制內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Java java.lang.ExceptionInInitializerError 錯誤如何解決
這篇文章主要介紹了 Java java.lang.ExceptionInInitializerError 錯誤如何解決的相關(guān)資料,需要的朋友可以參考下2017-06-06
手把手教你使用IDEA創(chuàng)建多模塊(maven)項目
這篇文章主要給大家介紹了關(guān)于如何使用IDEA創(chuàng)建多模塊(maven)項目的相關(guān)資料,文中通過圖文以及實例代碼介紹的非常詳細(xì),需要的朋友可以參考下2023-07-07
基于java中stack與heap的區(qū)別,java中的垃圾回收機制的相關(guān)介紹
本篇文章小編將為大家介紹,基于java中stack與heap的區(qū)別,java中的垃圾回收機制的相關(guān)介紹,需要的可以參考一下2013-04-04
使用spring-task定時任務(wù)動態(tài)配置修改執(zhí)行時間
這篇文章主要介紹了使用spring-task定時任務(wù)動態(tài)配置修改執(zhí)行時間,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2021-11-11
springboot?項目啟動后無日志輸出直接結(jié)束的解決
這篇文章主要介紹了springboot?項目啟動后無日志輸出直接結(jié)束的解決方案,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2021-12-12

