gopl-zh.github.com/ch9/ch9-05.md

107 lines
5.3 KiB
Markdown
Raw Normal View History

2015-12-09 07:45:11 +00:00
## 9.5. sync.Once初始化
2016-01-11 02:05:57 +00:00
如果初始化成本比較大的話那麽將初始化延遲到需要的時候再去做就是一個比較好的選擇。如果在程序啟動的時候就去做這類的初始化的話會增加程序的啟動時間併且因爲執行的時候可能也併不需要這些變量所以實際上有一些浪費。讓我們在本章早一些時候看到的icons變量
2016-01-10 11:31:19 +00:00
```go
var icons map[string]image.Image
```
2016-01-11 02:05:57 +00:00
這個版本的Icon用到了懶初始化(lazy initialization)。
2016-01-10 11:31:19 +00:00
```go
func loadIcons() {
2016-01-11 02:05:57 +00:00
icons = map[string]image.Image{
"spades.png": loadIcon("spades.png"),
"hearts.png": loadIcon("hearts.png"),
"diamonds.png": loadIcon("diamonds.png"),
"clubs.png": loadIcon("clubs.png"),
}
2016-01-10 11:31:19 +00:00
}
// NOTE: not concurrency-safe!
func Icon(name string) image.Image {
2016-01-11 02:05:57 +00:00
if icons == nil {
loadIcons() // one-time initialization
}
return icons[name]
2016-01-10 11:31:19 +00:00
}
```
2016-01-11 02:05:57 +00:00
如果一個變量隻被一個單獨的goroutine所訪問的話我們可以使用上面的這種模闆但這種模闆在Icon被併發調用時併不安全。就像前面銀行的那個Deposit(存款)函數一樣Icon函數也是由多個步驟組成的首先測試icons是否爲空然後load這些icons之後將icons更新爲一個非空的值。直覺會告訴我們最差的情況是loadIcons函數被多次訪問會帶來數據競爭。當第一個goroutine在忙着loading這些icons的時候另一個goroutine進入了Icon函數發現變量是nil然後也會調用loadIcons函數。
2016-01-10 11:31:19 +00:00
2016-01-11 02:05:57 +00:00
不過這種直覺是錯誤的。(我們希望現在你從現在開始能夠構建自己對併發的直覺,也就是説對併發的直覺總是不能被信任的!)迴憶一下9.4節。因爲缺少顯式的同步編譯器和CPU是可以隨意地去更改訪問內存的指令順序以任意方式隻要保證每一個goroutine自己的執行順序一致。其中一種可能loadIcons的語句重排是下面這樣。它會在填寫icons變量的值之前先用一個空map來初始化icons變量。
2016-01-10 11:31:19 +00:00
```go
func loadIcons() {
2016-01-11 02:05:57 +00:00
icons = make(map[string]image.Image)
icons["spades.png"] = loadIcon("spades.png")
icons["hearts.png"] = loadIcon("hearts.png")
icons["diamonds.png"] = loadIcon("diamonds.png")
icons["clubs.png"] = loadIcon("clubs.png")
2016-01-10 11:31:19 +00:00
}
```
2016-01-11 02:05:57 +00:00
因此一個goroutine在檢査icons是非空時也併不能就假設這個變量的初始化流程已經走完了(譯註可能隻是塞了個空map里面的值還沒填完也就是説填值的語句都沒執行完呢)。
2016-01-10 11:31:19 +00:00
2016-01-11 02:05:57 +00:00
最簡單且正確的保證所有goroutine能夠觀察到loadIcons效果的方式是用一個mutex來同步檢査。
2016-01-10 11:31:19 +00:00
```go
var mu sync.Mutex // guards icons
var icons map[string]image.Image
// Concurrency-safe.
func Icon(name string) image.Image {
2016-01-11 02:05:57 +00:00
mu.Lock()
defer mu.Unlock()
if icons == nil {
loadIcons()
}
return icons[name]
2016-01-10 11:31:19 +00:00
}
```
2016-01-11 02:05:57 +00:00
然而使用互斥訪問icons的代價就是沒有辦法對該變量進行併發訪問卽使變量已經被初始化完畢且再也不會進行變動。這里我們可以引入一個允許多讀的鎖
2016-01-10 11:31:19 +00:00
```go
var mu sync.RWMutex // guards icons
var icons map[string]image.Image
// Concurrency-safe.
func Icon(name string) image.Image {
2016-01-11 02:05:57 +00:00
mu.RLock()
if icons != nil {
icon := icons[name]
mu.RUnlock()
return icon
}
mu.RUnlock()
// acquire an exclusive lock
mu.Lock()
if icons == nil { // NOTE: must recheck for nil
loadIcons()
}
icon := icons[name]
mu.Unlock()
return icon
2016-01-10 11:31:19 +00:00
}
```
2016-01-11 02:05:57 +00:00
上面的代碼有兩個臨界區。goroutine首先會獲取一個寫鎖査詢map然後釋放鎖。如果條目被找到了(一般情況下)那麽會直接返迴。如果沒有找到那goroutine會獲取一個寫鎖。不釋放共享鎖的話也沒有任何辦法來將一個共享鎖陞級爲一個互斥鎖所以我們必鬚重新檢査icons變量是否爲nil以防止在執行這一段代碼的時候icons變量已經被其它gorouine初始化過了。
2016-01-10 11:31:19 +00:00
2016-01-11 02:05:57 +00:00
上面的模闆使我們的程序能夠更好的併發但是有一點太複雜且容易出錯。幸運的是sync包爲我們提供了一個專門的方案來解決這種一次性初始化的問題sync.Once。概念上來講一次性的初始化需要一個互斥量mutex和一個boolean變量來記録初始化是不是已經完成了互斥量用來保護boolean變量和客戶端數據結構。Do這個唯一的方法需要接收初始化函數作爲其參數。讓我們用sync.Once來簡化前面的Icon函數吧
2016-01-10 11:31:19 +00:00
```go
var loadIconsOnce sync.Once
var icons map[string]image.Image
// Concurrency-safe.
func Icon(name string) image.Image {
2016-01-11 02:05:57 +00:00
loadIconsOnce.Do(loadIcons)
return icons[name]
2016-01-10 11:31:19 +00:00
}
```
2016-01-11 02:05:57 +00:00
每一次對Do(loadIcons)的調用都會鎖定mutex併會檢査boolean變量。在第一次調用時變量的值是falseDo會調用loadIcons併會將boolean設置爲true。隨後的調用什麽都不會做但是mutex同步會保證loadIcons對內存(這里其實就是指icons變量啦)産生的效果能夠對所有goroutine可見。用這種方式來使用sync.Once的話我們能夠避免在變量被構建完成之前和其它goroutine共享該變量。
2016-01-10 11:31:19 +00:00
2016-01-11 02:05:57 +00:00
**練習 9.2** 重寫2.6.2節中的PopCount的例子使用sync.Once隻在第一次需要用到的時候進行初始化。(雖然實際上對PopCount這樣很小且高度優化的函數進行同步可能代價沒法接受)