Go语言接口内部实现
发布时间：2020-12-16 09:36:49 所属栏目：大数据 来源：网络整理
导读：前几节我们介绍了接口的基本概念和用法，定义接口只需简单声明一个方法集合即可，定义新类型时不需要显式地声明要实现的接口，接口的使用也很简单。 那么接口的底层是如何实现的呢？如何实现动态调用的呢？接口的动态调用到底有多大的额外开销？本节我们就来
|
前几节我们介绍了接口的基本概念和用法，定义接口只需简单声明一个方法集合即可，定义新类型时不需要显式地声明要实现的接口，接口的使用也很简单。 那么接口的底层是如何实现的呢？如何实现动态调用的呢？接口的动态调用到底有多大的额外开销？本节我们就来深入讲解一下接口的底层实现。 阅读本节需要读者了解Go语言接口的基础知识和Go语言汇编基础和函数调用规约，以及对 ELF 可执行文件格式有基本了解。本节内容有点偏底层，有一定的难度，如果阅读起来有困难，可以先跳过去，有时间再慢慢读。 数据结构从前面章节了解到，接口变量必须初始化才有意义，没有初始化的接口变量的默认值是 nil，没有任何意义。具体类型实例传递给接口称为接口的实例化。在接口的实例化的过程中，编译器通过特定的数据结构描述这个过程。首先介绍非空接口的内部数据结构，空接口的底层更简单，放到最后介绍。非空接口的底层数据结构是 iface，代码位于Go语言安装目录的 src/runtime/runtime2.go 文件中。 iface 数据结构非空接口初始化的过程就是初始化一个 iface 类型的结构，示例如下：
//src/runtime/runtime2.go
type iface struct {
tab *itab //itab 存放类型及方法指针信息
data unsafe.Pointer //数据信息
}
可以看到 iface 结构很简单，有两个指针类型字段。
data 指向具体的实例数据，如果传递给接口的是值类型，则 data 指向的是实例的副本；如果传递给接口的是指针类型，则 data 指向指针的副本。总而言之，无论接口的转换，还是函数调用，Go 遵循一样的规则——值传递。 接下来看一下 itab 数据结构，itab 是接口内部实现的核心和基础。示例如下：
//src/runtime/runtime2.go
type itab struct {
inter *interfacetype //接口自身的静态类型
_type *_type //_type 就是接口存放的具体实例的类型（动态类型）
//hash 存放具体类型的 Hash 值
hash uint32 // copy of _type.hash. Used for type switches.
_ [4]byte
fun [1]uintptr // variable sized. fun[0]==0 means _type does not implement inter.
}
itab 有 5 个字段：
itab 这个数据结构是非空接口实现动态调用的基础，itab 的信息被编译器和链接器保存了下来，存放在可执行文件的只读存储段（.rodata）中。itab 存放在静态分配的存储空间中，不受 GC 的限制，其内存不会被回收。 接下来介绍 _type 数据结构，Go语言是一种强类型的语言，编译器在编译时会做严格的类型校验。所以 Go 必然为每种类型维护一个类型的元信息，这个元信息在运行和反射时都会用到，Go语言的类型元信息的通用结构是 _type（代码位于 src/runtime/type.go）， 其他类型都是以 _type 为内嵌宇段封装而成的结构体。
//src/runtime/type.go
type type struct {
size uintptr // 大小
ptrdata uintptr //size of memory prefix holding all pointers
hash uint32 //类型Hash
tflag tflag //类型的特征标记
align uint8 //_type 作为整体交量存放时的对齐字节数
fieldalign uint8 //当前结构字段的对齐字节数
kind uint8 //基础类型枚举值和反射中的 Kind 一致，kind 决定了如何解析该类型
alg *typeAlg //指向一个函数指针表，该表有两个函数，一个是计算类型 Hash 函
//数，另一个是比较两个类型是否相同的 equal 函数
//gcdata stores the GC type data for the garbage collector.
//If the KindGCProg bit is set in kind,gcdata is a GC program.
//Otherwise it is a ptrmask bitmap. See mbitmap.go for details.
gcdata *byte //GC 相关信息
str nameOff //str 用来表示类型名称字符串在编译后二进制文件中某个 section
//的偏移量
//由链接器负责填充
ptrToThis typeOff //ptrToThis 用来表示类型元信息的指针在编译后二进制文件中某个
//section 的偏移量
//由链接器负责填充
}
_type 包含所有类型的共同元信息，编译器和运行时可以根据该元信息解析具体类型、类型名存放位置、类型的 Hash 值等基本信息。这里需要说明一下：＿type 里面的 nameOff 和 typeOff 最终是由链接器负责确定和填充的，它们都是一个偏移量（offset），类型的名称和类型元信息实际上存放在连接后可执行文件的某个段（section）里，这两个值是相对于段内的偏移量，运行时提供两个转换查找函数。例如：
//src/runtime/type.go 接下来看一下接口的类型元信息的数据结构。示例如下：
//描述接口的类型
type interfacetype struct {
typ _type //类型通用部分
pkgpath name //接口所属包的名字信息， name 内存放的不仅有名称，还有描述信息
mhdr []imethod //接口的方法
}
//接口方法元信息
type imethod struct {
name nameOff //方法名在编译后的 section 里面的偏移量
ityp typeOff //方法类型在编译后的 section 里面的偏移量
}
接口调用过程分析前面讨论了接口内部的基本数据结构，下面就来通过跟踪接口实例化和动态调用过程，使用 Go 源码和反汇编代码相结合的方式进行研究。下面是一段非常简单的接口调用代码。
//iface.go
package main
type Caler interface {
Add (a,b int) int
Sub (a,b int) int
}
type Adder struct ｛id int }
//go:noinline
func (adder Adder) Add(a,b int) int { return a + b }
//go:noinline
func (adder Adder) Sub(a,b int) int { return a - b }
func main () {
var m Caler=Adder{id: 1234}
m.Add(10,32)
}
生成汇编代码：go build -gcflags= "-S - N -l" iface.go >iface.s 2>&1 接下来分析 main 函数的汇编代码，非关键逻辑已经去掉：
"".main STEXT size=151 args=0x0 locals=0x40
...
0x000f 00015 (src/iface.go:16) SUBQ $64,SP
0x0013 00019 (src/iface.go:16) MOVQ BP,56(SP)
0x0018 00024 (src/iface.go:16) LEAQ 56(SP),BP
为 main 函数堆战开辟空间并保存原来的 BP 指针，这是函数调用前编译器的固定动作。var m Caler = Adder {id: 1234} 语句汇编代码分析：
0x00ld 00029 (src/iface.go:17) MOVQ??? $0,""..autotmp_1+32(SP)
0x002f 00047 (src/iface.go:17) LEAQ??? go.itab."".Adder,"".Caler(SB),AX 注意：这个标号在链接器链接的过程中会替换为具体的地址。我们知道 (SP) 里面存放的是指向 itab(Caler,Adder) 的元信息的地址，这里 (SP) 是函数调用第一个参数的位置。示例如下：
0x003a 00058 (src/iface.go:17) LEAQ ""..autotmp_1+32(SP),AX 0x0044 00068 (src/iface.go:17) CALL??? runtime.convT2I64(SB) runtime.convT2I64 函数是运行时接口动态调用的核心函数。runtime 中有一类这样的函数，看一下 runtime.convT2I64 的源码：
func convT2I64(tab *itab,elem unsafe.Pointer) (i iface) {
t := tab._type
if raceenabled {
raceReadObjectPC(t,elem,getcallerpc(unsafe.Pointer(&tab)),funcPC(convT2I64))
}
if msanenabled {
msanread (elem,t.size)
}
var x unsafe.Pointer
if *(uint64) (elem) == 0 {
x = unsafe.Pointer(&zeroVal[0])
} else {
x = mallocgc(8,t,false)
*(*uint64) (x) = *(*uint64) (elem)
}
i.tab = tab
i.data = x
return
}
从上述源码可以清楚地看出，runtime.convT2I64 的两个参数分别是 *itab 和 unsafe.Pointer 类型，这两个参数正是上文传递进去的两个参数值：go.itab."".Adder,"".Caler(SB) 和指向 Adder 对象复制的指针。runtime.convT2I64 的返回值是一个 iface 数据结构，其意义就是根据 itab 元信息和对象值复制的指针构建和初始化 iface 数据结构，iface 数据结构是实现接口动态调用的关键。至此己经完成了接口初始化的工作，即完成了 iface 数据结构的构建过程。下一步就是接口方法调用了。示例如下：
0x0049 00073 (src/iface.go:17) MOVQ 24(SP),AX m.Add(10,32) 对应的汇编代码如下：
0x00Sd 00093 (src/iface.go:18) MOVQ "".m+40(SP),AX
type itab struct {
inter *interfacetype
_type *type
link *itab
hash uint32 //copy of _type.hash.Used for type switches.
bad bool //type does not implement interface
inhash bool //has this itab been added to hash?
unused [2]byte
fun [1] uintptr //variable sized
}
32(AX) 正好是函数指针的位置， 即存放 Adder *Add() 方法指针的地址（注意：编译器将接收者为值类型的 Add 方法转换为指针的 Add 方法，编译器的这种行为是为了方便调用和优化）。第 3 条指令和第 6 条指令是将对象指针作为接下来函数调用的第 1 个参数。 第 4 条和第 5 条指令是准备函数的第 2、第 3 个参数。 第 8 条指令是调用 Adder 类型的 Add 方法。 此函数调用时，对象的值的副本作为第 1 个参数，调用格式可以表述为 func(reciver,param1,param2)。至此，整个接口的动态调用完成。从中可以清楚地看到，接口的动态调用分为两个阶段：
接下来看一下 go.itab. "".Adder,"".Caler(SB) 这个符号在哪里？我们使用 readelf 工具来静态地分析编译后的 ELF 格式的可执行程序。例如：
#编译
#go build -gcflag s= "-N -l" iface.go
#readelf -s -W iface legrep 'itab'
60:000000000047b220 0 OBJECT LOCAL DEFAULT 5 runtime.itablink
61:000000000047b230 0 OBJECT LOCAL DEFAULT 5 runtime.eitablink
88:00000000004aa100 48 OBJECT GLOBAL DEFAULT 8 go.itab.main.Adder,main.Caler
214:00000000004aa080 40 OBJECT GLOBAL DEFAULT 8 go.itab.runtime.errorString,error
418:00000000004095e0 1129 FUNC GLOBAL DEFAULT 1 runtime.getitab
419:0000000000409a50 1665 FUNC GLOBAL DEFAULT 1 runtime.additab
420:000000000040a0e0 257 FUNC GLOBAL DEFAULT 1 runtime.itabsinit
可以看到符号表里面 go.itab.main.Adder,main.Caler 对应本程序里面 itab 的元信息，它被存放在第 8 个段中。我们来看一下第 8 个段是什么段？
#readelf -S -W iface |egrep '＼[8] | I Nr' 接口调用代价前面讨论了接口动态调用过程，这个过程有两部分多余时耗，一个是接口实例化的过程，也就是 iface 结构建立的过程，一旦实例化后，这个接口和具体类型的 itab 数据结构是可以复用的；另一个是接口的方法调用，它是一个函数指针的间接调用。同时我们应考虑到接口调用是一种动态的计算后的跳转调用，这对现代的计算机 CPU 的执行很不友好，会导致 CPU 缓存失效和分支预测失败，这也有一部分的性能损失。当然最直接的办法就是对比测试，看看接口动态调用的性能损失到底有多大。 测试用例直接选用 GitHub 上的一个测试用例，稍作改写，代码如下。
package main
import (
"testing"
)
type identifier interface {
idInline() int32
idNoInline() int32
}
type id32 struct{ id int32 }
func (id *id32) idinline() int32 { return id.id }
//go:noinline
func (id *id32) idNoinline() int32 { return id.id }
var escapeMePlease *id32
//主要作用是强制变量内存在 heap 上分配
//go:noinline
func escapeToHeap(id *id32) identifier {
escapeMePlease = id
return escapeMePlease
}
//直接调用
func BenchmarkMethodCall_direct(b *testing.B) { //
var myID int32
b.Run("single/noinline",func(b *testing.B) {
m := escapeToHeap(&id32{id: 6754}).(*id32)
b.ResetTimer ()
for i :＝ 0; i ＜ b.N; i++ {
//CALL "".(*id32).idNoinline(SB)
//MOVL 8(SP),AX
//MOVQ "".&myID+40(SP),CX
//MOVL AX,(CX)
myID = m.idNoInline()
}
}
b.Run ("single/inline",func(b *testing.B) {
m := escapeToHeap(＆id32{id: 6754}).(*id32)
b.ResetTimer()
for i: ＝ 0; i < b.N; i++ {
//MOVL (DX),SI
//MOVL SI,(CX)
myID = m.idinline()
}
})
}
//接口调用
func BenchmarkMethodCall_interface(b *testing.B) { //
var myID int32
b.Run("single/noinline",func(b *testing.B) {
m := escapeToHeap(＆id32{id: 6754})
b.ResetTimer()
for i := 0; i < b.N ; i++ {
// MOVQ 32(AX),CX
// MOVQ "".m.data+40(SP),DX
// MOVQ DX,(SP)
// CALL CX
// MOVL 8(SP),AX
// MOVQ "".&myID+48(SP),CX
// MOVL AX,(CX)
myID = m.idNoInline()
}
})
b.Run("single/inline",func(b *testing.B) {
m := escapeToHeap(&id32{id: 6754})
b.ResetTimer()
for i := 0; i < b.N; i++ {
//MOVQ 24(AX),CX
//MOVQ "".m.data+40(SP),DX
//MOVQ DX,(SP)
//CALL CX
//MOVL 8(SP),AX
//MOVQ "". &myID+48(SP),ex
//MOVL AX,(CX)
myID = m.idinline()
}
})
} //
func main() {}
测试过程和结果//直接调用 #go test -bench= 'BenchmarkMethodCall_direct/single/noinline' -cpu=1 -count=5 iface_bench_test.go goos:linux goarch:amd64 BenchmarkMethodCall_direct/single/noinline 2000000000 2.00 ns/op BenchmarkMethodCall_direct/single/noinline 2000000000 1.97 ns/op BenchmarkMethodCall_direct/single/noinline 2000000000 1.97 ns/op BenchmarkMethodCall_direct/single/noinline 2000000000 1.94 ns/op BenchmarkMethodCall_direct/single/noinline 2000000000 1.97 ns/op PASS ok command-line-arguments 20.682s //接口调用 #go test -bench='BenchmarkMethodCall_interface/single/noinline' －cpu=1 -count=5 iface_bench_test.go goos:linux goarch:amd64 BenchmarkMethodCall_interface/single/noinline 1000000000 2.18 ns/op BenchmarkMethodCall_interface/single/noinline 1000000000 2.16 ns/op BenchmarkMethodCall_interface/single/noinline 1000000000 2.17 ns/op BenchmarkMethodCall_interface/single/noinline 1000000000 2.15 ns/op BenchmarkMethodCall_interface/single/noinline 1000000000 2.16 ns/op PASS ok command-line-arguments 11.930s 结果分析直接调用平均时耗为 1.97ns/op，接口调用的平均时耗为 2.16ns/op,(2.16-1.97)/1.97 约等于 9.64%。可以看到测试结果符合预期，每次迭代接口要慢 0.19ns，大约有 9% 的性能损失。但是要清楚这个百分比并不能真实地反映接口的效率问题，首先调用的方法是一个很简单的方法，方法的耗时占比很小，无形中放大了接口调用的耗时。如果方法里面有复杂的逻辑，则真实的性能损失远远小于9%。 从绝对值的角度来看更合理，那就是每次接口调用大约比直接调用慢 0.2ns ，从这个角度看，动态调用的性能损失几乎可以忽略不计。 空接口数据结构前面我们了解到空接口 interface{} 是没有任何方法集的接口，所以空接口内部不需要维护和动态内存分配相关的数据结构 itab 。空接口只关心存放的具体类型是什么，具体类型的值是什么，所以空接口的底层数据结构也很简单，具体如下：
//go/src/runtime/runtime2.go
//空接口
type eface struct {
_type *_type
data unsafe.Pointer
}
从 eface 的数据结构可以看出，空接口不是真的为空，其保留了具体实例的类型和值拷贝，即便存放的具体类型是空的，空接口也不是空的。由于空接口自身没有方法集，所以空接口变量实例化后的真正用途不是接口方法的动态调用。空接口在Go语言中真正的意义是支持多态，有如下几种方式使用了空接口（将空接口类型还原）：
至此，接口内部实现原理全部讲完，大家在了解和学习接口内部实现的知识的同时，更应该学习和思考分析过程中的方法和技巧，使用该方法可以继续分析接口断言、接口查询和接口赋值的内部实现机制。 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |