最近在學習MIT的分佈式課程6.824的過程當中,使用Go實現Raft協議時遇到了一些問題。參見以下代碼:git
for i := 0; i < len(rf.peers); i++ { DPrintf("i = %d", i) if i == rf.me { DPrintf("skipping myself #%d", rf.me) continue } go func() { DPrintf("len of rf.peers = %d", len(rf.peers)) DPrintf("server #%d sending request vote to server %d", rf.me, i) reply := &RequestVoteReply{} ok := rf.sendRequestVote(i, args, reply) if ok && reply.VoteGranted && reply.Term == rf.currentTerm { rf.voteCount++ if rf.voteCount > len(rf.peers)/2 { rf.winElectionCh <- true } } }() }
其中,peers切片的長度爲3,所以最高下標爲2,在非並行編程中代碼中的for-loop應該是很直觀的,我當時並無意識到有什麼問題。但是在調試過程當中,一直在報 index out of bounds 錯誤。調試信息顯示i的值爲3,當時就一直想不明白循環條件明明是 i < 2
,怎麼會變成3呢。github
雖然不明白髮生了什麼,但知道應該是循環中引入的 goroutine 致使的。通過Google,發現Go的wiki中就有一個頁面 Common Mistake - Using goroutines on loop iterator variables 專門提到了這個問題,看來真的是很 common 啊,笑哭~golang
初學者常常會使用以下代碼來並行處理數據:編程
for val := range values { go val.MyMethod() }
或者使用閉包(closure):閉包
for val := range values { go func() { fmt.Println(val) }() }
這裏的問題在於 val 其實是一個遍歷了切片中全部數據的單一變量。因爲閉包只是綁定到這個 val 變量上,所以極有可能上面的代碼的運行結果是全部 goroutine 都輸出了切片的最後一個元素。這是由於頗有可能當 for-loop 執行完以後 goroutine 纔開始執行,這個時候 val 的值指向切片中最後一個元素。分佈式
The val variable in the above loops is actually a single variable that takes on the value of each slice element. Because the closures are all only bound to that one variable, there is a very good chance that when you run this code you will see the last element printed for every iteration instead of each value in sequence, because the goroutines will probably not begin executing until after the loop.oop
以上代碼正確的寫法爲:學習
for val := range values { go func(val interface{}) { fmt.Println(val) }(val) }
在這裏將 val 做爲一個參數傳入 goroutine 中,每一個 val 都會被獨立計算並保存到 goroutine 的棧中,從而獲得預期的結果。this
另外一種方法是在循環內定義新的變量,因爲在循環內定義的變量在循環遍歷的過程當中是不共享的,所以也能夠達到一樣的效果:調試
for i := range valslice { val := valslice[i] go func() { fmt.Println(val) }() }
對於文章開頭提到的那個問題,最簡單的解決方案就是在循環內加一個臨時變量,並將後面 goroutine 內的 i 都替換爲這個臨時變量便可:
server := i
,