您好,登錄后才能下訂單哦!
這篇“Go如何實(shí)現(xiàn)安全的雙檢鎖”文章的知識(shí)點(diǎn)大部分人都不太理解,所以小編給大家總結(jié)了以下內(nèi)容,內(nèi)容詳細(xì),步驟清晰,具有一定的借鑒價(jià)值,希望大家閱讀完這篇文章能有所收獲,下面我們一起來(lái)看看這篇“Go如何實(shí)現(xiàn)安全的雙檢鎖”文章吧。
從其他語(yǔ)言轉(zhuǎn)入Go語(yǔ)言的同學(xué)經(jīng)常會(huì)陷入一個(gè)思考:如何創(chuàng)建一個(gè)單例?
有些同學(xué)可能會(huì)把其它語(yǔ)言中的雙檢鎖模式移植過(guò)來(lái),雙檢鎖模式也稱為懶漢模式,首次用到的時(shí)候才創(chuàng)建實(shí)例。大部分人首次用Golang寫出來(lái)的實(shí)例大概是這樣的:
type Conn struct { Addr string State int } var c *Conn var mu sync.Mutex func GetInstance() *Conn { if c == nil { mu.Lock() defer mu.Unlock() if c == nil { c = &Conn{"127.0.0.1:8080", 1} } } return c }
這里先解釋下這段代碼的執(zhí)行邏輯(已經(jīng)清楚的同學(xué)可以直接跳過(guò)):
GetInstance用于獲取結(jié)構(gòu)體Conn的一個(gè)實(shí)例,其中:先判斷c是否為空,如果為空則加鎖,加鎖之后再判斷一次c是否為空,如果還為空,則創(chuàng)建Conn的一個(gè)實(shí)例,并賦值給c。這里有兩次判空,所以稱為雙檢,需要第二次判空的原因是:加鎖之前可能有多個(gè)線程/協(xié)程都判斷為空,這些線程/協(xié)程都會(huì)在這里等著加鎖,它們最終也都會(huì)執(zhí)行加鎖操作,不過(guò)加鎖之后的代碼在多個(gè)線程/協(xié)程之間是串行執(zhí)行的,一個(gè)線程/協(xié)程判空之后創(chuàng)建了實(shí)例,其它線程/協(xié)程在判斷c是否為空時(shí)必然得出false的結(jié)果,這樣就能保證c僅創(chuàng)建一次。而且后續(xù)調(diào)用GetInstance時(shí)都會(huì)僅執(zhí)行第一次判空,得出false的結(jié)果,然后直接返回c。這樣每個(gè)線程/協(xié)程最多只執(zhí)行一次加鎖操作,后續(xù)都只是簡(jiǎn)單的判斷下就能返回結(jié)果,其性能必然不錯(cuò)。
了解Java的同學(xué)可能知道Java中的雙檢鎖是非線程安全的,這是因?yàn)橘x值操作中的兩個(gè)步驟可能會(huì)出現(xiàn)亂序執(zhí)行問(wèn)題。這兩個(gè)步驟是:對(duì)象內(nèi)存空間的初始化和將內(nèi)存地址設(shè)置給變量。因?yàn)榫幾g器或者CPU優(yōu)化,它們的執(zhí)行順序可能不確定,先執(zhí)行第2步的話,鎖外邊的線程很有可能訪問(wèn)到?jīng)]有初始化完畢的變量,從而引發(fā)某些異常。針對(duì)這個(gè)問(wèn)題,Java以及其它一些語(yǔ)言中可以使用volatile來(lái)修飾變量,實(shí)際執(zhí)行時(shí)會(huì)通過(guò)插入內(nèi)存柵欄阻止指令重排,強(qiáng)制按照編碼的指令順序執(zhí)行。
那么Go語(yǔ)言中的雙檢鎖是安全的嗎?
答案是也不安全。
先來(lái)看看指令重排問(wèn)題:
在Go語(yǔ)言規(guī)范中,賦值操作分為兩個(gè)階段:第一階段對(duì)賦值操作左右兩側(cè)的表達(dá)式進(jìn)行求值,第二階段賦值按照從左至右的順序執(zhí)行。
說(shuō)的有點(diǎn)抽象,但沒(méi)有提到賦值存在指令重排的問(wèn)題,隱約感覺(jué)不會(huì)有這個(gè)問(wèn)題。為了驗(yàn)證,讓我們看一下上邊那段代碼中賦值操作的偽匯編代碼:
紅框圈出來(lái)的部分對(duì)應(yīng)的代碼是: c = &Conn{"127.0.0.1:8080", 1}
其中有一行:CMPL $0x0, runtime.writeBarrier(SB) ,這個(gè)指令就是插入一個(gè)內(nèi)存柵欄。前邊是要賦值數(shù)據(jù)的初始化,后邊是賦值操作。如此看,賦值操作不存在指令重排的問(wèn)題。
既然賦值操作沒(méi)有指令重排的問(wèn)題,那這個(gè)雙檢鎖怎么還是不安全的呢?
在Golang中,對(duì)于大于單個(gè)機(jī)器字的值,讀寫它的時(shí)候是以一種不確定的順序多次執(zhí)行單機(jī)器字的操作來(lái)完成的。機(jī)器字大小就是我們通常說(shuō)的32位、64位,即CPU完成一次無(wú)定點(diǎn)整數(shù)運(yùn)算可以處理的二進(jìn)制位數(shù),也可以認(rèn)為是CPU數(shù)據(jù)通道的大小。比如在32位的機(jī)器上讀寫一個(gè)int64類型的值就需要兩次操作。
因?yàn)镚olang中對(duì)變量的讀和寫都沒(méi)有原子性的保證,所以很可能出現(xiàn)這種情況:鎖里邊變量賦值只處理了一半,鎖外邊的另一個(gè)goroutine就讀到了未完全賦值的變量。所以這個(gè)雙檢鎖的實(shí)現(xiàn)是不安全的。
Golang中將這種問(wèn)題稱為data race,說(shuō)的是對(duì)某個(gè)數(shù)據(jù)產(chǎn)生了并發(fā)讀寫,讀到的數(shù)據(jù)不可預(yù)測(cè),可能產(chǎn)生問(wèn)題,甚至導(dǎo)致程序崩潰??梢栽跇?gòu)建或者運(yùn)行時(shí)檢查是否會(huì)發(fā)生這種情況:
$ go test -race mypkg // to test the package $ go run -race mysrc.go // to run the source file $ go build -race mycmd // to build the command $ go install -race mypkg // to install the package
另外上邊說(shuō)單條賦值操作沒(méi)有重排序的問(wèn)題,但是重排序問(wèn)題在Golang中還是存在的,稍不注意就可能寫出BUG來(lái)。比如下邊這段代碼:
a=1 b=1 c=a+b
在執(zhí)行這段程序的goroutine中并不會(huì)出現(xiàn)問(wèn)題,但是另一個(gè)goroutine讀取到b1時(shí)并不代表此時(shí)a1,因?yàn)閍=1和b=1的執(zhí)行順序可能會(huì)被改變。針對(duì)重排序問(wèn)題,Golang并沒(méi)有暴露類似volatile的關(guān)鍵字,因?yàn)槔斫夂驼_使用這類能力進(jìn)行并發(fā)編程的門檻比較高,所以Golang只是在一些自己認(rèn)為比較適合的地方插入了內(nèi)存柵欄,盡量保持語(yǔ)言的簡(jiǎn)單。對(duì)于goroutine之間的數(shù)據(jù)同步,Go提供了更好的方式,那就是Channel,不過(guò)這不是本文的重點(diǎn),這里就不介紹了。
還是回到最開(kāi)始的問(wèn)題,如何在Golang中創(chuàng)建一個(gè)單例?
很多人應(yīng)該會(huì)被推薦使用 sync.Once ,這里看下如何使用:
type Conn struct { Addr string State int } var c *Conn var once sync.Once func setInstance() { fmt.Println("setup") c = &Conn{"127.0.0.1:8080", 1} } func doPrint() { once.Do(setInstance) fmt.Println(c) } func loopPrint() { for i := 0; i < 10; i++ { go doprint() } }
這里重用上文的結(jié)構(gòu)體Conn,設(shè)置Conn單例的方法是setInstance,這個(gè)方法在doPrint中被once.Do調(diào)用,這里的once就是sync.Once的一個(gè)實(shí)例,然后我們?cè)趌oopPrint方法中創(chuàng)建10個(gè)goroutine來(lái)調(diào)用doPrint方法。
按照sync.Once的語(yǔ)義,setInstance應(yīng)該近執(zhí)行一次??梢詫?shí)際執(zhí)行下看看,我這里直接貼出結(jié)果:
setup
&{127.0.0.1:8080 1}
&{127.0.0.1:8080 1}
&{127.0.0.1:8080 1}
&{127.0.0.1:8080 1}
&{127.0.0.1:8080 1}
&{127.0.0.1:8080 1}
&{127.0.0.1:8080 1}
&{127.0.0.1:8080 1}
&{127.0.0.1:8080 1}
&{127.0.0.1:8080 1}
無(wú)論執(zhí)行多少遍,都是這個(gè)結(jié)果。那么sync.Once是怎么做到的呢?源碼很短很清楚:
type Once struct { done uint32 m Mutex } func (o *Once) Do(f func()) { if atomic.LoadUint32(&o.done) == 0 { o.doSlow(f) } } func (o *Once) doSlow(f func()) { o.m.Lock() defer o.m.Unlock() if o.done == 0 { defer atomic.StoreUint32(&o.done, 1) f() } }
Once是一個(gè)結(jié)構(gòu)體,其中第一個(gè)字段標(biāo)識(shí)是否執(zhí)行過(guò),第二個(gè)字段是一個(gè)互斥量。Once僅公開(kāi)了一個(gè)Do方法,用于執(zhí)行目標(biāo)函數(shù)f。
這里重點(diǎn)看下目標(biāo)函數(shù)f是怎么被執(zhí)行的?
Do方法中第一行是判斷字段done是否為0,為0則代表沒(méi)執(zhí)行過(guò),為1則代表執(zhí)行過(guò)。這里用了原子讀,寫的時(shí)候也要原子寫,這樣可以保證讀寫不會(huì)同時(shí)發(fā)生,能夠讀到當(dāng)前最新的值。
如果done為0,則調(diào)用doSLow方法,從名字我們就可以體會(huì)到這個(gè)方法比較慢。
doSlow中首先會(huì)加鎖,使用的是Once結(jié)構(gòu)體的第二個(gè)字段。
然后再判斷done是否為0,注意這里沒(méi)有使用原子讀,為什么呢?因?yàn)殒i中的方法是串行執(zhí)行的,不會(huì)發(fā)生并發(fā)讀寫。
如果done為0,則調(diào)用目標(biāo)函數(shù)f,執(zhí)行相關(guān)的業(yè)務(wù)邏輯。
在執(zhí)行目標(biāo)函數(shù)f前,這里還聲明了一個(gè)defer:defer atomic.StoreUint32(&o.done, 1) ,使用原子寫改變done的值為1,代表目標(biāo)函數(shù)已經(jīng)執(zhí)行過(guò)。它會(huì)在目標(biāo)函數(shù)f執(zhí)行完畢,doSlow方法返回之前執(zhí)行。這個(gè)設(shè)計(jì)很精妙,精確控制了改寫done值的時(shí)機(jī)。
可以看出,這里用的也是雙檢鎖的模式,只不過(guò)做了兩個(gè)增強(qiáng):一是使用原子讀寫,避免了并發(fā)讀寫的內(nèi)存數(shù)據(jù)不一致問(wèn)題;二是在defer中更改完成標(biāo)識(shí),保證了代碼執(zhí)行順序,不會(huì)出現(xiàn)完成標(biāo)識(shí)更改邏輯被編譯器或者CPU優(yōu)化提前執(zhí)行。
需要注意,如果目標(biāo)函數(shù)f中發(fā)生了panic,目標(biāo)函數(shù)也僅執(zhí)行一次,不會(huì)執(zhí)行多次直到成功。
有了對(duì)sync.Once的理解,我們可以改造之前寫的雙檢鎖邏輯,讓它也能安全起來(lái)。
type Conn struct { Addr string State int } var c *Conn var mu sync.Mutex var done uint32 func getInstance() *Conn { if atomic.LoadUint32(&done) == 0 { mu.Lock() defer mu.Unlock() if done == 0 { defer atomic.StoreUint32(&done, 1) c = &Conn{"127.0.0.1:8080", 1} } } return c }
改變的地方就是sync.Once做的兩個(gè)增強(qiáng);原子讀寫和defer中更改完成標(biāo)識(shí)。
當(dāng)然如果要做的工作僅限于此,還不如直接使用sync.Once。
有時(shí)候我們需要的單例不是一成不變的,比如在ylog中需要每小時(shí)創(chuàng)建一個(gè)日志文件的實(shí)例,再比如需要為每一個(gè)用戶創(chuàng)建不同的單例;再比如創(chuàng)建實(shí)例的過(guò)程中發(fā)生了錯(cuò)誤,可能我們還會(huì)期望再執(zhí)行實(shí)例的創(chuàng)建過(guò)程,直到成功。這兩個(gè)需求是sync.Once無(wú)法做到的。
這里在創(chuàng)建Conn的時(shí)候模擬一個(gè)panic。
i:=0 func newConn() *Conn { fmt.Println("newConn") div := i i++ k := 10 / div return &Conn{"127.0.0.1:8080", k} }
第1次執(zhí)行newConn時(shí)會(huì)發(fā)生一個(gè)除零錯(cuò)誤,并引發(fā) panic。再執(zhí)行時(shí)則可以正常創(chuàng)建。
panic可以通過(guò)recover進(jìn)行處理,因此可以在捕捉到panic時(shí)不更改完成標(biāo)識(shí),之前的getInstance方法可以修改為:
func getInstance() *Conn { if atomic.LoadUint32(&done) == 0 { mu.Lock() defer mu.Unlock() if done == 0 { defer func() { if r := recover(); r == nil { defer atomic.StoreUint32(&done, 1) } }() c = newConn() } } return c }
可以看到這里只是改了下defer函數(shù),捕捉不到panic時(shí)才去更改完成標(biāo)識(shí)。注意此時(shí)c并沒(méi)有創(chuàng)建成功,會(huì)返回零值,或許你還需要增加其它的錯(cuò)誤處理。
如果業(yè)務(wù)代碼不是拋出panic,而是返回error,這時(shí)候怎么處理?
可以將error轉(zhuǎn)為panic,比如newConn是這樣實(shí)現(xiàn)的:
func newConn() (*Conn, error) { fmt.Println("newConn") div := i i++ if div == 0 { return nil, errors.New("the divisor is zero") } k := 1 / div return &Conn{"127.0.0.1:8080", k}, nil }
我們可以再把它包裝一層:
func mustNewConn() *Conn { conn, err := newConn() if err != nil { panic(err) } return conn }
如果不使用panic,還可以再引入一個(gè)變量,有error時(shí)對(duì)它賦值,在defer函數(shù)中增加對(duì)這個(gè)變量的判斷,如果有錯(cuò)誤值,則不更新完成標(biāo)識(shí)位。代碼也比較容易實(shí)現(xiàn),不過(guò)還要增加變量,感覺(jué)復(fù)雜了,這里就不測(cè)試這種方法了。
前文提到過(guò)有時(shí)單例不是一成不變的,我這里將這種單例稱為有范圍的單例。
這里還是復(fù)用前文的Conn結(jié)構(gòu)體,不過(guò)需求修改為要為每個(gè)用戶創(chuàng)建一個(gè)Conn實(shí)例。
看一下User的定義:
type User struct { done uint32 Id int64 mu sync.Mutex c *Conn }
其中包括一個(gè)用戶Id,其它三個(gè)字段還是用于獲取當(dāng)前用戶的Conn單例的。
再看看getInstance函數(shù)怎么改:
func getInstance(user *User) *Conn { if atomic.LoadUint32(&user.done) == 0 { user.mu.Lock() defer user.mu.Unlock() if user.done == 0 { defer func() { if r := recover(); r == nil { defer atomic.StoreUint32(&user.done, 1) } }() user.c = newConn() } } return user.c }
這里增加了一個(gè)參數(shù) user,方法內(nèi)的邏輯基本沒(méi)變,只不過(guò)操作的東西都變成user的字段。這樣就可以為每個(gè)用戶創(chuàng)建一個(gè)Conn單例。
這個(gè)方法有點(diǎn)泛型的意思了,當(dāng)然不是泛型。
有范圍單例的另一個(gè)示例:在ylog中需要每小時(shí)創(chuàng)建一個(gè)日志文件用于記錄當(dāng)前小時(shí)的日志,在每個(gè)小時(shí)只需創(chuàng)建并打開(kāi)這個(gè)文件一次。
先看看Logger的定義(這里省略和創(chuàng)建單例無(wú)關(guān)的內(nèi)容。):
type FileLogger struct { lastHour int64 file *os.File mu sync.Mutex ... }
lastHour是記錄的小時(shí)數(shù),如果當(dāng)前小時(shí)數(shù)不等于記錄的小時(shí)數(shù),則說(shuō)明應(yīng)該創(chuàng)建新的文件,這個(gè)變量類似于sync.Once中的done字段。
file是打開(kāi)的文件實(shí)例。
mu是創(chuàng)建文件實(shí)例時(shí)需要加的鎖。
下邊看一下打開(kāi)文件的方法:
func (l *FileLogger) ensureFile() (err error) { curTime := time.Now() curHour := getTimeHour(curTime) if atomic.LoadInt64(&l.lastHour) != curHour { return l.ensureFileSlow(curTime, curHour) } return } func (l *FileLogger) ensureFileSlow(curTime time.Time, curHour int64) (err error) { l.mu.Lock() defer l.mu.Unlock() if l.lastHour != curHour { defer func() { if r := recover(); r == nil { atomic.StoreInt64(&l.lastHour, curHour) } }() l.createFile(curTime, curHour) } return }
這里模仿sync.Once中的處理方法,有兩點(diǎn)主要的不同:數(shù)值比較不再是0和1,而是每個(gè)小時(shí)都會(huì)變化的數(shù)字;增加了對(duì)panic的處理。如果打開(kāi)文件失敗,則還會(huì)再次嘗試打開(kāi)文件。
要查看完整的代碼請(qǐng)?jiān)L問(wèn)Github:https://github.com/bosima/ylog/tree/1.0
從原理上分析,雙檢鎖的性能要好過(guò)互斥鎖,因?yàn)榛コ怄i每次都要加鎖;不使用原子操作的雙檢鎖要比使用原子操作的雙檢鎖好一些,畢竟原子操作也是有些成本的。那么實(shí)際差距是多少呢?
這里做一個(gè)Benchmark Test,還是處理上文的Conn結(jié)構(gòu)體,為了方便測(cè)試,定義一個(gè)上下文:
type Context struct { done uint32 c *Conn mu sync.Mutex }
編寫三個(gè)用于測(cè)試的方法:
func ensure_unsafe_dcl(context *Context) { if context.done == 0 { context.mu.Lock() defer context.mu.Unlock() if context.done == 0 { defer func() { context.done = 1 }() context.c = newConn() } } } func ensure_dcl(context *Context) { if atomic.LoadUint32(&context.done) == 0 { context.mu.Lock() defer context.mu.Unlock() if context.done == 0 { defer atomic.StoreUint32(&context.done, 1) context.c = newConn() } } } func ensure_mutex(context *Context) { context.mu.Lock() defer context.mu.Unlock() if context.done == 0 { defer func() { context.done = 1 }() context.c = newConn() } }
這三個(gè)方法分別對(duì)應(yīng)不安全的雙檢鎖、使用原子操作的安全雙檢鎖和每次都加互斥鎖。它們的作用都是確保Conn結(jié)構(gòu)體的實(shí)例存在,如果不存在則創(chuàng)建。
使用的測(cè)試方法都是下面這種寫法,按照計(jì)算機(jī)邏輯處理器的數(shù)量并行運(yùn)行測(cè)試方法:
func BenchmarkInfo_DCL(b *testing.B) { context := &Context{} b.ResetTimer() b.RunParallel(func(pb *testing.PB) { for pb.Next() { ensure_dcl(context) processConn(context.c) } }) }
先看一下Benchmark Test的結(jié)果:
可以看到使用雙檢鎖相比每次加鎖的提升是兩個(gè)數(shù)量級(jí),這是正常的。
而不安全的雙檢鎖和使用原子操作的安全雙檢鎖時(shí)間消耗相差無(wú)幾,為什么呢?
主要原因是這里寫只有1次,剩下的全是讀。即使使用了原子操作,絕大部分情況下CPU讀數(shù)據(jù)的時(shí)候也不用在多個(gè)核心之間同步(鎖總線、鎖緩存等),只需要讀緩存就可以了。這也從一個(gè)方面證明了雙檢鎖模式的意義。
另外上文提到過(guò)Go讀寫超過(guò)一個(gè)機(jī)器字的變量時(shí)是非原子的,那如果讀寫只有1個(gè)機(jī)器字呢?在64位機(jī)器上讀寫int64本身就是原子操作,也就是說(shuō)讀寫應(yīng)該都只需1次操作,不管用不用atomic方法。這可以在編譯器文檔或者CPU手冊(cè)中驗(yàn)證。
不過(guò)這兩個(gè)分析不是說(shuō)我們使用原子操作沒(méi)有意義,不安全雙檢鎖的執(zhí)行結(jié)果是沒(méi)有Go語(yǔ)言規(guī)范保證的,上邊的結(jié)果只是在特定編譯器、特定平臺(tái)下的基準(zhǔn)測(cè)試結(jié)果,不同的編譯器、CPU,甚至不同版本的Go都不知道會(huì)出什么幺蛾子,運(yùn)行的效果也就無(wú)法保證。我們不得不考慮程序的可移植性。
以上就是關(guān)于“Go如何實(shí)現(xiàn)安全的雙檢鎖”這篇文章的內(nèi)容,相信大家都有了一定的了解,希望小編分享的內(nèi)容對(duì)大家有幫助,若想了解更多相關(guān)的知識(shí)內(nèi)容,請(qǐng)關(guān)注億速云行業(yè)資訊頻道。
免責(zé)聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng),如果涉及侵權(quán)請(qǐng)聯(lián)系站長(zhǎng)郵箱:is@yisu.com進(jìn)行舉報(bào),并提供相關(guān)證據(jù),一經(jīng)查實(shí),將立刻刪除涉嫌侵權(quán)內(nèi)容。