Tony Bai - Part 84

六月 12, 2022

本文永久链接 – https://tonybai.com/2022/06/12/go-1-19-foresight

美国时间2022年5月7日，Go 1.19版本开发分支进入新特性冻结(freeze)阶段，即只能修Bug，不能再向Go 1.19版本中增加新特性了。由于上一个版本Go 1.18因引入泛型改动较大，推迟了一个月发布，这直接导致了Go 1.19版本的开发周期被缩短。

虽然开发周期少了近一个月，但Go 1.19版本仍然会按计划在2022年8月份发布。而Go 1.19的第一个beta版也于今天凌晨发布了。Go 1.19版本都有哪些重要变化呢，我通过这篇文章带大家先睹为快。

注1：版本特性变化以最终发布为准！
注2：本文仅是前瞻，不会过于深入细节。细节待Go 1.19正式发布后再聊。

泛型问题的fix

尽管Go核心团队在Go 1.18泛型上投入了很多精力，但Go 1.18发布后泛型这块依然有已知的天生局限，以及后续逐渐发现的一些问题，而Go 1.19版本将继续打磨Go泛型，并重点fix Go 1.18中发现的泛型问题。目前Go 1.19开发版本中大约有5-6个泛型问题待解决。之前谈到的可能放开一些泛型约束，在Go 1.19估计不会如期兑现了。

不过可以确定的是Go 1.19将包含Go语法规范中的一处关于泛型的修正，即由下面表述：

The scope of an identifier denoting a type parameter of a function or declared by a method receiver is the function body and all parameter lists of the function.(译文：一个用于表示函数的类型参数或由方法接收器声明的类型参数的标识符的作用域范围包括函数体和函数的所有形式参数列表。)

改为下面更新版的表述：

The scope of an identifier denoting a type parameter of a function or declared by a method receiver starts after the function name and ends at the end of the function body.(译文：一个用于表示函数的类型参数或由方法接收器声明的类型参数的标识符的作用域始于函数名，终止于函数体末尾。)

这样一个改动，使得原本在当前版本Go编译器(Go 1.18.x)下编译报错的源码，在Go 1.19版本中可以正常编译通过：

type T[T any] struct {}
func (T[T]) m() {} // error: T is not a generic type

修订Go memory model

Go memory model是Go文档中最抽象的一篇，没有之一！随着Go的演进，原先的Go memory model描述有很多地方不够正式，也缺少对一些同步机制的说明，如atomic等。

这次修订，参考了Hans-J. Boehm和Sarita V. Adve在“Foundations of the C++ Concurrency Memory Model，(PLDI 2008)”中对C++ memory model的描述方式，对Go memory model做了更正式的整体描述，增加了对multiword竞态、runtime.SetFinalizer、更多sync类型、atomic操作以及编译器优化方面的描述。

修订go doc comment格式

Go内置了将comment直接提取为包文档的能力，这与其他语言通过第三方工具生成文档不同。go doc comment为Gopher提供了很大便利。但go doc comment设计于2009年，有些过时。对很多呈现形式的支持不够或缺少更为精确的格式描述，这次Russ Cox主导了go doc comment的修订，增加了对超链、列表、标题、标准库API引用等格式支持，修订后的go doc comment并非markdown语法，但从markdown语法中做了借鉴，同时兼容老comment格式。下面是Russ Cox提供的一些新doc comment的渲染后的效果图：

同时，Go团队还提供了go/doc/comment包，gopher使用它可以轻松解析go doc comment。

runtime.SetMemoryLimit

在Go 1.19中，一个新的runtime.SetMemoryLimit函数以及一个GOMEMLIMIT环境变量被引入。有了这个memory软限制，Go运行时将通过限制堆的大小，以及更积极地将内存返回给底层os，来试图维持这个内存限制，以尽量避免Go程序因分配heap过多，超出系统内存资源限制而被kill。

默认memory limit是math.MaxInt64。一旦通过SetMemoryLimit自行设定limit，那么Go运行时将尊重这个memory limit，通过调整GC回收频率以及及时将内存返还给os来保证go运行时掌控的内存总size在limit之下。

注意：limit限制的是go runtime掌控的内存总量，对于开发者自行从os申请的内存(比如通过mmap)则不予考虑。limit的具体措施细节可以参考该proposal design文档。

另外要注意的是：该limit不能100%消除out-of-memory的情况。

Go 1.19在启动时将默认提高打开文件的限值

