Look! A stupid mistake you can't make when using Go struct!

This article GitHub github.com/eddycjy/blog has been included

Hello everyone, I am Jianyu.

Some time ago I shared "Shandou Go Interviewer: Can Go structures be compared? Why?" 》 article, studied the comparison basis of basic Go struct. No, recently a reader encountered a new problem about struct that he couldn't solve.

Let’s take a look together. It is recommended that you think about the answer after seeing the code example, and then read on.

It is important to think independently.

Doubtful example

The example given is as follows:

type People struct {}

func main() {
 a := &People{}
 b := &People{}
 fmt.Println(a == b)
}

What do you think the output result is?

The output result is: false.

With a slight modification, Example 2 is as follows:

type People struct {}

func main() {
 a := &People{}
 b := &People{}
 fmt.Printf("%p\n", a)
 fmt.Printf("%p\n", b)
 fmt.Println(a == b)
}

The output result is: true.

His question is "Why does the first one return false and the second one return true? What's the reason?

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

fmt.Print method, but an output method in the standard library will cause this Strange problem?

The result of escape analysis.

// 源代码结构
$ 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

fmt.Println method is called, which involves a large number of calls to reflection-related methods, which will cause escape behavior and also It is allocated on the heap.

// runtime/malloc.go
var zerobase uintptr

zerobase is the base address of all 0-byte allocations. Going further , which is empty (0 bytes). After escape analysis, everything allocated to the heap will point to the zerobase address.

, the two are equal when compared, and true is returned. Why they are not equal without escape

Focus on the second detail, which is "Why before escape, the two Are empty structs not equal? ”.

From the Go spec, this is a deliberate design by the Go team. We don’t want everyone to rely on this as a basis for judgment. .As follows:

also said a very classic saying:

In addition, empty struct is rarely used in actual use scenarios. The common ones are:

• Set empty struct is temporarily used in business scenarios.
• But in business scenarios, most of them will continue to change with the development of the business. Suppose there is a Go code from ancient times that relies on empty struct Wouldn't it be an accident to judge directly?

Cannot be relied upon directly

Therefore, the Go team's operation is exactly the same as the randomness of Go map. It is worthwhile to avoid everyone's direct reliance on this kind of logic. Thinking.

In the scenario where there is no escape, the comparison action of two empty structs, you think it is really comparing. In fact, it has been directly optimized during the code optimization stage and turned to false.

Therefore, although it looks like == is being compared in the code, in fact when the result is a == b, it is directly converted to false, and there is no need to compare.

Don’t you think it’s wonderful?

No escape to make it equal

Now that we know that it is optimized during the code optimization phase, then on the other hand, if we know the principle, we can also use gcflags during go compilation and runtime. Instructions to prevent him from optimizing.

在运行前面的例子时，执行 -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 催更。