Slice | Tony Bai

标签 Slice 下的文章

Go 1.21新特性前瞻

四月 26, 2023
0 条评论

本文永久链接 – https://tonybai.com/2023/04/26/go-1-21-foresight

Go 1.21版本正在如火如荼地开发当中，按照Go核心团队的一年两次的发布节奏来算，Go 1.21版本预计将在2023年8月发布(Go 1.20版本是在2023年2月份发布的)。

本文将和大家一起看看Go 1.21都会带来哪些新特性。不过由于目前为时尚早，下面列出的有些变化最终不一定能进入到Go 1.21的最终版本中，所以切记一切变更要以最终Go 1.21版本发布时为准。

在细数变化之前，我们先来看看Go语言的当前状态。

1. Go语言当前状态

在《2022年Go语言盘点》一文中，我们提到年初Go语言的2022年终排名为12位，同时TIOBE官方编辑也提到：“在新兴编程语言中，Go是唯一一个可能在未来冲入前十的后端编程语言”。Go语言的发展似乎应验了这一预测，在今年的3月份，Go就再次进入编程语言排行榜前十：

一个月后的四月初，TIOBE排行榜上，Go稳住了第10名的位次：

在国内，在鹅厂前不久发布的《2022年腾讯研发大数据报告》中，

在国内，继Go在2021年从C++手中夺过红旗首次登顶鹅厂最热门编程语言之后，在鹅厂前不久发布的《2022年腾讯研发大数据报告》中，Go蝉联鹅厂最热门编程语言，继续夯实在国内头部互联网公司内的优势地位：

Go于2009年开源，在经历多年的宣传和鼓吹后，Go目前进入了平稳发展的阶段。疫情结束后，原先线上举办或取消的国内外的Go技术大会现在陆续又都开始恢复了，相信这会让更多开发人员接触到Go。像Go这样的能在世界各地持续多年举办技术大会的语言真是不多了。

接下来，我们就来聚焦到Go 1.21版本，挖掘一下这个版本都有哪些新特性。

2. 语言变化

目前Go 1.21版本里程碑中涉及语言变化的有大约2项，我们来看看。

2.1 增加clear预定义函数

Go 1.21增加了一个clear预定义函数用来做切片和map的clear操作，其原型如下：

// $GOROOT/src/builtin.go

// The clear built-in function clears maps and slices.
// For maps, clear deletes all entries, resulting in an empty map.
// For slices, clear sets all elements up to the length of the slice
// to the zero value of the respective element type. If the argument
// type is a type parameter, the type parameter's type set must
// contain only map or slice types, and clear performs the operation
// implied by the type argument.
func clear[T ~[]Type | ~map[Type]Type1](t T)

clear是针对map和slice的操作函数，它的语义是什么呢？我们通过一个例子来看一下：

package main

import "fmt"

func main() {
    var sl = []int{1, 2, 3, 4, 5, 6}
    fmt.Printf("before clear, sl=%v, len(sl)=%d, cap(sl)=%d\n", sl, len(sl), cap(sl))
    clear(sl)
    fmt.Printf("after clear, sl=%v, len(sl)=%d, cap(sl)=%d\n", sl, len(sl), cap(sl))

    var m = map[string]int{
        "tony": 13,
        "tom":  14,
        "amy":  15,
    }
    fmt.Printf("before clear, m=%v, len(m)=%d\n", m, len(m))
    clear(m)
    fmt.Printf("after clear, m=%v, len(m)=%d\n", m, len(m))
}

运行该程序：

before clear, sl=[1 2 3 4 5 6], len(sl)=6, cap(sl)=6
after clear, sl=[0 0 0 0 0 0], len(sl)=6, cap(sl)=6
before clear, m=map[amy:15 tom:14 tony:13], len(m)=3
after clear, m=map[], len(m)=0

我们看到：

针对slice，clear保持slice的长度和容量，但将所有slice内已存在的元素(len个)都置为元素类型的零值；
针对map，clear则是清空所有map的键值对，clear后，我们将得到一个empty map。

