前言 生活中我們看待一個事物總有不同的態度,比如半瓶水,悲觀的人會覺得只有半瓶水了,而樂觀的人則會認為還有半瓶水呢。很多技術思想往往源於生活,因此在多個線程併發訪問數據的時候,有了悲觀鎖和樂觀鎖。 悲觀鎖認為這個數據肯定會被其他線程給修改了,那我就給它上鎖,只能自己訪問,要等我訪問完,其他人才能訪問 ...
前言
生活中我們看待一個事物總有不同的態度,比如半瓶水,悲觀的人會覺得只有半瓶水了,而樂觀的人則會認為還有半瓶水呢。很多技術思想往往源於生活,因此在多個線程併發訪問數據的時候,有了悲觀鎖和樂觀鎖。
- 悲觀鎖認為這個數據肯定會被其他線程給修改了,那我就給它上鎖,只能自己訪問,要等我訪問完,其他人才能訪問,我上鎖、解鎖都得花費我時間。
- 樂觀鎖認為這個數據不會被修改,我就直接訪問,當我發現數據真的修改了,那我也“禮貌的”讓自己訪問失敗。
悲觀鎖和樂觀鎖其實本質都是一種思想,在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
,所以線程不會陷入阻塞,這是效率提升的因素之一 - 但如果競爭激烈,可以想到重試必然頻繁發生,反而效率會受影響
- 因為沒有使用
更多技術幹活盡在個人公眾號——JAVA旭陽
本文來自博客園,作者:JAVA旭陽,轉載請註明原文鏈接:https://www.cnblogs.com/alvinscript/p/16952679.html