Go: For-Loop-Variable 适合面试的小问题

在面试的过程中, 如果恰好遇到对方日常也使用 Go 做为主力语言, 我会选择一些简单而可扩展的问题交流下双方对 Go 的熟悉程度.

我喜欢的一个问题是让面试者告诉我下述代码的运行结果:

func main() {
	for i := 0; i < 3; i++ {
		go func() {
			fmt.Println(i)
		}()
	}

	time.Sleep(time.Second)
}

正确的答案应该是: 乱序输出三个数字. 对于三种错误答案: 输出 1, 2, 3; 输出三个数字; 乱序输出 1, 2, 3; 都可以通过反问再给予一次机会.

进一步的, 我们可以询问如何让其至少将 1, 2, 3 都输出一次. 大多数时候, 我们的得到的答案会是将 i 做为参数传入. 此时我喜欢再追问, 下述代码中 i := i 的写法是否正确.

func main() {
	for i := 0; i < 3; i++ {
		i := i
		go func() {
			fmt.Println(i)
		}()
	}

	time.Sleep(time.Second)
}

我并不认为这是一个 Language Lawyer 问题, 由于 Go 中 for 循环的特殊实现方式, i := i 这种方式在 Go 中是普遍存在的.

极少数情况下, 我们可以再讨论下上述例子的原因, 允许面试者有更大的发挥机会. 其中包括的点有:

Go 并不保证先启动的 goroutine 先执行
Go 中 for 循环的实现是 one-instance-per-loop, 而不是 one-instance-per-iteration.

我们在下述例子中看到, i 和 v 的内存地址始终未曾改变:

~ cat main.go
func main() {
    nums := []int{1, 2, 3}
    for i, v := range nums {
        fmt.Println(&i, &v)
    }
}
~ go run main.go
0x1400009a018 0x1400009a020
0x1400009a018 0x1400009a020
0x1400009a018 0x1400009a020

闭包(closure)可能以值(by value)或者地址(by reference)的形式引用外部变量; 当引用 for 循环的中变量时, 是以地址的方式
Go 允许在 inner block 中定义重名的变量, 下述代码虽然不好但合法

~ cat main.go | grep -A 7 "func fnVarScope"
func fnVarScope() {
    s := "hello world"
    {
        s := 10
        fmt.Println("s:", s)
    }
    fmt.Println("s:", s)
}
~ go run main.go
s: 10
s: hello world

Source: https://github.com/j2gg0s/j2gg0s/blob/main/_posts/2023-12-29-Go%3A%20For-Loop-Variable%20%E9%80%82%E5%90%88%E9%9D%A2%E8%AF%95%E7%9A%84%E5%B0%8F%E9%97%AE%E9%A2%98.md

lesismal

131 天前

个人觉得研究这些细节挺好玩，但是卷到面试题里真挺烦的

像我们很多务实的人喜欢按简单正确的方式写，不喜欢语法上的茴字的 N 种写法的那些奇技淫巧，所以除了手误、正常情况下不会在写 for lopp i 里再写个 i:=i ，即使要临时变量复制也是 idx:=i 或者其他变量名。
所以当我看到这种面试题，即使能答对，但仍然要因为同名变量耽误那么一下自己再确认下是不是自己眼花会不会看错、甚至猜测你们是不是出题手滑写错了，正常人怎么会写 i:=i 这种不规范的代码，所以又要担心，万一是你们出题错了我答对了会不会反倒被你们判断为答错了。。

同名局部变量这么搞用来迷惑老实人，感觉是跟风 cpp ，多点实在，少整点这种垃圾题目，尤其还有国内 golang 大论坛、公众号，也搞这些带节奏，然后一堆脑残面试官拿去恶心同行，搞得行业面试风气都差得很

隔三岔五看到这类题目就觉得很烦，建议改改

geelaw

131 天前

随便看了一下文档，正确答案不是“乱序输出三个数字”，而是“乱序输出三个数字或者程序在不知道什么时候崩溃”。

https://go.dev/ref/mem

> While programmers should write Go programs without data races, there are limitations to what a Go implementation can do in response to a data race. An implementation may always react to a data race by reporting the race and terminating the program. Otherwise, each read of a single-word-sized or sub-word-sized memory location must observe a value actually written to that location (perhaps by a concurrent executing goroutine) and not yet overwritten.

另外 i 和 v 的地址未曾改变不能证明任何事情，即使每次迭代的变量是新的，编译器也可以证明复用旧的内存位置没问题，于是优化之后会看到相同的地址。