经调查，一些系统对打开的文件数量设置了一个人为的soft限制, 主要是为了与使用select和其硬编码的最大文件描述符（由 fd_set 的大小限制）的代码兼容。通常限制为1024，有的更小，比如256。这样即便是gofmt这样的简单程序，当它们并行地遍历一个文件树时，也很容易遇到打开文件描述符超量的错误。

Go不使用select，所以它不应该受这些限制的影响。于是对于导入os包的go程序，Go将在1.19中默认提高这些限制值到hard limit。

Go 1.19 race detector将升级到v3版thread sanitizer

升级后的新版race detector的race检测性能相对于上一版将提升1.5倍-2倍，内存开销减半，并且没有对goroutine的数量的上限限制。

注：thread sanitizer检测数据竞态的工作原理：记录每一个内存访问的信息，并检测线程对这块内存的访问是否存在竞争。基于这种原理，我们也可以知道一旦开启race detect，Go程序的执行效率将受到很大影响，运行的开销将大幅增加。v3版thread sanitizer虽然得到了优化，但对程序的总体影响还是存在的并且依旧很大。

Go 1.19增加”unix” build tag

Go 1.19将增加”unix”构建标签：

//go:build unix

等价于

//go:build aix || linux || darwin || dragonfly || freebsd || openbsd || netbsd || solaris

不过要注意，”*_unix.go”还保留原语义，不能被识别，以便向后兼容现有文件，尤其是go标准库之外的使用。

标准库的一些变化

net软件包将使用EDNS

在Go 1.19中，net软件包将使用EDNS来增加DNS数据包的大小，以遵守现代DNS标准和实现。这应该有助于解决一些DNS服务器的问题。

flag包增加TextVar函数

Go flag包增加TextVar函数，这样flag包便可以与任何实现了encoding.Text{Marshaler,Unmarshaler}的Go类型集成。比如：

flag.TextVar(&ipaddr, "ipaddr", net.IPv4(192, 168, 0, 1), "what server to connect to?") // 与net.IPv4类型
flag.TextVar(&start, "start", time.Now(), "when should we start processing?") // 与time.Time类型

其它

在linux上，Go正式支持64位龙芯cpu架构 (GOOS=linux, GOARCH=loong64)。
当Go程序空闲时，Go GC进入到周期性的GC循环的情况下(2分钟一次)，Go运行时现在会在idle的操作系统线程上安排更少的GC worker goroutine，减少空闲时Go应用对os资源的占用。
Go行时将根据goroutine的历史平均栈使用率来分配初始goroutine栈，避免了一些goroutine的最多2倍的goroutine栈空间浪费。
sync/atomic包增加了新的高级原子类型Bool, Int32, Int64, Uint32, Uint64, Uintptr和Pointer，提升了使用体验。
Go 1.19中Go编译器使用jump table重新实现了针对大整型数和string类型的switch语句，平均性能提升20%左右。

小结

相对于Go 1.18，Go 1.19的确是一个“小版本”。但Go 1.19对memory model的更新、SetMemoryLimit的加入、go doc comment的修订以及对go runtime的持续打磨依然可以让gopher们产生一丝丝“小兴奋”，尤其是SetMemoryLimit的加入，是否能改善Go应用因GC不及时被kill的情况呢，让我们拭目以待。

Go 1.19的里程碑在这里，所有feature和fix大家可以在该里程碑中看到。

“Gopher部落”知识星球旨在打造一个精品Go学习和进阶社群！高品质首发Go技术文章，“三天”首发阅读权，每年两期Go语言发展现状分析，每天提前1小时阅读到新鲜的Gopher日报，网课、技术专栏、图书内容前瞻，六小时内必答保证等满足你关于Go语言生态的所有需求！2022年，Gopher部落全面改版，将持续分享Go语言与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

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

Go：方法集合中“消失的方法”

本文永久链接 – https://tonybai.com/2022/06/06/the-disappeared-method-in-method-set

在《Go语言第一课》中，我花了三节课对Go方法做了全面细致的讲解，而类型的方法集合是其中的一个重点，因为方法集合决定接口实现，并且课程还分门别类地对各种使用类型嵌入(type embedding)机制定义的类型进行了说明，讲解了这些类型的方法集合的组成规则。我还提供了一个可以输出某类型的方法集合的辅助函数，便于大家很直观地查看特定类型的方法集合。

学员们在Go方法集合方面也投入了极大的学习热情，提出了不少好问题。这不，前两天有一位学员Aeins就提出了一个很好的问题，其问题如下(略做润色)：

Aeins：

下面示例中的结构体类型使用两种不同方式嵌入接口类型。

由于接口类型嵌入允许重名方法，因此I接口有三个方法。类型SI嵌入了接口类型I，因此，SI也有三个方法；

