想在golang里用好泛型还挺难的

打印 上一主题 下一主题

主题 900|帖子 900|积分 2700

golang的泛型已经出来了一年多了,从提案被接受开始我就在关注泛型了,如今不管是在生产环境还是开源项目里我都写了不少泛型代码,是时候全面得回顾下golang泛型的使用体验了。
先说说结论,好用是好用,但问题也很多,有些问题比较影响使用体验,到了不吐不快的地步了。
这篇文章不会教你泛型的基础语法,并且要求你对golang的泛型使用有一定经验,如果你还是个泛型的新手,可以先阅读下官方的教程,然后再阅读本篇文章。
泛型的实现

实现泛型有很多种方法,常见的主流的是下面这些:

  • 以c++为代表的,类型参数就是个占位符,最后实际上会替换成实际类型,然后以此为模板生成实际的代码,生成多份代码,每份的类型都不一样
  • 以TypeScript和Java为代表的类型擦除,把类型参数泛化成一个满足类型约束的类型(Object或者某个interface),只生成一份代码
  • 以c#为代表,代码里表现的像类型擦除,但运行的时候实际上和c++一样采用模板实例化对每个不同的类型都生成一份代码
那么golang用的哪种呢?哪种都不是,golang有自己的想法:gcshape。
什么是gcshape?简单得说,所有拥有相同undelyring type的类型都算同一种shape,所有的指针都算一种shape,除此之外就算两个类型大小相同甚至字段的类型相同也不算同一个shape。
那么这个shape又是什么呢?gc编译器会根据每个shape生成一份代码,拥有相同shape的类型会共用同一份代码。
看个简单例子:
  1. func Output[T any]() {
  2.         var t T
  3.         fmt.Printf("%#v\n", t)
  4. }
  5. type A struct {
  6.         a,b,c,d,e,f,g int64
  7.         h,i,j string
  8.         k []string
  9.         l, m, n map[string]uint64
  10. }
  11. type B A
  12. func main() {
  13.         Output[string]()
  14.         Output[int]()
  15.         Output[uint]()
  16.         Output[int64]()
  17.         Output[uint64]() // 上面每个都underlying type都不同,尽管int64和uint64大小一样,所以生成5份不同的代码
  18.         Output[*string]()
  19.         Output[*int]()
  20.         Output[*uint]()
  21.         Output[*A]() // 所有指针都是同一个shape,所以共用一份代码
  22.         Output[A]()
  23.         Output[*B]()
  24.         Output[B]() // B的underlying tyoe和A一样,所以和A共用代码
  25.         Output[[]int]()
  26.         Output[*[]int]()
  27.         Output[map[int]string]()
  28.         Output[*map[int]string]()
  29.         Output[chan map[int]string]()
  30. }
复制代码
验证也很简单,看看符号表即可:

为啥要这么做?按提案的说法,这么做是为了避免代码膨胀同时减轻gc的负担,看着是有那么点道理,有相同shape的内存布局是一样的,gc处理起来也更简单,生成的代码也确实减少了——如果我就是不用指针那生成的代码其实也没少多少。
尽管官方拿不出证据证明gcshape有什么性能优势,我们还是姑且认可它的动机吧。但这么实现泛型后导致了很多严重的问题:

  • 性能不升反降
  • 正常来说类型参数是可以当成普通的类型来用的,但golang里有很多时候不能
正因为有了gcshape,想在golang里用对泛型还挺难的。
性能问题

这一节先说说性能。看个例子:
  1. type A struct {
  2.         num  uint64
  3.         num1 int64
  4. }
  5. func (a *A) Add() {
  6.         a.num++
  7.         a.num1 = int64(a.num / 2)
  8. }
  9. type B struct {
  10.         num1 uint64
  11.         num2 int64
  12. }
  13. func (b *B) Add() {
  14.         b.num1++
  15.         b.num2 = int64(b.num1 / 2)
  16. }
  17. type Adder interface {
  18.         Add()
  19. }
  20. func DoAdd[T Adder](t T) {
  21.         t.Add()
  22. }
  23. func DoAddNoGeneric(a Adder) {
  24.         a.Add()
  25. }
  26. func BenchmarkNoGenericA(b *testing.B) {
  27.         obj := &A{}
  28.         for i := 0; i < b.N; i++ {
  29.                 obj.Add()
  30.         }
  31. }
  32. func BenchmarkNoGenericB(b *testing.B) {
  33.         obj := &B{}
  34.         for i := 0; i < b.N; i++ {
  35.                 obj.Add()
  36.         }
  37. }
  38. func BenchmarkGenericA(b *testing.B) {
  39.         obj := &A{}
  40.         for i := 0; i < b.N; i++ {
  41.                 DoAdd(obj)
  42.         }
  43. }
  44. func BenchmarkGenericB(b *testing.B) {
  45.         obj := &B{}
  46.         for i := 0; i < b.N; i++ {
  47.                 DoAdd(obj)
  48.         }
  49. }
  50. func BenchmarkGenericInterfaceA(b *testing.B) {
  51.         var obj Adder = &A{}
  52.         for i := 0; i < b.N; i++ {
  53.                 DoAdd(obj)
  54.         }
  55. }
  56. func BenchmarkGenericInterfaceB(b *testing.B) {
  57.         var obj Adder = &B{}
  58.         for i := 0; i < b.N; i++ {
  59.                 DoAdd(obj)
  60.         }
  61. }
  62. func BenchmarkDoAddNoGeneric(b *testing.B) {
  63.         var obj Adder = &A{}
  64.         for i := 0; i < b.N; i++ {
  65.                 DoAddNoGeneric(obj)
  66.         }
  67. }
