本文 GitHub github.com/eddycjy/blog 已收錄
#大家好，我是煎魚。
前陣子我分享了 《手撕 Go 面試官：Go 結構體是否可以比較，為什麼？ 》的文章，把基本 Go struct 的比較基礎研究了一番。這不，最近有一位讀者，遇到了一個關於 struct 的新問題，不得解決。
大家一起來看看，建議大家在看到程式碼範例後先思考一下答案，再往下看。
獨立思考很重要。
疑惑的例子
其給的例子一如下：
type People struct {}
func main() {
a := &People{}
b := &People{}
fmt.Println(a == b)
}
你認為輸出結果是什麼？
輸出結果是：false。
再稍加改造一下，範例二如下：
type People struct {}
func main() {
a := &People{}
b := &People{}
fmt.Printf("%p\n", a)
fmt.Printf("%p\n", b)
fmt.Println(a == b)
}
輸出結果是：true。
他的問題是"為什麼第一個返回false 第二個返回true，是什麼原因導致的？
#煎魚進一步的精簡這個例子，得到最小範例：
func main() {
a := new(struct{})
b := new(struct{})
println(a, b, a == b)
c := new(struct{})
d := new(struct{})
fmt.Println(c, d)
println(c, d, c == d)
}
輸出結果：
// a, b; a == b
0xc00005cf57 0xc00005cf57 false
// c, d
&{} &{}
// c, d, c == d
0x118c370 0x118c370 true
第一段程式碼的結果是false，第二段的結果是true，而且可以看到記憶體位址指向的完全一樣，也就是排除了輸出後變數記憶體指向改變導致的原因。
進一步來看，似乎是fmt.Print 方法導致的，但一個標準庫裡的輸出方法，會導致這種奇怪的問題？
問題剖析
如果之前有被這個「坑」過，或有看過源碼的同學。可能能夠快速的意識到，導致這個輸出是逃逸分析所致的結果。
我們對例子進行逃逸分析：
// 源代码结构
$ cat -n main.go
5 func main() {
6 a := new(struct{})
7 b := new(struct{})
8 println(a, b, a == b)
9
10 c := new(struct{})
11 d := new(struct{})
12 fmt.Println(c, d)
13 println(c, d, c == d)
14 }
// 进行逃逸分析
$ go run -gcflags="-m -l" main.go
# command-line-arguments
./main.go:6:10: a does not escape
./main.go:7:10: b does not escape
./main.go:10:10: c escapes to heap
./main.go:11:10: d escapes to heap
./main.go:12:13: ... argument does not escape
透過分析可得知變數a, b 皆是分配在堆疊中，而變數c, d 分配在堆中。
其關鍵原因是因為調用了fmt.Println 方法，該方法內部是涉及到大量的反射相關方法的調用，會造成逃逸行為，也就是分配到堆上。
為什麼逃逸後相等
注意第一個細節，就是「為什麼逃逸後，兩個空struct 會是相等的？ 」。
這裡主要與Go runtime 的一個最佳化細節有關，如下：
// runtime/malloc.go var zerobase uintptr
變數zerobase 是所有0 位元組分配的基礎位址。更進一步來講，就是空（0位元組）的在進行了逃逸分析後，往堆分配的都會指向zerobase 這一個位址。
所以空struct 在逃逸後本質上指向了zerobase，其兩者比較就是相等的，回傳了true。
為什麼沒逃逸不相等
注意第二個細節，就是「為什麼沒逃逸前，兩個空struct 比較不相等？ 」。
從Go spec 來看，這是Go 團隊刻意而為之的設計，不希望大家依賴這一個來做判斷依據。如下：
This is an intentional language choice to give implementations flexibility in how they handle pointers to zero-sized objects. If every pointer to a zero-sized object were red the ben eacher to ben allocation of a zero-sized object would have to allocate at least one byte. If every pointer to a zero-sized object were required to be the same, it would be different to handle taking the 地址struct.
也說了一句很經典的，細品：
Pointers to distinct zero-size variables may or may not be equal.
#另外空struct 在實際使用中的場景是比較少的，常見的是：
- 設定context，傳遞時作為key 時用到。
- 設定空struct 業務場景中臨時用到。
但業務場景的情況下，也大多數會隨著業務發展而不斷改變，假設有個遠古時代的Go 程式碼，依賴了空struct 的直接判斷，豈不是事故上身？
不可直接依賴
因此Go 團隊這番操作，與Go map 的隨機性如出一轍，避免大家對這類邏輯的直接依賴，是值得思考的。
而在沒逃逸的場景下，兩個空struct 的比較動作，你以為是真的在比較。實際上已經在程式碼優化階段被直接優化掉，轉為了false。
因此，雖然在程式碼上看上去是== 在做比較，實際上結果是a == b 時就直接轉為了false，比都不需要比了。
你說妙不？
沒逃逸讓他相等
既然我們知道了他是在程式碼最佳化階段被優化的，那麼相對的，知道了原理的我們也可以藉助在go 編譯運行時的gcflags指令，讓他不要優化。
在运行前面的例子时，执行 -gcflags="-N -l" 指令：
$ go run -gcflags="-N -l" main.go
0xc000092f06 0xc000092f06 true
&{} &{}
0x118c370 0x118c370 true
你看，两个比较的结果都是 true 了。
总结
在今天这篇文章中，我们针对 Go 语言中的空结构体（struct）的比较场景进行了进一步的补全。经过这两篇文章的洗礼，你会更好的理解 Go 结构体为什么叫既可比较又不可比较了。
而空结构比较的奇妙，主要原因如下：
- 若逃逸到堆上，空结构体则默认分配的是
runtime.zerobase变量，是专门用于分配到堆上的 0 字节基础地址。因此两个空结构体，都是runtime.zerobase，一比较当然就是 true 了。 - 若没有发生逃逸，也就分配到栈上。在 Go 编译器的代码优化阶段，会对其进行优化，直接返回 false。并不是传统意义上的，真的去比较了。
不会有人拿来出面试题，不会吧，为什么 Go 结构体说可比较又不可比较？
若有任何疑问欢迎评论区反馈和交流，最好的关系是互相成就，各位的点赞就是煎鱼创作的最大动力，感谢支持。
文章持续更新，可以微信搜【脑子进煎鱼了】阅读，回复【000】有我准备的一线大厂面试算法题解和资料；本文 GitHub github.com/eddycjy/blog 已收录，欢迎 Star 催更。