今天看到項(xiàng)目中的kafka客戶端包裝結(jié)構(gòu)體的獲取是單例模式<br>單例的實(shí)現(xiàn)是老生常談的問(wèn)題了，懶漢餓漢線程安全，因?yàn)榭吹巾?xiàng)目中寫的還是有些問(wèn)題，網(wǎng)上go單例實(shí)現(xiàn)的搜索結(jié)果比較少經(jīng)測(cè)試也并不靠譜，所以在這記錄下

現(xiàn)狀

當(dāng)前有的項(xiàng)目直接使用Mutex鎖，有的就直接判斷nil則創(chuàng)建，對(duì)于前者，每次都加鎖性能差，對(duì)于后者則會(huì)出現(xiàn)多個(gè)實(shí)例，也就不是單例了

改進(jìn)

進(jìn)而想要改進(jìn)一下，在這不討論餓漢和線程非安全的實(shí)現(xiàn)，對(duì)于go中線程安全的懶漢實(shí)現(xiàn)，常見(jiàn)兩種：

雙重檢驗(yàn)sync.Once

雙重檢驗(yàn)示例：

package main
 
import (
    "sync"
    "testing"
)
var (
    instance *int
    lock      sync.Mutex
func getInstance() *int {
    if instance == nil {
        lock.Lock()
        defer lock.Unlock()
        if instance == nil {
            i := 1
            instance = &i
        }
    }
    return instance
}
// 用于下邊基準(zhǔn)測(cè)試
func BenchmarkSprintf(b *testing.B){
    for i:=0;i<b.N;i++{
        go getInstance()

是否線程安全

基于java中雙重檢驗(yàn)鎖的經(jīng)驗(yàn)，因?yàn)閖vm的內(nèi)存模型，雙重檢驗(yàn)鎖會(huì)出現(xiàn)可見(jiàn)性問(wèn)題，可以通過(guò) volatile解決
那么在go里會(huì)有類似問(wèn)題嗎？
關(guān)鍵點(diǎn)在于instance變量的讀和寫是否是原子操作
這里做了個(gè)race競(jìng)態(tài)檢測(cè)：

可以看到20行的寫入和14行的讀取發(fā)生了競(jìng)態(tài)
上例中用64位(系統(tǒng)是64位)的int指針表示一個(gè)實(shí)例，也說(shuō)明了對(duì)于64位數(shù)據(jù)的寫入和讀取是非原子操作

我們看另一種實(shí)現(xiàn)：sync.Once方法

package main
 
import (
    "sync"
    "testing"
)
var (
    instance *int
    once      sync.Once
func getInstance() *int {
    once.Do(func(){
        if instance == nil {
            i := 1
            instance = &i
        }
    })
    return instance
}
func BenchmarkSprintf(b *testing.B){
    for i:=0;i<b.N;i++{
        go getInstance()
    }

實(shí)現(xiàn)比雙重檢驗(yàn)看起來(lái)要整潔許多

race檢測(cè)結(jié)果：

沒(méi)有發(fā)生競(jìng)態(tài)

關(guān)于sync.Once

那么sync.Once是怎么實(shí)現(xiàn)的呢

看下源碼：

package sync
 
import (
   "sync/atomic"
)
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()

可以看到sync.Once內(nèi)部其實(shí)也是一個(gè)雙重檢驗(yàn)鎖，但是對(duì)于共享變量（done字段）的讀和寫使用了atomic包的StoreUint32和LoadUint32方法

sync.Once使用一個(gè)32位無(wú)符號(hào)整數(shù)表示共享變量，即使是32位變量的讀寫操作都需要atomic包方法來(lái)實(shí)現(xiàn)原子性，更說(shuō)明了go里邊指針的讀寫不能保證原子性

關(guān)于atomic和metex

引用一段話：https://ms2008.github.io/2019/05/12/golang-data-race/

解決 race 的問(wèn)題時(shí)，無(wú)非就是上鎖?？赡芎芏嗳硕悸?tīng)說(shuō)過(guò)一個(gè)高逼格的詞叫「無(wú)鎖隊(duì)列」。 都一聽(tīng)到加鎖就覺(jué)得很 low，那無(wú)鎖又是怎么一回事？其實(shí)就是利用 atomic 特性，那 atomic 會(huì)比 mutex 有什么好處呢？go race detector 的作者總結(jié)了這兩者的一個(gè)區(qū)別：
Mutexes do no scale. Atomic loads do.
mutex 由操作系統(tǒng)實(shí)現(xiàn)，而 atomic 包中的原子操作則由底層硬件直接提供支持。在 CPU 實(shí)現(xiàn)的指令集里，有一些指令被封裝進(jìn)了 atomic 包，這些指令在執(zhí)行的過(guò)程中是不允許中斷（interrupt）的，因此原子操作可以在 lock-free 的情況下保證并發(fā)安全，并且它的性能也能做到隨 CPU 個(gè)數(shù)的增多而線性擴(kuò)展。
若實(shí)現(xiàn)相同的功能，后者通常會(huì)更有效率，并且更能利用計(jì)算機(jī)多核的優(yōu)勢(shì)。所以，以后當(dāng)我們想并發(fā)安全的更新一些變量的時(shí)候，我們應(yīng)該優(yōu)先選擇用 atomic 來(lái)實(shí)現(xiàn)。

結(jié)論

• go單例實(shí)現(xiàn)—雙重檢測(cè)法對(duì)共享變量直接讀取和賦值是不安全的，需要atomic包實(shí)現(xiàn)原子操作的讀寫
• 對(duì)于懶漢模式單例的實(shí)現(xiàn)，sync.Once是更好的辦法，簡(jiǎn)潔安全，sync.Once已經(jīng)幫我們實(shí)現(xiàn)了安全的雙重檢驗(yàn)，能做到加載完成后不再加鎖
• 這里也提醒我們，只要是對(duì)于共享變量的并發(fā)訪問(wèn)，一定要注意安全性，go更推崇避免共享變量，使用chan來(lái)交流信息，如果無(wú)法避免共享內(nèi)存，優(yōu)先使用atomic實(shí)現(xiàn)，其次sync，安全第一！

到此這篇關(guān)于go單例實(shí)現(xiàn)雙重檢測(cè)是否安全的文章就介紹到這了,更多相關(guān)go單例雙重檢測(cè)內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論