ToB企服应用市场:ToB评测及商务社交产业平台

标题: golang1.21新特性速览 [打印本页]
作者: 吴旭华    时间: 2023-8-9 22:20
标题: golang1.21新特性速览
经过了半年左右的开发，golang 1.21 在今天早上正式发布了。
这个版本中有不少重要的新特性和变更，尤其是在泛型相关的代码上。
因为有不少大变动，所以建议等第一个patch版本也就是1.21.1出来之后再进行升级，以免遇到一些意外的bug带来麻烦。
好了，一起来看看1.21带来的新特性吧。
  本文索引

  
新的内置函数

1.21添加了三个新的内置函数：min、max和clear。
min、max如其字面意思，用了选出一组变量里（数量大于等于1，只有一个变量的时候就返回那个变量的值）最大的或者最小的值。两个函数定义是这样的：
  1. func min[T cmp.Ordered](x T, y ...T) T
  2. func max[T cmp.Ordered](x T, y ...T) T
复制代码
注意那个类型约束，这是新的标准库里提供的，原型如下：
  1. type Ordered interface {
  2.     ~int | ~int8 | ~int16 | ~int32 | ~int64 |
  3.     ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr |
  4.     ~float32 | ~float64 |
  5.     ~string
  6. }
复制代码
也就是说只有基于所有除了map，chan，slice以及复数之外的基本类型的变量才能使用这两个函数。或者换句话说，只有可以使用、=、==和!=进行比较的类型才可以使用min和max。
有了min和max，可以把许多自己手写的代码替换成新的内置函数，可以少写一些帮助函数。而且使用新的内置函数还有一个好处，在变量个数比较少的时候还有编译器的优化可用，比自己写min函数性能上要稍好一些。
使用上也很简单：
  1. numbers := []int{7, 6, 5, 4, 3, 2, 1}
  2. maxIntValue := max(0, numbers...) // 7 type int
  3. minIntValue := min(8, numbers...) // 1 type int
复制代码
对于clear来说事情比min和max复杂。clear只接受slice和map，如果是对泛型的类型参数使用clear，那么类型参数的type set必须是map或者slice，否则编译报错。
clear的定义如下：
  1. func clear[T ~[]Type | ~map[Type]Type1](t T)
复制代码
对于参数是map的情况，clear会删除所有map里的元素（不过由于golang的map本身的特性，map存储的数据会被正常销毁，但map已经分配的空间不会释放）：
  1. func main() {
  2.         m := map[int]int{1:1, 2:2, 3:3, 4:4, 5:5}
  3.         fmt.Println(len(m))  // 5
  4.         clear(m)
  5.         fmt.Println(len(m))  // 0
  6. }
复制代码
燃而对于slice，它的行为又不同了：会把slice里所有元素变回零值。看个例子：
  1. func main() {
  2.         s := make([]int, 0, 100) // 故意给个大的cap便于观察
  3.         s = append(s, []int{1, 2, 3, 4, 5}...)
  4.         fmt.Println(s) // [1 2 3 4 5]
  5.         fmt.Println(len(s), cap(s)) // len: 5; cap: 100
  6.         clear(s)
  7.         fmt.Println(s) // [0 0 0 0 0]
  8.         fmt.Println(len(s), cap(s)) // len: 5; cap: 100
  9. }
复制代码
这个就比较反直觉了，毕竟clear首先想到的应该是把所有元素删除。那它的意义是什么呢？对于map来说意义是很明确的，但对于slice来说就有点绕弯了：
slice的真实大小是cap所显示的那个大小，如果只是用s := s[:0]来把所有元素“删除”，那么这些元素实际上还是留在内存里的，直到s本身被gc回收或者往s里添加新元素把之前的对象覆盖掉，否则这些对象是不会被回收掉的，这一方面可以提高内存的利用率，另一方面也会带来泄露的问题（比如存储的是指针类型或者包含指针类型的值的时候，因为指针还存在，所以被指向的对象始终有一个有效的引用导致无法被回收），所以golang选择了折中的办法：把所有已经存在的元素设置成0值
如果想安全的正常删除slice的所有元素，有想复用slice的内存，该怎么办？答案是：
  1. s := make([]T, 0, 100) // 故意给个大的cap便于观察
  2. s = append(s, []T{*new(T), *new(T)}...)
  4. clear(s)
  5. s = s[:0]
