编译器 | Tony Bai

标签编译器下的文章

Ian Lance Taylor：Go泛型使用的一般准则

十一月 7, 2021
0 条评论

本文永久链接 – https://tonybai.com/2021/11/07/using-generics-in-go

在近期Google Open Source Live的Go Day 2021环节，Go泛型的主要设计者Ian Lance Taylor做了Using Generics in Go的简短演讲(国内地址在这里)。这篇演讲的重点不是即将于Go 1.18版本降临的Go泛型的语法细节，而是介绍目前Go核心团队在设计、实现以及内部实践Go泛型的过程中积累的一些实践经验。Ian将这些经验总结成了这么一段小视频，旨在Go泛型落地之前，为Go社区提供一些Go泛型使用的通用指导原则。这里将演讲内容整理出来，供大家参考。

我们将于2022年2月的Go 1.18版本中提供泛型。

什么是泛型？

泛型可以让你先来编写数据结构和函数，然后在使用时指定其中的类型。当然，当前Go语言中的函数也有形式参数(parameter)。但有了泛型后，函数可以支持一类新的形式参数(parameter)，这类形式参数被称为“类型参数（type parameter）”。当前不支持任何参数的类型也可以拥有自己的类型参数。带有类型参数的函数与类型可以通过类型实参(type argument)进行实例化。对于类型参数，我们会用“实例化”而不是调用(call)，因为整个操作发生在编译阶段，而不是运行阶段。

类型参数定义了约束(constraints)，这些约束限制了允许的类型实参集合，这与普通形参通过类型限制允许的实参集合类似。比如下面这个例子：

看看MapKeys这个函数，它接受一个map类型形参，返回一个包含该map所有key的切片。在Go中，我们很容易这对特定的map类型实现这个函数。上面的例子就是一个针对map[string]int类型形参的实现。但对你要使用的特定map类型，你需要编写一个该函数的不同副本，或者你也可以通过标准库的reflect（反射包）来实现这个函数。但后者实现起来很笨拙并且性能相对来说也不高。使用reflect包来实现非常复杂，这里我就不举例了。

或者，你用类型参数来实现它：

使用类型参数，你只需要实现一遍这个函数，它便可以支持所有map类型，并且编译器可以对传入的参数进行充分的类型检查。这里类型参数命名为K和V。而之前例子中类型为map[string]int的普通形参m在这个例子中的类型为map[K]V。类型参数K是map的key的类型，它应该是可比较的(comparable)。在例子代码中，我们通过为K增加表述这一要求的约束。你也可以将其视为类型参数的元类型(meta type)。它就是是一个预声明的约束comparable。类型参数V可以使任意类型，所以它的约束是预声明的约束any，该约束顾名思义，意味着V可以是任意类型。函数体与原先一样，除了变量s的类型变为了元素类型为K的切片类型，而不再是元素类型为字符串的切片了。

泛型这个新语法特性还有很多语法细节，但我在这里不会详说。重要的是你知道函数可以拥有类型参数了，另外虽然这个例子没有展示，但实际上类型本身也可以有类型参数。你可以通过https://golang.org/s/generics-proposal这个链接页面了解关于泛型特性的更多细节。

什么情况适合使用泛型

我今天要谈的不是什么是泛型或如何使用泛型，我要谈的是什么情况下适合使用泛型以及什么情况下不适合使用泛型。更明确来说，我在这里将给出一些通用的指导建议，但它们不是不可违反的硬性规定。具体情况，你自己来判断。如果你不能确定，你可以参考下面我要讲解的内容。

首先，我们先来说说Go编程的一般指导规则。我们通过编写代码来编写Go程序，而不是通过定义类型。当涉及泛型时，如果你编写Go代码时，总是在尝试定义类型参数的约束，那你可能走错路了。你应该从编写函数开始，如果你明确了类型参数会有用，那么后续为函数添加类型参数非常容易。

让我们看一下什么情况下类型参数很有用。

类型参数的一种有用的情况是当编写的函数的操作元素的类型为slice、map、channel等特定类型时。如果一个函数接受这些类型的形参，并且函数代码没有对参数的元素类型作出任何假设，那么使用类型参数可能会非常有用。例如，我们之前看到的MapKeys函数。那个函数返回map中所有key组成的切片。函数对Map key的类型没有做任何假设，这让MapKeys函数成为使用类型参数的一个很好的候选者。正如我之前提到过的，此类使用类型参数的函数的另外一个替代方案通常是使用反射(reflection)。那是一个更笨拙的编程模型，并且它无法进行静态类型检查，运行起来也更慢。