SI12嵌入了接口类型I1和I2, 但SI12却只有两个方法。难道是结构体类型嵌入不允许重名，M 方法被自动隐藏了？，

package main

import (
    "fmt"
    "reflect"
)

type I1 interface {
    M()
    M1()
}

type I2 interface {
    M()
    M2()
}

type I interface {
    I1
    I2
}

type SI struct {
    I
}

type SI12 struct {
    I1
    I2
}

func main() {
    var si SI
    var si12 SI12
    DumpMethodSet(si)
    DumpMethodSet(si12)
}

func DumpMethodSet(i interface{}) {
    dynTyp := reflect.TypeOf(i)

    if dynTyp == nil {
        fmt.Printf("there is no dynamic type\n")
        return
    }

    n := dynTyp.NumMethod()
    if n == 0 {
        fmt.Printf("%s's method set is empty!\n", dynTyp)
        return
    }

    fmt.Printf("%s's method set:\n", dynTyp)
    for j := 0; j < n; j++ {
        fmt.Println("-", dynTyp.Method(j).Name)
    }
    fmt.Printf("\n")
}

============

main.SI's method set:
- M
- M1
- M2

main.SI12's method set:
- M1
- M2

从这个问题的示例代码中我们看到Aeins这位学员的疑问：通过嵌入组合了I1和I2的接口类型I的类型SI的方法集合中包含了方法M，而通过直接嵌入接口类型I1和I2的类型SI2的方法集合中的方法M却“消失”了，这是为什么呢？

好了，下面我们就来分析一下。

我们知道：一个类型的方法集合中的方法应该都是可以被这个类型实例所合法调用的。比如：

// https://go.dev/play/p/gGkgsGRJpHv
package main

type I interface {
    M1()
    M2()
}

type T struct {
}

func (T) M1() {
}

func (T) M2() {
}

type S struct {
    I
}

func (S) M3() {}

func main() {
    var s = S{
        I: T{},
    }
    s.M1()
    s.M2()
    s.M3()
}

结构体类型S的方法集合中有三个方法，其中M1、M2来自于对接口类型I的类型嵌入，M3则是S自定义的方法。不过无论是哪个方法，一旦进入S的方法集合，它就可以被S实例合法调用。

反过来说：只有能被类型实例直接调用的方法才能进入其方法集合。那么我们分别看看问题示例中的SI和SI12。

先来分析一下SI。SI嵌入了接口类型I，而接口类型I则是由I1和I2两个接口类型组合而成。这种通过嵌入其他接口类型来创建新接口类型的方式，在Go 1.14版本之前是有约束的：如果新接口类型嵌入了多个接口类型，这些嵌入的接口类型的方法集合不能有交集，同时嵌入的接口类型的方法集合中的方法名字，也不能与新接口中的其他方法同名。但自Go 1.14版本开始，Go语言去除了这些约束，这也是I1和I2的方法集合有交集，但仍可以同时嵌入到SI中的原因。这样接口类型SI的方法集合就包含了M、M1和M2。

当SI通过嵌入I进行定义时，SI的方法集合“继承”了接口类型I的方法集合，通过合理初始化后的SI的实例，我们可以合法调用M、M1和M2：

type S3 struct {
}
func (S3) M() {
}
func (S3) M1() {
}
func (S3) M2() {
}

func main() {
    var s = SI{
        I : S3{},
    }
    s.M()   //ok
    s.M1()  //ok
    s.M2()  //ok
}

我们再来看SI12。在问题示例中，SI12没有嵌入整合了I1和I2的接口类型I，而是直接嵌入了I1和I2。那么是否I1和I2的方法集合中的方法都会变成SI12类型的方法集合中的方法呢？那要看SI12类型的实例是否可以合法调用I1和I2的方法？我们看下面例子：

type S1 struct {
}

func (S1) M() {
}
func (S1) M1() {
}

type S2 struct {
}

func (S2) M() {
}
func (S2) M2() {
}

func main() {
    var si12 = SI12{
        I1: S1{},
        I2: S2{},
    }
    DumpMethodSet(si12)
    si12.M1() // ok
    si12.M2() // ok
    si12.M() // ambiguous selector si12.M
}

我们看到通过SI12类型的实例可以成功调用M1和M2方法，但在调用M方法时出现了“歧义”，Go编译器无法确定究竟该调用si12.I1.M方法还是si12.I2.M方法，即Go编译器无法合法调用M方法，因此M方法因未决的歧义性不能被列入SI12的方法集合中。

这就是SI12类型方法集合中方法M“消失”的原因，你get到了么！

img{512x368}

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

我的联系方式：