Golang 通道,执行顺序
Golang channels, order of execution
我正在学习 Go,并且 运行 跨越以下代码片段:
package main
import "fmt"
func sum(a []int, c chan int) {
sum := 0
for _, v := range a {
sum += v
}
c <- sum // send sum to c
}
func main() {
a := []int{7, 2, 8, -9, 4, 0}
c := make(chan int, 2)
go sum(a[0:3], c)
go sum(a[3:6], c)
x := <-c
y := <-c
// x, y := <-c, <-c // receive from c
fmt.Println(x, y)
}
Output:
-5 17
Program exited.
有人可以告诉我为什么 "sum" 函数的第二次调用在第一次调用之前通过通道进行吗?在我看来,输出应该是:
17 -5
我还使用无缓冲通道对此进行了测试,它也提供了相同的输出顺序。我错过了什么?
您正在代码中调用 go 例程,您不知道例程何时结束以及值将传递到缓冲通道。
由于此代码是异步的,因此只要例程完成,它就会将数据写入通道并在另一端读取。在上面的示例中,您只调用了两个 go 例程,因此行为是确定的,并且在大多数情况下会以某种方式生成相同的输出,但是当您增加 go 例程时,输出将不相同并且顺序将不同,除非您使它是同步的。
示例:
package main
import "fmt"
func sum(a []int, c chan int) {
sum := 0
for _, v := range a {
sum += v
}
c <- sum // send sum to c
}
func main() {
a := []int{7, 2, 8, -9, 4, 2, 4, 2, 8, 2, 7, 2, 99, -32, 2, 12, 32, 44, 11, 63}
c := make(chan int)
for i := 0; i < len(a); i = i + 5 {
go sum(a[i:i+5], c)
}
output := make([]int, 5)
for i := 0; i < 4; i++ {
output[i] = <-c
}
close(c)
fmt.Println(output)
}
The output for this code on different sample runs was
[12 18 0 78 162]
[162 78 12 0 18]
[12 18 78 162 0]
这是因为 goroutines 将输出异步写入缓冲通道。
希望对您有所帮助。
Goroutines 是异步启动的,它们可以以任何顺序写入通道。如果你稍微修改一下你的例子就更容易看到:
package main
import (
"fmt"
"time"
)
func sum(a []int, c chan int, name string, sleep int) {
fmt.Printf("started goroutine: %s\n", name)
time.Sleep(time.Second * time.Duration(sleep))
sum := 0
for _, v := range a {
sum += v
}
fmt.Printf("about end goroutine: %s\n", name)
c <- sum // send sum to c
}
func main() {
a := []int{7, 2, 8, -9, 4, 0}
c := make(chan int, 2)
go sum(a[0:3], c, "A", 1)
go sum(a[3:6], c, "B", 1)
x := <-c
y := <-c
// x, y := <-c, <-c // receive from c
fmt.Println(x, y)
}
https://play.golang.org/p/dK4DT0iUfzY
结果:
started goroutine: B
started goroutine: A
about end goroutine: A
about end goroutine: B
17 -5
当运行 golang.org 沙箱时,我每次都得到相同的结果。如上所述。但是当我 运行 在我自己的沙箱(在我的计算机上)中使用相同的片段时,它有时会改变线程的顺序。这样就满意多了。它表明我不能期望任何特定的线程执行顺序,这是直观的。我只是想不通为什么我会得到相同的执行顺序,而且这与线程启动的顺序相反。我认为这只是 golang.org 沙盒中的运气。
我正在学习 Go,并且 运行 跨越以下代码片段:
package main
import "fmt"
func sum(a []int, c chan int) {
sum := 0
for _, v := range a {
sum += v
}
c <- sum // send sum to c
}
func main() {
a := []int{7, 2, 8, -9, 4, 0}
c := make(chan int, 2)
go sum(a[0:3], c)
go sum(a[3:6], c)
x := <-c
y := <-c
// x, y := <-c, <-c // receive from c
fmt.Println(x, y)
}
Output:
-5 17
Program exited.
有人可以告诉我为什么 "sum" 函数的第二次调用在第一次调用之前通过通道进行吗?在我看来,输出应该是:
17 -5
我还使用无缓冲通道对此进行了测试,它也提供了相同的输出顺序。我错过了什么?
您正在代码中调用 go 例程,您不知道例程何时结束以及值将传递到缓冲通道。
由于此代码是异步的,因此只要例程完成,它就会将数据写入通道并在另一端读取。在上面的示例中,您只调用了两个 go 例程,因此行为是确定的,并且在大多数情况下会以某种方式生成相同的输出,但是当您增加 go 例程时,输出将不相同并且顺序将不同,除非您使它是同步的。
示例:
package main
import "fmt"
func sum(a []int, c chan int) {
sum := 0
for _, v := range a {
sum += v
}
c <- sum // send sum to c
}
func main() {
a := []int{7, 2, 8, -9, 4, 2, 4, 2, 8, 2, 7, 2, 99, -32, 2, 12, 32, 44, 11, 63}
c := make(chan int)
for i := 0; i < len(a); i = i + 5 {
go sum(a[i:i+5], c)
}
output := make([]int, 5)
for i := 0; i < 4; i++ {
output[i] = <-c
}
close(c)
fmt.Println(output)
}
The output for this code on different sample runs was
[12 18 0 78 162] [162 78 12 0 18] [12 18 78 162 0]
这是因为 goroutines 将输出异步写入缓冲通道。
希望对您有所帮助。
Goroutines 是异步启动的,它们可以以任何顺序写入通道。如果你稍微修改一下你的例子就更容易看到:
package main
import (
"fmt"
"time"
)
func sum(a []int, c chan int, name string, sleep int) {
fmt.Printf("started goroutine: %s\n", name)
time.Sleep(time.Second * time.Duration(sleep))
sum := 0
for _, v := range a {
sum += v
}
fmt.Printf("about end goroutine: %s\n", name)
c <- sum // send sum to c
}
func main() {
a := []int{7, 2, 8, -9, 4, 0}
c := make(chan int, 2)
go sum(a[0:3], c, "A", 1)
go sum(a[3:6], c, "B", 1)
x := <-c
y := <-c
// x, y := <-c, <-c // receive from c
fmt.Println(x, y)
}
https://play.golang.org/p/dK4DT0iUfzY
结果:
started goroutine: B
started goroutine: A
about end goroutine: A
about end goroutine: B
17 -5
当运行 golang.org 沙箱时,我每次都得到相同的结果。如上所述。但是当我 运行 在我自己的沙箱(在我的计算机上)中使用相同的片段时,它有时会改变线程的顺序。这样就满意多了。它表明我不能期望任何特定的线程执行顺序,这是直观的。我只是想不通为什么我会得到相同的执行顺序,而且这与线程启动的顺序相反。我认为这只是 golang.org 沙盒中的运气。