用Gostruct不能犯的一个低级错误！

大家好，我是煎鱼。

让客户满意是我们工作的目标，不断超越客户的期望值来自于我们对这个行业的热爱。我们立志把好的技术通过有效、简单的方式提供给客户，将通过不懈努力成为客户在信息化领域值得信任、有价值的长期合作伙伴，公司提供的服务项目有：空间域名、网站空间、营销软件、网站建设、让胡路网站维护、网站推广。

前段时间我分享了 《手撕 Go 面试官：Go 结构体是否可以比较，为什么?》的文章，把基本 Go struct 的比较依据研究了一番。这不，最近有一位读者，遇到了一个关于 struct 的新问题，踩到了雷区。不得解。

大家一起来看看，建议大家在看到代码例子后先思考一下答案，再往下看。

独立思考很重要。

疑惑的例子

其给出的例子一如下：

 
 
 
 
    
  
  
  
  
  1. type People struct {} 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. func main() { 
    4. 
  
  
  
  
  4.  a := &People{} 
    5. 
  
  
  
  
  5.  b := &People{} 
    6. 
  
  
  
  
  6.  fmt.Println(a == b) 
    7. 
  
  
  
  
  7. } 
    8.

你认为输出结果是什么呢?

输出结果是：false。

再稍加改造一下，例子二如下：

 
 
 
 
    
  
  
  
  
  1. type People struct {} 
    2. 
  
  
  
  
  2.  
    3. 
  
  
  
  
  3. func main() { 
    4. 
  
  
  
  
  4.  a := &People{} 
    5. 
  
  
  
  
  5.  b := &People{} 
    6. 
  
  
  
  
  6.  fmt.Printf("%p\n", a) 
    7. 
  
  
  
  
  7.  fmt.Printf("%p\n", b) 
    8. 
  
  
  
  
  8.  fmt.Println(a == b) 
    9. 
  
  
  
  
  9. } 
    10.

输出结果是：true。

他的问题是 "为什么第一个返回 false 第二个返回 true，是什么原因导致的?

煎鱼进一步的精简这个例子，得到最小示例：

 
 
 
 
    
  
  
  
  
  1. func main() { 
    2. 
  
  
  
  
  2.  a := new(struct{}) 
    3. 
  
  
  
  
  3.  b := new(struct{}) 
    4. 
  
  
  
  
  4.  println(a, b, a == b) 
    5. 
  
  
  
  
  5.  
    6. 
  
  
  
  
  6.  c := new(struct{}) 
    7. 
  
  
  
  
  7.  d := new(struct{}) 
    8. 
  
  
  
  
  8.  fmt.Println(c, d) 
    9. 
  
  
  
  
  9.  println(c, d, c == d) 
    10. 
  
  
  
  
  10. } 
    11.

输出结果：

 
 
 
 
    
  
  
  
  
  1. // a, b; a == b 
    2. 
  
  
  
  
  2. 0xc00005cf57 0xc00005cf57 false 
    3. 
  
  
  
  
  3.  
    4. 
  
  
  
  
  4. // c, d 
    5. 
  
  
  
  
  5. &{} &{} 
    6. 
  
  
  
  
  6. // c, d, c == d 
    7. 
  
  
  
  
  7. 0x118c370 0x118c370 true 
    8.

第一段代码的结果是 false，第二段的结果是 true，且可以看到内存地址指向的完全一样，也就是排除了输出后变量内存指向改变导致的原因。

进一步来看，似乎是 fmt.Print 方法导致的，但一个标准库里的输出方法，会导致这种奇怪的问题?

问题剖析

如果之前有被这个 “坑” 过，或有看过源码的同学。可能能够快速的意识到，导致这个输出是逃逸分析所致的结果。