2.2 改变panic(nil)语义

使用defer+recover捕获panic是Go语言唯一处理panic的方法，其典型模式如下：

package main

import "fmt"

func foo() {
    defer func() {
        if err := recover(); err != nil {
            fmt.Printf("panicked: %v\n", err)
            return
        }
        fmt.Println("it's ok")
    }()

    panic("some error")
}

func main() {
    foo()
}

运行上面程序会输出：

panicked: some error

例子中我们向panic传入了表示panic原因的字符串，panic的参数是一个interface{}类型，可以传入任意值，当然也可以传入nil。

比如上面例子，当我们给foo函数的panic调用传入nil时，我们将得到下面结果：

it's ok

这可能会给开发者带去疑惑：明明是触发了panic，但函数却按照正常逻辑处理！2018年，前Go核心团队成员bradfitz就提出了一个issue：spec: guarantee non-nil return value from recover，提出当开发者调用panic(nil)时，recover应该返回某种runtime error，而不是nil。这个issue在今年被纳入了Go 1.21版本，现在该issue的实现已经被merge到了主干。

新的实现在src/runtime/panic.go中定义了一个名为PanicNilError的新Error：

// $GOROOT/src/runtime/panic.go

// A PanicNilError happens when code calls panic(nil).
//
// Before Go 1.21, programs that called panic(nil) observed recover returning nil.
// Starting in Go 1.21, programs that call panic(nil) observe recover returning a *PanicNilError.
// Programs can change back to the old behavior by setting GODEBUG=panicnil=1.
type PanicNilError struct {
    // This field makes PanicNilError structurally different from
    // any other struct in this package, and the _ makes it different
    // from any struct in other packages too.
    // This avoids any accidental conversions being possible
    // between this struct and some other struct sharing the same fields,
    // like happened in go.dev/issue/56603.
    _ [0]*PanicNilError
}

func (*PanicNilError) Error() string { return "panic called with nil argument" }
func (*PanicNilError) RuntimeError() {}

Go编译器会将panic(nil)替换为panic(new(runtime.PanicNilError))，这样我们用Go 1.21版本运行上面的程序，我们就会得到下面结果了：

panicked: panic called with nil argument

如果你的遗留代码中调用了panic(nil)(注：显然这不是一种很idiomatic的作法)，升级到Go 1.21版本后你就要小心了。如果你想保留原先的panic(nil)行为，可以用GODEBUG=panicnil=1。

有童鞋可能会质疑这违反了Go1兼容性承诺，但实际上Go1兼容性规范保留了对语言规范中不一致或错误的修订权力，即便这种修订会导致遗留代码出现与原先不一致的行为。

3. 编译器与工具链

每个Go版本中，编译器和工具链的改动都不少，我们挑重点看一下：

3.1 一些OS的最小支持版本的更新

Go 1.21开始，go installer支持最小macOS版本更新为10.15，而最小Windows版本为Windows 10。

3.2 低版本的go编译器将拒绝编译高版本的go module

从Go 1.21版本开始，低版本的go编译器将拒绝编译高版本的go module(go.mod中go version标识最低版本) ，这也是Russ Cox策划的Go扩展的向前兼容性提案的一部分。此外，Go扩展向前兼容性提案感觉比较复杂，可能不会全部在Go 1.21版本落地。

3.3 支持WASI

Go从1.11版本就开始支持将Go源码编译为wasm二进制文件，并在支持wasm的浏览器环境中运行。

不过WebAssembly绝不仅仅被设计为仅限于在Web浏览器中运行，核心的WebAssembly语言是独立于其周围环境的，WebAssembly完全可以通过API与外部世界互动。在Web上，它自然使用浏览器提供的现有Web API。然而，在浏览器之外，之前还没有一套标准的API可以让WebAssembly程序使用。这使得创建真正可移植的非Web WebAssembly程序变得困难。WebAssembly System Interface(WASI)是一个填补这一空白的倡议，它有一套干净的API，可以由多个引擎在多个平台上实现，并且不依赖于浏览器的功能（尽管它们仍然可以在浏览器中运行）。

