淺談golang for 循環中使用協程的問題
兩個例子
package main
import (
"fmt"
"time"
)
func Process1(tasks []string) {
for _, task := range tasks {
// 啟動協程並發處理任務
go func() {
fmt.Printf("Worker start process task: %s\n", task)
}()
}
}
func main() {
tasks := []string{"1", "2", "3", "4", "5"}
Process1(tasks)
time.Sleep(2 * time.Second)
}
結果：
第一次運行
Worker start process task: 3 Worker start process task: 4 Worker start process task: 4 Worker start process task: 5 Worker start process task: 5
第二次運行
Worker start process task: 2 Worker start process task: 5 Worker start process task: 5 Worker start process task: 5 Worker start process task: 5
package main
import (
"fmt"
"time"
)
func Process1(tasks []string) {
for _, task := range tasks {
// 啟動協程並發處理任務
go func() {
fmt.Printf("Worker start process task: %s\n", task)
}()
}
}
func Process2(tasks []string) {
for _, task := range tasks {
// 啟動協程並發處理任務
go func(t string) {
fmt.Printf("Worker start process task: %s\n", t)
}(task)
}
}
func main() {
tasks := []string{"1", "2", "3", "4", "5"}
Process2(tasks)
time.Sleep(2 * time.Second)
}
結果
第一次運行
Worker start process task: 5 Worker start process task: 4 Worker start process task: 2 Worker start process task: 3 Worker start process task: 1
第二次運行
Worker start process task: 2 Worker start process task: 5 Worker start process task: 4 Worker start process task: 1 Worker start process task: 3
上述問題，有個共同點就是都引用瞭循環變量。即在for index, value := range xxx語句中，
index和value便是循環變量。不同點是循環變量的使用方式，有的是直接在協程中引用（題目一），有的作為參數傳遞（題目二）。
循環變量是易變的
首先，循環變量實際上隻是一個普通的變量。
語句for index, value := range xxx中，每次循環index和value都會被重新賦值（並非生成新的變量）。
如果循環體中會啟動協程（並且協程會使用循環變量），就需要格外註意瞭，因為很可能循環結束後協程才開始執行，
此時，所有協程使用的循環變量有可能已被改寫。（是否會改寫取決於引用循環變量的方式）
循環變量需要綁定
在題目一中，協程函數體中引用瞭循環變量task，協程從被創建到被調度執行期間循環變量極有可能被改寫，所以會出現兩次結果相差較大，比如第一個協程啟動for range變量正好循環到3，for屬於主協程的一部分。go func是子協程，主子分開看。這種情況下，其實for range裡面的循環變量沒有跟子協程綁定，稱之為變量沒有綁定。所以，題目一打印結果是混亂的。很有可能（隨機）所有協程執行的task都是列表中的最後一個task，也可能不是。
在題目二中，協程函數體中並沒有直接引用循環變量task，而是使用的參數與協程進行瞭綁定。而在創建協程時，循環變量task
作為函數參數傳遞給瞭協程。參數傳遞的過程實際上也生成瞭新的變量，也即間接完成瞭綁定。
所以，題目二實際上是沒有問題的。就是實際參數順序是按照for range產生的變量順序綁定給子協程的。
ps：
簡單點來說
如果循環體沒有並發出現，則引用循環變量一般不會出現問題；
如果循環體有並發，則根據引用循環變量的位置不同而有所區別
通過參數完成綁定，則一般沒有問題；
函數體中引用，則需要顯式地綁定
補充：Go語言的協程中，寫死循環的註意點：
現象：
在寫Go的多協程程序時，出現過幾次無法理解的情況。
有一次，我想寫一個能跑滿cpu的程序，最容易想到的就是，開幾個Go的協程，每個協程裡寫死循環。沒想到，運行的時候發現，協程就隻開出瞭一個。
另一次，我寫瞭個程序，也是開瞭多個協程。因為如果不阻塞住主函數，主函數一結束，程序就會結束。所以我就在主函數結束前加瞭個死循環。然後就發現整個協程都被卡住瞭。
分析：
其實，這個東西是協程的特點。以前沒用過協程，加上Go又說可以當線程用。所以想當然的寫瞭死循環。
準確的說，是在Go語言裡，寫瞭死循環，並且死循環內並沒有什麼系統調用，隻有簡單的計算這類的。你就會發現，Go的協程調度就廢掉瞭。
協程並非像線程那樣，是由CPU中斷來觸發切換的。它不是應用程序能控制的（操作系統內核的某些關鍵操作會被保護，不被中斷）。即使你在線程裡寫瞭死循環，隻要周期一到，CPU產生終端，死循環會被打斷，重新調度。但是，協程就不是這樣瞭，協程的調度其實是在協程調用瞭某個系統調用時，自動跳到另一個協程執行。也就是這個“中斷”是程序主動產生的，而不是被”中斷”。
所以，協程中，如果你寫瞭死循環，那你的死循環就會一直跑著，而不會讓別的協程運行。主函數中也是一樣，而且主函數中執行這個會讓整個協程卡住，因為調度的代碼沒法被執行。
在Go語言中，如果你想寫死循環，循環裡面沒有系統調用，又想讓Go的協程能起作用，隻需要在死循環裡面加一條語句即可。估計系統調用時也是這個語句起的作用。
runtime.Gosched() //主動讓出時間片
還可以使用
select{}
來實現無限阻塞，而不是使用for{}
以上為個人經驗，希望能給大傢一個參考，也希望大傢多多支持WalkonNet。如有錯誤或未考慮完全的地方，望不吝賜教。