我们对例子进行逃逸分析：

 
 
 
 
    
  
  
  
  
  1. // 源代码结构 
    2. 
  
  
  
  
  2. $ cat -n main.go 
    3. 
  
  
  
  
  3.      5 func main() { 
    4. 
  
  
  
  
  4.      6  a := new(struct{}) 
    5. 
  
  
  
  
  5.      7  b := new(struct{}) 
    6. 
  
  
  
  
  6.      8  println(a, b, a == b) 
    7. 
  
  
  
  
  7.      9  
    8. 
  
  
  
  
  8.     10  c := new(struct{}) 
    9. 
  
  
  
  
  9.     11  d := new(struct{}) 
    10. 
  
  
  
  
  10.     12  fmt.Println(c, d) 
    11. 
  
  
  
  
  11.     13  println(c, d, c == d) 
    12. 
  
  
  
  
  12.     14 } 
    13. 
  
  
  
  
  13.  
    14. 
  
  
  
  
  14. // 进行逃逸分析 
    15. 
  
  
  
  
  15. $ go run -gcflags="-m -l" main.go 
    16. 
  
  
  
  
  16. # command-line-arguments 
    17. 
  
  
  
  
  17. ./main.go:6:10: a does not escape 
    18. 
  
  
  
  
  18. ./main.go:7:10: b does not escape 
    19. 
  
  
  
  
  19. ./main.go:10:10: c escapes to heap 
    20. 
  
  
  
  
  20. ./main.go:11:10: d escapes to heap 
    21. 
  
  
  
  
  21. ./main.go:12:13: ... argument does not escape 
    22.

通过分析可得知变量 a, b 均是分配在栈中，而变量 c, d 分配在堆中。

其关键原因是因为调用了 fmt.Println 方法，该方法内部是涉及到大量的反射相关方法的调用，会造成逃逸行为，也就是分配到堆上。

为什么逃逸后相等

关注第一个细节，就是 “为什么逃逸后，两个空 struct 会是相等的?”。

这里主要与 Go runtime 的一个优化细节有关，如下：

 
 
 
 
    
  
  
  
  
  1. // runtime/malloc.go 
    2. 
  
  
  
  
  2. var zerobase uintptr 
    3.

变量 zerobase 是所有 0 字节分配的基础地址。更进一步来讲，就是空(0字节)的在进行了逃逸分析后，往堆分配的都会指向 zerobase 这一个地址。

所以空 struct 在逃逸后本质上指向了 zerobase，其两者比较就是相等的，返回了 true。

为什么没逃逸不相等

关注第二个细节，就是 “为什么没逃逸前，两个空 struct 比较不相等?”。

Go spec

从 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" 指令：

 
 
 
 
    
  
  
  
  
  1. $ go run -gcflags="-N -l" main.go  
    2. 
  
  
  
  
  2. 0xc000092f06 0xc000092f06 true 
    3. 
  
  
  
  
  3. &{} &{} 
    4. 
  
  
  
  
  4. 0x118c370 0x118c370 true 
    5.

你看，两个比较的结果都是 true 了。

总结

在今天这篇文章中，我们针对 Go 语言中的空结构体(struct)的比较场景进行了进一步的补全。经过这两篇文章的洗礼，你会更好的理解 Go 结构体为什么叫既可比较又不可比较了。

而空结构比较的奇妙，主要原因如下：

若逃逸到堆上，空结构体则默认分配的是 runtime.zerobase 变量，是专门用于分配到堆上的 0 字节基础地址。因此两个空结构体，都是 runtime.zerobase，一比较当然就是 true 了。

若没有发生逃逸，也就分配到栈上。在 Go 编译器的代码优化阶段，会对其进行优化，直接返回 false。并不是传统意义上的，真的去比较了。

不会有人拿来出面试题，不会吧，为什么 Go 结构体说可比较又不可比较?

当前名称：用Gostruct不能犯的一个低级错误！
URL地址：http://www.shufengxianlan.com/qtweb/news31/482281.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

品牌网站制作知识

行业网站建设

成都网站建设　　 　重庆网站建设　　 　娄底尾呼妄服装　　 　成都服务器运维　　 　成都企业网站建设公司　　 　成都网站设计　　 　广安网站建设　　 　成都做网站　　 　免费收录网站　　 　四川艺考培训　　 　郫都区消防器材　　 　成都企业网站改版　　 　东方电机技改　　 　成都网站制作　　 　交互设计　　 　橡塑保温板　　 　成都学生服定制　　 　德阳东方电机技改　　 　四川成都托管服务器　　 　广汉锦华