标签 链接器 下的文章

Go 1.15中值得关注的几个变化

img{512x368}

Go 1.15版本在8月12日就正式发布了,给我的感觉就是发布的挺痛快^_^。这种感觉来自与之前版本发布时间的对比:Go 1.13版本发布于当年的9月4日,更早的Go 1.11版本发布于当年的8月25日。

不过这个时间恰与我家二宝出生和老婆月子时期有重叠,每天照顾孩子团团转的我实在抽不出时间研究Go 1.15的变化:(。如今,我逐渐从照顾二宝的工作中脱离出来^_^,于是“Go x.xx版本值得关注的几个变化”系列将继续下去。关注Go语言的演变对掌握和精通Go语言大有裨益,凡是致力于成为一名高级Gopher的读者都应该密切关注Go的演进。
截至写稿时,Go 1.15最新版是Go 1.15.2。Go 1.15一如既往的遵循Go1兼容性承诺语言规范方面没有任何变化。可以说这是一个“面子”上变化较小的一个版本,但“里子”的变化还是不少的,在本文中我就和各位读者一起就重要变化逐一了解一下。

一. 平台移植性

Go 1.15版本不再对darwin/386和darwin/arm两个32位平台提供支持了。Go 1.15及以后版本仅对darwin/amd64和darwin/arm64版本提供支持。并且不再对macOS 10.12版本之前的版本提供支持。

Go 1.14版本中,Go编译器在被传入-race和-msan的情况下,默认会执行-d=checkptr,即对unsafe.Pointer的使用进行合法性检查-d=checkptr主要检查两项内容:

  • 当将unsafe.Pointer转型为*T时,T的内存对齐系数不能高于原地址的;

  • 做完指针算术后,转换后的unsafe.Pointer仍应指向原先Go堆对象

但在Go 1.14中,这个检查并不适用于Windows操作系统。Go 1.15中增加了对windows系统的支持。

对于RISC-V架构,Go社区展现出十分积极的姿态,早在Go 1.11版本,Go就为RISC-V cpu架构预留了GOARCH值:riscv和riscv64。Go 1.14版本则为64bit RISC-V提供了在linux上的实验性支持(GOOS=linux, GOARCH=riscv64)。在Go 1.15版本中,Go在GOOS=linux, GOARCH=riscv64的环境下的稳定性和性能得到持续提升,并且已经可以支持goroutine异步抢占式调度了。

二. 工具链

1. GOPROXY新增以管道符为分隔符的代理列表值

Go 1.13版本中,GOPROXY支持设置为多个proxy的列表,多个proxy之间采用逗号分隔。Go工具链会按顺序尝试列表中的proxy以获取依赖包数据,但是当有proxy server服务不可达或者是返回的http状态码不是404也不是410时,go会终止数据获取。但是当列表中的proxy server返回其他错误时,Go命令不会向GOPROXY列表中的下一个值所代表的的proxy server发起请求,这种行为模式没能让所有gopher满意,很多Gopher认为Go工具链应该向后面的proxy server请求,直到所有proxy server都返回失败。Go 1.15版本满足了Go社区的需求,新增以管道符“|”为分隔符的代理列表值。如果GOPROXY配置的proxy server列表值以管道符分隔,则无论某个proxy server返回什么错误码,Go命令都会向列表中的下一个proxy server发起新的尝试请求。

注:Go 1.15版本中GOPROXY环境变量的默认值依旧为https://proxy.golang.org,direct

2. module cache的存储路径可设置

Go module机制自打在Go 1.11版本中以试验特性的方式引入时就将module的本地缓存默认放在了\$GOPATH/pkg/mod下(如果没有显式设置GOPATH,那么默认值将是~/go;如果GOPATH下面配置了多个路径,那么选择第一个路径),一直到Go 1.14版本,这个位置都是无法配置的。

Go module的引入为去除GOPATH提供了前提,于是module cache的位置也要尽量与GOPATH“脱钩”:Go 1.15提供了GOMODCACHE环境变量用于自定义module cache的存放位置。如果没有显式设置GOMODCACHE,那么module cache的默认存储路径依然是\$GOPATH/pkg/mod

三. 运行时、编译器和链接器

1. panic展现形式变化

在Go 1.15之前,如果传给panic的值是bool, complex64, complex128, float32, float64, int, int8, int16, int32, int64, string, uint, uint8, uint16, uint32, uint64, uintptr等原生类型的值,那么panic在触发时会输出具体的值,比如:

// go1.15-examples/runtime/panic.go

package main

func foo() {
    var i uint32 = 17
    panic(i)
}

func main() {
    foo()
}

使用Go 1.14运行上述代码,得到如下结果:

$go run panic.go
panic: 17

goroutine 1 [running]:
main.foo(...)
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.15-examples/runtime/panic.go:5
main.main()
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.15-examples/runtime/panic.go:9 +0x39
exit status 2

Go 1.15版本亦是如此。但是对于派生于上述原生类型的自定义类型而言,Go 1.14只是输出变量地址:

// go1.15-examples/runtime/panic.go

package main

type myint uint32

func bar() {
    var i myint = 27
    panic(i)
}

func main() {
    bar()
}

使用Go 1.14运行上述代码:

$go run panic.go
panic: (main.myint) (0x105fca0,0xc00008e000)

goroutine 1 [running]:
main.bar(...)
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.15-examples/runtime/panic.go:12
main.main()
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.15-examples/runtime/panic.go:17 +0x39
exit status 2

Go 1.15针对此情况作了展示优化,即便是派生于这些原生类型的自定义类型变量,panic也可以输出其值。使用Go 1.15运行上述代码的结果如下:

$go run panic.go
panic: main.myint(27)

goroutine 1 [running]:
main.bar(...)
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.15-examples/runtime/panic.go:12
main.main()
    /Users/tonybai/go/src/github.com/bigwhite/experiments/go1.15-examples/runtime/panic.go:17 +0x39
exit status 2

2. 将小整数([0,255])转换为interface类型值时将不会额外分配内存

Go 1.15在runtime/iface.go中做了一些优化改动:增加一个名为staticuint64s的数组,预先为[0,255]这256个数分配了内存。然后在convT16、convT32等运行时转换函数中判断要转换的整型值是否小于256(len(staticuint64s)),如果小于,则返回staticuint64s数组中对应的值的地址;否则调用mallocgc分配新内存。

$GOROOT/src/runtime/iface.go

// staticuint64s is used to avoid allocating in convTx for small integer values.
var staticuint64s = [...]uint64{
        0x00, 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07,
        0x08, 0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f,
        0x10, 0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17,
        0x18, 0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f,
        0x20, 0x21, 0x22, 0x23, 0x24, 0x25, 0x26, 0x27,
        0x28, 0x29, 0x2a, 0x2b, 0x2c, 0x2d, 0x2e, 0x2f,
        0x30, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37,

        ... ...

        0xf0, 0xf1, 0xf2, 0xf3, 0xf4, 0xf5, 0xf6, 0xf7,
        0xf8, 0xf9, 0xfa, 0xfb, 0xfc, 0xfd, 0xfe, 0xff,

}

func convT16(val uint16) (x unsafe.Pointer) {
        if val < uint16(len(staticuint64s)) {
                x = unsafe.Pointer(&staticuint64s[val])
                if sys.BigEndian {
                        x = add(x, 6)
                }
        } else {
                x = mallocgc(2, uint16Type, false)
                *(*uint16)(x) = val
        }
        return
}

func convT32(val uint32) (x unsafe.Pointer) {
        if val < uint32(len(staticuint64s)) {
                x = unsafe.Pointer(&staticuint64s[val])
                if sys.BigEndian {
                        x = add(x, 4)
                }
        } else {
                x = mallocgc(4, uint32Type, false)
                *(*uint32)(x) = val
        }
        return
}

我们可以用下面例子来验证一下:

// go1.15-examples/runtime/tinyint2interface.go

package main

import (
    "math/rand"
)

func convertSmallInteger() interface{} {
    i := rand.Intn(256)
    var j interface{} = i
    return j
}

func main() {
    for i := 0; i < 100000000; i++ {
        convertSmallInteger()
    }
}

我们分别用go 1.14和go 1.15.2编译这个源文件(注意关闭内联等优化,否则很可能看不出效果):

// go 1.14

go build  -gcflags="-N -l" -o tinyint2interface-go14 tinyint2interface.go

// go 1.15.2

go build  -gcflags="-N -l" -o tinyint2interface-go15 tinyint2interface.go

我们使用下面命令输出程序执行时每次GC的信息:

$env GODEBUG=gctrace=1 ./tinyint2interface-go14
gc 1 @0.025s 0%: 0.009+0.18+0.021 ms clock, 0.079+0.079/0/0.20+0.17 ms cpu, 4->4->0 MB, 5 MB goal, 8 P
gc 2 @0.047s 0%: 0.003+0.14+0.013 ms clock, 0.031+0.099/0.064/0.037+0.10 ms cpu, 4->4->0 MB, 5 MB goal, 8 P
gc 3 @0.064s 0%: 0.008+0.20+0.016 ms clock, 0.071+0.071/0.018/0.081+0.13 ms cpu, 4->4->0 MB, 5 MB goal, 8 P
gc 4 @0.081s 0%: 0.005+0.14+0.013 ms clock, 0.047+0.059/0.023/0.032+0.10 ms cpu, 4->4->0 MB, 5 MB goal, 8 P
gc 5 @0.098s 0%: 0.005+0.10+0.017 ms clock, 0.042+0.073/0.027/0.080+0.13 ms cpu, 4->4->0 MB, 5 MB goal, 8 P

... ...

gc 192 @3.264s 0%: 0.003+0.11+0.013 ms clock, 0.024+0.060/0.005/0.035+0.11 ms cpu, 4->4->0 MB, 5 MB goal, 8 P
gc 193 @3.281s 0%: 0.005+0.13+0.032 ms clock, 0.042+0.075/0.041/0.050+0.25 ms cpu, 4->4->0 MB, 5 MB goal, 8 P
gc 194 @3.298s 0%: 0.004+0.12+0.013 ms clock, 0.033+0.072/0.030/0.033+0.10 ms cpu, 4->4->0 MB, 5 MB goal, 8 P
gc 195 @3.315s 0%: 0.003+0.17+0.023 ms clock, 0.029+0.062/0.055/0.024+0.18 ms cpu, 4->4->0 MB, 5 MB goal, 8 P

$env GODEBUG=gctrace=1 ./tinyint2interface-go15

我们看到和go 1.14编译的程序不断分配内存,不断导致GC相比,go1.15.2没有输出GC信息,间接证实了小整数转interface变量值时不会触发内存分配。

3. 加入更现代化的链接器(linker)

一个新版的现代化linker正在逐渐加入到Go中,Go 1.15是新版linker的起点。后续若干版本,linker优化会逐步加入进来。在Go 1.15中,对于大型项目,新链接器的性能要提高20%,内存占用减少30%。

4. objdump支持输出GNU汇编语法

go 1.15为objdump工具增加了-gnu选项,以在Go汇编的后面,辅助输出GNU汇编,便于对照

// go 1.14:

$go tool objdump -S tinyint2interface-go15|more
TEXT go.buildid(SB)

  0x1001000             ff20                    JMP 0(AX)
  0x1001002             476f                    OUTSD DS:0(SI), DX
  0x1001004             206275                  ANDB AH, 0x75(DX)
  0x1001007             696c642049443a20        IMULL $0x203a4449, 0x20(SP), BP
... ...

//go 1.15.2:

$go tool objdump  -S -gnu tinyint2interface-go15|more
TEXT go.buildid(SB)

  0x1001000             ff20                    JMP 0(AX)                            // jmpq *(%rax)           

  0x1001002             476f                    OUTSD DS:0(SI), DX                   // rex.RXB outsl %ds:(%rsi),(%dx)
  0x1001004             206275                  ANDB AH, 0x75(DX)                    // and %ah,0x75(%rdx)     

  0x1001007             696c642049443a20        IMULL $0x203a4449, 0x20(SP), BP      // imul $0x203a4449,0x20(%rsp,%riz,2),%ebp

... ...

四. 标准库

和以往发布的版本一样,标准库有大量小改动,这里挑出几个笔者感兴趣的和大家一起看一下。

1. 增加tzdata包

Go time包中很多方法依赖时区数据,但不是所有平台上都自带时区数据。Go time包会以下面顺序搜寻时区数据:

- ZONEINFO环境变量指示的路径中

- 在类Unix系统中一些常见的存放时区数据的路径(zoneinfo_unix.go中的zoneSources数组变量中存放这些常见路径):

    "/usr/share/zoneinfo/",
    "/usr/share/lib/zoneinfo/",
    "/usr/lib/locale/TZ/"

- 如果平台没有,则尝试使用$GOROOT/lib/time/zoneinfo.zip这个随着go发布包一起发布的时区数据。但在应用部署的环境中,很大可能不会进行go安装。

如果go应用找不到时区数据,那么go应用运行将会受到影响,就如下面这个例子:

// go1.15-examples/stdlib/tzdata.go

package main

import (
    "fmt"
    "time"
)

func main() {
    loc, err := time.LoadLocation("America/New_York")
    if err != nil {
        fmt.Println("LoadLocation error:", err)
        return
    }
    fmt.Println("LoadLocation is:", loc)
}

我们移除系统的时区数据(比如将/usr/share/zoneinfo改名)和Go安装包自带的zoneinfo.zip(改个名)后,在Go 1.15.2下运行该示例:

$ go run tzdata.go
LoadLocation error: unknown time zone America/New_York

为此,Go 1.15提供了一个将时区数据嵌入到Go应用二进制文件中的方法:导入time/tzdata包

// go1.15-examples/stdlib/tzdata.go

package main

import (
    "fmt"
    "time"
    _ "time/tzdata"
)

func main() {
    loc, err := time.LoadLocation("America/New_York")
    if err != nil {
        fmt.Println("LoadLocation error:", err)
        return
    }
    fmt.Println("LoadLocation is:", loc)
}

我们再用go 1.15.2运行一下上述导入tzdata包的例子:

$go run testtimezone.go
LoadLocation is: America/New_York

不过由于附带tzdata数据,应用二进制文件的size会增大大约800k,下面是在ubuntu下的实测值:

-rwxr-xr-x 1 root root 2.0M Oct 11 02:42 tzdata-withouttzdata*
-rwxr-xr-x 1 root root 2.8M Oct 11 02:42 tzdata-withtzdata*

2. 增加json解码限制

json包是日常使用最多的go标准库包之一,在Go 1.15中,go按照json规范的要求,为json的解码增加了一层限制:

// json规范要求

//https://tools.ietf.org/html/rfc7159#section-9

A JSON parser transforms a JSON text into another representation.  A
   JSON parser MUST accept all texts that conform to the JSON grammar.
   A JSON parser MAY accept non-JSON forms or extensions.

   An implementation may set limits on the size of texts that it
   accepts.  An implementation may set limits on the maximum depth of
   nesting.  An implementation may set limits on the range and precision
   of numbers.  An implementation may set limits on the length and
   character contents of strings.

这个限制就是增加了一个对json文本最大缩进深度值:

// $GOROOT/src/encoding/json/scanner.go

// This limits the max nesting depth to prevent stack overflow.
// This is permitted by https://tools.ietf.org/html/rfc7159#section-9
const maxNestingDepth = 10000

如果一旦传入的json文本数据缩进深度超过maxNestingDepth,那json包就会panic。当然,绝大多数情况下,我们是碰不到缩进10000层的超大json文本的。因此,该limit对于99.9999%的gopher都没啥影响。

3. reflect包

Go 1.15版本之前reflect包存在一处行为不一致的问题,我们看下面例子(例子来源于https://play.golang.org/p/Jnga2_6Rmdf):

// go1.15-examples/stdlib/reflect.go

package main

import "reflect"

type u struct{}

func (u) M() { println("M") }

type t struct {
    u
    u2 u
}

func call(v reflect.Value) {
    defer func() {
        if err := recover(); err != nil {
            println(err.(string))
        }
    }()
    v.Method(0).Call(nil)
}

func main() {
    v := reflect.ValueOf(t{}) // v := t{}
    call(v)                   // v.M()
    call(v.Field(0))          // v.u.M()
    call(v.Field(1))          // v.u2.M()
}

我们使用Go 1.14版本运行该示例:

$go run reflect.go
M
M
reflect: reflect.flag.mustBeExported using value obtained using unexported field

我们看到同为类型t中的非导出字段(field)的u和u2(u是以嵌入类型方式称为类型t的字段的),通过reflect包可以调用字段u的导出方法(如输出中的第二行的M),却无法调用非导出字段u2的导出方法(如输出中的第三行的panic信息)。

这种不一致在Go 1.15版本中被修复,我们使用Go 1.15.2运行上述示例:

$go run reflect.go
M
reflect: reflect.Value.Call using value obtained using unexported field
reflect: reflect.Value.Call using value obtained using unexported field

我们看到reflect无法调用非导出字段u和u2的导出方法了。但是reflect依然可以通过提升到类型t的方法来间接使用u的导出方法,正如运行结果中的第一行输出。
这一改动可能会影响到遗留代码中使用reflect调用以类型嵌入形式存在的非导出字段方法的代码,如果你的代码中存在这样的问题,可以直接通过提升(promote)到包裹类型(如例子中的t)中的方法(如例子中的call(v))来替代之前的方式。

五. 小结

由于Go 1.15删除了一些GC元数据和一些无用的类型元数据,Go 1.15编译出的二进制文件size会减少5%左右。我用一个中等规模的go项目实测了一下:

-rwxr-xr-x   1 tonybai  staff    23M 10 10 16:54 yunxind*
-rwxr-xr-x   1 tonybai  staff    24M  9 30 11:20 yunxind-go14*

二进制文件size的确有变小,大约4%-5%。

如果你还没有升级到Go 1.15,那么现在正是时候

本文中涉及的代码可以在这里下载。https://github.com/bigwhite/experiments/tree/master/go1.15-examples


我的Go技术专栏:“改善Go语⾔编程质量的50个有效实践”上线了,欢迎大家订阅学习!

我的网课“Kubernetes实战:高可用集群搭建、配置、运维与应用”在慕课网上线了,感谢小伙伴们学习支持!

我爱发短信:企业级短信平台定制开发专家 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

微信赞赏:
img{512x368}

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

Go 1.7中值得关注的几个变化

零、从Release Cycle说起

从Go 1.3版本开始,Golang核心开发Team的版本开发周期逐渐稳定下来。经过Go 1.4Go1.5Go 1.6的实践,大神Russ CoxGo wiki上大致定义了Go Release Cycle的一般流程:

  1. 半年一个major release版本。
  2. 发布流程启动时间:每年8月1日和次年2月1日(真正发布日期有可能是这个日子,也可能延后几天)。
  3. 半年的周期中,前三个月是Active Development,then 功能冻结(大约在11月1日和次年的5月1日)。接下来的三个月为test和polish。
  4. 下一个版本的启动计划时间:7月15日和1月15日,版本计划期持续15天,包括讨论这个major版本中要实现的主要功能、要fix的前期遗留的bug。
  5. release前的几个阶段版本:beta版本若干(一般是2-3个)、release candidate版本若干(一般是1-2个)和最后的release版本。
  6. major release版本的维护是通过一系列的minor版本体现的,主要是修正一些导致crash的严重问题或是安全问题,比如major release版本Go 1.6目前就有go 1.6.1和go 1.6.2两个后续minor版本发布。

在制定下一个版本启动计划时,一般会由Russ Cox在golang-dev group发起相关讨论,其他Core developer在讨论帖中谈一下自己在下一个版本中要做的事情,让所有开发者大致了解一下下个版本可能包含的功能和修复的bug概况。但这些东西是否能最终包含在下一个Release版本中,还要看Development阶段feature代码是否能完成、通过review并加入到main trunk中;如果来不及加入,这个功能可能就会放入下一个major release中,比如SSA就错过了Go 1.6(由于Go 1.5改动较大,留给Go 1.6的时间短了些)而放在了Go 1.7中了。

个人感觉Go社区采用的是一种“民主集中制”的文化,即来自Google的Golang core team的少数人具有实际话语权,尤其是几个最早加入Go team的大神,比如Rob Pike老头、Russ Cox以及Ian Lance Taylor等。当然绝大部分合理建议还是被merge到了Go代码中的,但一些与Go哲学有背离的想法,比如加入泛型、增加新类型、改善错误处理等,基本都被Rob Pike老头严词拒绝了,至少Go 1兼容版本中,大家是铁定看不到的了。至于Go 2,就连Go core team的人也不能不能打包票说一定会有这样的新语言规范。不过从Rob Pike前些阶段的一些言论中,大致可以揣摩出Pike老头正在反思Go 1的设计,也许他正在做Go 2的语言规范也说不定呢^_^。这种“文化”并不能被很多开源开发者所欣赏,在GopherChina 2016大会上,大家就对这种“有些独裁”的文化做过深刻了辩论,尤其是对比Rust那种“绝对民主”的文化。见仁见智的问题,这里就不深入了。个人觉得Go core team目前的做法还是可以很好的保持Go语言在版本上的理想的兼容性和发展的一致性的,对于一门面向工程领域的语言而言,这也许是开发者们较为看重的东西;编程语言语法在不同版本间“跳跃式”的演进也许会在短时间内带来新鲜感,但长久看来,对代码阅读和维护而言,都会有一个不小的负担。

下面回归正题。Go 1.7究竟带来了哪些值得关注的变化呢?马上揭晓^_^。(以下测试所使用的Go版本为go 1.7 beta2)。

一、语言

Go 1.7在版本计划阶段设定的目标就是改善和优化(polishing),因此在Go语言(Specification)规范方面继续保持着与Go 1兼容,因此理论上Go 1.7的发布对以往Go 1兼容的程序而言是透明的,已存在的代码均可以正常通过Go 1.7的编译并正确执行。

不过Go 1.7还是对Go1 Specs中关于“Terminating statements”的说明作了一个extremely tiny的改动:

A statement list ends in a terminating statement if the list is not empty and its final statement is terminating.
=>
A statement list ends in a terminating statement if the list is not empty and its final non-empty statement is terminating.

Specs是抽象的,例子是生动的,我们用一个例子来说明一下这个改动:

// go17-examples/language/f.go

package f

func f() int {
    return 3
    ;
}

对于f.go中f函数的body中的语句列表(statement list),所有版本的go compiler或gccgo compiler都会认为其在”return 3″这个terminating statement处terminate,即便return语句后面还有一个“;”也没关系。但Go 1.7之前的gotype工具却严格按照go 1.7之前的Go 1 specs中的说明进行校验,由于最后的statement是”;” – 一个empty statement,gotype会提示:”missing return”:

// Go 1.7前版本的gotype

$gotype f.go
f.go:6:1: missing return

于是就有了gotype与gc、gccgo行为的不一致!为此Go 1.7就做了一些specs上的改动,将statements list的terminate点从”final statement”改为“final non-empty statement”,这样即便后面再有”;”也不打紧了。于是用go 1.7中的gotype执行同样的命令,得到的结果却不一样:

// Go 1.7的gotype
$gotype f.go
没有任何错误输出

gotype默认以源码形式随着Go发布,我们需要手工将其编译为可用的工具,编译步骤如下:

$cd $GOROOT/src/go/types
$go build gotype.go
在当前目录下就会看到gotype可执行文件,你可以将其mv or cp到$GOBIN下,方便在命令行中使用。

二、Go Toolchain(工具链)

Go的toolchain的强大实用是毋容置疑的,也是让其他编程语言Fans直流口水的那部分。每次Go major version release,Go工具链都会发生或大或小的改进,这次也不例外。

1、SSA

SSA(Static Single-Assignment),对于大多数开发者来说都是不熟悉的,也是不需要关心的,只有搞编译器的人才会去认真研究它究竟为何物。对于Go语言的使用者而言,SSA意味着让编译出来的应用更小,运行得更快,未来有更多的优化空间,而这一切的获得却不需要Go开发者修改哪怕是一行代码^_^。

在Go core team最初的计划中,SSA在Go 1.6时就应该加入,但由于Go 1.6开发周期较为短暂,SSA的主要开发者Keith Randall没能按时完成相关开发,尤其是在性能问题上没能达到之前设定的目标,因此merge被推迟到了Go 1.7。即便是Go 1.7,SSA也只是先完成了x86-64系统。
据实而说,SSA后端的引入,风险还是蛮大的,因此Go在编译器中加入了一个开关”-ssa=0|1″,可以让开发者自行选择是否编译为SSA后端,默认情况下,在x86-64平台下SSA后端是打开的。同时,Go 1.7还修改了包导出的元数据的格式,由以前的文本格式换成了更为短小精炼的二进制格式,这也让Go编译出来的结果文件的Size更为small。

我们可以简单测试一下上述两个优化后对编译后结果的影响,我们以编译github.com/bigwhite/gocmpp/examples/client/例:

-rwxrwxr-x 1 share share 4278888  6月 20 14:20 client-go16*
-rwxrwxr-x 1 share share 3319205  6月 20 14:04 client-go17*
-rwxrwxr-x 1 share share 3319205  6月 20 14:05 client-go17-no-newexport*
-rwxrwxr-x 1 share share 3438317  6月 20 14:04 client-go17-no-ssa*
-rwxrwxr-x 1 share share 3438317  6月 20 14:03 client-go17-no-ssa-no-newexport*

其中:client-go17-no-ssa是通过下面命令行编译的:

$go build -a -gcflags="-ssa=0" github.com/bigwhite/gocmpp/examples/client

client-go17-no-newexport*是通过下面命令行编译的:

$go build -a -gcflags="-newexport=0" github.com/bigwhite/gocmpp/examples/client

client-go17-no-ssa-no-newexport是通过下面命令行编译的:

$go build -a -gcflags="-newexport=0 -ssa=0" github.com/bigwhite/gocmpp/examples/client

对比client-go16和client-go17,我们可以看到默认情况下Go 17编译出来的可执行程序(client-go17)比Go 1.6编译出来的程序(client-go16)小了约21%,效果十分明显。这也与Go官方宣称的file size缩小20%~30%de 平均效果相符。

不过对比client-go17和client-go17-no-newexport,我们发现,似乎-newexport=0并没有起到什么作用,两个最终可执行文件的size相同。这个在ubuntu 14.04以及darwin平台上测试的结果均是如此,暂无解。

引入SSA后,官方说法是:程序的运行性能平均会提升5%~35%,数据来源于官方的benchmark数据,这里就不再重复测试了。

2、编译器编译性能

Go 1.5发布以来,Go的编译器性能大幅下降就遭到的Go Fans们的“诟病”,虽然Go Compiler的性能与其他编程语言横向相比依旧是“独领风骚”。最差时,Go 1.5的编译构建时间是Go 1.4.x版本的4倍还多。这个问题也引起了Golang老大Rob Pike的极大关注,在Russ Cox筹划Go 1.7时,Rob Pike就极力要求要对Go compiler&linker的性能进行优化,于是就有了Go 1.7“全民优化”Go编译器和linker的上百次commit,至少从目前来看,效果是明显的。

Go大神Dave Cheney为了跟踪开发中的Go 1.7的编译器性能情况,建立了三个benchmark:benchjujubenchkubebenchgogs。Dave上个月最新贴出的一幅性能对比图显示:编译同一项目,Go 1.7编译器所需时间仅约是Go 1.6的一半,Go 1.4.3版本的2倍;也就是说经过优化后,Go 1.7的编译性能照比Go 1.6提升了一倍,离Go 1.4.3还有一倍的差距。

img{}

3、StackFrame Pointer

在Go 1.7功能freeze前夕,Russ Cox将StackFrame Pointer加入到Go 1.7中了,目的是使得像Linux Perf或Intel Vtune等工具能更高效的抓取到go程序栈的跟踪信息。但引入STackFrame Pointer会有一些性能上的消耗,大约在2%左右。通过下面环境变量设置可以关闭该功能:

export GOEXPERIMENT=noframepointer

4、Cgo增加C.CBytes

Cgo的helper函数在逐渐丰富,这次Cgo增加C.CBytes helper function就是源于开发者的需求。这里不再赘述Cgo的这些Helper function如何使用了,通过一小段代码感性了解一下即可:

// go17-examples/gotoolchain/cgo/print.go

package main

// #include <stdio.h>
// #include <stdlib.h>
//
// void print(void *array, int len) {
//  char *c = (char*)array;
//
//  for (int i = 0; i < len; i++) {
//      printf("%c", *(c+i));
//  }
//  printf("\n");
// }
import "C"

import "unsafe"

func main() {
    var s = "hello cgo"
    csl := C.CBytes([]byte(s))
    C.print(csl, C.int(len(s)))
    C.free(unsafe.Pointer(csl))
}

执行该程序:

$go run print.go
hello cgo

5、其他小改动

  • 经过Go 1.5和Go 1.6实验的go vendor机制在Go 1.7中将正式去掉GO15VENDOREXPERIMENT环境变量开关,将vendor作为默认机制。
  • go get支持git.openstack.org导入路径。
  • go tool dist list命令将打印所有go支持的系统和硬件架构,在我的机器上输出结果如下:
$go tool dist list
android/386
android/amd64
android/arm
android/arm64
darwin/386
darwin/amd64
darwin/arm
darwin/arm64
dragonfly/amd64
freebsd/386
freebsd/amd64
freebsd/arm
linux/386
linux/amd64
linux/arm
linux/arm64
linux/mips64
linux/mips64le
linux/ppc64
linux/ppc64le
linux/s390x
nacl/386
nacl/amd64p32
nacl/arm
netbsd/386
netbsd/amd64
netbsd/arm
openbsd/386
openbsd/amd64
openbsd/arm
plan9/386
plan9/amd64
plan9/arm
solaris/amd64
windows/386
windows/amd64

三、标准库

1、支持subtests和sub-benchmarks

表驱动测试是golang内置testing框架的一个最佳实践,基于表驱动测试的思路,Go 1.7又进一步完善了testing的组织体系,增加了subtests和sub-benchmarks。目的是为了实现以下几个Features:

  • 通过外部command line(go test –run=xx)可以从一个table中选择某个test或benchmark,用于调试等目的;
  • 简化编写一组相似的benchmarks;
  • 在subtest中使用Fail系列方法(如FailNow,SkipNow等);
  • 基于外部或动态表创建subtests;
  • 更细粒度的setup和teardown控制,而不仅仅是TestMain提供的;
  • 更多的并行控制;
  • 与顶层函数相比,对于test和benchmark来说,subtests和sub-benchmark代码更clean。

下面是一个基于subtests文档中demo改编的例子:

传统的Go 表驱动测试就像下面代码中TestSumInOldWay一样:

// go17-examples/stdlib/subtest/foo_test.go

package foo

import (
    "fmt"
    "testing"
)

var tests = []struct {
    A, B int
    Sum  int
}{
    {1, 2, 3},
    {1, 1, 2},
    {2, 1, 3},
}

func TestSumInOldWay(t *testing.T) {
    for _, tc := range tests {
        if got := tc.A + tc.B; got != tc.Sum {
            t.Errorf("%d + %d = %d; want %d", tc.A, tc.B, got, tc.Sum)
        }
    }
}

对于这种传统的表驱动测试,我们在控制粒度上仅能在顶层测试方法层面,即TestSumInOldWay这个层面:

$go test --run=TestSumInOldWay
PASS
ok      github.com/bigwhite/experiments/go17-examples/stdlib/subtest    0.008s

同时为了在case fail时更容易辨别到底是哪组数据导致的问题,Errorf输出时要带上一些测试数据的信息,比如上面代码中的:”%d+%d=%d; want %d”。

若通过subtests来实现,我们可以将控制粒度细化到subtest层面。并且由于subtest自身具有subtest name唯一性,无需在Error中带上那组测试数据的信息:

// go17-examples/stdlib/subtest/foo_test.go

func assertEqual(A, B, expect int, t *testing.T) {
    if got := A + B; got != expect {
        t.Errorf("got %d; want %d", got, expect)
    }
}

func TestSumSubTest(t *testing.T) {
    //setup code ... ...

    for i, tc := range tests {
        t.Run("A=1", func(t *testing.T) {
            if tc.A != 1 {
                t.Skip(i)
            }
            assertEqual(tc.A, tc.B, tc.Sum, t)
        })

        t.Run("A=2", func(t *testing.T) {
            if tc.A != 2 {
                t.Skip(i)
            }
            assertEqual(tc.A, tc.B, tc.Sum, t)
        })
    }

    //teardown code ... ...
}

我们故意将tests数组中的第三组测试数据的Sum值修改错误,这样便于对比测试结果:

var tests = []struct {
    A, B int
    Sum  int
}{
    {1, 2, 3},
    {1, 1, 2},
    {2, 1, 4},
}

执行TestSumSubTest:

$go test --run=TestSumSubTest
--- FAIL: TestSumSubTest (0.00s)
    --- FAIL: TestSumSubTest/A=2#02 (0.00s)
        foo_test.go:19: got 3; want 4
FAIL
exit status 1
FAIL    github.com/bigwhite/experiments/go17-examples/stdlib/subtest    0.007s

分别执行”A=1″和”A=2″的两个subtest:

$go test --run=TestSumSubTest/A=1
PASS
ok      github.com/bigwhite/experiments/go17-examples/stdlib/subtest    0.007s

$go test --run=TestSumSubTest/A=2
--- FAIL: TestSumSubTest (0.00s)
    --- FAIL: TestSumSubTest/A=2#02 (0.00s)
        foo_test.go:19: got 3; want 4
FAIL
exit status 1
FAIL    github.com/bigwhite/experiments/go17-examples/stdlib/subtest    0.007s

测试的结果验证了前面说到的两点:
1、subtest的输出自带唯一标识,比如:“FAIL: TestSumSubTest/A=2#02 (0.00s)”
2、我们可以将控制粒度细化到subtest的层面。

从代码的形态上来看,subtest支持对测试数据进行分组编排,比如上面的测试就将TestSum分为A=1和A=2两组,以便于分别单独控制和结果对比。

另外由于控制粒度支持subtest层,setup和teardown也不再局限尽在TestMain级别了,开发者可以在每个top-level test function中,为其中的subtest加入setup和teardown,大体模式如下:

func TestFoo(t *testing.T) {
    //setup code ... ...

    //subtests... ...

    //teardown code ... ...
}

Go 1.7中的subtest同样支持并发执行:

func TestSumSubTestInParalell(t *testing.T) {
    t.Run("blockgroup", func(t *testing.T) {
        for _, tc := range tests {
            tc := tc
            t.Run(fmt.Sprint(tc.A, "+", tc.B), func(t *testing.T) {
                t.Parallel()
                assertEqual(tc.A, tc.B, tc.Sum, t)
            })
        }
    })
    //teardown code
}

这里嵌套了两层Subtest,”blockgroup”子测试里面的三个子测试是相互并行(Paralell)执行,直到这三个子测试执行完毕,blockgroup子测试的Run才会返回。而TestSumSubTestInParalell与foo_test.go中的其他并行测试function(如果有的话)的执行是顺序的。

sub-benchmark在形式和用法上与subtest类似,这里不赘述了。

2、Context包

Go 1.7将原来的golang.org/x/net/context包挪入了标准库中,放在$GOROOT/src/context下面,这显然是由于context模式用途广泛,Go core team响应了社区的声音,同时这也是Go core team自身的需要。Std lib中net、net/http、os/exec都用到了context。关于Context的详细说明,没有哪个比Go team的一篇”Go Concurrent Patterns:Context“更好了。

四、其他改动

Runtime这块普通开发者很少使用,一般都是Go core team才会用到。值得注意的是Go 1.7增加了一个runtime.Error(接口),所有runtime引起的panic,其panic value既实现了标准error接口,也实现了runtime.Error接口。

Golang的GC在1.7版本中继续由Austin Clements和Rick Hudson进行打磨和优化。

Go 1.7编译的程序的执行效率由于SSA的引入和GC的优化,整体上会平均提升5%-35%(在x86-64平台上)。一些标准库的包得到了显著的优化,比如:crypto/sha1, crypto/sha256, encoding/binary, fmt, hash/adler32, hash/crc32, hash/crc64, image/color, math/big, strconv, strings, unicode, 和unicode/utf16,性能提升在10%以上。

Go 1.7还增加了对使用二进制包(非源码)构建程序的实验性支持(出于一些对商业软件发布形态的考虑),但Go core team显然是不情愿在这方面走太远,不承诺对此进行完整的工具链支持。

标准库中其他的一些细微改动,大家尽可以参考Go 1.7 release notes。

本文涉及到的example代码在这里可以下载到。

如发现本站页面被黑,比如:挂载广告、挖矿等恶意代码,请朋友们及时联系我。十分感谢! Go语言第一课 Go语言精进之路1 Go语言精进之路2 Go语言编程指南
商务合作请联系bigwhite.cn AT aliyun.com

欢迎使用邮件订阅我的博客

输入邮箱订阅本站,只要有新文章发布,就会第一时间发送邮件通知你哦!

这里是 Tony Bai的个人Blog,欢迎访问、订阅和留言! 订阅Feed请点击上面图片

如果您觉得这里的文章对您有帮助,请扫描上方二维码进行捐赠 ,加油后的Tony Bai将会为您呈现更多精彩的文章,谢谢!

如果您希望通过微信捐赠,请用微信客户端扫描下方赞赏码:

如果您希望通过比特币或以太币捐赠,可以扫描下方二维码:

比特币:

以太币:

如果您喜欢通过微信浏览本站内容,可以扫描下方二维码,订阅本站官方微信订阅号“iamtonybai”;点击二维码,可直达本人官方微博主页^_^:
本站Powered by Digital Ocean VPS。
选择Digital Ocean VPS主机,即可获得10美元现金充值,可 免费使用两个月哟! 著名主机提供商Linode 10$优惠码:linode10,在 这里注册即可免费获 得。阿里云推荐码: 1WFZ0V立享9折!


View Tony Bai's profile on LinkedIn
DigitalOcean Referral Badge

文章

评论

  • 正在加载...

分类

标签

归档



View My Stats