另一个相似的适合使用类型参数的情况是编写通用数据结构。所谓的通用数据结构，我指的是像切片或map，但Go语言没有提供原生支持的类型。比如一个链表或一个二叉树。今天，需要这类数据结构的程序会使用特定的元素类型实现它们，或使用接口类型(interface{})实现。使用类型参数替换特定元素类型可以实现一个更通用的数据结构，这个通用的数据结构将可以被其他程序所复用。用类型参数替换接口类型通常也会让数据存储的更为高效。在一些场合，使用类型参数替代接口类型意味着代码可以避免进行类型断言(type assertion)，并且在编译阶段还可以进行全面的类型静态检查。比如下面这个例子：

这是使用了类型参数的二叉树结构的一个可能实现。这是一个类型使用类型参数的例子。树中每个叶子节点(leaf)都包含一个类型参数T类型的值。当我们用某个具体类型实参对这个树结构进行实例化时，类型实参的值将直接存储在叶子节点中，它们不会被存储为interface类型的值。下面是这个树类型的一个方法实现：

无需过于关注代码的实现细节或代码的风格，重点在于这是一个类型参数合理使用的示例，因为这个树结构以及上述方法的实现代码多是与元素类型T无关的。这个数据结构的确需要知道如何比较元素类型T的值，它使用一个传入的比较函数来进行元素的比较。你可以看到在上面代码的第四行，它调用了bt.cmp函数。除此之外，类型参数没有任何其他作用。

这个二叉树的例子为我们展示了另外一条一般原则：当你需要使用像比较函数这样的功能时，最好使用函数而不是方法。我们本可以将这个二叉树结构定义为其元素类型需要实现一个compare方法或less方法，我们可以通过定义一个需要compare或less方法的约束来实现。这就意味着任何用来实例化这个树结构的类型实参必须包含这样一个方法。但是这就意味着任何想用一个简单类型int来实例化这个树结构的开发者都必须定义一个带有compare方法的自定义int类型。同时这样意味着任何想用自定义类型实例化这个树结构的开发者也都要为其自定义的类型定一个compare方法，即便这本不需要。

如果我们像上面示例中代码那样，定义一个接受一个函数的树结构，那么传入一个期望的compare函数十分容易。并且如果元素恰好拥有compare方法，我们可以简单的以element.compare形式传入method expression来作为比较函数即可。换句话说，将方法转换为函数比向一个类型添加一个方法要容易的多。因此，对于通用数据结构，最好使用函数，而不是编写一个需要方法的约束。

另外一个类型参数有用的情况是当不同类型需要实现一些通用方法，并且不同类型的方法实现看起来都相同。比如考虑一下标准库sort包的sort.Interface，它需要实现它的类型实现三个方法：Len、Swap和Less。下面这个例子展示了一个sliceFn，一个为任意类型实现sort.Interface而定义的泛型类型：

对于任意slice类型，Len与Swap方法的实现都相同。Less方法需要一个比较函数，这就是sliceFn名字中Fn部分的功能，和我们在之前树结构例子中一样，当我们创建一个sliceFn时，我们传入一个函数。下面的代码演示了如何使用sliceFn对任意切片进行排序：

这里，对于任何slice类型，我们都使用类型参数去实现sort.Interface的方法。类型参数非常适合这个例子，因为对于所有切片类型来说，这些方法的实现都相同。

现在我应该说一下：Go 1.18版本很大可能会包含一个使用比较函数做切片排序的通用函数，并且这个通用函数很大可能不会使用sort.Interface，但即便这个示例今后可能没有用处，但其观点仍然是对的。

当你需要实现的相关类型的方法看起来都一样时，使用类型参数是合理的。

什么情况不宜使用泛型

现在让我们来讨论这个问题的另一面：什么情况不宜使用泛型。

什么情况下，使用类型参数不是一个好主意呢？

Go拥有interface类型。接口类型已经支持了一定程度上的通用机制。例如：广泛使用的io.Reader接口提供了一种从任意含有信息的值，或生产类似随机数生成器的地方读取数据。

如果你对于某一类型的值所要做的全部操作仅仅是在那个值上调用一个方法，请使用interface类型，而不是类型参数。io.Reader易读且高效。没有必要使用一个类型参数像调用Read方法那样去从一个值中读取数据。例如，不要像下面这样编写代码：

我们可以不用类型参数实现相同功能的函数。省略类型参数将使得函数更简洁易读易实现，并且运行时间可能是相同的。