复制代码
猜猜结果,是不是觉得引入了泛型可以解决很多性能问题?答案揭晓:

哈哈,纯泛型和正常代码比有不到10%的差异,而接口+泛型就慢了接近100%。直接用接口是这里最快的,不过这是因为接口被编译器优化了,原因参加这篇
你说谁会这么写代码啊,没事,我再举个更常见的例子:
  1. func Search[T Equaler[T]](slice []T, target T) int {
  2.         index := -1
  3.         for i := range slice {
  4.                 if slice[i].Equal(target) {
  5.                         index = i
  6.                 }
  7.         }
  8.         return index
  9. }
  10. type MyInt int
  11. func (m MyInt) Equal(rhs MyInt) bool {
  12.         return int(m) == int(rhs)
  13. }
  14. type Equaler[T any] interface {
  15.         Equal(T) bool
  16. }
  17. func SearchMyInt(slice []MyInt, target MyInt) int {
  18.         index := -1
  19.         for i := range slice {
  20.                 if slice[i].Equal(target) {
  21.                         index = i
  22.                 }
  23.         }
  24.         return index
  25. }
  26. func SearchInterface(slice []Equaler[MyInt], target MyInt) int {
  27.         index := -1
  28.         for i := range slice {
  29.                 if slice[i].Equal(target) {
  30.                         index = i
  31.                 }
  32.         }
  33.         return index
  34. }
  35. var slice []MyInt
  36. var interfaces []Equaler[MyInt]
  37. func init() {
  38.         slice = make([]MyInt, 100)
  39.         interfaces = make([]Equaler[MyInt], 100)
  40.         for i := 0; i < 100; i++ {
  41.                 slice[i] = MyInt(i*i + 1)
  42.                 interfaces[i] = slice[i]
  43.         }
  44. }
  45. func BenchmarkSearch(b *testing.B) {
  46.         for i := 0; i < b.N; i++ {
  47.                 Search(slice, 99*99)
  48.         }
  49. }
  50. func BenchmarkInterface(b *testing.B) {
  51.         for i := 0; i < b.N; i++ {
  52.                 SearchInterface(interfaces, 99*99)
  53.         }
  54. }
  55. func BenchmarkSearchInt(b *testing.B) {
  56.         for i := 0; i < b.N; i++ {
  57.                 SearchMyInt(slice, 99*99)
  58.         }
  59. }
复制代码
这是结果:

泛型代码和使用接口的代码相差无几,比普通代码慢了整整六倍
为啥?因为gcshape的实现方式导致了类型参数T并不是真正的类型,所以在调用上面的方法的时候得查找一个叫type dict的东西找到当前使用的真正的类型,然后再把绑定在T上的变量转换成那个类型。多了一次查找+转换,这里的MyInt转换后还会被复制一次,所以能不慢么。
这也解释了为什么把接口传递给类型参数是最慢的,因为除了要查一次type dict,接口本身还得再做一次类型检查并查找对应的method。
所以想靠泛型大幅提升性能的人还是洗洗睡吧,只有一种情况泛型的性能不会更差:在类型参数上只使用内置的运算符比如加减乘除,不调用任何方法。
但也不该因噎废食,首先泛型struct和泛型interface受到的影响很小,其次如我所说,如果不使用类型约束上的方法,那性能损耗几乎没有,所以像lo、mo这样的工具库还是能放心用的。
这个问题1.18就有人提出来了,然而gcshape的实现在这点上太拉胯,小修小补解决不了问题,官方也没改进的动力,所以哪怕到了1.21还是能复现同样的问题。
不过噩梦才刚刚开始,更劲爆的还在后面呢。
如何创建对象

