Java中鎖的實現(xiàn)和內(nèi)存語義淺析
1. 概述
鎖是Java并發(fā)編程中最重要的同步機制。鎖除了讓臨界區(qū)互斥執(zhí)行外,還可以讓釋放鎖的線程獲取同一個鎖的線程發(fā)送消息。
鎖在實際使用時只是明白鎖限制了并發(fā)訪問, 但是鎖是如何實現(xiàn)并發(fā)訪問的, 同學(xué)們可能不太清楚, 下面這篇文章就來揭開鎖的神秘面紗.
2. 鎖的內(nèi)存語義
- 當(dāng)線程獲取鎖時, JMM會把線程對應(yīng)的本地內(nèi)存置為無效. 從而使得被監(jiān)視器保護的臨界區(qū)的變量必須從主內(nèi)存中讀取.
- 當(dāng)線程釋放鎖時, JMM會把該線程對應(yīng)的本地內(nèi)存中的共享變量刷新到主內(nèi)存中(并不是不釋放鎖就不刷新到主內(nèi)存, 只是釋放鎖時把未刷新到主內(nèi)存中的數(shù)據(jù)刷新到主內(nèi)存).
鎖的內(nèi)存語義與volatile的內(nèi)存語義
- 鎖獲取與volatile讀有相同的內(nèi)存語義.
- 鎖釋放與volatile寫有相同的內(nèi)存語義.
內(nèi)存語義總結(jié)
- 線程A釋放一個鎖, 實質(zhì)上是線程A向接下來將要獲取這個鎖的某個線程發(fā)出了(線程A對共享變量所做修改的)消息.
- 線程B獲取一個鎖, 實質(zhì)上是線程B接收了之前某個線程發(fā)出的(在釋放這個鎖之前對共享變量所做修改的)消息.
- 線程A釋放鎖, 隨后線程B獲取這個鎖, 這個過程實質(zhì)上是線程A通過主內(nèi)存向線程B發(fā)送消息.
3. 鎖內(nèi)存語義的實現(xiàn)
下面以ReentrantLock為例, 獲取到鎖就是把state改為1(不考慮重入), 釋放鎖時改為0.
而加鎖的關(guān)鍵代碼就是
protected final boolean compareAndSetState(int expect, int update) {
return unsafe.compareAndSwapInt(this, stateOffset, expect, update);
}
該方法以原子操作的方式更新state變量, 本文把Java的compareAndSet()方法簡稱為CAS. JDK文檔對該方法的說明如下: 如果當(dāng)前狀態(tài)值等于預(yù)期值, 則以原子方式將同步狀態(tài)設(shè)置為給定的更新值. 此操作具有volatile讀和寫的內(nèi)存語義.
這里我們分別從編譯器和處理器的角度來分析: CAS如何同時具有volatile讀和volatile寫的內(nèi)存語義.
我們知道, 編譯器不會對volatile讀與volatile讀后面的任意內(nèi)存操作重排序; 編譯器不會對volatile寫與volatile寫前面的任意內(nèi)存操作重排序. 組合這兩個條件, 意味著為了同時實現(xiàn)volatile讀和volatile寫的內(nèi)存語義, 編譯器不能對CAS與CAS前面和后面的任意內(nèi)存操作重排序.
下面我們來分析在常見的intel X86處理器中, CAS是如何同時具有volatile讀和volatile寫的內(nèi)存語義的.
下面是sun.misc.Unsafe類的compareAndSwapInt()方法的源代碼.
public final native boolean compareAndSwapInt(Object var1, long var2, int var4, int var5);
可以看到, 這是一個本地方法調(diào)用. 這個本地方法在openjdk中依次調(diào)用的c++代碼為: unsafe.cpp, atomic.cpp 和 atomic_windows_x86.inline.hpp. 這個本地方法的最終實現(xiàn)在openjdk的如下位置: openjdk-7-fcs-src-b147-
27_jun_2011\openjdk\hotspot\src\os_cpu\windows_x86\vm\atomic_windows_x86.inline.hpp(對應(yīng)于
Windows操作系統(tǒng), X86處理器). 下面是對應(yīng)于intel X86處理器的源代碼的片段.
inline jint Atomic::cmpxchg (jint exchange_value, volatile jint* dest, jint compare_value) {
// alternative for InterlockedCompareExchange
int mp = os::is_MP();
__asm {
mov edx, dest
mov ecx, exchange_value
mov eax, compare_value
LOCK_IF_MP(mp)
cmpxchg dword ptr [edx], ecx
}
}
如上面源代碼所示, 程序會根據(jù)當(dāng)前處理器的類型來決定是否為cmpxchg指令添加lock前綴. 如果程序是在多處理器上運行, 就為cmpxchg指令加上lock前綴(Lock Cmpxchg). 反之, 如果程序是在單處理器上運行, 就省略lock前綴(單處理器自身會維護單處理器內(nèi)的順序一致性, 不需要lock前綴提供的內(nèi)存屏障效果).
intel的手冊對lock前綴的說明如下.
- 確保對內(nèi)存的讀-改-寫操作原子執(zhí)行. 在Pentium及Pentium之前的處理器中, 帶有l(wèi)ock前綴的指令在執(zhí)行期間會鎖住總線, 使得其他處理器暫時無法通過總線訪問內(nèi)存. 很顯然, 這會帶來昂貴的開銷. 從Pentium 4、Intel Xeon及P6處理器開始, Intel使用緩存鎖定(Cache Locking)
來保證指令執(zhí)行的原子性. 緩存鎖定將大大降低lock前綴指令的執(zhí)行開銷. - 禁止該指令, 與之前和之后的讀和寫指令重排序.
- 把寫緩沖區(qū)中的所有數(shù)據(jù)刷新到內(nèi)存中.
上面的第2點和第3點所具有的內(nèi)存屏障效果, 足以同時實現(xiàn)volatile讀和volatile寫的內(nèi)存語義.
經(jīng)過上面的分析, 現(xiàn)在我們終于能明白為什么JDK文檔說CAS同時具有volatile讀和volatile寫的內(nèi)存語義了.
從本文對ReentrantLock的分析可以看出, 鎖釋放-獲取的內(nèi)存語義的實現(xiàn)至少有下面兩種方式.
- 利用volatile變量的寫-讀所具有的內(nèi)存語義.
- 利用CAS所附帶的volatile讀和volatile寫的內(nèi)存語義.
4. 總結(jié)
對于鎖, 可以這么理解, N個線程去通過CAS去修改一個volatile變量, 但是由于CPU提供的機制, 只能有一個線程修改成功, 修改成功的線程獲得鎖, 其它線程以及后來的線程要么自旋一會兒, 要么直接掛起, 等待獲取鎖的線程釋放鎖時去喚醒. 就是這么個過程.
好了,以上就是這篇文章的全部內(nèi)容了,希望本文的內(nèi)容對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價值,如果有疑問大家可以留言交流,謝謝大家對腳本之家的支持。
相關(guān)文章
MyBatis實現(xiàn)表連接查詢寫法(三種對應(yīng)關(guān)系)的方法總結(jié)
這篇文章主要介紹了MyBatis實現(xiàn)表連接查詢寫法(一對一關(guān)系、一對多關(guān)系、多對多關(guān)系)的方法,文中的示例代碼講解詳細,感興趣的可以了解一下2023-01-01
springboot themaleaf 第一次進頁面不加載css的問題
這篇文章主要介紹了springboot themaleaf 第一次進頁面不加載css的問題,具有很好的參考價值,希望對大家有所幫助。如有錯誤或未考慮完全的地方,望不吝賜教2022-10-10

