知道你在这里问什么很重要。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;
}
这里没有什么太令人惊讶的了。但是你好奇的第一个案例呢:
_main.main.func1:
goto _main.main.func1;
它变成了一个noop。毫不夸张的说; 这是程序集:
_main.main.func1:
000000000109d1b0 nop ; CODE XREF=_main.main.func1+1
000000000109d1b1 jmp _main.main.func1 ; _main.main.func1
这是怎么发生的?好吧,编译器可以看看这段代码:
go func() {
for {
x++
}
}()
它知道什么都没有读过x
。任何东西都无法读取x
,因为没有锁定x
,这个 goroutine 永远不会终止。所以在这个 goroutine 完成x
后没有什么可以读取的。请参阅Go Memory Model了解更多关于某事在某事之前或之后发生的意义。
“但我确实读过x!” 不,你没有。那将是无效代码,编译器知道您没有编写无效代码。当比赛检测器告诉您这是无效的时,谁会这样做?因此,由于编译器可以清楚地看到什么都没有读取x
,因此没有理由费心更新它。
在您的有限循环示例中,goroutine 终止,因此之后可能会读取某些内容x
。编译器不够聪明,无法注意到从未进行过有效读取,因此它没有尽可能地优化它。也许未来的编译器会足够聪明,在这两种情况下都输出 0。也许未来的编译器会足够聪明,在第一种情况下完全删除你的无操作 goroutine。
但这里的关键点是无限循环的情况是完全正确的,尽管效率比它可能的要低一些。非无限循环的情况也是完全正确的,尽管它的效率要低得多。