首先可以先看看這篇文章，對鎖有些了解

GO語言并發(fā)編程之互斥鎖、讀寫鎖詳解

Mutex-互斥鎖

Mutex 的實現(xiàn)主要借助了 CAS 指令 + 自旋 + 信號量

數(shù)據結構：

type Mutex struct {
	state int32
	sema  uint32
}

上述兩個加起來只占 8 字節(jié)空間的結構體表示了 Go語言中的互斥鎖

狀態(tài)：

在默認情況下，互斥鎖的所有狀態(tài)位都是 0，int32 中的不同位分別表示了不同的狀態(tài)：

• 1位表示是否被鎖定
• 1位表示是否有協(xié)程已經被喚醒
• 1位表示是否處于饑餓狀態(tài)
• 剩下29位表示阻塞的協(xié)程數(shù)
  

正常模式和饑餓模式

正常模式：所有goroutine按照FIFO的順序進行鎖獲取，被喚醒的goroutine和新請求鎖的goroutine同時進行鎖獲取，通常新請求鎖的goroutine更容易獲取鎖(持續(xù)占有cpu)，被喚醒的goroutine則不容易獲取到鎖

饑餓模式：所有嘗試獲取鎖的goroutine進行等待排隊，新請求鎖的goroutine不會進行鎖獲取(禁用自旋)，而是加入隊列尾部等待獲取鎖

如果一個 Goroutine 獲得了互斥鎖并且它在隊列的末尾或者它等待的時間少于 1ms，那么當前的互斥鎖就會切換回正常模式。

與饑餓模式相比，正常模式下的互斥鎖能夠提供更好地性能，饑餓模式的能避免 Goroutine 由于陷入等待無法獲取鎖而造成的高尾延時。

互斥鎖加鎖過程

• 如果互斥鎖處于初始狀態(tài)，會直接加鎖
• 如果互斥鎖處于加鎖狀態(tài)，并且工作在普通模式下，goroutine會進入自旋，等待鎖的釋放

goroutine 進入自旋的條件非常苛刻：

• 互斥鎖只有在普通模式才能進入自旋；
• runtime.sync_runtime_canSpin需要返回 true

運行在多 CPU 的機器上；

當前 Goroutine 為了獲取該鎖進入自旋的次數(shù)小于四次；

當前機器上至少存在一個正在運行的處理器 P 并且處理的運行隊列為空；

• 如果當前 Goroutine 等待鎖的時間超過了 1ms，互斥鎖就會切換到饑餓模式；
• 互斥鎖在正常情況下會通runtime.sync_runtime_SemacquireMutex將嘗試獲取鎖的 Goroutine 切換至休眠狀態(tài)，等待鎖的持有者喚醒；
• 如果當前 Goroutine 是互斥鎖上的最后一個等待的協(xié)程或者等待的時間小于 1ms，那么它會將互斥鎖切換回正常模式；

互斥鎖解鎖過程

當互斥鎖已經被解鎖時，再解鎖會拋出異常

當互斥鎖處于饑餓模式時，將鎖的所有權交給等待隊列最前面的 Goroutine

當互斥鎖處于正常模式時，如果沒有 Goroutine 等待鎖的釋放或者已經有被喚醒的 Goroutine 獲得了鎖，會直接返回；在其他情況下會通過喚醒對應的 Goroutine；

關于互斥鎖鎖的使用建議寫業(yè)務時不能全局使用同一個 Mutex千萬不要將要加鎖和解鎖分到兩個以上 Goroutine 中進行Mutex 千萬不能被復制（包括不能通過函數(shù)參數(shù)傳遞），否則會復制傳參前鎖的狀態(tài)：已鎖定 or 未鎖定。很容易產生死鎖，關鍵是編譯器還發(fā)現(xiàn)不了這個 Deadlock~

RWMutex-讀寫鎖

Go 中 RWMutex 使用的是寫優(yōu)先的設計

數(shù)據結構：

type RWMutex struct {
	w           Mutex	//復用互斥鎖提供的能力
	writerSem   uint32	//writer信號量
	readerSem   uint32	//reader信號量
	readerCount int32	//存儲了當前正在執(zhí)行的讀操作數(shù)量
	readerWait  int32	// 表示寫操作阻塞時，等待讀操作完成的個數(shù)
}

寫鎖

獲取寫鎖 ：

• 調用結構體持有的Mutex結構體的Mutex.Lock阻塞后續(xù)的寫操作
• 將readerCount減少2^30,成為負數(shù)，以阻塞后續(xù)讀操作
• 如果有其他Goroutine 持有讀鎖，該 Goroutine會進入休眠狀態(tài)等待所有讀鎖執(zhí)行結束后釋放writerSem信號量將當前協(xié)程喚醒

釋放寫鎖：

• 將readerCount變回正數(shù)，釋放讀鎖
• 喚醒所有因為讀鎖而睡眠的Goroutine
• 調用Mutex.Unlock 釋放寫鎖

獲取寫鎖時會先阻塞寫鎖的獲取，后阻塞讀鎖的獲取，這種策略能夠保證讀操作不會被連續(xù)的寫操作『餓死』。

讀鎖

獲取讀鎖

獲取讀鎖的方法 sync.RWMutex.RLock 很簡單，該方法會將readerCount加一：

• 如果該方法返回負數(shù)（代表其他 goroutine 獲得了寫鎖，當前 goroutine 就會使其陷入休眠等待鎖的釋放
• 如果該方法返回結果為非負數(shù)，代表沒有 goroutine 獲得寫鎖，會成功返回

釋放讀鎖

解鎖讀鎖的方法sync.RWMutex.RUnlock，該方法會：

• 將readerCount減一，根據返回值的不同會分別進行處理
• 如果返回值大于等于0，讀鎖直接解鎖成功
• 如果小于0代表有正在執(zhí)行的寫操作，會調用sync.RWMutex.rUnlockSlow，將readerWait減一，并且當所有讀操作都被釋放后觸發(fā)信號量 writerSem，該信號量被觸發(fā)時，調度器就會喚醒嘗試獲取寫鎖的 Goroutine
  

WaitGroup

sync.WaitGroup可以等待一組 Goroutine 的返回

sync.WaitGroup 對外暴露了三個方法：

sync.WaitGroup.Done只是對 sync.WaitGroup.Add 方法的簡單封裝，相當于是加 -1

Sync.Map

Go語言中內置的map不是并發(fā)安全的。

Go語言的sync包中提供了一個開箱即用的并發(fā)安全版map–sync.Map。使用互斥鎖保證并發(fā)安全

數(shù)據結構：

type Map struct {
    mu Mutex
    read atomic.Value // readOnly
    dirty map[interface{}]*entry
    misses int
}

開箱即用表示不用像內置的map一樣使用make函數(shù)初始化就能直接使用。同時sync.Map內置了方法:

原子操作(atomic包)

代碼中的加鎖操作因為涉及內核態(tài)的上下文切換會比較耗時、代價比較高。針對基本數(shù)據類型我們還可以使用原子操作來保證并發(fā)安全，因為原子操作是Go語言提供的方法它在用戶態(tài)就可以完成，因此性能比加鎖操作更好。Go語言中原子操作由內置的標準庫sync/atomic提供。

參考資料：

Go 語言并發(fā)編程、同步原語與鎖 | Go 語言設計與實現(xiàn) (draveness.me)

到此這篇關于go語言中并發(fā)安全和鎖的文章就介紹到這了,更多相關go語言中并發(fā)安全和鎖內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論