首先你不能这么写:T{},因为int之类的内置类型不支持这么做。也不能这样:make(T, 0),因为T不是类型占位符,不知道具体类型是什么,万一是不能用make的类型编译会报错。
那么对于一个类型T,想要在泛型函数里创建一个它的实例就只能这样了:
  1. func F[T any]() T {
  2.     var ret T
  3.     // 如果需要指针,可以用new(T),但有注意事项,下面会说
  4.     return ret
  5. }
复制代码
So far, so good。那么我要把T的类型约束换成一个有方法的interface呢?
  1. type A struct {i int}
  2. func (*A)Hello() {
  3.         fmt.Println("Hello from A!")
  4. }
  5. func (a *A) Set(i int) {
  6.         a.i = i
  7. }
  8. type B struct{i int}
  9. func (*B)Hello(){
  10.         fmt.Println("Hello from B!")
  11. }
  12. func (b *B) Set(i int) {
  13.         b.i = i
  14. }
  15. type API interface {
  16.         Hello()
  17.         Set(int)
  18. }
  19. func SayHello[PT API](a PT) {
  20.         a.Hello()
  21.         var b PT
  22.         b.Hello()
  23.         b.Set(222222)
  24.         fmt.Println(a, b)
  25. }
  26. func main() {
  27.         a := new(A)
  28.         a.Set(111)
  29.         fmt.Println(a)
  30.         SayHello(&A{})
  31.         SayHello(&B{})
  32. }
复制代码
运行结果是啥?啥都不是,运行时会奖励你一个大大的panic:

你懵了,如果T的约束是any的时候就是好的,虽然不能调用方法,怎么到这调Set就空指针错误了呢?
这就是我要说的第二点严重问题了,类型参数不是你期待的那种int,MyInt那种类型,类型参数有自己独有的类型,叫type parameter。有兴趣可以去看语言规范里的定义,没兴趣就这么简单粗暴的理解也够了:这就是种会编译期间进行检查的interface
理解了这点你的问题就迎刃而解了,因为它类似下面的代码:
  1. var a API
  2. a.Set(1)
复制代码
a没绑定任何东西,那么调Set百分百空指针错误。同理,SayHello里的b也没绑定任何数据,一样会空指针错误。为什么b.Hello()调成功了,因为这个方法里没对接收器的指针解引用。
同样new(T)这个时候是创建了一个type parameter的指针,和原类型的关系就更远了。
但对于像这样~int、[]int的有明确的core type的约束,编译器又是双标的,可以正常创建实例变量。
怎么解决?没法解决,当然不排除是我不会用golang的泛型,如果你知道在不使用unsafe或者给T添加创建实例的新方法的前提下满足需求的解法,欢迎告诉我。
目前为止这还不是大问题,一般不需要在泛型代码里创建实例,大部分需要的情况也可以在函数外创建后传入。而且golang本身没有构造函数的概念,怎么创建类型的实例并不是类型的一部分,这点上不支持还是可以理解的。
但下面这个问题就很难找到合理的借口了。
把指针传递给类型参数

最佳实践:永远不要把指针类型作为类型参数,就像永远不要获取interface的指针一样。
为啥,看看下面的例子就行:
  1. func Set[T *int|*uint](ptr T) {
  2.         *ptr = 1
  3. }
  4. func main() {
  5.         i := 0
  6.         j := uint(0)
  7.         Set(&i)
  8.         Set(&j)
  9.         fmt.Println(i, j)
  10. }
复制代码
输出是啥,是编译错误:
  1. $ go build a.go
  2. # command-line-arguments
  3. ./a.go:6:3: invalid operation: pointers of ptr (variable of type T constrained by *int | *uint) must have identical base types
复制代码
这个意思是T不是指针类型,没法解引用。猜都不用猜,肯定又是type parameter作怪了。
是的。T是type parameter,而type parameter不是指针,不支持解引用操作。
不过比起前一个问题,这个是有解决办法的,而且办法很多,第一种,明确表明ptr是个指针:
  1. func Set[T int|uint](ptr *T) {
  2.         *ptr = 1
  3. }
复制代码
第二种,投机取巧:
  1. func Set[T int|uint, PT interface{*T}](ptr PT) {
  2.         *ptr = 1
  3. }
