Go?常見設(shè)計(jì)模式之單例模式詳解
餓漢式
餓漢式實(shí)現(xiàn)單例模式非常簡(jiǎn)單,直接看代碼:
package singleton type singleton struct{} var instance = &singleton{} func GetSingleton() *singleton { return instance }
singleton
包在被導(dǎo)入時(shí)會(huì)自動(dòng)初始化 instance
實(shí)例,使用時(shí)通過調(diào)用 singleton.GetSingleton()
函數(shù)即可獲得 singleton
這個(gè)結(jié)構(gòu)體的單例對(duì)象。
由于單例對(duì)象是在包加載時(shí)立即被創(chuàng)建出來,所以也就有了這個(gè)形象的名稱叫作餓漢式。與之對(duì)應(yīng)的另一種實(shí)現(xiàn)方式叫作懶漢式,當(dāng)實(shí)例被第一次使用時(shí)才會(huì)被創(chuàng)建。
需要注意的是,盡管餓漢式實(shí)現(xiàn)單例模式如此簡(jiǎn)單,但大多數(shù)情況下仍不被推薦使用,因?yàn)槿绻麊卫龑?shí)例化時(shí)初始化內(nèi)容過多,可能造成程序加載用時(shí)較長(zhǎng)。
懶漢式
接下來我們?cè)賮砜聪氯绾瓮ㄟ^懶漢式實(shí)現(xiàn)單例模式:
package singleton type singleton struct{} var instance *singleton func GetSingleton() *singleton { if instance == nil { instance = &singleton{} } return instance }
相較于餓漢式的實(shí)現(xiàn),我們把實(shí)例化 singleton
結(jié)構(gòu)體部分的代碼移到了 GetSingleton()
函數(shù)內(nèi)部。這樣一來,就將對(duì)象實(shí)例化的步驟延遲到了 GetSingleton()
被第一次調(diào)用時(shí)。
通過 instance == nil
的判斷來實(shí)現(xiàn)單例并不十分可靠,當(dāng)有多個(gè) goroutine
同時(shí)調(diào)用 GetSingleton()
時(shí)無法保證并發(fā)安全。
支持并發(fā)的單例
如果你用 Go 語言寫過并發(fā)編程,那么應(yīng)該可以很快想到解決懶漢式單例模式并發(fā)安全問題的方案:
package singleton import "sync" type singleton struct{} var instance *singleton var mu sync.Mutex func GetSingleton() *singleton { mu.Lock() defer mu.Unlock() if instance == nil { instance = &singleton{} } return instance }
我們對(duì)代碼的主要修改就是在 GetSingleton()
函數(shù)最開始加了如下兩行代碼:
mu.Lock() defer mu.Unlock()
通過加鎖的機(jī)制,就可以保證這個(gè)實(shí)現(xiàn)單例模式的函數(shù)是并發(fā)安全的。
不過這樣也有些問題,因?yàn)橛昧随i機(jī)制,每次調(diào)用 GetSingleton()
時(shí)程序都會(huì)進(jìn)行加鎖、解鎖的步驟,這樣會(huì)導(dǎo)致程序性能的下降。
雙重鎖定
加鎖導(dǎo)致程序性能下降,但我們又不得不用鎖來保證程序的并發(fā)安全,于是有人想出了雙重鎖定(Double-Check Locking
)的方案:
package singleton import "sync" type singleton struct{} var instance *singleton var mu sync.Mutex func GetSingleton() *singleton { if instance == nil { mu.Lock() defer mu.Unlock() if instance == nil { instance = &singleton{} } } return instance }
可以看到,所謂的雙重鎖定實(shí)際上就是在程序加鎖前又加了一層 instance == nil
判斷,這樣就兼顧了性能和安全兩個(gè)方面。
不過這段代碼看起來有些奇怪,既然外層已經(jīng)判斷了 instance == nil
,加鎖后卻又進(jìn)行了第二次 instance == nil
判斷。其實(shí)外層的 instance == nil
判斷是為了提高程序的執(zhí)行效率,因?yàn)槿绻?instance
已經(jīng)存在,則無需進(jìn)入 if
邏輯,程序直接返回 instance
即可。這樣就免去了原來每次調(diào)用 GetSingleton()
都上鎖的操作,將加鎖的粒度更加精細(xì)化。而內(nèi)層的 instance == nil
判斷則是考慮了并發(fā)安全,在極端情況下,多個(gè) goroutine
同時(shí)走到了加鎖這一步,內(nèi)層判斷就起到作用了。
Gopher 慣用方案
雖然我們通過雙重鎖定機(jī)制兼顧和性能和并發(fā)安全,但代碼有些丑陋,不符合廣大 Gopher 的期待。好在 Go 語言在 sync
包中提供了 Once
機(jī)制能夠幫助我們寫出更加優(yōu)雅的代碼:
package singleton import "sync" type singleton struct{} var instance *singleton var once sync.Once func GetSingleton() *singleton { once.Do(func() { instance = &singleton{} }) return instance }
Once
是一個(gè)結(jié)構(gòu)體,在執(zhí)行 Do
方法的內(nèi)部通過 atomic
操作和加鎖機(jī)制來保證并發(fā)安全,且 once.Do
能夠保證多個(gè) goroutine
同時(shí)執(zhí)行時(shí) &singleton{}
只被創(chuàng)建一次。
其實(shí) Once
并不神秘,其內(nèi)部實(shí)現(xiàn)跟上面使用的雙重鎖定機(jī)制非常類似,只不過把 instance == nil
換成了 atomic
操作,感興趣的同學(xué)可以查看下其對(duì)應(yīng)源碼。
總結(jié)
以上就是 Go 語言中實(shí)現(xiàn)單例模式的幾種常用套路,經(jīng)過對(duì)比可以得出結(jié)論,最推薦的方式是使用 once.Do
來實(shí)現(xiàn),sync.Once
包幫我們隱藏了部分細(xì)節(jié),卻可以讓代碼可讀性得到很大提升。
希望此文能對(duì)你有所幫助。
到此這篇關(guān)于Go 常見設(shè)計(jì)模式之單例模式詳解的文章就介紹到這了,更多相關(guān)Go單例模式內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!
相關(guān)文章
Go語言如何實(shí)現(xiàn)將[][]byte轉(zhuǎn)為io.Reader
本文主要介紹了如何在Go語言中實(shí)現(xiàn)將[][]byte轉(zhuǎn)換為io.Reader,文中通過示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2025-02-02GO 使用Webhook 實(shí)現(xiàn)github 自動(dòng)化部署的方法
這篇文章主要介紹了GO 使用Webhook 實(shí)現(xiàn)github 自動(dòng)化部署的方法,本文通過實(shí)例代碼給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-05-05一文帶你了解Golang中reflect反射的常見錯(cuò)誤
go?反射的錯(cuò)誤大多數(shù)都來自于調(diào)用了一個(gè)不適合當(dāng)前類型的方法,?而且,這些錯(cuò)誤通常是在運(yùn)行時(shí)才會(huì)暴露出來,而不是在編譯時(shí),如果我們傳遞的類型在反射代碼中沒有被覆蓋到那么很容易就會(huì)?panic。本文就介紹一下使用?go?反射時(shí)很大概率會(huì)出現(xiàn)的錯(cuò)誤,需要的可以參考一下2023-01-01Go標(biāo)準(zhǔn)庫之Requests的介紹與基本使用
Python中的Requests庫非常強(qiáng)大,所以Go開發(fā)者模仿Python的Requests庫,由此誕生了Grequests庫,本文主要介紹了Requests的基本使用,有需要的可以參考下2024-04-04