共计 3129 个字符，预计需要花费 8 分钟才能阅读完成。
微信搜寻【脑子进煎鱼了】关注这一只爆肝煎鱼。本文 GitHub github.com/eddycjy/blog 已收录，有我的系列文章、材料和开源 Go 图书。
大家好，我是煎鱼。
前段时间我分享了《手撕 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 required to be different, then each 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 address of a zero-sized field within a larger 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 催更。
参考
- 欧神的微信交换
- 曹大的一个空 struct 的“坑”