复制代码
第二种为什么行,因为在类型约束里如果T的约束有具体的core type(包括any),那么在这里就会被当成实际的类型用而不是type parameter。所以PT代表的意思是“有一个类型,它必须是T代表的实际类型的指针类型”。因为PT是指针类型了,所以第二种方法也可以达到目的。
但我永远只推荐你用第一种方法,别给自己找麻烦
泛型和类型的方法集

先看一段代码:
  1. type A struct {i int}
  2. func (*A)Hello() {
  3.         fmt.Println("Hello from A!")
  4. }
  5. type B struct{i int}
  6. func (*B)Hello(){
  7.         fmt.Println("Hello from B!")
  8. }
  9. func SayHello[T ~*A|~*B](a T) {
  10.         a.Hello()
  11. }
  12. func main() {
  13.         SayHello(&A{})
  14.         SayHello(&B{})
  15. }
复制代码
输出是啥?又是编译错误:
  1. $ go build a.go
  2. # command-line-arguments
  3. ./a.go:17:4: a.Hello undefined (type T has no field or method Hello)
复制代码
你猜到了,因为T是类型参数,而不是(*A),所以没有对应的方法存在。所以你这么改了:
  1. func SayHello[T A|B](a *T) {
  2.         a.Hello()
  3. }
复制代码
这时候输出又变了:
  1. $ go build a.go
  2. # command-line-arguments
  3. ./a.go:17:4: a.Hello undefined (type *T is pointer to type parameter, not type parameter)
复制代码
这个报错好像挺眼熟啊,这不就是取了interface的指针之后在指针上调用方法时报的那个错吗?
对,两个错误都差不多,因为type parameter有自己的数据结构,而它没有任何方法,所以通过指针指向type parameter后再调用方法会报一模一样的错。
难道我们只能建个interface里面放上Hello这个方法了吗?虽然我推荐你这么做,但还有别的办法,我们可以利用上一节的PT,但需要给它加点method:
  1. func SayHello[T A|B, PT interface{*T; Hello()}](a PT) {
  2.         a.Hello()
  3. }
复制代码
原理是一样的,但现在a还同时支持指针的操作。
直接用interface{Hello()}不好吗?绝大部分时间都可以,但如果我只想限定死某些类型的话就不适用了。
如何复制一个对象

大部分情况下直接b := a即可,不过要注意这是浅拷贝。
对于指针就比较复杂了,因为type parameter的存在,我们得特殊处理:
  1. type A struct {i int}
  2. func (*A)Hello() {
  3.         fmt.Println("Hello from A!")
  4. }
  5. func (a *A) Set(i int) {
  6.         a.i = i
  7. }
  8. type B struct{i int/*j*/}
  9. func (*B)Hello(){
  10.         fmt.Println("Hello from B!")
  11. }
  12. func (b *B) Set(i int) {
  13.         b.i = i
  14. }
  15. type API[T any] interface {
  16.         *T
  17.         Set(int)
  18. }
  19. func DoCopy[T any, PT API[T]](a PT) {
  20.         b := *a
  21.         (PT(&b)).Set(222222) // 依旧是浅拷贝
  22.         fmt.Println(a, b)
  23. }
复制代码
PT是指针类型,所以可以解引用得到T的值,然后再赋值给b,完成了一次浅拷贝。
注意,拷贝出来的b是T类型的,得先转成*T再转成PT。
想深拷贝怎么办,那只能定义和实现这样的接口了:CloneAble[T any] interface{Clone() T}。这倒也没那么不合理,为了避免浅拷贝问题一般也需要提供一个可以复制自身的方法,算是顺势而为吧。
总结

这一年多来我遇到的令人不爽的问题就是这些,其中大部分是和指针相关的,偶尔还要外加一个性能问题。
一些最佳实践:

  • 明确使用*T,而不是让T代表指针类型
  • 明确使用[]T和map[T1]T2,而不是让T代表slice或map
  • 少写泛型函数,可以多用泛型struct
  • 类型约束的core type直接影响被约束的类型可以执行哪些操作,要当心
如果是c++,那不会有这些问题,因为类型参数是占位符,会被替换成真实的类型;如果是ts,java也不会有这些问题,因为它们没有指针的概念;如果是c#,也不会有问题,至少在8.0的时候编译器不允许构造类似T*的东西,如果你这么写,会有清晰明确的错误信息。
而我们的golang呢?虽然不支持,但给的报错却是一个代码一个样,对golang的类型系统和泛型实现细节没点了解还真不知道该怎么处理呢。
我的建议是,在golang想办法改进这些问题之前,只用别人写的泛型库,只用泛型处理slice和map。其他的杂技我们就别玩了,容易摔着。

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

倒序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

欢乐狗

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表