"Do not communicate by sharing memory; instead, share memory by communicating" 這句話在講 Golang 并發(fā)的好多文章里看到過，仿佛是一個(gè)格言一般新娜。然而對(duì)于它的真正含義一直不是很清楚赵辕。
最近看到了如下的代碼，才對(duì)這句話有所思考和理解概龄。
摘自 https://golang.org/ref/mem 的一段 錯(cuò)誤 的并發(fā)代碼：
var a string
var done bool
func setup() {
a = "hello, world"
done = true
}
func main() {
go setup()
for !done {
}
print(a)
}
這段代碼是典型的 communicate by sharing memory还惠。而官網(wǎng)說到這段錯(cuò)誤的代碼可能的結(jié)局有兩種不能接受：
-
print(a)打印出來的是空字符串。 -
main函數(shù)陷入死循環(huán)私杜。
先來解釋一下1：Go的內(nèi)存模型里說到 “happen before” 這樣一條原則蚕键，也講了很多種遵循這條原則的操作，比如在一個(gè) goroutine 中如果對(duì)一個(gè)變量的寫w和讀r衰粹，如果w在代碼上位于r的前面锣光，則 w 先于 r 發(fā)生。而這里對(duì) a 的寫操作 和 對(duì) done 的寫操作并不屬于 happen before 的范圍铝耻。也就是說誊爹，它們有可能同時(shí)發(fā)生 甚至 順序顛倒。所以在 檢測(cè)到 done 為 true 時(shí)田篇，a 還未賦值的情況是有可能發(fā)生的替废。
再來看2：如果在main函數(shù)的一開始或者在init函數(shù)中通過runtime.GOMAXPROCS(1)將并發(fā)數(shù)設(shè)置為1，那么setup永遠(yuǎn)不會(huì)執(zhí)行泊柬，main將會(huì)陷入死循環(huán)椎镣。即使 runtime.GOMAXPROCS>1，依然存在 done 一直為false的可能性：如果 setup 所在 goroutine 中對(duì) done 的寫入一直不flush到內(nèi)存（在寄存器或cache）兽赁，內(nèi)存中的done就會(huì)一直為false状答。
官網(wǎng)也講到了 Go 的各種并發(fā)元語(yǔ)是如何滿足 happens-before 原則的冷守。思考一下，上述例子在 GOMAXPROCS = 1 時(shí)是無法正常執(zhí)行的惊科，那么那些正確的并發(fā)程序在 GOMAXPROCS = 1 時(shí)表現(xiàn)如何呢拍摇？所謂正確的并發(fā)程序，goroutine之間應(yīng)當(dāng)是通過并發(fā)元語(yǔ)來溝通協(xié)作的馆截，那么他們之間必然有某種 happen-before 的約束存在充活，happen-before 的實(shí)質(zhì)作用其實(shí)是將兩個(gè)goroutine的某一部分串行起來，使用并發(fā)原語(yǔ)蜡娶，也就是為了將需要串行的部分串行起來混卵，這樣即使是 GOMAXPROCS = 1，多個(gè)goroutine 也是能夠正確協(xié)作的窖张。
所以對(duì)于 “Do not communicate by sharing memory; instead, share memory by communicating” 這句話幕随，我認(rèn)為 share memory by communicating 的 communicating 不光是指 channel，Go 的并發(fā)元語(yǔ)都是 communicating宿接，Mutex赘淮，Once，atomic睦霎， channel 等都是 goroutine 之間溝通的正確方式梢卸。