最后强调一点，开发者(尤其是那些熟悉C++的)可能会假设，使用特定类型实参实例化的函数往往比使用虚拟方法的代码运行稍快。我说虚拟方法，是因为C++使用的是虚拟方法。就本次演讲而言，C++所说的虚拟方法类似于Go语言中的接口方法。当然在Go语言中，具体的细节还取决于编译器。

与使用接口方法的类似代码相比，使用类型实参实例化的函数很有可能并不是更快。因此，不要出于效率考虑使用类型参数。使用类型参数的原因是它们让你的代码更清晰。如果是它们让你的代码变得更复杂，就不要使用。

现在回到类型参数与接口类型之间的选择。当不同的类型使用一个共同的方法时，考虑该方法的实现。前面我们说过，如果一个方法的实现对于所有类型都相同，则使用类型参数；相反，如果每种类型的实现各不相同，请使用不同的方法，不要使用类型参数。例如，从文件读取的实现与从随机数生成器读取的实现完全不同。这意味着我们要编写两种不同的读取方法，并且两种方法都不应使用类型参数。

虽然我今天仅提到了几次，Go也有反射。反射确实允许进行某种通用编程，它允许你编写适用于任何类型的代码。如果某些操作必须支持甚至没有方法的类型，那么接口类型便不起作用。并且如果每种类型的操作都不同，请使用反射。这方面的一个典型例子是json编码包。我们不要求我们编码的每个类型都支持MarshalJSON方法，因此我们不能使用接口类型。但是对整数类型进行编码与对结构类型进行编码完全不同，因此我们不应该使用类型参数。json包使用的是反射。相关代码太复杂，这里就不展示了。如果你有兴趣，可以查看go源码。

一个简单的准则

最后，整个talk可总结为一条简单的准则，如果你发现自己多次编写完全相同的代码(样板代码)，各个版本之间唯一的差别是代码使用不同的类型，请考虑是否可以使用类型参数。换一种表达方法，在你注意到自己要多次编写完全相同的代码之前，应该避免使用类型参数。

感谢聆听。希望你在泛型特性推出后，能谨慎合理的使用go泛型。

“Gopher部落”知识星球正式转正（从试运营星球变成了正式星球）！“gopher部落”旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！部落目前虽小，但持续力很强，欢迎大家加入！

img{512x368}

我爱发短信：企业级短信平台定制开发专家 https://tonybai.com/。smspush : 可部署在企业内部的定制化短信平台，三网覆盖，不惧大并发接入，可定制扩展；短信内容你来定，不再受约束, 接口丰富，支持长短信，签名可选。2020年4月8日，中国三大电信运营商联合发布《5G消息白皮书》，51短信平台也会全新升级到“51商用消息平台”，全面支持5G RCS消息。

著名云主机服务厂商DigitalOcean发布最新的主机计划，入门级Droplet配置升级为：1 core CPU、1G内存、25G高速SSD，价格5$/月。有使用DigitalOcean需求的朋友，可以打开这个链接地址：https://m.do.co/c/bff6eed92687 开启你的DO主机之路。

Gopher Daily(Gopher每日新闻)归档仓库 – https://github.com/bigwhite/gopherdaily

我的联系方式：

微博：https://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite
“Gopher部落”知识星球：https://public.zsxq.com/groups/51284458844544

微信赞赏：
img{512x368}

商务合作方式：撰稿、出书、培训、在线课程、合伙创业、咨询、广告合作。

Go 1.17新特性详解：使用基于寄存器的调用惯例

八月 20, 2021
0 条评论

本文永久链接 – https://tonybai.com/2021/08/20/using-register-based-calling-convention-in-go-1-17

除了Go语言特性与go module有重要变化之外，Go编译器与Go运行时也都有着优化与改进，这两方面的变化对Go程序的构建与运行影响巨大。在这个系列的最后一篇中，我们来看看编译器与运行时中那些值得关注的变化。

1. 使用基于寄存器的调用惯例替代基于堆栈的调用惯例

所谓“调用惯例(calling convention)”是调用方和被调用方对于函数调用的一个明确的约定，包括：函数参数与返回值的传递方式、传递顺序。只有双方都遵守同样的约定，函数才能被正确地调用和执行。如果不遵守这个约定，函数将无法正确执行。

Go 1.17版本之前，Go采用基于栈的调用约定，即函数的参数与返回值都通过栈来传递，这种方式的优点是实现简单，不用担心底层cpu架构寄存器的差异，适合跨平台；但缺点就是牺牲了一些性能，我们都知道寄存器的访问速度要远高于内存。

大多数平台上的大多数语言实现都使用基于寄存器的调用约定，通过寄存器而不是内存传递函数参数和返回结果，并指定一些寄存器为调用保存寄存器，允许函数在不同的调用中保持状态。

