引言 首先来一段简单的代码逻辑热身,下面的代码大家觉得应该会打印什么呢? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 type OKR struct { id i
引言首先来一段简单的代码逻辑热身,下面的代码大家觉得应该会打印什么呢?
Golang类型设计原则在讲反射之前,先来看看 Golang 关于类型设计的一些原则
接下来要说的反射,就是能够在运行时更新变量和检查变量的值、调用变量的方法和变量支持的内在操作,而不需要在编译时就知道这些变量的具体类型。这种机制被称为反射。Golang 的基础类型是静态的(也就是指定 int、string 这些的变量,它的 type 是 static type),在创建变量的时候就已经确定,反射主要与 Golang 的 interface 类型相关(它的 type 是 concrete type),只有运行时 interface 类型才有反射一说。 Golang 中为什么要使用反射/什么场景可以(应该)使用反射当程序运行时, 我们获取到一个 interface 变量, 程序应该如何知道当前变量的类型,和当前变量的值呢? 当然我们可以有预先定义好的指定类型, 但是如果有一个场景是我们需要编写一个函数,能够处理一类共性逻辑的场景,但是输入类型很多,或者根本不知道接收参数的类型是什么,或者可能是没约定好; 也可能是传入的类型很多,这些类型并不能统一表示。 这时反射就会用的上了,典型的例子如:json.Marshal。 再比如说有时候需要根据某些条件决定调用哪个函数,比如根据用户的输入来决定。这时就需要对函数和函数的参数进行反射,在运行期间动态地执行函数。 举例场景:比如我们需要将一个 struct 执行某种操作(用格式化打印代替),这种场景下我们有多种方式可以实现,比较简单的方式是:switch case
但是这种简单的方法存在一个问题, 当增加一个场景时,比如需要对 slice 支持,则需要在增加一个分支,这种增加是无穷无尽的,每当我需要支持一种类型,哪怕是自定义类型, 本质上是 int64 也仍然需要增加一个分支。 反射的基本用法在 Golang 中为我们提供了两个方法,分别是 reflect.ValueOf 和 reflect.TypeOf,见名知意这两个方法分别能帮我们获取到对象的值和类型。Valueof 返回的是 Reflect.Value 对象,是一个 struct,而 typeof 返回的是 Reflect.Type 是一个接口。我们只需要简单的使用这两个进行组合就可以完成多种功能。
反射的性能分析与优缺点大家都或多或少听说过反射性能偏低,使用反射要比正常调用要低几倍到数十倍,不知道大家有没有思考过反射性能都低在哪些方面,我先做一个简单分析,通过反射在获取或者修改值内容时,多了几次内存引用,多绕了几次弯,肯定没有直接调用某个值来的迅速,这个是反射带来的固定性能损失,还有一方面的性能损失在于,结构体类型字段比较多时,要进行遍历匹配才能获取对应的内容。 下面就根据反射具体示例来分析性能: 测试反射结构体初始化
运行结果: 可以看出,利用反射初始化结构体和直接使用创建 new 结构体是有性能差距的,但是差距不大,不到一倍的性能损耗,看起来对于性能来说损耗不是很大,可以接受。 测试结构体字段读取/赋值
测试结果: 从上面可以看出,通过反射进行 struct 字段读取耗时是直接读取耗时的百倍。直接对实例变量进行赋值每次 0.5 ns,性能是通过反射操作实例指定位置字段的10 倍左右。 使用 FieldByName("Age") 方法性能比使用 Field(1) 方法性能要低十倍左右,看代码的话我们会发现,FieldByName 是通过遍历匹配所有的字段,然后比对字段名称,来查询其在结构体中的位置,然后通过位置进行赋值,所以性能要比直接使用 Field(index) 低上很多。 建议:
测试结构体方法调用
这个测试结果同上面的分析相同 优缺点优点:
缺点:
反射在 okr 中的简单应用
结论使用反射必定会导致性能下降,但是反射是一个强有力的工具,可以解决我们平时的很多问题,比如数据库映射、数据序列化、代码生成场景。 在使用反射的时候,我们需要避免一些性能过低的操作,例如使用 FieldByName() 和MethodByName() 方法,如果必须使用这些方法的时候,我们可以预先通过字段名或者方法名获取到对应的字段序号,然后使用性能较高的反射操作,以此提升使用反射的性能。 |
2022-04-28
2022-04-21
2022-05-13
2022-08-17
2022-02-25