复制代码
如果没有内置函数clear，那么我们得自己循环一个个赋值处理。而有clear的好处是，编译器会直接用memset把slice的内存里的数据设置为0，比循环会快很多。有兴趣的可以看看clear在slice上的实现：代码在这 。
类型推导更加智能

其实就是bug修复，以前类似这样的代码在某些情况下没法正常进行推导：
  1. func F[T ~E[], E any](t T, callable func(E))
  3. func generic[E any](e E) {}
  4. F(t, generic) // before go1.21: error; after go1.21: ok
复制代码
理论上只要能推导出E的类型，那么F和generic的所有类型参数都能推导出来，哪怕generic本身是个泛型函数。以前想正常使用就得这么写：F(t, generic[Type])。
所以与其说是新特性，不如说是对类型推导的bug修复。
针对类型推导还有其他一些修复和报错信息的内容优化，但这些都没上面这个变化大，所以恕不赘述。
panic的行为变化

1.21开始如果goroutine里有panic，那么这个goroutine里的defer里调用的recover必然不会返回nil值。
这导致了一个问题：recover的返回值是传给panic的参数的值，panic(nil)这样的代码怎么办？
先要提醒一下，panic(nil)本身是无意义的，且会导致recover的调用方无法判断究竟发生了什么，所以一直是被各类linter包括go vet命令警告的。然而这么写语法上完全正确，所以只有警告并不能解决问题。
解决办法是，如果现在使用panic(nil)或者panic(值为nil的接口)，recover会收到一个新类型的error：*runtime.PanicNilError。
总体上算是解决了问题，然而它把有类型的但值是nil的接口也给转换了，虽然从最佳实践的角度来讲panic一个空值的接口是不应该的，但多少还是会给使用上带来一些麻烦。
所以目前想要禁用这一行为的话，可以设置环境变量：export GODEBUG=panicnil=1。如果go.mod里声明的go版本小于等于1.20，这个环境变量的功能自动启用。
对于modules的变化，会在下一节讲解。
modules的变化

最大的变化是现在mod文件里写的go版本号的意义改变了。
变成了：mod文件里写的go的版本意味着这个mod最低支持的golang版本是多少。
比如：
  1. module github.com/apocelipes/flatmap
  3. go 1.21.0
复制代码
意味着这个modules最低要求go的版本是go1.21.0，而且可以注意到，现在patch版本也算在内里，所以一个声明为go 1.21.1的modules没法被1.21.0版本的go编译。
这么做的好处是能严格控制自己的程序和库可以在哪些版本的golang上运行，且可以推动库版本和golang本身版本的升级。
如果严格按照官方要求使用语义版本来控制自己的modules的话，这个改动没有什么明显的坏处，唯一的缺点是只有1.21及更高版本的go工具链才有这样的功能。
这个变更对go.work文件同样适用。
包初始化顺序的改变

现在按新的顺序来初始化包：
这样做的好处是包的初始化顺序终于有明确的标准化的定义了，坏处有两点：
我们能做的只有遵守最佳实践：不要依赖特定的包直接的初始化顺序；以及在使用某个第三方库前要仔细考量。
编译器和runtime的变化

