Mutex的4種易錯(cuò)使用場景

1.Lock/Unlock 不成對出現(xiàn)

Lock/Unlock 沒有成對出現(xiàn)，就可能會(huì)出現(xiàn)死鎖或者是因?yàn)閁nlock一個(gè)未加鎖的Mutex而導(dǎo)致 panic。

忘記Unlock的情形

• 代碼中有太多的 if-else 分支，可能在某個(gè)分支中漏寫了 Unlock；
• 在重構(gòu)的時(shí)候把 Unlock 給刪除了；
• Unlock 誤寫成了 Lock。

忘記Lock的情形一般是誤刪除了或者注釋掉了Lock。

eg:

func main() {
   var mu sync.Mutex
   defer mu.Unlock()
   fmt.Println("oh, missing Lock!")
}

error result:

2.Copy 已使用的 Mutex

實(shí)際上sync包下的同步原語在使用后都是不可復(fù)制的，原因在于Mutex是有狀態(tài)的，其state的值時(shí)刻在變化，如果復(fù)制一個(gè)已經(jīng)加鎖的Metux對象給一個(gè)新的變量，可能這個(gè)變量剛初始化就顯示被加鎖了，這顯然是不合理的。

eg:以下代碼在調(diào)用 foo 函數(shù)的時(shí)候，調(diào)用者會(huì)復(fù)制 Mutex 變量 c 作為 foo 函數(shù)的參數(shù)，不幸的是，復(fù)制之前已經(jīng)使用了這個(gè)鎖，這就導(dǎo)致，復(fù)制的 Counter 是一個(gè)帶狀態(tài) Counter，從而會(huì)導(dǎo)致死鎖。

type Counter struct {
   sync.Mutex
   Count int
}
func main() {
   var c Counter
   c.Lock()
   defer c.Unlock()
   c.Count++
   foo(c) // 復(fù)制鎖
}
// 這里Counter的參數(shù)是通過復(fù)制的方式傳入的
func foo(c Counter) {
   c.Lock()
   defer c.Unlock()
   fmt.Println("in foo")
}

error result:還好有Go的協(xié)程死鎖檢查機(jī)制，程序運(yùn)行后會(huì)快速失敗而不是一直hang住。

Go Vet指令

我們當(dāng)然不想程序運(yùn)行了才發(fā)現(xiàn)死鎖，我們可以通過go vet指令來在運(yùn)行前檢查我們的代碼是否存在lock copy問題:

檢查原理

檢查是通過copylock分析器靜態(tài)分析實(shí)現(xiàn)的。這個(gè)分析器會(huì)分析函數(shù)調(diào)用、range 遍歷、復(fù)制、聲明、函數(shù)返回值等位置，有沒有鎖的值 copy 的情景，以此來判斷有沒有問題。

通過源碼我們可以看到實(shí)現(xiàn)了Lock或者Unlock接口的struct都支持copylock檢查。

var lockerType *types.Interface
 // Construct a sync.Locker interface type.
 func init() {
     nullary := types.NewSignature(nil, nil, nil, false) // func()
     methods := []*types.Func{
     types.NewFunc(token.NoPos, nil, "Lock", nullary),
     types.NewFunc(token.NoPos, nil, "Unlock", nullary),
 }
 lockerType = types.NewInterface(methods, nil).Complete()
 }

3.重入

Mutex不像Java中的ReentrantLock擁有可重入的功能，主要是因?yàn)槠鋵?shí)現(xiàn)中沒有標(biāo)記位記錄哪個(gè)goroutine 擁有這把鎖，所以Mutex是一個(gè)不可重入鎖,而一旦誤用Mutex的重入就會(huì)報(bào)錯(cuò)。

eg:

func foo(l sync.Locker) {
   fmt.Println("in foo")
   l.Lock()
   bar(l)
   l.Unlock()
}
func bar(l sync.Locker) {
   l.Lock()
   fmt.Println("in bar")
   l.Unlock()
}
func main() {
   l := &sync.Mutex{}
   foo(l)
}

error result:我們可以看到當(dāng)在bar方法中嘗試再次獲取鎖時(shí)，獲取不到，觸發(fā)了死鎖。

4.死鎖

兩個(gè)或兩個(gè)以上的進(jìn)程（或線程，goroutine）

執(zhí)行過程中，因爭奪共享資源而處于一種互相等待的狀態(tài)，如果沒有外部干涉，它們都將無法推進(jìn)下去，此時(shí)，我們稱系統(tǒng)處于死鎖狀態(tài)或系統(tǒng)產(chǎn)生了死鎖。

死鎖產(chǎn)生的4個(gè)必要條件

如果想避免死鎖，我們只要思考如何打破以下任意條件就可以。

• 1.互斥： 至少一個(gè)資源是被排他性獨(dú)享的，其他線程必須處于等待狀態(tài)，直到資源被釋放。
• 2.持有和等待：goroutine 持有一個(gè)資源，并且還在請求其它 goroutine 持有的資源，也就是咱們常說的“吃著碗里，看著鍋里”的意思。
• 3. 不可剝奪：資源只能由持有它的 goroutine 來釋放。
• 4.環(huán)路等待：一般來說，存在一組等待進(jìn)程，P={P1，P2，…，PN}，P1 等待 P2 持有的

資源，P2 等待 P3 持有的資源，依此類推，最后是 PN 等待 P1 持有的資源，這就形成
了一個(gè)環(huán)路等待的死結(jié)。

eg:在這里我們以辦理居住證業(yè)務(wù)，舉一個(gè)簡單的環(huán)路等待導(dǎo)致死鎖的例子:

//辦理居住證
func main() {
   // 網(wǎng)簽中心證明
   var psCertificate sync.Mutex
   // 社區(qū)證明
   var propertyCertificate sync.Mutex
   var wg sync.WaitGroup
   wg.Add(2) // 需要網(wǎng)簽中心和社區(qū)都處理
   // 網(wǎng)簽中心處理goroutine
   go func() {
      defer wg.Done() // 網(wǎng)簽中心處理完成
      psCertificate.Lock()
      defer psCertificate.Unlock()
      // 檢查材料
      time.Sleep(5 * time.Second)
      // 請求社區(qū)的證明
      propertyCertificate.Lock()
      propertyCertificate.Unlock()
   }()
   // 社區(qū)處理goroutine
   go func() {
      defer wg.Done() // 社區(qū)處理完成
      propertyCertificate.Lock()
      defer propertyCertificate.Unlock()
      // 檢查材料
      time.Sleep(5 * time.Second)
      // 請求網(wǎng)簽中心的證明
      psCertificate.Lock()
      psCertificate.Unlock()
   }()
   wg.Wait()
   fmt.Println("成功完成")
}

error result:

解決策略

1.可以引入一個(gè)第三方的鎖，大家都依賴這個(gè)鎖進(jìn)行業(yè)務(wù)處理，比如現(xiàn)在政府推行的一站式政務(wù)服務(wù)中心。

2.解決持有等待問題，比如社區(qū)不需要看到網(wǎng)簽中心的證明才給開居住證明。

以上就是Go并發(fā)同步Mutex典型易錯(cuò)使用場景的詳細(xì)內(nèi)容，更多關(guān)于Go Mutex易錯(cuò)場景的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論