Java 中15種鎖的介紹
在讀很多並發文章中,會提及各種樣鎖如公平鎖,樂觀鎖等等,這篇文章介紹各種鎖的分類。介紹的內容如下:
公平鎖 / 非公平鎖
可重入鎖 / 不可重入鎖定
# 獨享鎖 / 共享鎖定
互斥鎖 / 讀寫鎖定
樂觀鎖 / 悲觀鎖
分段鎖定
# 偏向鎖 / 輕量級鎖定 / 重量級鎖定
自旋鎖定
# 上面是很多鎖的名詞,這些分類並不是全是指鎖的狀態,有的指鎖的特性,有的指鎖的設計,下面總結的內容是對每個鎖的名詞進行一定的解釋。
公平鎖 / 非公平鎖
公平鎖
# 公平鎖是指多個執行緒依照申請鎖的順序來取得鎖。
非公平鎖
# 非公平鎖是指多個執行緒取得鎖的順序並不是依照申請鎖的順序,有可能後申請的執行緒比先申請的執行緒優先取得鎖。有可能,會造成優先反轉或飢餓現象。
對於Java ReentrantLock而言,透過建構子指定該鎖是否為公平鎖,預設為非公平鎖。非公平鎖的優點在於吞吐量比公平鎖大。對Synchronized而言,也是一種非公平鎖。由於其並不像ReentrantLock是透過AQS的來實現執行緒調度,所以並沒有任何辦法使其變成公平鎖。
可重入鎖 / 不可重入鎖定
# 可重入鎖定
廣義的可重入鎖指的是可重複可遞歸呼叫的鎖,在外層使用鎖之後,在內層仍然可以使用,並且不發生死鎖(前提得是同一個物件或class),這樣的鎖就叫做可重入鎖。 ReentrantLock和synchronized都是可重入鎖定
# synchronized void setA() throws Exception{
# Thread.sleep(1000);
# setB();
}
# synchronized void setB() throws Exception{
# Thread.sleep(1000);
# }
# 上面的程式碼就是一個可重入鎖的一個特點,如果不是可重入鎖的話,setB可能不會被當前執行緒執行,可能造成死鎖。
不可重入鎖定
不可重入鎖,與可重入鎖相反,不可遞歸調用,遞歸調用就發生死鎖。看到一個經典的講解,使用自旋鎖來模擬一個不可重入鎖,程式碼如下
import java.util.concurrent.atomic.AtomicReference;
public class UnreentrantLock {
#
private AtomicReference
public void lock() {
Thread current = Thread.currentThread();
# //這句是很經典的「自旋」語法,AtomicInteger中也有
# for (;;) {
if (!owner.compareAndSet(null, current)) {
# return;
# }
# }
# }
# public void unlock() {
# Thread current = Thread.currentThread();
# owner.compareAndSet(current, null);
}
# }
# 程式碼也比較簡單,使用原子引用來存放線程,同一線程兩次呼叫lock()方法,如果不執行unlock()釋放鎖的話,第二次呼叫自旋的時候就會產生死鎖,這個鎖就不是可重入的,而實際上同一個執行緒不必每次都去釋放鎖再來取得鎖,這樣的調度切換是很耗資源的。
把它變成一個可重入鎖:
import java.util.concurrent.atomic.AtomicReference;
public class UnreentrantLock {
#
private AtomicReference
private int state = 0;
# public void lock() {
Thread current = Thread.currentThread();
# if (current == owner.get()) {
state ;
# return;
# }
# //這句是很經典的「自旋」式語法,AtomicInteger中也有
for (;;) {
if (!owner.compareAndSet(null, current)) {
# return;
# }
# }
# }
# public void unlock() {
# Thread current = Thread.currentThread();
# if (current == owner.get()) {
if (state != 0) {
# state--;
# } else {
owner.compareAndSet(current, null);
}
# }
# }
# }
# 在執行每次操作前,判斷目前鎖持有者是否為目前對象,採用state計數,不用每次去釋放鎖。
ReentrantLock中可重入鎖定實作
# 這裡看非公平鎖的鎖定獲取方法:
final boolean nonfairTryAcquire(int acquires) {
# final Thread current = Thread.currentThread();
# int c = getState();
if (c == 0) {
# if (compareAndSetState(0, acquires)) {
# setExclusiveOwnerThread(current);
return true;
}
# }
# //就是這裡
# else if (current == getExclusiveOwnerThread()) {
int nextc = c acquires;
# if (nextc < 0) // overflow
throw new Error("Maximum lock count exceeded");
setState(nextc);
return true;
}
# return false;
}
# 在AQS中維護了一個private volatile int state來計數重入次數,避免了頻繁的持有釋放操作,這樣既提升了效率,又避免了死鎖。
獨享鎖 / 共享鎖定
獨享鎖和共享鎖在你去讀C.U.T包下的ReeReentrantLock和ReentrantReadWriteLock你就會發現,它倆一個是獨享一個是共享鎖。
獨享鎖:該鎖每次只能被一個執行緒所持有。
共享鎖:此鎖可被多個執行緒共有,典型的就是ReentrantReadWriteLock裡的讀鎖,它的讀鎖是可以被共享的,但是它的寫鎖確每次只能獨佔。
另外讀鎖的共享可保證並發讀是非常有效率的,但是讀寫和寫寫,寫讀都是互斥的。
獨享鎖與共享鎖也是透過AQS來實現的,透過實現不同的方法,來實現獨享或共享。對Synchronized而言,當然是獨享鎖。
互斥鎖 / 讀寫鎖定
互斥鎖
# 在存取共享資源之前對進行加鎖操作,在存取完成之後進行解鎖操作。加鎖後,任何其他試圖再次加鎖的執行緒會被阻塞,直到目前程序解鎖。
如果解鎖時有一個以上的線程阻塞,那麼所有該鎖上的線程都被編程就緒狀態, 第一個變為就緒狀態的線程又執行加鎖操作,那麼其他的線程又會進入等待。在這種方式下,只有一個執行緒能夠存取被互斥鎖保護的資源
# 讀寫鎖定
# 讀寫鎖既是互斥鎖,又是共享鎖,read模式是共享,write是互斥(排它鎖)的。
讀寫鎖有三種狀態:讀加鎖狀態、寫加鎖狀態和不加鎖狀態
讀寫鎖在Java中的具體實作就是ReadWriteLock
一次只有一個執行緒可以佔有寫入模式的讀寫鎖定,但是多個執行緒可以同時佔有讀取模式的讀寫鎖定。只有一個執行緒可以佔有寫入狀態的鎖,但可以有多個執行緒同時佔有讀取狀態鎖,這也是它可以實現高並發的原因。當其處於寫入狀態鎖下,任何想要嘗試獲得鎖的執行緒都會被阻塞,直到寫入狀態鎖被釋放;如果是處於讀取狀態鎖下,允許其它執行緒獲得它的讀取狀態鎖,但是不允許獲得它的寫狀態鎖,直到所有執行緒的讀狀態鎖被釋放;為了避免想要嘗試寫操作的執行緒一直無法使用寫狀態鎖,當讀寫鎖感知到有執行緒想要獲得寫狀態鎖時,便會阻塞其後所有想要獲得讀取狀態鎖定的執行緒。所以讀寫鎖定非常適合資源的讀取操作遠多於寫入操作的情況。
樂觀鎖 / 悲觀鎖
悲觀鎖
# 總是假設最壞的情況,每次去拿數據的時候都認為別人會修改,所以每次在拿數據的時候都會上鎖,這樣別人想拿這個數據就會阻塞直到它拿到鎖(共享資源每次只給一個執行緒使用,其它執行緒阻塞,用完後再把資源轉讓給其它執行緒)。傳統的關係型資料庫裡邊就用到了很多這種鎖機制,例如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖。 Java中synchronized和ReentrantLock等獨佔鎖就是悲觀鎖思想的實現。
樂觀鎖
# 總是假設最好的情況,每次去拿數據的時候都認為別人不會修改,所以不會上鎖,但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數據,可以使用版本號機制和CAS演算法實作。樂觀鎖適用於多讀的應用類型,這樣可以提高吞吐量,像是資料庫提供的類似write_condition機制,其實都是提供的樂觀鎖。在Java中java.util.concurrent.atomic套件下面的原子變數類別就是使用了樂觀鎖定的一種實作方式CAS實現的。
分段鎖定
# 分段鎖其實是一種鎖的設計,並不是具體的一種鎖,對於ConcurrentHashMap而言,其並發的實現就是透過分段鎖的形式來實現高效的並發操作。
並發容器類別的加鎖機制是基於粒度更小的分段鎖,分段鎖也是提升多重並發程式效能的重要手段之一。
在並發程序中,串行操作是會降低可擴展性,並且上下文切換也會降低效能。在鎖上發生競爭時將通水導致這兩種問題,使用獨佔鎖時保護受限資源的時候,基本上是採用串行方式—-每次只能有一個線程能訪問它。所以對於可伸縮性來說最大的威脅就是獨佔鎖。
我們一般有三種方式降低鎖的競爭程度: 1、減少鎖的持有時間 2、降低鎖的請求頻率 3、使用帶有協調機制的獨佔鎖,這些機制允許更高的並發性。
在某些情況下我們可以將鎖分解技術進一步擴展為一組獨立物件上的鎖進行分解,這成為分段鎖。
其實說的簡單一點就是:
容器裡有多把鎖,每一把鎖用於鎖容器其中一部分數據,那麼當多線程訪問容器裡不同數據段的數據時,線程間就不會存在鎖競爭,從而可以有效的提高並發訪問效率,這就是ConcurrentHashMap所使用的鎖分段技術,首先將資料分成一段一段的存儲,然後給每一段資料配一把鎖,當一個執行緒佔用鎖訪問其中一個段資料的時候,其他段的資料也能被其他線程存取。
例如:在ConcurrentHashMap中使用了一個包含16個鎖的數組,每個鎖保護所有散列桶的1/16,其中第N個散列桶由第(N mod 16)個鎖來保護。假設使用合理的雜湊演算法使關鍵字能夠均勻的分部,那麼這大約可以使對鎖的請求減少到越來的1/16。也正是這項技術使得ConcurrentHashMap支援多達16個並發的寫入線程。
偏向鎖 / 輕量級鎖定 / 重量級鎖定
鎖的狀態:
# 無鎖定狀態
# 偏向鎖定狀態
# 輕量級鎖定狀態
重量級鎖定狀態
鎖的狀態是透過物件監視器在物件頭中的欄位來表示的。四種狀態會隨著競爭的情況逐漸升級,而且是不可逆的過程,也就是不可降級。這四種狀態都不是Java語言中的鎖,而是Jvm為了提高鎖的獲取與釋放效率而做的優化(使用synchronized時)。
偏向鎖
# 偏向鎖是指一段同步程式碼一直被一個執行緒所訪問,那麼該執行緒會自動取得鎖。降低獲取鎖的代價。
輕量級
# 輕量級鎖是指當鎖是偏向鎖的時候,被另一個線程所訪問,偏向鎖就會升級為輕量級鎖,其他線程會通過自旋的形式嘗試獲取鎖,不會阻塞,提高性能。
重量級鎖定
# 重量級鎖是指當鎖為輕量級鎖的時候,另一個執行緒雖然是自旋,但自旋不會一直持續下去,當自旋一定次數的時候,還沒有取得到鎖,就會進入阻塞,該鎖膨脹為重量級鎖。重量級鎖會讓其他申請的線進入阻塞,效能降低。
自旋鎖定
# 我們知道CAS演算法是樂觀鎖的一種實現方式,CAS演算法中又涉及到自旋鎖,所以這裡跟大家講一下什麼是自旋鎖。
簡單回顧一下CAS演算法
CAS是英文單字Compare and Swap(比較並交換),是一種有名的無鎖演算法。無鎖編程,也就是不使用鎖的情況下實現多執行緒之間的變數同步,也就是在沒有執行緒被阻塞的情況下實現變數的同步,所以也叫非阻塞同步(Non-blocking Synchronization)。 CAS演算法涉及三個運算元
需要讀寫的記憶體值 V
進行比較的值 A
擬寫入的新值 B
更新一個變數的時候,只有當變數的預期值A和記憶體位址V當中的實際值相同時,才會將記憶體位址V對應的值修改為B,否則不會執行任何動作。一般情況下是一個自旋操作,即不斷的重試。
什麼是自旋鎖?
自旋鎖(spinlock):是指當一個線程在獲取鎖的時候,如果鎖已經被其它線程獲取,那麼該線程將循環等待,然後不斷的判斷鎖是否能夠被成功獲取,直到獲取到鎖才會退出循環。
它是為實現保護共享資源而提出一種鎖定機制。其實,自旋鎖與互斥鎖比較類似,它們都是為了解決某項資源的互斥使用。無論是互斥鎖,還是自旋鎖,在任何時刻,最多只能有一個保持者,也就說,在任何時刻最多只能有一個執行單元獲得鎖。但是兩者在調度機制上略有不同。對於互斥鎖,如果資源已經被佔用,資源申請者只能進入睡眠狀態。但是自旋鎖不會引起呼叫者睡眠,如果自旋鎖已經被別的執行單元保持,呼叫者就一直循環在那裡看是否該自旋鎖的保持者已經釋放了鎖,」自旋」一詞就是因此而得名。
Java如何實現自旋鎖?
下面是個簡單的例子:
public class SpinLock {
private AtomicReference
public void lock() {
Thread current = Thread.currentThread();
# // 利用CAS
while (!cas.compareAndSet(null, current)) {
// DO nothing
}
# }
# public void unlock() {
# Thread current = Thread.currentThread();
# cas.compareAndSet(current, null);
}
# }
# lock()方法利用的CAS,當第一個線程A獲取鎖的時候,能夠成功獲取到,不會進入while循環,如果此時線程A沒有釋放鎖,另一個線程B又來獲取鎖,此時由於不滿足CAS,所以就會進入while循環,不斷判斷是否滿足CAS,直到A執行緒呼叫unlock方法釋放了該鎖。
自旋鎖存在的問題
1、如果某個執行緒持有鎖的時間過長,就會導致其它等待取得鎖的執行緒進入循環等待,消耗CPU。使用不當會造成CPU使用率極高。 2.上面Java實現的自旋鎖不是公平的,也就是無法滿足等待時間最長的執行緒優先獲取鎖。不公平的鎖就會有「線程飢餓」問題。
自旋鎖的優點
# 1.自旋鎖不會使線程狀態切換,一直處於用戶態,即線程一直都是active的;不會使線程進入阻塞狀態,減少了不必要的上下文切換,執行速度快2、非自旋鎖在取得不到鎖的時候會進入阻塞狀態,從而進入內核態,取得到鎖的時候需要從內核態恢復,需要執行緒上下文切換。 (線程被阻塞後便進入核心(Linux)調度狀態,這個會導致系統在用戶態與內核態之間來回切換,嚴重影響鎖的效能)
可重入的自旋鎖與不可重入的自旋鎖
文章開始的時候的那段程式碼,仔細分析一下就可以看出,它是不支援重入的,即當一個線程第一次已經獲取到了該鎖,在鎖釋放之前又一次重新獲取該鎖,第二次就不能成功取得到。由於不滿足CAS,所以第二次獲取會進入while循環等待,而如果是可重入鎖,第二次也是應該能夠成功獲取到的。
而且,即使第二次能夠成功獲取,那麼當第一次釋放鎖的時候,第二次獲取到的鎖也會被釋放,而這是不合理的。
為了實現可重入鎖,我們需要引入一個計數器,用來記錄取得鎖的執行緒數。
public class ReentrantSpinLock {
#
private AtomicReference
private int count;
public void lock() {
Thread current = Thread.currentThread();
# if (current == cas.get()) { // 如果當前執行緒已經取得了鎖,執行緒數增加一,然後回傳
count ;
# return;
# }
# // 如果沒取得到鎖,則透過CAS自旋
# while (!cas.compareAndSet(null, current)) {
// DO nothing
}
# }
# public void unlock() {
# Thread cur = Thread.currentThread();
# if (cur == cas.get()) {
if (count > 0) {// 如果大於0,表示當前執行緒多次取得了該鎖,釋放鎖透過count減一來模擬
count--;
# } else {// 如果count==0,可以將鎖釋放,這樣就能保證取得鎖的次數與釋放鎖的次數是一致的了。
cas.compareAndSet(cur, null);
}
# }
# }
# }
# 自旋鎖與互斥鎖
自旋鎖與互斥鎖都是為了實現保護資源共享的機制。
無論是自旋鎖或互斥鎖,在任意時刻,都最多只能有一個保持者。
取得互斥鎖的線程,如果鎖已經被佔用,則該線程將進入睡眠狀態;獲取自旋鎖的線程則不會睡眠,而是一直循環等待鎖釋放。
以上是Java 中的各種鎖有哪些?的詳細內容。更多資訊請關注PHP中文網其他相關文章!