Golang全局變量加鎖的問(wèn)題解決

如果全局變量只讀取 那自然是不需要加鎖的

如果全局變量多進(jìn)程讀，多進(jìn)程寫(xiě)，那自然是需要加讀寫(xiě)鎖的

但是如果全局變量只有一個(gè)進(jìn)程寫(xiě)，其他進(jìn)程讀呢？ 如果采用COW的方式，寫(xiě)進(jìn)程只是通過(guò)單次賦值的方式來(lái)更新變量，是否就可以不加鎖了呢？

就第三種情況而言：

當(dāng)然我們通過(guò) go build -race 或者 go run -race 就會(huì)出現(xiàn)

WARNING: DATA RACE。 但是出現(xiàn) data race 就證明一定有問(wèn)題么？

其實(shí)核心點(diǎn)在于這個(gè)賦值是否是原子的。也就是說(shuō)是否存在 p1 = p2 的寫(xiě)入時(shí)，指針被臨時(shí)替換為p3，并在此時(shí)goroutine切出的情況?？梢韵氲降囊环N情況是64字節(jié)的指針需要兩次mv才能完成全部變量的賦值。那么就有可能在兩次mv中間切出，進(jìn)而出現(xiàn)p3的情況。

之前在stackoverflow 上有個(gè)討論

https://stackoverflow.com/questions/21447463/is-assigning-a-pointer-atomic-in-go

其中高votes的回答是說(shuō)：

在go中，唯一保證原子性的操作是在 sync.atomic, 所以如果你想確保原子性，可以使用sync.Mutex 或者 sync.atomic 中的原子函數(shù)。 但是我不建議 sync.atomic中函數(shù)， 因?yàn)槟悴坏貌辉谌魏问褂弥羔樀牡胤绞褂盟麄儯@是非常難做到正確使用的。

用mutex 是好的go style - 你可以很方便的定義一個(gè)函數(shù)返回指針。 比如

import "sync"
var secretPointer *int
var pointerLock sync.Mutex
func CurrentPointer() *int {
    pointerLock.Lock()
    defer pointerLock.Unlock()
    return secretPointer
}
func SetPointer(p *int) {
    pointerLock.Lock()
    secretPointer = p
    pointerLock.Unlock()
}

所以一個(gè)ok的go style 應(yīng)該是使用 sync.Mutex 的。

golang doc也是這么說(shuō)的。

type T struct {
 msg string
}
var g *T
func setup() {
 t := new(T)
 t.msg = "hello, world"
 g = t
}
func main() {
 go setup()
 for g == nil {
 }
 print(g.msg)
}

Even if main observes g != nil and exits its loop, there is no guarantee that it will observe the initialized value for g.msg.

In all these examples, the solution is the same: use explicit synchronization.

但是當(dāng)我們用go tool asm看時(shí)， 確實(shí)只有一個(gè)指令 MOVQ。

所以只能說(shuō)

因?yàn)橐?guī)范沒(méi)有指定，所以你應(yīng)該假設(shè)它不是原子的。即使它現(xiàn)在是原子的，它也有可能在不違反規(guī)范的情況下改變。

總之我們不應(yīng)該做賦值原子的假設(shè)，而應(yīng)該按照規(guī)范，使用sync.Mutex 來(lái)做。

補(bǔ)充：Golang對(duì)全局變量加鎖同步解決資源訪問(wèn)共享問(wèn)題——使用Go協(xié)程來(lái)同時(shí)并發(fā)計(jì)算多個(gè)數(shù)字（1-200）的階乘

使用互斥鎖解決資源共享問(wèn)題

使用Go協(xié)程來(lái)同時(shí)并發(fā)計(jì)算多個(gè)數(shù)字（1-200）的階乘，然后存儲(chǔ)在數(shù)組當(dāng)中

package main 
import (
 "fmt"
 "time"
)
 
var(
 myMap = make(map[int]int, 10)
)
 
func test(n int){
 res:=1
 for i:=1; i=n; i++{
  res*=i
 }
 myMap[n]=res
}
 
func main(){
 for i:=1; i=200; i++{
  go test(i)
 }
 
 time.Sleep(time.Second*10) 
 for i,v:=range myMap{
  fmt.Printf("myMap[%d]=%d\n", i, v)
 }
}

代碼如下，運(yùn)行結(jié)果如下：但是我們發(fā)現(xiàn)其并沒(méi)有正常計(jì)算出各個(gè)數(shù)字的階乘來(lái)

原因是我們沒(méi)有對(duì)全局變量myMap加鎖，導(dǎo)致了資源搶奪的問(wèn)題，因此我們可以對(duì)代碼加入互斥鎖

package main 
import (
 "fmt"
 "time"
 "sync"
)
 
var(
 myMap = make(map[int]int, 10)
 //聲明一個(gè)全局互斥鎖
 lock sync.Mutex
)
 
func test(n int){
 res:=1
 for i:=1; i=n; i++{
  res+=i //這里我將階乘改成求和，防止數(shù)據(jù)溢出
 }
 //加鎖
 lock.Lock()
 myMap[n]=res
 //解鎖
 lock.Unlock()
}
 
func main(){
 for i:=1; i=200; i++{
  go test(i)
 }
 
 time.Sleep(time.Second*10)
 
 for i,v:=range myMap{
  fmt.Printf("myMap[%d]=%d\n", i, v)
 }
}

對(duì)資源加了互斥鎖之后，多個(gè)協(xié)程之間的并發(fā)問(wèn)題就得到了解決

但是上述解決方案不太完美，有其缺陷：

（1）主線程在等待所有g(shù)oroutine全部完成的時(shí)間很難確定

（2）如果主線程休眠時(shí)間過(guò)長(zhǎng)，就會(huì)加長(zhǎng)等待時(shí)間，如果等待時(shí)間短了，還可能會(huì)有g(shù)oroutine因?yàn)橹骶€程的退出而被銷(xiāo)毀

（3）通過(guò)全局變量加鎖同步來(lái)實(shí)現(xiàn)通訊，也不利于多個(gè)協(xié)程對(duì)全局變量的讀寫(xiě)操作

以上為個(gè)人經(jīng)驗(yàn)，希望能給大家一個(gè)參考，也希望大家多多支持腳本之家。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教。