runtime的变化上，gc一如既往地得到了小幅度优化，现在对于gc压力较大的程序来说gc延迟和内存占用都会有所减少。
cgo也有优化，现在cgo函数调用最大可以比原先快一个数量级。
编译器的变化上比较显著的是这个：PGO已经可以正式投入生产使用。使用教程。
PGO可以带来6%左右的性能提升，1.21凭借PGO和上个版本的优化现在不仅没有了泛型带来的编译速度减低，相比以前还有细微提升。
还有最后一个变化，这个和编译器关系：现在没有被使用的全局的map类型的变量（需要达到一定大小，且初始化的语句中没有任何副作用会产生），现在编译完成的程序里不会在包含这个变量。因为map本身占用内存且初始化需要花费一定时间（map越大花的时间越多）。这个好处是很实在的，既可以减小产生的二进制可执行文件的大小，又可以提升运行性能。但有个缺点，如果有什么程序要依赖编译好的可执行文件内部的某些数据的话，这个变更可能会带来麻烦，普通用户可以忽略这点。
新标准库

这个版本添加了大把的新标准库，一起来看看。
log/slog和testing/slogtest

官方提供的结构化日志库。
可以通过实现slog.Handler来定义自己的日志处理器，可以把日志转换成json等格式。标准库自带了很多预定义的处理器，比如json的：
  1. logger := slog.New(slog.NewJSONHandler(os.Stdout, nil))
  2. logger.Info("hello", "count", 3)
  3. // {"time":"2023-08-09T15:28:26.000000000+09:00","level":"INFO","msg":"hello","count":3}
复制代码
简单得说，就是个简化版的zap，如果想使用最基础的结构化日志的功能，又不想引入zap这样的库，那么slog是个很好的选择。
testing/slogtest里有帮助函数用来测试自己实现的日志处理器是否符合标准库的要求。
slices和maps

把golang.org/x/exp/slices和golang.org/x/exp/maps引入了标准库。
slices库提供了排序、二分查找、拼接、增删改查等常用功能，sort这个标准库目前可以停止使用用slices来替代了。
maps提供了常见的对map的增删改查拼接合并等功能。
两个库使用泛型，且针对golang的slice和map进行了细致入微的优化，性能上比自己写的版本有更多优势，比标准库sort更是有数量级的碾压。
这两个库本来1.20就该被接收进标准库了，但因为需要重新设计api和进行优化，所以拖到1.21了。
cmp

这个也是早该进入标准库的，但拖到了现在。随着slices、maps和新内置函数都进入了新版本，这个库想不接收也不行了。
这个库一共有三个东西：Ordered、Less、Compare。
最重要的是Ordered，它是所有可以使用内置运算符进行比较的类型的集合。
Less和Ordered顾名思义用来比大小的，且只能比Ordered类型的大小。
之所以还有单独造出这两个函数，是因为他们对Nan有检查，比如：
  1. // Less reports whether x is less than y.
  2. // For floating-point types, a NaN is considered less than any non-NaN,
  3. // and -0.0 is not less than (is equal to) 0.0.
  4. func Less[T Ordered](x, y T) bool {
  5.         return (isNaN(x) && !isNaN(y)) || x < y
  6. }
复制代码
所以在泛型函数里不知道要比较的数据的类型是不是有float的时候，用cmp里提供的函数是最安全的。这就是他俩存在的意义。
但如果可以100%确定没有float存在，那么就不应该用Less等，应该直接用运算符去比较，因为大家都看到，Less和直接比较相比效率是较低的。
已有的标准库的变化

因为是速览，所以我只挑重点说。
bytes

bytes.Buffer添加了AvailableBuffer和Available两个方法，分别返回目前可用的buf切片和可用的长度。主要可以配合strconv.AppendInt来使用，直接把数据写入buffer对应的内存里，可以提升性能。不要对AvailableBuffer返回的切片扩容，否则必然踩坑。
context

新的context.WithoutCancel会把原来的context.Context复制一份，并去除cancel函数，这意味着原先被复制的上下文取消了这个新的上下文也将继续存在。例子：
[code]func main() {    ctx, cancel := context.WithCancel(context.Background())    newCtx := context.WithoutCancel(ctx)    cancel()



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4