我先聲明一下，并不是真的加鎖失效，而是我之前的理解有誤，導(dǎo)致看起來像是加鎖失效一樣。于是乎記錄一下，加深一下印象。

我之前有個理解誤區(qū)（不知道大家有沒有，有的話趕緊糾正一下——其實也是因為我這塊的知識掌握不牢固導(dǎo)致的）：覺得只要是加鎖后，在我主動調(diào)用解鎖之前，這個塊范圍內(nèi)的變量一定不會被其他地方修改。后來驗證發(fā)現(xiàn)，我大錯特錯了。

起因

最近在學(xué)習(xí) sync.Mutex 加鎖時，寫了下面一段代碼進(jìn)行練習(xí)。

package main

import (
	"fmt"
	"sync"
	"time"
)


type Info struct {
	mu sync.Mutex
	Value string
}

func Update(info *Info) {
	fmt.Printf("%s: before update. Value: %s\n", time.Now().Format(timeFormat), info.Value)
	info.mu.Lock()
	defer info.mu.Unlock()
	time.Sleep(2 * time.Second)
	fmt.Printf("%s: in update. Value: %s\n", time.Now().Format(timeFormat), info.Value)
	info.Value = "update"
	fmt.Printf("%s: after update. Value: %s\n", time.Now().Format(timeFormat), info.Value)
}

const timeFormat = "2006-01-02 15:04:05"

func main() {
	fmt.Printf("%s: main start\n", time.Now().Format(timeFormat))
	info := &Info{}
	var wg sync.WaitGroup
	wg.Add(1)
	go func() {
		defer wg.Done()
		Update(info)
	}()
	time.Sleep(time.Second)
	info.Value = "main"
	fmt.Printf("%s: in main. Value: %s\n", time.Now().Format(timeFormat), info.Value)
	wg.Wait()
}

按照我原先上面的理解，Update() 函數(shù)當(dāng)中，before update 和 in update 中對應(yīng)結(jié)構(gòu)體的值應(yīng)該是不會變的（畢竟我加了鎖）。然而從運(yùn)行結(jié)果發(fā)現(xiàn)，Update() 函數(shù)執(zhí)行期間，結(jié)構(gòu)體變量的 Value 竟然還是被外部主線程修改了。

分析

那么為什么會這樣呢？明明 Update() 里邊已經(jīng)添加了鎖，為什么執(zhí)行期間還是會被其他地方修改呢？

最后發(fā)現(xiàn)，究其原因，還是在于主線程修改變量的值的時候，沒有先判斷鎖 mu 是否已經(jīng)釋放，就直接進(jìn)行了修改操作。

主線程中加上獲取鎖的操作后，會先判斷當(dāng)前鎖是否被釋放，如果沒被釋放，就會一直進(jìn)行等待直到鎖釋放后才繼續(xù)執(zhí)行后面的操作。

輸出結(jié)果也和預(yù)期保持一致 。

2024-04-16 23:59:13: main start
2024-04-16 23:59:13: before update. Value: 
2024-04-16 23:59:15: in update. Value: 
2024-04-16 23:59:15: after update. Value: update
2024-04-16 23:59:15: in main. Value: main

正常來說，鎖是要配合多 goroutine 來使用的， 對于單線程來說，由于沒有其他線程進(jìn)行資源競爭，加鎖的意義不大；對于多 goroutine 而言，對于獲取和釋放鎖的時機(jī)，應(yīng)該由應(yīng)用程序合理控制。關(guān)于鎖的使用，還有一些其他注意事項，這塊也一并寫一下。

• 在一個 goroutine 獲得 Mutex 后，其他 goroutine 只能等到這個 goroutine 釋放該 Mutex
• 使用 Lock() 加鎖后，不能再繼續(xù)對其加鎖，直到利用 Unlock() 解鎖后才能再加鎖
• 在 Lock() 之前使用 Unlock() 會導(dǎo)致 panic 異常
• 已經(jīng)鎖定的 Mutex 并不與特定的 goroutine 相關(guān)聯(lián)，這樣可以利用一個 goroutine 對其加鎖，再利用其他 goroutine 對其解鎖
• 在同一個 goroutine 中的 Mutex 解鎖之前再次進(jìn)行加鎖，會導(dǎo)致死鎖
• 適用于讀寫不確定，并且只有一個讀或者寫的場景

緩沖通道實現(xiàn)互斥邏輯

當(dāng)然，我們還可以通過緩沖為1的通道實現(xiàn)互斥鎖的邏輯。

package main

import (
	"fmt"
	"sync"
	"time"
)


type Info struct {
	Value string
}

func Update(info *Info, sem chan bool) {
	fmt.Printf("%s: before update. Value: %s\n", time.Now().Format(timeFormat), info.Value)
	sem <- true
	defer func() {
		<- sem
	}()
	time.Sleep(2 * time.Second)
	fmt.Printf("%s: in update. Value: %s\n", time.Now().Format(timeFormat), info.Value)
	info.Value = "update"
	fmt.Printf("%s: after update. Value: %s\n", time.Now().Format(timeFormat), info.Value)
}

const timeFormat = "2006-01-02 15:04:05"

func main() {
	sem := make(chan bool, 1)
	fmt.Printf("%s: main start\n", time.Now().Format(timeFormat))
	info := &Info{}
	var wg sync.WaitGroup
	wg.Add(1)
	go func() {
		defer wg.Done()
		Update(info, sem)
	}()
	time.Sleep(time.Second)
	sem <- true
	info.Value = "main"
	fmt.Printf("%s: in main. Value: %s\n", time.Now().Format(timeFormat), info.Value)
	<- sem
	wg.Wait()
}

2024-04-17 00:26:25: main start
2024-04-17 00:26:25: before update. Value: 
2024-04-17 00:26:26: in main. Value: main
2024-04-17 00:26:27: in update. Value: main
2024-04-17 00:26:27: after update. Value: update

到此這篇關(guān)于Go中sync.Mutex 加鎖失效的問題解決的文章就介紹到這了,更多相關(guān)Go sync.Mutex 加鎖失效內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！ 

最新評論