于是Go在1.17版本决定向这些语言看齐，在amd64架构下率先实现了从基于堆栈的调用惯例到基于寄存器的调用惯例的切换。

在Go 1.17的版本发布说明文档中有提到：切换到基于寄存器的调用惯例后，一组有代表性的Go包和程序的基准测试显示，Go程序的运行性能提高了约5%，二进制文件大小典型减少约2%。

我们来实测一下，下面采用的是之前进阶专栏中的一个多种方法进行字符串连接的benchmark测试，在Go 1.16.5和Go 1.17下面分别运行Benchmark结果如下：

Go 1.16.5：

$go test -bench .
goos: darwin
goarch: amd64
pkg: github.com/bigwhite/demo
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkConcatStringByOperator-8                       12132355            91.51 ns/op
BenchmarkConcatStringBySprintf-8                         2707862           445.1 ns/op
BenchmarkConcatStringByJoin-8                           24101215            50.84 ns/op
BenchmarkConcatStringByStringsBuilder-8                 11104750           124.4 ns/op
BenchmarkConcatStringByStringsBuilderWithInitSize-8     24542085            48.24 ns/op
BenchmarkConcatStringByBytesBuffer-8                    14425054            77.73 ns/op
BenchmarkConcatStringByBytesBufferWithInitSize-8        20863174            49.07 ns/op
PASS
ok      github.com/bigwhite/demo    9.166s

Go 1.17：

$go test -bench .
goos: darwin
goarch: amd64
pkg: github.com/bigwhite/demo
cpu: Intel(R) Core(TM) i5-8257U CPU @ 1.40GHz
BenchmarkConcatStringByOperator-8                       13058850            89.47 ns/op
BenchmarkConcatStringBySprintf-8                         2889898           410.1 ns/op
BenchmarkConcatStringByJoin-8                           25469310            47.15 ns/op
BenchmarkConcatStringByStringsBuilder-8                 13064298            92.33 ns/op
BenchmarkConcatStringByStringsBuilderWithInitSize-8     29780911            41.14 ns/op
BenchmarkConcatStringByBytesBuffer-8                    16900072            70.28 ns/op
BenchmarkConcatStringByBytesBufferWithInitSize-8        27310650            43.96 ns/op
PASS
ok      github.com/bigwhite/demo    9.198s

我们看到，相对于Go 1.16.5跑出的结果，Go 1.17在每一个测试项上都有小幅的性能提升，有些性能提升甚至达到10%左右。这种新版本带来的性能的“自然提升”显然是广大Gopher想看到的。

我们再来看看编译后的Go二进制文件的Size变化。以一个自有的1w行左右代码的Go程序为例，分别用Go 1.16.5和Go 1.17进行编译，得到的结果如下：

-rwxr-xr-x   1 tonybai  staff  7264432  8 13 18:31 myapp-go1.16.5*
-rwxr-xr-x   1 tonybai  staff  6934352  8 13 18:32 myapp-go1.17*

我们看到Go 1.17编译后的二进制文件大小相较于Go 1.16.5版本的减少了约4%。

另外Go 1.17发布说明也提到了：改为基于register的调用惯例后，绝大多数程序不会受到影响。只有那些之前就已经违反unsafe.Pointer的使用规则的代码可能会受到影响，比如不遵守unsafe规则通过unsafe.Pointer访问函数参数，或依赖一些像比较函数代码指针的未公开的行为。

除了改为基于寄存器的调用惯例之外，Go 1.17编译器还支持包含闭包的函数的内联(inline)了！这样一来，一个带有闭包的函数可能会在函数被内联的每个地方产生一个不同的闭包代码指针，因此，Go函数的值不能直接比较！

2. 引入//go:build形式的构建约束指示符，以替代原先易错的// +build形式

Go 1.17之前，我们可以通过在源码文件头部放置+build构建约束指示符来实现构建约束，但这种形式十分易错，并且它并不支持&&和||这样的直观的逻辑操作符，而是用逗号、空格替代，下面是原+build形式构建约束指示符的用法及含义：

这种与程序员直觉“有悖”的形式让Gopher们十分痛苦，于是Go 1.17回归“正规”，引入了//go:build形式的构建约束指示符，这样一方面是与源文件中的其他指示符保持形式一致，比如: //go:nosplit、//go:norace、//go:noinline、//go:generate等。另外一方面，新形式将支持&&和||逻辑操作符，对于程序员来说，这样的形式就是自解释的，我们无需再像上面那样列出一个表来解释每个指示符组合的含义了，如下代码所示：

