就是不讓你拷貝的意思够挂。
不是所有的東西都可以拷貝的,比如sync包下面的Mutex結(jié)構(gòu)體藕夫,就是不可以拷貝的。為了防止有些不應(yīng)該被拷貝的對(duì)象被拷貝枯冈,于是就有了noCopy毅贮。
golang中如何禁止復(fù)制
noCopy是一個(gè)golang基礎(chǔ)包內(nèi)部的結(jié)構(gòu)體(小寫開頭,說明不對(duì)外暴露尘奏,不想讓用戶調(diào)用)滩褥,其聲明如下:
type noCopy struct{}
// Lock is a no-op used by -copylocks checker from `go vet`.
func (*noCopy) Lock() {}
func (*noCopy) Unlock() {}
當(dāng)我們聲明的結(jié)構(gòu)體里包含noCopy時(shí):
type DoNotCopyMe struct {
noCopy
}
var d DoNotCopyMe
d2 := d // 這里發(fā)生了拷貝
編譯器是不會(huì)報(bào)錯(cuò)的,對(duì)炫加,你沒有看錯(cuò)瑰煎,編譯器是不會(huì)報(bào)錯(cuò)的,只能用vet工具檢查:
// 假設(shè)我們上面的代碼寫在main.go文件中
go vet main.go
// 會(huì)看到如下輸出
./main.go:616:11: assignment copies lock value to d2: command-line-arguments.DoNotCopyMe contains command-line-arguments.noCopy
./main.go:618:23: call of fmt.Printf copies lock value: command-line-arguments.DoNotCopyMe contains command-line-arguments.noCopy
如果沒有錯(cuò)誤的使用不能被copy的代碼審核俗孝,運(yùn)行命令時(shí)不會(huì)看到輸出酒甸。
從上面的實(shí)驗(yàn)我們可以得出兩點(diǎn)結(jié)論:
如果一個(gè)結(jié)構(gòu)體實(shí)現(xiàn)了Lock和Unlock函數(shù),原則上就不能被拷貝赋铝。
但是編譯器沒有做限制插勤,如果想知道代碼里是否有錯(cuò)誤的用法,需要用go vet命令檢查。
為什么sync.Mutex不能復(fù)制
如果說實(shí)現(xiàn)了Lock和Unlock方法的結(jié)構(gòu)體是不能復(fù)制的农尖,那么sync包下的Mutex肯定是符合條件的析恋,是不允許被復(fù)制的,我們來(lái)看個(gè)例子盛卡。
type Container struct {
sync.Mutex
counters map[string]int
}
func (c Container) inc(name string) {
c.Lock()
defer c.Unlock()
c.counters[name]++
}
func main() {
c := Container{counters: map[string]int{"a": 0, "b": 0}}
doIncrement := func(name string, n int) {
for i := 0; i < n; i++ {
c.inc(name) // A
}
}
go doIncrement("a", 100000)
go doIncrement("a", 100000)
time.Sleep(300 * time.Millisecond)
fmt.Println(c.counters)
}
讓我們運(yùn)行一下助隧,看會(huì)發(fā)生什么?
fatal error: concurrent map writes
拋異常了滑沧。
按說這段代碼是可以正常工作的呀并村,我們考慮到了map是不支持并發(fā)的,所以使用了互斥鎖來(lái)保護(hù)map嚎货,為什還會(huì)發(fā)生異常呢橘霎?
問題出在A部分,這里發(fā)生了對(duì)象拷貝殖属,也就是說姐叁,一個(gè)規(guī)定了noCopy的對(duì)象被拷貝了。
我們?nèi)绻薷纳厦娴拇a洗显,使它能正常工作呢外潜?
我們?cè)诼暶鱥nc方法的時(shí)候,應(yīng)該這樣聲明:
func (c *Container) inc(name string) {
c.Lock()
defer c.Unlock()
c.counters[name]++
}
把c改成指針類型就可以了挠唆,當(dāng)c無(wú)論在哪里引用处窥,都是同一個(gè)c,那么內(nèi)部使用的還是同一個(gè)Mutex對(duì)象玄组,是不會(huì)發(fā)生拷貝的滔驾。
Mutex會(huì)產(chǎn)生異常更本質(zhì)的原因
以后我們?cè)賹懳恼氯ソ馕鯩utex的原理,今天我們只對(duì)Mutex做淺顯的研究俄讹,能解決我們的疑惑即可哆致。我們看下Mutex的結(jié)構(gòu)體,在mutext.go文件里患膛,它是這樣定義的:
// A Mutex must not be copied after first use.
type Mutex struct {
state int32
sema uint32
}
在這個(gè)結(jié)構(gòu)體里并沒有指針摊阀,也就是說,外面c變量被拷貝了多少次踪蹬,Mutex也被拷貝了多少次胞此,這里沒有任何東西是共享的,每個(gè)goroutine里使用的Mutex實(shí)例都是自己的跃捣,并不是公用的漱牵,但是因?yàn)閙ap的本質(zhì)是一個(gè)指針,所以map倒是公用的疚漆。這就相當(dāng)于每個(gè)人都有自己的鑰匙布疙,卻要去開同一把鎖蚊惯,產(chǎn)生競(jìng)爭(zhēng)是必然的,map中有并發(fā)檢查灵临,于是就拋異常了截型。
所以,在了解到問題的本質(zhì)后儒溉,我們還有另一種解法:
type Container struct {
*sync.Mutex
counters map[string]int
}
c := Container{counters: map[string]int{"a": 0, "b": 0}, Mutex: &sync.Mutex{}}
把sync.Mutex定義成一個(gè)指針宦焦,這樣外面的c變量無(wú)論被拷貝多少次,內(nèi)部使用的鎖還是同一個(gè)顿涣,也能保持并發(fā)的inc方法能正常執(zhí)行波闹。
在結(jié)構(gòu)體中引用了Mutex后,很容易在拷貝后發(fā)生并發(fā)錯(cuò)誤涛碑。所以總是把Mutex聲明為指針不失為一個(gè)安全的方法精堕。
type AlwaysSafe struct {
mux *sync.Mutex
}
只是要記得初始化:
a := AlwaysSafe{mux: &sync.Mutex{}}