为什么结构数组比较有不同的结果答案

【问题标题】：why struct arrays comparing has different result为什么结构数组比较有不同的结果
【发布时间】：2019-02-24 12:40:33
【问题描述】：

我不知道为什么会发生以下情况，也找不到相关的源代码。谁能给我解释一下？

var s, ss struct{} // two empty structs
arr1 := [6]*struct{}{&s} // array with empty struct pointer
arr2 := [6]*struct{}{&ss} // array with empty struct pointer
fmt.Println(&s == &ss, arr1 == arr2)  // false, true

var l, ll struct{A int}{}
arr3 := [6]*struct{A int}{&l} // array with empty struct pointer
arr4 := [6]*struct{A int}{&ll} // array with empty struct pointer
fmt.Println(&l == &ll, arr3 == arr4)  // false, false

【问题讨论】：

不打印（&s）给你一个内存地址和打印（arr1）一个值

标签： arrays pointers go struct compare

【解决方案1】：

Spec: Comparison operators:

指针值是可比较的。如果两个指针值指向同一个变量，或者两者都具有值nil，则它们相等。 指向不同 zero-size 变量的指针可能相等，也可能不相等。

还有Spec: Size and alignment guarantees:

如果结构或数组类型不包含大小大于零的字段（或元素），则它的大小为零。两个不同的零大小变量可能在内存中具有相同的地址。

s 和 ss 变量的大小为零，因此 &s 和 &ss 是指向不同的零大小变量的指针，因此规范不保证它们的相等性。这意味着&s == &ss 可能评估为true 或false，你不能指望结果会是什么，这样做是错误的。

不过，奇怪的是，在应用程序的单个运行时，一旦它们相等，一旦它们不相等。教训是永远不要依赖它。

可以通过查看逃逸分析来解释不同的行为。

让我们将您的应用简化为：

var s, ss struct{}                   // two empty structs
arr1 := [6]*struct{}{&s}             // array with empty struct pointer
arr2 := [6]*struct{}{&ss}            // array with empty struct pointer
fmt.Println(&s == &ss, arr1 == arr2) // false, true

使用go run -gcflags '-m' play.go 运行逃逸分析会得到：

./play.go:13:17: &s == &ss escapes to heap
./play.go:13:30: arr1 == arr2 escapes to heap
./play.go:11:23: main &s does not escape
./play.go:12:23: main &ss does not escape
./play.go:13:14: main &s does not escape
./play.go:13:20: main &ss does not escape
./play.go:13:13: main ... argument does not escape
false true

&s 和 &ss 不会转义（因为它们不会传递给 fmt.Println()，只有 &s == &ss 的结果）。

如果我们在上面的简化应用程序中添加一行：

var s, ss struct{}                   // two empty structs
arr1 := [6]*struct{}{&s}             // array with empty struct pointer
arr2 := [6]*struct{}{&ss}            // array with empty struct pointer
fmt.Println(&s == &ss, arr1 == arr2) // true, true

fmt.Printf("%p %p\n", &s, &ss) // true, true

运行逃逸分析现在给出：

./play.go:13:17: &s == &ss escapes to heap
./play.go:13:30: arr1 == arr2 escapes to heap
./play.go:15:24: &s escapes to heap
./play.go:15:24: &s escapes to heap
./play.go:10:6: moved to heap: s
./play.go:15:28: &ss escapes to heap
./play.go:15:28: &ss escapes to heap
./play.go:10:9: moved to heap: ss
./play.go:11:23: main &s does not escape
./play.go:12:23: main &ss does not escape
./play.go:13:14: main &s does not escape
./play.go:13:20: main &ss does not escape
./play.go:13:13: main ... argument does not escape
./play.go:15:12: main ... argument does not escape
true true

行为发生了变化：我们现在看到true true 输出（在Go Playground 上尝试）。

行为改变的原因是因为&s 和&ss 转义到堆：它们直接传递给fmt.Println()，所以编译器改变了它们的存储方式（位置），随之而来的是它们的存储方式地址。

查看相关/可能的重复：Golang Address of Slices of Empty Structs

【讨论】：

感谢您的详细回复。我会找到一些关于逃逸堆的东西，以便更好地理解。再次感谢..