Go 1.21将增加对WASI的支持，初期先支持WASI Preview1版本，之后会支持WASI Preview2版本，直至最终WASI API版本发布！目前我们可以使用GOOS=wasip1 GOARCH=wasm将Go源码编译为支持WASI的wasm程序，下面是一个例子：

// main.go
package main            

func main() {
    println("hello")
}

下载最新go dev版本后(go install http://golang.org/dl/gotip@latest)，可以执行下面命令将main.go编译为wasm程序：

$ GOARCH=wasm GOOS=wasip1 gotip build -o main.wasm main.go

开源的wasm运行时有很多，wazero是目前比较火的且使用纯Go实现的wasm运行时程序，安装wazero后，可以用来执行上面编译出来的main.wasm：

$curl https://wazero.io/install.sh
$wazero run main.wasm
hello

3.4 Go 1.21可能推出纯静态工具链，不再依赖glibc

使用纯Go实现的net resolver，原先DNS的问题也将被解决，这样Go团队很可能在构建工具链的时候使用CGO_ENABLED=0构建出静态工具链，没有动态链接库的依赖。

3.5 go test -c支持为多个包同时构建测试二进制程序

Go 1.21版本之前，go test -c仅支持将单个包的测试代码编译为测试二进制程序，Go 1.21版本则允许我们同时为多个包构建测试二进制程序。

下面是官方给出的例子：

$ go test -c -o /tmp ./pkg1 ./pkg2 ./pkg2
$ ls /tmp
pkg1.test pkg2.test pkg3.test

3.6 增加\$GOROOT/go.env

今天使用go env -w命令修改的默认环境变量会写入：filepath.Join(os.UserConfigDir(), “go/env”)。在Mac上，这个路径是\$HOME/Library/Application Support/go/env；在Linux上，这个路径是\$HOME/.config/go/env。

Go 1.21将增加一个全局层次上的go.env，放在\$GOROOT下面，目前默认的go.env为：

// $GOROOT/go.env

# This file contains the initial defaults for go command configuration.
# Values set by 'go env -w' and written to the user's go/env file override these.
# The environment overrides everything else.

# Use the Go module mirror and checksum database by default.
# See https://proxy.golang.org for details.
GOPROXY=https://proxy.golang.org,direct
GOSUMDB=sum.golang.org

我们仍然可以通过go env -w命令修改user级的env文件来覆盖上述配置，当然最高优先级的是OS用户环境变量，如果在OS用户环境变量文件(比如.bash_profile、.bashrc)中设置了Go的环境变量值，比如GOPROXY等，那么以OS用户环境变量为优先。

4. 标准库

我们接下来再来看看变更最多的一部分：标准库，我们将对主要变更项作简要介绍。

4.1 slices和maps进入标准库

Go 1.18版本泛型落地发布前的最后一刻，Rob Pike叫停了slices、maps等泛型包的入库，后来这两个包先放置在golang.org/x/exp下作为实验包。随着Go泛型日益成熟以及Go团队对泛型使用经验的增多，Go团队终于决定将golang.org/x/exp/slices和golang.org/x/exp/maps在Go 1.21版本中将挪入标准库。

4.2 log/slog加入标准库

log/slog是Go官方版结构化日志包，大致与uber的zap包相当。在我之前的一篇文章《slog：Go官方版结构化日志包》有对slog的详尽说明，大家可以移步到那篇文章看看。不过slog的proposal依旧很多，后续slog可能会有持续改进和变更，与那篇文章中的内容可能会有一些差异。

4.3 sync包增加OnceFunc、OnceValue和OnceValues

在sync.Once的基础上，这个issue增加了三个与Once相关的”语法糖”API，用在一些对Once有需求的最常见的场景中。

4.4 增加testing.Testing函数

Go 1.21为testing包增加了func Testing() bool函数，该函数可以用来报告当前程序是否是go test创建的测试程序。使用Testing函数，我们可以确保一些无需在单测阶段执行的函数不被执行。比如下面例子来自这个issue：

// file/that/should/not/be/used/from/testing.go

func prodEnvironmentData() *Environment {
    if testing.Testing() {
        log.Fatal("Using production data in unit tests")
    }
    ....
}

4.5 一些变更点

context: 增加为deadline或timeout context设置cancel原因的API – https://github.com/golang/go/issues/56661
unicode升级到15.0版本 – https://github.com/golang/go/issues/55079

5. 参考资料

Go 1.21 milestone – https://github.com/golang/go/milestone/279

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2023年，Gopher部落将进一步聚焦于如何编写雅、地道、可读、可测试的Go代码，关注代码质量并深入理解Go核心技术，并继续加强与星友的互动。欢迎大家加入！

img{512x368}

著名云主机服务厂商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
微博2：https://weibo.com/u/6484441286
博客：tonybai.com
github: https://github.com/bigwhite

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

一文告诉你哪些map element类型支持就地更新

四月 2, 2023
0 条评论

本文永久链接 – https://tonybai.com/2023/04/02/map-element-types-support-in-place-update

年初，我代表团队和人民邮电出版社签订了翻译《Go Fundamentals》一书的合同，本月底便是四分之一进度的交稿时间点，近期闲时我们都在忙着做交叉review。

上周末我review小伙伴翻译的有关map类型的章节时，看到了书中对map element就地更新的讲解。Mark Bates和Cory LaNou的这本书属于入门级Go语言书，只是举例说明了一些支持就地更新的map element类型以及不能就地更新的典型类型，但对不能更新的原因并未做深入说明。我觉得这个知识点不错，借这篇文章系统梳理一下。

一. 什么是map element的就地更新(in-place update)

我们知道Go中的map类型是一种无序的键值对集合，它的内部实现是基于哈希表的，支持高效地进行插入、查找和删除操作。map的key必须是可以进行相等比较的类型，比如整数、字符串、指针等，而element(也称为value)则可以是任意类型。并且，map是引用类型，它的零值为nil，使用前需要先使用内置函数make或map类型字面值进行空间分配。此外，在使用map时还需要注意并发安全问题，可以使用sync包提供的同步原语中来实现map的并发安全。

更多关于map的入门介绍与原理说明，可以阅读我的极客时间专栏《Go语言第一课》的第16讲。

下面我们就来声明一个简单的map类型变量：

m := map[string]int{}

m是一个键为string类型、element为int类型的map。我们可以通过下面代码向map中插入一个键值对：

m["boy"] = 0

我们可以将其想象为一个统计班里男孩子数量的计数器：每数到一个男孩，我们就可以将其加1：

n := m["boy"]
n++
m["boy"] = n

你可以看到上述代码更新了键”boy”对应的element值(+1)。不过这种方法比较繁琐，要更新键”boy”对应的element值，我们还有下面这个更为简洁的方法：

m["boy"]++

我们看到和前面一种方法相比，这种方法没有引入额外的变量(比如前面的变量n)，而是直接在map element上进行了更新的操作，这种方法就称为map element的“就地更新”。

下面还有一些支持“就地更新”的map element类型的例子，比如：string、切片等：

m["boy"] += 1

// element类型为string
m1 := map[int]string{
    1 : "hello",
    2 : "bye",
} // map[1:hello 2:bye]

m1[1] += ", world" // map[1:hello, world 2:bye]

// element类型为切片
m2 := map[string][]int{
    "k1": {1, 2},
    "k2": {3, 4},
} // map[k1:[1 2] k2:[3 4]]
m2["k1"][0] = 11 // map[k1:[11 2] k2:[3 4]]

不过并非所有类型都支持“就地更新”，比如下面的数组与结构体作为map element类型时就会导致编译错误：

m3 := map[int][10]int{
    1 : {1,2,3,4,5,6,7,8,9,10},
}
m3[1][0] = 11 // 编译错误：cannot assign to m3[1][0] (value of type int)

type P struct {
    a int
    b float64
}

m4 := map[int]P {
    1 : {1, 3.14},
    2 : {2, 6.28},
}
m4[1].a = 11 // 编译错误：cannot assign to struct field m4[1].a in map

那么为什么会这样呢？为什么同样作为map element，有的类型可以就地更新，有的类型就不支持呢？我们继续向下看。

二. element类型支持就地更新的本质

支持element类型就地更新这种“语法糖”在实际编写代码中体验还是非常好的，避免了下面这种“三行”冗余代码：

a := m["boy"]
a++
m["boy"] = a

那么，Go究竟是如何实现“就地更新”的呢？我们还以以上面的m变量为例：

m := map[string]int{
    "boy" : 0,
    "girl" : 0,
}

当我们执行下面的就地更新语句时：

m["boy"]++

我们来看一下底层的汇编是啥样的：

汇编语句不是很好懂，不过我们仅关注一下重点。我们看到汇编调用了runtime.mapassign_faststr这个函数，该函数的语义就是通过传入的key，找到对应的element，并将element的地址传出来。这里element的地址放入了AX寄存器中；接下来我们看到汇编调用INCQ指令将AX寄存器指向的内存块中的数据做了加1操作，从而实现了m["boy"]++这个语句的语义。

如果用伪代码来表示这个过程大致是这样的：

// 伪代码，下面的代码无法通过go编译，go在语法层面不支持获取map element的地址

p := &m["boy"]
(*p)++

到这里小伙伴们可能会问：为什么Go不针对类型为struct和array的element提供这种语法糖呢？我们假设struct的字段更新也支持就地更新，那么会发生什么呢？

type P struct {
    a int
    b float64
}

m4 := map[int]P {
    1 : {1, 3.14},
    2 : {2, 6.28},
}
m4[1].a = 11

上面的m4[1].a = 11将等价于如下代码：

t := &(m4[1])
t.a = 11

我们看到与element类型为int或string不同，由于要更新struct内部的字段，我们这次必须获取element的地址。一旦可以获取地址，问题就来了！这个地址是map在runtime层维护的内存地址，一旦暴露出来至少会有如下两个问题：

并发访问时会导致该element数据的竞争问题；
map自动扩容后，element地址会变更，通过上述代码获取的地址可能变为无效。

当然第二点更为重要，也正是因为这个原因，Go决定不支持对map的element取地址。

不过这似乎也并非是什么不可逾越的“鸿沟”，在runtime层面，element地址还是可以拿到的，就像前面的map[string]int那样。但目前Go团队依旧没有松口，在Go issue 3117中，Go团队一直跟踪着上述结构体类型作为map element时不能就地更新的问题。该issue并没有close，说明也许未来Go针对这样的行为的处理可能会发生变化。

那是否可以用整体替换的三行代码方案来提供针对struct和array类型的element就地更新语法糖呢？以struct为例：

m4[1].a = 11 

<=>

t := m4[1]
t.a = 11
m4[1] = t

即将struct和array作为一个整体，从map中获取副本，然后在临时变量中更新后，再重新覆盖map中的element。

go为什么不提供这种“语法糖”呢？我猜是因为这么做的性能开销较大！struct可以聚合很多字段，array的size也可能很可观，这样的两次copy的开销可能是Go开发者比较顾忌的。

那么目前的替代方案是什么呢? 其实很简单，那就是element类型使用指针类型，比如下面element类型为结构体指针类型的代码：

type P struct {
    a int
    b float64
}

m := map[int]*P{
    1: {1, 3.14},
    2: {2, 6.28},
}
fmt.Println(m[1]) // &{1 3.14}

m[1].a = 11

fmt.Println(m[1]) // &{11 3.14}

再比如element类型为数组指针类型的代码：

m1 := map[int]*[10]int{
    1: {1, 2, 3},
}
fmt.Println(m1[1]) // &[1 2 3 0 0 0 0 0 0 0]
m1[1][0] = 11
fmt.Println(m1[1]) // &[11 2 3 0 0 0 0 0 0 0]

对map element“就地更新”的限制也会影响到是否能调用element类型的相关方法，我们再来看下面例子：

type P struct {
    a int
    b float64
}

func (P) normalFunc() {
}

func (p *P) updateInPlace(a int) {
    p.a = a
}

func main() {

    m1 := map[int]P{
        1: {1, 3.14},
        2: {2, 6.28},
    }
    m1[1].normalFunc()
    m1[1].updateInPlace(11) // 编译错误：cannot call pointer method updateInPlace on P

    m2 := map[int]*P{
        1: {1, 3.14},
        2: {2, 6.28},
    }
    fmt.Println(m2[1].a) // 1
    m2[1].normalFunc()
    m2[1].updateInPlace(11)
    fmt.Println(m2[1].a) // 11
}

我们看到当element类型为P时，我们无法通过语法糖来调用会对结构体字段进行修改的updateInPlace方法，但可以调用normalFunc。而当element类型为P指针类型时，则无此限制。

那么，我们究竟如何判断哪些类型支持就地更新，哪些不支持呢？我们接下来就来说说。

三. 梳理与小结

我们最后来梳理一下Go的主要类型是否支持就地更新。

不涉及就地更新的类型

当element类型为布尔类型、函数类型时，我没找出针对这些map element就地更新的写法。

注：函数在Go中是一等公民。

Go原生的基本类型，比如整型、浮点型、complex类型、string类型等

当这些类型作为map element类型时，它们和整型一样，支持元素的就地更新，其原理与上面的map[string]int也是类似的：

// 整型
m1 := map[int]int{
    1: 1,
}
m1[1]++
fmt.Println(m1[1]) // 2

// 浮点型
m3 := map[int]float64{
    1: 3.14,
}
m3[1]++
fmt.Println(m3[1]) // 4.140000000000001

// complex类型
m4 := map[int]complex128{
    1: complex(2, 3), // 2+3i
}
m4[1]++
fmt.Println(m4[1]) // 3+3i

// string类型
m5 := map[int]string{
    1: "hello",
}
m5[1] += " world"
fmt.Println(m5[1]) // hello world

对于指针、map、channel等类型

通过前面的讲解，我们知道使用指针作为map element类型是支持就地更新的，这里就不重复举例了。

map类型自身在Go运行时表示中也是一个指针，它也是支持就地更新的：

m := map[int]map[int]string{
    1: {1: "hello"},
}
m[1][1] += " world"
fmt.Println(m[1][1]) // hello world

关于channel类型，如果将向channel写入数据当作“就地更新”的话，那么channel也勉强算是支持：

// channel
m1 := map[int]chan int{
    1: make(chan int),
}
go func() {
    m1[1] <- 11
}()

fmt.Println(<-m1[1]) // 11

对于切片、接口类型

通过前面的讲解，我们知道使用切片作为map element类型是支持就地更新的，这里就不重复举例了。

而对于接口类型，我理解的就地更新场景有两种，一种是通过接口值调用动态类型的方法，一种则是通过type assert来修改某些值。下面这两个场景的示例代码：

type MyInterface interface {
    normalFunc()
    updateInPlace(a int)
}

type P struct {
    a int
    b float64
}

func (P) normalFunc() {
}

func (p *P) updateInPlace(a int) {
    p.a = a
}

func main() {
    // interface
    m1 := map[int]MyInterface{
        1: &P{1, 3.14},
    }

    m1[1].updateInPlace(11) // 场景1：调用就地更新的方法

    p := m1[1].(*P)
    fmt.Println(p.a) // 11

    (m1[1].(*P)).a = 21     // 场景2：通过type assert设置值
    p = m1[1].(*P)
    fmt.Println(p.a) // 21
}

对于数组、struct类型

通过前面的讲解，我们知道使用数组和struct类型作为map element类型是不支持就地更新的，这里就不重复举例了。

综上，目前只有当数组和结构体类型作为map元素类型时是不支持就地更新的。不过这种限制不一定一直持续下去，毕竟就地更新这种“语法糖”在编码过程中很好用，让代码变得更加简洁，也更加高效。后面Go团队可能会修改Go编译器以及运行时，让这种“语法糖”适用于所有类型。