我们选择 go 语言的一个重要原因是,它有非常高的性能。但是它反射的性能却一直为人所诟病,本篇文章就来看看 go 反射的性能问题。
在开始之前,有必要先了解一下 go 的性能测试。在 go 里面进行性能测试很简单,只需要在测试函数前面加上 Benchmark
前缀,
然后在函数体里面使用 b.N
来进行循环,就可以得到每次循环的耗时。如下面这个例子:
func BenchmarkNew(b *testing.B) {
b.ReportAllocs()
for i := 0; i < b.N; i++ {
New()
}
}
我们可以使用命令 go test -bench=. reflect_test.go
来运行这个测试函数,又或者如果使用 goland 的话,直接点击运行按钮就可以了。
说明:
*_test.go
文件中 Benchmark*
前缀函数是性能测试函数,它的参数是 *testing.B
类型。b.ReportAllocs()
:报告内存分配次数,这是一个非常重要的指标,因为内存分配相比单纯的 CPU 计算是比较耗时的操作。在性能测试中,我们需要关注内存分配次数,以及每次内存分配的大小。b.N
:是一个循环次数,每次循环都会执行 New()
函数,然后记录下来每次循环的耗时。go 里面很多优化都致力于减少内存分配,减少内存分配很多情况下都可以提高性能。
输出:
BenchmarkNew-20 1000000000 0.1286 ns/op 0 B/op 0 allocs/op
输出说明:
BenchmarkNew-20
:BenchmarkNew
是测试函数名,-20
是 CPU 核数。1000000000
:循环次数。0.1286 ns/op
:每次循环的耗时,单位是纳秒。这里表示每次循环耗时 0.1286 纳秒。0 B/op
:每次循环内存分配的大小,单位是字节。这里表示每次循环没有分配内存。0 allocs/op
:每次循环内存分配的次数。这里表示每次循环没有分配内存。动态语言的灵活性是以牺牲性能为代价的,go 语言也不例外,go 的 interface{} 提供了一定的灵活性,但是处理 interface{} 的时候就要有一些性能上的损耗了。
我们都知道,go 是一门静态语言,这意味着我们在编译的时候就知道了所有的类型,而不是在运行时才知道类型。
但是 go 里面有一个 interface{}
类型,它可以表示任意类型,这就意味着我们可以在运行时才知道类型。
但本质上,interface{}
类型还是静态类型,只不过它的类型和值是动态的。
在 interface{}
类型里面,存储了两个指针,一个指向类型信息,一个指向值信息。具体可参考《go interface 设计与实现》。
有了 interface{}
类型,让 go 也拥有了动态语言的特性,比如,定义一个函数,它的参数是 interface{}
类型,
那么我们就可以传入任意类型的值给这个函数。比如下面这个函数(做任意整型的加法,返回 int64
类型):
func convert(i interface{}) int64 {
typ := reflect.TypeOf(i)
switch typ.Kind() {
case reflect.Int:
return int64(i.(int))
case reflect.Int8:
return int64(i.(int8))
case reflect.Int16:
return int64(i.(int16))
case reflect.Int32:
return int64(i.(int32))
case reflect.Int64:
return i.(int64)
default:
panic("not support")
}
}
func add(a, b interface{}) int64 {
return convert(a) + convert(b)
}
说明:
convert()
函数:将 interface{}
类型转换为 int64
类型。对于非整型的类型,会 panic。(当然不是很严谨,还没涵盖 uint*
类型)add()
函数:做任意整型的加法,返回 int64
类型。相比之下,如果是确定的类型,我们根本不需要判断类型,直接相加就可以了:
func add1(a, b int64) int64 {
return a + b
}
我们可以通过以下的 benchmark 来对比一下:
func BenchmarkAdd(b *testing.B) {
b.ReportAllocs()
for i := 0; i < b.N; i++ {
add(1, 2)
}
}
func BenchmarkAdd1(b *testing.B) {
b.ReportAllocs()
for i := 0; i < b.N; i++ {
add1(1, 2)
}
}
结果:
BenchmarkAdd-12 179697526 6.667 ns/op 0 B/op 0 allocs/op
BenchmarkAdd1-12 1000000000 0.2353 ns/op 0 B/op 0 allocs/op
我们可以看到非常明显的性能差距,add()
要比 add1()
慢了非常多,而且这还只是做了一些简单的类型判断及类型转换的情况下。
通过这个例子我们知道,go 虽然通过 interface{}
为我们提供了一定的灵活性支持,但是使用这种动态的特性是有一定代价的,比如:
Field
, FieldByName
, Method
, MethodByName
),这些操作都是在运行时做的,所以会有一定的性能损耗。Field
, Method
)查找相比通过 name (FieldByName
, MethodByName
)查找快很多,后者有内存分配的操作int
类型相加,本来可以直接相加。但是通过反射,我们不得不先根据 interface{}
创建一个反射对象,然后再做类型判断,再做类型转换,最后再做加法。总的来说,go 的 interface{} 类型虽然给我们提供了一定的灵活性,让开发者也可以在 go 里面实现一些动态语言的特性,
但是这种灵活性是以牺牲一定的性能来作为代价的,它会让一些简单的操作变得复杂,一方面生成的编译指令会多出几十倍,另一方面也有可能在这过程有内存分配的发生(比如 FieldByName
)。
从上面的例子中,我们发现 go 的反射好像慢到了让人无法忍受的地步,然后就有人提出了一些解决方案,
比如:通过代码生成的方式避免运行时的反射操作,从而提高性能。比如 easyjson
但是这类方案都会让代码变得繁杂起来。我们需要权衡之后再做决定。为什么呢?因为反射虽然慢,但我们要知道的是,如果我们的应用中有网络调用,任何一次网络调用的时间往往都不会少于 1ms,而这 1ms 足够 go 做很多次反射操作了。这给我们什么启示呢?如果我们不是做中间件或者是做一些高性能的服务,而是做一些 web 应用,那么我们可以考虑一下性能瓶颈是不是在反射这里,如果是,那么我们就可以考虑一下代码生成的方式来提高性能,如果不是,那么我们真的需要牺牲代码的可维护性、可读性来提高反射的性能吗?优化几个慢查询带来的收益是不是更高呢?
如果可以的话,最好的优化就是不要用反射。
这里以 easyjson
为例,我们来看一下它是怎么做的。假设我们有如下结构体,我们需要对其进行 json 序列化/反序列化:
// person.go
type Person struct {
Name string `json:"name"`
Age int `json:"age"`
}
使用 easyjson
的话,我们需要为结构体生成代码,这里我们使用 easyjson
的命令行工具来生成代码:
easyjson -all person.go
这样,我们就会在当前目录下生成 person_easyjson.go
文件,里面包含了 MarshalJSON
和 UnmarshalJSON
方法,这两个方法就是我们需要的序列化和反序列化方法。不同于标准库里面的 json.Marshal
和 json.Unmarshal
,这两个方法是不需要反射的,它们的性能会比标准库的方法要好很多。
func easyjsonDb0593a3EncodeGithubComGinGonicGinCEasy(out *jwriter.Writer, in Person) {
out.RawByte('{')
first := true
_ = first
{
const prefix string = ",\"name\":"
out.RawString(prefix[1:])
out.String(string(in.Name))
}
{
const prefix string = ",\"age\":"
out.RawString(prefix)
out.Int(int(in.Age))
}
out.RawByte('}')
}
// MarshalJSON supports json.Marshaler interface
func (v Person) MarshalJSON() ([]byte, error) {
w := jwriter.Writer{}
easyjsonDb0593a3EncodeGithubComGinGonicGinCEasy(&w, v)
return w.Buffer.BuildBytes(), w.Error
}
我们看到,我们对 Person
的序列化操作现在只需要几行代码就可以完成了,但是也有很明显的缺点,生成的代码会很多。
性能差距:
goos: darwin
goarch: amd64
pkg: github.com/gin-gonic/gin/c/easy
cpu: Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
BenchmarkJson
BenchmarkJson-12 3680560 305.9 ns/op 152 B/op 2 allocs/op
BenchmarkEasyJson
BenchmarkEasyJson-12 16834758 71.37 ns/op 128 B/op 1 allocs/op
我们可以看到,使用 easyjson
生成的代码,序列化的性能比标准库的方法要好很多,好了 4 倍以上。
这种方法适用于需要根据名称查找结构体字段或者查找方法的场景。
假设我们有一个结构体 Person
,其中有 5 个方法,M1
、M2
、M3
、M4
、M5
,我们需要通过名称来查找其中的方法,那么我们可以使用 reflect
包来实现:
p := &Person{}
v := reflect.ValueOf(p)
v.MethodByName("M4")
这是很容易想到的办法,但是性能如何呢?通过性能测试,我们可以看到,这种方式的性能是非常差的:
func BenchmarkMethodByName(b *testing.B) {
p := &Person{}
v := reflect.ValueOf(p)
b.ReportAllocs()
for i := 0; i < b.N; i++ {
v.MethodByName("M4")
}
}
结果:
BenchmarkMethodByName-12 5051679 237.1 ns/op 120 B/op 3 allocs/op
相比之下,我们如果使用索引来获取其中的方法的话,性能会好很多:
func BenchmarkMethod(b *testing.B) {
p := &Person{}
v := reflect.ValueOf(p)
b.ReportAllocs()
for i := 0; i < b.N; i++ {
v.Method(3)
}
}
结果:
BenchmarkMethod-12 200091475 5.958 ns/op 0 B/op 0 allocs/op
我们可以看到两种性能相差几十倍。那么我们是不是可以通过 Method
方法来替代 MethodByName
从而获得更好的性能呢?答案是可以的,我们可以缓存 MethodByName
的结果(就是方法名对应的下标),下次通过反射获取对应方法的时候直接通过这个下标来获取:
这里需要通过 reflect.Type 的 MethodByName 来获取反射的方法对象。
// 缓存方法名对应的方法下标
var indexCache = make(map[string]int)
func methodIndex(p interface{}, method string) int {
if _, ok := indexCache[method]; !ok {
m, ok := reflect.TypeOf(p).MethodByName(method)
if !ok {
panic("method not found!")
}
indexCache[method] = m.Index
}
return indexCache[method]
}
性能测试:
func BenchmarkMethodByNameCache(b *testing.B) {
p := &Person{}
v := reflect.ValueOf(p)
b.ReportAllocs()
var idx int
for i := 0; i < b.N; i++ {
idx = methodIndex(p, "M4")
v.Method(idx)
}
}
结果:
// 相比原来的 MethodByName 快了将近 20 倍
BenchmarkMethodByNameCache-12 86208202 13.65 ns/op 0 B/op 0 allocs/op
BenchmarkMethodByName-12 5082429 235.9 ns/op 120 B/op 3 allocs/op
跟这个例子类似的是 Field/FieldByName 方法,可以采用同样的优化方式。这个可能是更加常见的操作,反序列化可能需要通过字段名查找字段,然后进行赋值。
在实际使用中,如果只是需要进行一些简单的类型判断的话,比如判断是否实现某一个接口,那么可以使用类型断言来实现:
type Talk interface {
Say()
}
type person struct {
}
func (p person) Say() {
}
func BenchmarkReflectCall(b *testing.B) {
p := person{}
v := reflect.ValueOf(p)
for i := 0; i < b.N; i++ {
idx := methodIndex(&p, "Say")
v.Method(idx).Call(nil)
}
}
func BenchmarkAssert(b *testing.B) {
p := person{}
for i := 0; i < b.N; i++ {
var inter interface{} = p
if v, ok := inter.(Talk); ok {
v.Say()
}
}
}
结果:
goos: darwin
goarch: amd64
cpu: Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz
BenchmarkReflectCall-12 6906339 173.1 ns/op
BenchmarkAssert-12 171741784 6.922 ns/op
在这个例子中,我们就算使用了缓存版本的反射,性能也跟类型断言差了将近 25 倍。
因此,在我们使用反射之前,我们需要先考虑一下是否可以通过类型断言来实现,如果可以的话,那么就不需要使用反射了。
go test -bench=.
这种命令来进行性能测试,运行命令之后,文件夹下的测试文件中的 Benchmark*
函数会被执行。b.ReportAllocs()
来进行统计的。内存分配的次数和内存分配的字节数越少,性能越好。FieldByName
, MethodByName
这种方法,它们需要遍历所有的字段和方法,然后进行比较,这个比较的过程也是需要消耗一定时间的。而且这个过程还需要分配内存,这会进一步降低性能。Field
代替 FieldByName
等。反射是一个很庞大的话题,这里只是简单的介绍了一小部分反射的性能问题,讨论了一些可行的优化方案,但是每个人使用反射的场景都不一样,所以需要根据实际情况来做优化。