1. 程式人生 > >鎖--自旋鎖、阻塞鎖、可重入鎖、悲觀鎖、樂觀鎖、讀寫鎖、偏向所、輕量級鎖、重量級鎖、鎖膨脹、物件鎖和類鎖

鎖--自旋鎖、阻塞鎖、可重入鎖、悲觀鎖、樂觀鎖、讀寫鎖、偏向所、輕量級鎖、重量級鎖、鎖膨脹、物件鎖和類鎖

參考:http://blog.csdn.net/a314773862/article/details/54095819

自旋鎖

自旋鎖可以使執行緒在沒有取得鎖的時候,不被掛起,而轉去執行一個空迴圈,(即所謂的自旋,就是自己執行空迴圈),若在若干個空迴圈後,執行緒如果可以獲得鎖,則繼續執行。若執行緒依然不能獲得鎖,才會被掛起。

使用自旋鎖後,執行緒被掛起的機率相對減少,執行緒執行的連貫性相對加強。因此,對於那些鎖競爭不是很激烈,鎖佔用時間很短的併發執行緒,具有一定的積極意義,但對於鎖競爭激烈,單執行緒鎖佔用很長時間的併發程式,自旋鎖在自旋等待後,往往毅然無法獲得對應的鎖,不僅僅白白浪費了CPU時間,最終還是免不了被掛起的操作 ,反而浪費了系統的資源。

可能引起的問題:
1.過多佔據CPU時間:如果鎖的當前持有者長時間不釋放該鎖,那麼等待者將長時間的佔據cpu時間片,導致CPU資源的浪費,因此可以設定一個時間,當鎖持有者超過這個時間不釋放鎖時,等待者會放棄CPU時間片阻塞;
2.死鎖問題

:試想一下,有一個執行緒連續兩次試圖獲得自旋鎖(比如在遞迴程式中),第一次這個執行緒獲得了該鎖,當第二次試圖加鎖的時候,檢測到鎖已被佔用(其實是被自己佔用),那麼這時,執行緒會一直等待自己釋放該鎖,而不能繼續執行,這樣就引起了死鎖。因此遞迴程式使用自旋鎖應該遵循以下原則:遞迴程式決不能在持有自旋鎖時呼叫它自己,也決不能在遞迴呼叫時試圖獲得相同的自旋鎖。

阻塞鎖

讓執行緒進入阻塞狀態進行等待,當獲得相應的訊號(喚醒,時間) 時,才可以進入執行緒的準備就緒狀態,準備就緒狀態的所有執行緒,通過競爭,進入執行狀態。。
JAVA中,能夠進入\退出、阻塞狀態或包含阻塞鎖的方法有 ,synchronized 關鍵字(其中的重量鎖),ReentrantLock,Object.wait()\notify()

可重入鎖

避免死鎖

可重入鎖,也叫做遞迴鎖,指的是同一執行緒 外層函式獲得鎖之後 ,內層遞迴函式仍然有獲取該鎖的程式碼,但不受影響。
在JAVA環境下 ReentrantLock 和synchronized 都是 可重入鎖

悲觀鎖和樂觀鎖

悲觀鎖(Pessimistic Lock), 顧名思義就是很悲觀,每次去拿資料的時候都認為別人會修改,所以每次在拿資料的時候都會上鎖,這樣別人想拿這個資料就會block直到它拿到鎖。傳統的關係型資料庫裡邊就用到了很多這種鎖機制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖。共享鎖、排它鎖、獨佔鎖是悲觀鎖的一種實現

樂觀鎖(Optimistic Lock), 顧名思義,就是很樂觀,每次去拿資料的時候都認為別人不會修改,所以不會上鎖,但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料,可以使用版本號或時間戳

等機制。樂觀鎖適用於多讀的應用型別,這樣可以提高吞吐量,像資料庫如果提供類似於write_condition機制的其實都是提供的樂觀鎖。使用CAS來保證,保證這個操作的原子性

樂觀鎖不是資料庫自己實現的

悲觀鎖是資料庫自己實現的


兩種鎖各有優缺點,不可認為一種好於另一種,像樂觀鎖適用於寫比較少的情況下,即衝突真的很少發生的時候,這樣可以省去了鎖的開銷,加大了系統的整個吞吐量。但如果經常產生衝突,上層應用會不斷的進行retry,這樣反倒是降低了效能,所以這種情況下用悲觀鎖就比較合適。

輪循鎖和定時鎖

由tryLock實現,與無條件獲取鎖模式相比,它們具有更完善的錯誤恢復機制。可避免死鎖的發生:
boolean tryLock():僅在呼叫時鎖為空閒狀態才獲取該鎖。如果鎖可用,則獲取鎖,並立即返回值 true。如果鎖不可用,則此方法將立即返回值 false。

顯示鎖和內建鎖

顯示鎖用Lock來定義、內建鎖用syschronized。
內建鎖:每個java物件都可以用做一個實現同步的鎖,這些鎖成為內建鎖。執行緒進入同步程式碼塊或方法的時候會自動獲得該鎖,在退出同步程式碼塊或方法時會釋放該鎖。獲得內建鎖的唯一途徑就是進入這個鎖的保護的同步程式碼塊或方法。
內建鎖是互斥鎖

讀寫鎖

Lock介面以及物件,使用它,很優雅的控制了競爭資源的安全訪問,但是這種鎖不區分讀寫,稱這種鎖為普通鎖。為了提高效能,Java提供了讀寫鎖,在讀的地方使用讀鎖,在寫的地方使用寫鎖,靈活控制,如果沒有寫鎖的情況下,讀是無阻塞的,在一定程度上提高了程式的執行效率。
Java中讀寫鎖有個介面java.util.concurrent.locks.ReadWriteLock,也有具體的實現ReentrantReadWriteLock,詳細的API可以檢視JavaAPI文件。
ReentrantReadWriteLock 和 ReentrantLock 不是繼承關係,但都是基於 AbstractQueuedSynchronizer 來實現。
lock方法 是基於CAS 來實現的
ReadWriteLock中暴露了兩個Lock物件:

在讀寫鎖的加鎖策略中,允許多個讀操作同時進行,但每次只允許一個寫操作。讀寫鎖是一種效能優化的策略。

RentrantReadWriteLock在構造時也可以選擇是一個非公平的鎖(預設)還是公平的鎖。

物件鎖和類鎖

java的物件鎖和類鎖在鎖的概念上基本上和內建鎖是一致的,但是,兩個鎖實際是有很大的區別的,物件鎖是用於物件例項方法,或者一個物件例項上的,類鎖是用於類的靜態方法或者一個類的class物件上的。
類的物件例項可以有很多個,但是每個類只有一個class物件,所以不同物件例項的物件鎖是互不干擾的,但是每個類只有一個類鎖。但是有一點必須注意的是,其實類鎖只是一個概念上的東西,並不是真實存在的,它只是用來幫助我們理解鎖定例項方法和靜態方法的區別的.
synchronized只是一個內建鎖的加鎖機制,當某個方法加上synchronized關鍵字後,就表明要獲得該內建鎖才能執行,並不能阻止其他執行緒訪問不需要獲得該內建鎖的方法。

呼叫物件wait()方法時,會釋放持有的物件鎖,以便於呼叫notify方法使用。notify()呼叫之後,會等到notify所在的執行緒執行完之後再釋放鎖

鎖粗化

鎖粗化的概念應該比較好理解,就是將多次連線在一起的加鎖、解鎖操作合併為一次,將多個連續的鎖擴充套件成一個範圍更大的鎖

互斥鎖

互斥鎖, 指的是一次最多隻能有一個執行緒持有的鎖。如Java的Lock

無鎖狀態-》偏向鎖-》輕量級鎖-》重量級鎖

鎖的狀態總共有四種:無鎖狀態、偏向鎖、輕量級鎖和重量級鎖隨著鎖的競爭,鎖可以從偏向鎖升級到輕量級鎖,再升級的重量級鎖(但是鎖的升級是單向的,也就是說只能從低到高升級,不會出現鎖的降級)。JDK 1.6中預設是開啟偏向鎖和輕量級鎖的,
鎖膨脹:從輕量鎖膨脹到重量級鎖是在輕量級鎖解鎖過程發生的。
重量級鎖:Synchronized是通過物件內部的一個叫做監視器鎖(monitor)來實現的。但是監視器鎖本質又是依賴於底層的作業系統的Mutex Lock來實現的。而作業系統實現執行緒之間的切換這就需要從使用者態轉換到核心態,這個成本非常高,狀態之間的轉換需要相對比較長的時間,這就是為什麼Synchronized效率低的原因。因此,這種依賴於作業系統Mutex Lock所實現的鎖我們稱之為“重量級鎖”。
輕量級鎖:“輕量級”是相對於使用作業系統互斥量來實現的傳統鎖而言的。但是,首先需要強調一點的是,輕量級鎖並不是用來代替重量級鎖的,它的本意是在沒有多執行緒競爭的前提下,減少傳統的重量級鎖使用產生的效能消耗。在解釋輕量級鎖的執行過程之前,先明白一點,輕量級鎖所適應的場景是執行緒交替執行同步塊的情況,如果存在同一時間訪問同一鎖的情況,就會導致輕量級鎖膨脹為重量級鎖。
偏向鎖: 引入偏向鎖是為了在無多執行緒競爭的情況下儘量減少不必要的輕量級鎖執行路徑,因為輕量級鎖的獲取及釋放依賴多次CAS原子指令,而偏向鎖只需要在置換ThreadID的時候依賴一次CAS原子指令(由於一旦出現多執行緒競爭的情況就必須撤銷偏向鎖,所以偏向鎖的撤銷操作的效能損耗必須小於節省下來的CAS原子指令的效能消耗)。上面說過,輕量級鎖是為了線上程交替執行同步塊時提高效能,而偏向鎖則是在只有一個執行緒執行同步塊時進一步提高效能。

無鎖狀態:在程式碼進入同步塊的時候,如果同步物件鎖狀態為無鎖狀態。

鎖消除

鎖消除即刪除不必要的加鎖操作。根據程式碼逃逸技術,如果判斷到一段程式碼中,堆上的資料不會逃逸出當前執行緒,那麼可以認為這段程式碼是執行緒安全的,不必要加鎖。