关于golang:用-Go-struct-不能犯的一个低级错误

微信搜寻【脑子进煎鱼了】关注这一只爆肝煎鱼。本文 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 的“坑”

关于golang:用-Go-struct-不能犯的一个低级错误

纳闷的例子

问题分析

为什么逃逸后相等

为什么没逃逸不相等

不可间接依赖

没逃逸让他相等

总结

参考