Go 面试题:Go interface 的一个 “坑” 及原理分析

前几天在读者交流群里看到一位小伙伴,针对 interface 的使用有了比较大的疑惑。

无独有偶,我也在网上看到有小伙伴在 Go 面试的时候被问到了:

Go 面试题:Go interface 的一个 “坑” 及原理分析 - 图1来自网上博客的截图

今天特意分享出来让大家避开这个坑。

例子一

第一个例子,如下代码:

  1. func main() {
  2. var v interface{}
  3. v = (*int)(nil)
  4. fmt.Println(v == nil)
  5. }

你觉得输出结果是什么呢?

答案是:

  1. false

为什么不是 true。明明都已经强行置为 nil 了。是不是 Go 编译器有问题?

例子二

第二个例子,如下代码:

  1. func main() {
  2. var data *byte
  3. var in interface{}
  4. fmt.Println(data, data == nil)
  5. fmt.Println(in, in == nil)
  6. in = data
  7. fmt.Println(in, in == nil)
  8. }

你觉得输出结果是什么呢?

答案是:

  1. <nil> true
  2. <nil> true
  3. <nil> false

这可就更奇怪了,为什么刚刚声明出来的 datain 变量,确实是输出结果是 nil,判断结果也是 true

怎么把变量 data 一赋予给变量 in,世界就变了?输出结果依然是 nil,但判定却变成了false

和上面的第一个例子结果类似,真是神奇。

原因

interface 判断与想象中不一样的根本原因是,interface 并不是一个指针类型,虽然他看起来很像,以至于误导了不少人。

我们钻下去 interface,interface 共有两类数据结构:

Go 面试题:Go interface 的一个 “坑” 及原理分析 - 图2

  • runtime.eface 结构体:表示不包含任何方法的空接口,也称为 empty interface。
  • runtime.iface 结构体:表示包含方法的接口。

看看这两者相应的底层数据结构:

  1. type eface struct {
  2. _type *_type
  3. data unsafe.Pointer
  4. }
  5. type iface struct {
  6. tab *itab
  7. data unsafe.Pointer
  8. }

你会发现 interface 不是单纯的值,而是分为类型和值

所以传统认知的此 nil 并非彼 nil,必须得类型和值同时都为 nil 的情况下,interface 的 nil 判断才会为 true

解决办法

与其说是解决方法,不如说是委婉的破局之道。在不改变类型的情况下,方法之一是利用反射(reflect),如下代码:

  1. func main() {
  2. var data *byte
  3. var in interface{}
  4. in = data
  5. fmt.Println(IsNil(in))
  6. }
  7. func IsNil(i interface{}) bool {
  8. vi := reflect.ValueOf(i)
  9. if vi.Kind() == reflect.Ptr {
  10. return vi.IsNil()
  11. }
  12. return false
  13. }

利用反射来做 nil 的值判断,在反射中会有针对 interface 类型的特殊处理,最终输出结果是:true,达到效果。

其他方法的话,就是改变原有的程序逻辑,例如:

  • 对值进行 nil 判断,再返回给 interface 设置。
  • 返回具体的值类型,而不是返回 interface。

总结

Go interface 是 Go 语言中最常用的类型之一,大家用惯了 if err != nil 就很容易顺手就踩进去了。

建议大家要多留个心眼,如果对 interface 想要有更进一步的了解,可以看看我的这篇深入解析的文章:《一文吃透 Go 语言解密之接口 interface》

小伙伴们有没有踩到过,或遇到过 interface 相关的 “坑” 呢?欢迎大家下方留言讨论,分享出来。

大家一起冲!