为什么这个 goroutine 不运行,即使有 `time.Sleep`?

Ham*_*eni 1 go goroutine go-scheduler

拿这段代码:

func main() {
    var x int
    go func() {
        for {
            x++
        }
    }()
    time.Sleep(time.Second)
    fmt.Println("x =", x)
}
Run Code Online (Sandbox Code Playgroud)

为什么最后x相等0?我知道 Go 的调度程序需要time.Sleep()调用来获取 goroutine,但为什么不这样做?

提示:在 for 循环内放置 atime.Sleep()或调用runtime.Gosched()可修复此代码。但为什么?

更新:检查相同代码的以下版本:

func main() {
    var x int
    go func() {
        for i := 0; i < 10000; i++ {
            x++
        }
    }()
    time.Sleep(time.Second)
    fmt.Println("x =", x)
}
Run Code Online (Sandbox Code Playgroud)

奇怪的是 goroutine 里面的代码现在被执行了,x不再是 0 了。 编译器在这里做了什么优化吗?

Rob*_*ier 6

重要的是要知道你在这里问什么。在 Go 中没有承诺这个程序会做任何特别的事情,因为这个程序是无效的。但是作为对优化器的探索,提供一些有关它当前是如何实现的见解可能会很有趣。任何依赖此信息的程序都将非常脆弱和无效,但它仍然是一种好奇心。

我们可以编译程序,然后查看输出。我特别喜欢你提供的两个版本,因为它们让用户看到了差异。我已经使用 Hopper 完成了反编译(这些是用 go1.14 darwin/amd64 编译的)。

在第二种情况下,goroutine 看起来像您认为的那样:

void _main.main.func1(int arg0, int arg1, int arg2, int arg3, int arg4, int arg5, int arg6) {
    rax = arg6;
    for (rcx = 0x0; rcx < 0x2710; rcx = rcx + 0x1) {
            *rax = *rax + 0x1;
    }
    return;
}
Run Code Online (Sandbox Code Playgroud)

这里没什么太令人惊讶的。但是你好奇的第一种情况呢:

_main.main.func1:
    goto _main.main.func1;
Run Code Online (Sandbox Code Playgroud)

它变成了一个 noop。毫不夸张的说; 这是大会:

                     _main.main.func1:
000000000109d1b0         nop                                                    ; CODE XREF=_main.main.func1+1
000000000109d1b1         jmp        _main.main.func1                            ; _main.main.func1
Run Code Online (Sandbox Code Playgroud)

这是怎么发生的?好吧,编译器可以看看这段代码:

go func() {
    for {
        x++
    }
}()
Run Code Online (Sandbox Code Playgroud)

它知道没有任何东西可以读取x。任何东西都无法读取x,因为没有锁定x并且这个 goroutine 永远不会终止。所以x 这个 goroutine 完成后,没有任何东西可以读取。查看Go 内存模型以了解更多关于某事发生在其他事情之前或之后的含义。

“但我确实读过x!” 不,你没有。那将是无效代码,编译器知道您没有编写无效代码。当比赛检测器告诉您这是无效的时,谁会这样做?因此,由于编译器可以清楚地看到什么都没有读取x,因此没有理由费心更新它。

在您的有限循环示例中,goroutine 终止,因此之后可能会读取某些内容x。编译器不够聪明,无法注意到没有进行过有效的读取,因此它没有尽可能地优化它。也许未来的编译器会足够聪明,在这两种情况下都输出 0。也许未来的编译器会足够聪明,可以在第一种情况下完全删除您的 no-op goroutine。

但这里的关键点是无限循环的情况是完全正确的,尽管效率略低。并且非无限循环的情况也是完全正确的,尽管效率要低得多。