//go:build linux && (386 || amd64 || arm || arm64 || mips64 || mips64le || ppc64 || ppc64le)
//go:build linux && (mips64 || mips64le)
//go:build linux && (ppc64 || ppc64le)
//go:build linux && !386 && !arm

考虑到兼容性，Go命令可以识别这两种形式的构建约束指示符，但推荐Go 1.17之后都用新引入的这种形式。

gofmt可以兼容处理两种形式，处理原则是：如果一个源码文件只有// +build形式的指示符，gofmt会将与其等价的//go:build行加入。否则，如果一个源文件中同时存在这两种形式的指示符行，那么//+build行的信息将被//go:build行的信息所覆盖。

go vet工具也会检测源文件中同时存在的不同形式的构建指示符语义不一致的情况，比如针对下面这段代码：

// github.com/bigwhite/experiments/tree/master/go1.17-examples/runtime/buildtag.go

//go:build linux && !386 && !arm
// +build linux

package main

import "fmt"

func main() {
    fmt.Println("hello, world")
}

go vet会提示如下问题：

./buildtag.go:2:1: +build lines do not match //go:build condition

3. 运行时栈跟踪输出信息的格式更“可读”

之前写过一篇文章《记一次go panic问题的解决过程》，在那篇文章中，我们探讨了如何解读panic发生后输出的函数栈跟踪信息。

下面的代码示例用于对比运行时栈输出信息的差异：

// github.com/bigwhite/experiments/tree/master/go1.17-examples/runtime/stacktrace.go

package main

type myStruct struct {
    m int
    s string
    p *float64
}

func foo(a int, b string, c []byte, f *myStruct) (int, error) {
    panic("mypanic")
}

func main() {
    f := 3.14
    ms := myStruct{
        m: 17,
        s: "myStruct",
        p: &f,
    }
    a := 11
    b := "hello"
    c := []byte{'a', 'b', 'c'}
    foo(a, b, c, &ms)
}

在这个示例程序中，我们在foo函数中“故意”panic，以便go运行时在程序退出前输出栈跟踪信息（注意编译时关闭内联优化）。针对这个示例程序，Go 1.17之前的版本输出的栈跟踪信息是这样的(go 1.16.5版本):

$go build -gcflags '-N -l' -o stacktrace-go1.16.5 stacktrace.go
$./stacktrace-go1.16.5
panic: mypanic

goroutine 1 [running]:
main.foo(0xb, 0x1073f53, 0x5, 0xc000046715, 0x3, 0x3, 0xc000046758, 0x0, 0x0, 0x0)
    /Users/tonybai/Go/src/github.com/bigwhite/experiments/go1.17-examples/runtime/stacktrace.go:10 +0x4a
main.main()
    /Users/tonybai/Go/src/github.com/bigwhite/experiments/go1.17-examples/runtime/stacktrace.go:23 +0x148

上面输出信息中foo函数后面括号中的各个值与foo函数原型完全对不上。要想知道这些数值的含义究竟是什么，可以参考我上面提到的那篇文章，这里不赘述。

使用Go 1.17版本编译后会是什么样子呢？我们再来看一下：

go 1.17:

$go build -gcflags '-N -l' -o stacktrace-go1.17 stacktrace.go
$./stacktrace
panic: mypanic

goroutine 1 [running]:
main.foo(0xb, {0x10608d4, 0x5}, {0xc00004270d, 0x3, 0x3}, 0xc000042750)
    /Users/tonybai/Go/src/github.com/bigwhite/experiments/go1.17-examples/runtime/stacktrace.go:10 +0x59
main.main()
    /Users/tonybai/Go/src/github.com/bigwhite/experiments/go1.17-examples/runtime/stacktrace.go:23 +0x10f

对照着该示例程序中foo函数的原型：

func foo(a int, b string, c []byte, f *myStruct) (int, error)

这回一目了然了！我们看到Go 1.17改进了当发送未捕获的panic或当runtime.Stack被调动时，运行时输出的栈跟踪信息的格式。Go 1.17版本之前，函数参数被打印成基于内存布局的十六进制值的形式，就像前面那个难于解读的输出信息。Go 1.17版，源码中函数的每个参数都被单独打印，用逗号分隔。聚合类型（结构体、数组、字符串、切片、接口和complex）的参数用大括号分隔。需要注意的是，只存在于寄存器中而没有存储到内存中的参数的值可能是不准确的。函数的返回值（通常是不准确的）不再被打印了。

通过上的输出，我们还可以清晰的看到string、byte切片以及结构体在内存中的表示方式，string本质上是一个拥有两个字段的结构，而切片则是一个三元组表示的结构。