又到了Go语言新版本的发布时间窗口了！这次的主角是Go 1.10。

曾几何时， 这是很多Gopher在Go 1.8、Go 1.9时猜测是否存在的那个版本，毕竟minor version即将进化到两位数。从Go语言第一封设计mail发出到现在的十年间，尤其是Go语言经历了近几年的爆发式增长，基本奠定了云原生第一语言的位置之后，人们对Go语言有了更多新的、更为深刻的认知，同时对这门编程语言也有了更多的改进和优化的期望。Go2在Gopher心中的位置日益提升，直到Russ Cox在GopherCon 2017上公布了Go core team对Go2的开发策略，我们才意识到：哦，Go1还将继续一段时间，甚至是一段很长的时间。2018年2月，我们将迎来Go 1.10版本。

从Go 1.4版本开始，我自己都没想到我能将“Go x.x中值得关注的几个变化”这个系列一直写到Go 1.10。不过现在看来，这个系列还会继续，以后可能还有Go 1.11、Go 1.12…，甚至是进化到Go2之后的各个版本。

Go从1.0版本发布之日起，便遵守着自己“变与不变”的哲学。不变的是对Go对“Go1 promise of compatibility”的严格遵守，变化的则是对语言性能、运行时、GC、工具以及标准库更为精细和耐心地打磨。这次发布的Go 1.10依然延续着这种理念，将重点的改进放在了运行时、工具以及标准库上。接下来，我就和大家一起看看即将发布的Go 1.10都有哪些值得重点关注的变化。

一、语言

Go language Spec是当前Go语言的唯一语言规范标准，虽然其严谨性与那些以ISO标准形式编写成的语言规范（比如：C语言、C++语言的规范）还有一定差距。因此，对go spec的优化，就是在严谨性方面下功夫。当前spec的主要修订者是Go语言三个设计者之一的Robert Griesemer，他在Go 1.10周期对spec做了较多语言概念严谨性方面的改进。

1、显式定义Representability（可表示性）

在Properties of types and values章节下，Robert Griesemer显式引入了一个新的术语Representability，这里译为可表示性。这一术语的引入并未带来语法的变化，只是为了更精确的阐释规范。Representability的定义明确了当规范中出现“a constant x is representable by a value of type T”时成立的几种条件，尤其是针对浮点类型和复数类型。这里摘录（不翻译）：

A constant x is representable by a value of type T if one of the following conditions applies:

- x is in the set of values determined by T.
- T is a floating-point type and x can be rounded to T's precision without overflow. Rounding uses IEEE 754 round-to-even rules but with an IEEE negative zero further simplified to an unsigned zero. Note that constant values never result in an IEEE negative zero, NaN, or infinity.
- T is a complex type, and x's components real(x) and imag(x) are representable by values of T's component type (float32 or float64).

2、澄清未指定类型的常量作为shift(移位)非常量位操作的左操作数时在某些特定上下文中的类型

虽然不及ISO标准规范严谨，但凡是language spec，理解起来都是有门槛的。这个改进针对的是那些未指定类型的常量，在作为shift非常量位操作的左操作数时，在shift表达式结果作为下标表达式中的下标、切片表达式下标或者make函数调用中的size参数时，这个常量将被赋予int类型。我们还是看个例子更加直观：

// go1.10-examples/spec/untypedconst.go
package main

var (
    s uint = 2
)

func main() {
    a := make([]int, 10)
    a[1.0<<s] = 4
}

上面的例子中，重点看a[1.0 << s] = 4这一行，这一行恰好满足了几个条件：

• 1.0 << s 是一个shift表达式，且作为slide表达式的下标；
• shift表达式所移动的位数为s，s是一个变量，非常量，因此这是一个非常量位的移位操作；
• 1.0是未指定类型的常量(untyped const)，且作为shift表达式左操作数

在Go 1.9.2下面，上面的程序编译结果如下：

// go 1.9.2编译器build：

$go build untypedconst.go
# command-line-arguments
./untypedconst.go:9:7: invalid operation: 1 << s (shift of type float64)

在Go 1.9.2下，1.0这个常量被compiler赋予了float64类型，导致编译出错。在Go 1.10下，根据最新的spec，1.0被赋予了int型，编译则顺利通过。

但一旦脱离了下标这个上下文环境，1.0这个常量依旧会被compiler识别为float64类型，比如下面代码中1.0<<s作为Println的参数就是不符合语法的：

// go1.10-examples/spec/untypedconst.go
package main

import "fmt"

var (
    s uint = 2
)

func main() {
    a := make([]int, 10)
    a[1.0<<s] = 4
    fmt.Println(1.0<<s)
}

// go 1.10rc2编译器build：
 $go build untypedconst.go
# command-line-arguments
./untypedconst.go:12:17: invalid operation: 1 << s (shift of type float64)
./untypedconst.go:12:17: cannot use 1 << s as type interface {} in argument to fmt.Println

3、明确预声明类型(predeclared type)是defined type还是alias type

Go在1.9版本中引入了alias语法，同时引入defined type(以替代named type)和alias type，并使用alias语法对某些predeclared type的实现进行了调整。在Go 1.10 spec中，Griesemer进一步明确了哪些predeclared type是alias type：

目前内置的predeclared type只有两个类型是alias type:

byte        alias for uint8
rune        alias for int32

其余的predeclared type都是defined type。

4、移除spec中对method expression: T.m中T的类型的限制

这次是spec落伍于compiler了。Go 1.9.2就可以顺利编译运行下面的代码：

//go1.10-examples/spec/methodexpression.go
package main

import "fmt"

type foo struct{}
func (foo)f() {
    fmt.Println("i am foo")
}

func main() {
    interface{f()}.f(foo{})
}

但在Go 1.9.2的spec中，对Method expression的定义如下：

Go 1.9.2 spec:

MethodExpr    = ReceiverType "." MethodName .
ReceiverType  = TypeName | "(" "*" TypeName ")" | "(" ReceiverType ")" .

Go 1.9.2的spec说，method expression形式:T.m中的T仅能使用Typename，而非上述代码中type实现。Go 1.10的spec中放开了对method expression中T的限制，使得type的实现也可以作为T调用method，与编译器的实际实现行为同步：

Go 1.10rc2 spec:

MethodExpr    = ReceiverType "." MethodName .
ReceiverType  = Type .

不过目前Go 1.10 rc2 compiler还存在一个问题，我们看一下下面的代码：

//go1.10-examples/spec/methodexpression1.go
package main

func main() {
    (*struct{ error }).Error(nil)
}

使用Go 110rc2构建该源码，得到如下错误：

$go build methodexpression1.go
# command-line-arguments
go.(*struct { error }).Error: call to external function
main.main: relocation target go.(*struct { error }).Error not defined
main.main: undefined: "go.(*struct { error }).Error"

该问题目前已经有issue对应，状态还是Open。

二、工具

Go语言有着让其他主流编程语言羡慕的工具集，每次Go版本更新，工具集都会得到进一步的加强，无论是功能还是从开发者体验方面，都有提升。

1、默认的GOROOT

继Go 1.8版本引入默认的GOPATH后，Go 1.10版本为继续改进Go工具的开发者体验，进一步降低新手的使用门槛，引入了默认GOROOT：即开发者无需显式设置GOROOT环境变量，go程序会自动根据自己所在路径推导出GOROOT的路径。这样一来，Gopher们就可以将下载的Go预编译好的安装包解压放置到任意本地路径下，唯一要做的就是将go二进制程序路径放置到PATH环境变量中。比如我们将go1.10rc2的安装包解压到下面路径下：

➜  /Users/tony/.bin/go1.10rc2 $ls
AUTHORS            LICENSE            VERSION            blog/            lib/            robots.txt
CONTRIBUTING.md        PATENTS            api/            doc/            misc/            src/
CONTRIBUTORS        README.md        bin/            favicon.ico        pkg/            test/

在设置为PATH后，我们通过go env命令查看go自动推导的GOROOT以及其他相关变量的值：

$go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/Users/tony/Library/Caches/go-build"
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/tony/go"
GORACE=""
GOROOT="/Users/tony/.bin/go1.10rc2"
GOTMPDIR=""
GOTOOLDIR="/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -gno-record-gcc-switches -fno-common"

从输出结果看到，go正确找到了安装路径，并得到了GOROOT信息。

2、增加GOTMPDIR变量

在上面的go env命令输出内容中，我们发现了一个陌生的变量：GOTMPDIR，其值默认为空串。这个GOTMPDIR变量是Go 1.10新引入的变量，用于设置Go tool创建和使用的临时文件的路径的。有人可能会说：这个变量看似没什么必要，直接用系统的/tmp路径就好了啊。但是在/tmp路径中编译和执行编译后的程序至少有两点问题，这些问题实际上在go的issues历史中已经存在许久了：

• 有些机器上/tmp路径下被设置了无执行权限(set noexec)
• 有些机器上/tmp下空间有限

我们知道默认情况下，go build和go run都会在/tmp下设置一个临时WORK目录来编译源码和执行编译后的程序的，从下面的一个最简单的helloworld源码的编译执行过程输出(WORK变量)，我们就能看到这点：

// on ubuntu 16.04

# go run -x hello.go
WORK=/tmp/go-build001434392
mkdir -p $WORK/b001/
... ...
mkdir -p $WORK/b001/exe/
cd .
/root/.bin/go1.10rc2/pkg/tool/linux_amd64/link -o $WORK/b001/exe/hello -importcfg $WORK/b001/importcfg.link -s -w -buildmode=exe -buildid=fcYMWp_1J2Xqgzc_Vdga/UpnEUti07R2GzG8dUU3x/MLkSlJVesZhf2kQUaDUU/fcYMWp_1J2Xqgzc_Vdga -extld=gcc /root/.cache/go-build/9f/9f34be2dbcc3f8a62dd6efd6d35be18ecdcbc49e3c8b52b003ecd72b6264e19e-d
$WORK/b001/exe/hello

我个人就遇到过由于IaaS供应商提供的系统盘（不允许定制和修改）过小，导致系统盘空间满，使得Go应用构建和执行失败的问题。我们来设置一下GOTMPDIR，看看效果。我们将GOTMPDIR设置为~/.gotmp，生效后，重新build上面的那个helloworld代码：

# go build -x hello.go
WORK=/root/.gotmp/go-build452283009
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg << 'EOF' # internal
... ...
mkdir -p $WORK/b001/exe/
cd .
/root/.bin/go1.10rc2/pkg/tool/linux_amd64/link -o $WORK/b001/exe/a.out -importcfg $WORK/b001/importcfg.link -buildmode=exe -buildid=kO-wBNzMZmfHCKzMDziw/jCGBCt7bcrS5NEN-cR4H/8-du6iTQz8uPH3UC-FtB/kO-wBNzMZmfHCKzMDziw -extld=gcc $WORK/b001/_pkg_.a
/root/.bin/go1.10rc2/pkg/tool/linux_amd64/buildid -w $WORK/b001/exe/a.out # internal
mv $WORK/b001/exe/a.out hello
rm -r $WORK/b001/

可以看到，go tool转移到我们设置的GOTMPDIR下构建和执行了。

3、通过cache实现增量构建，提高go tools性能

Go语言具有较高的编译性能是Go语言最初设计时就确定下来的目标，Go编译器的性能在Go 1.4.3版本达到顶峰，这虽然是得益于其使用C语言实现，但更重要的是其为高性能构建而定义的便于依赖分析的语言构建模型，同时避免了像C/C++那样的重复多次扫描大量头文件的负担。随着Go自举的实现，使用Go语言实现的go compiler性能有较大下降，但即便这样，其编译速度在主流编程语言中仍然是数一数二的。在经过了Go 1.6到Go1.9等多个版本对compiler的优化后，go compiler的编译速度已经恢复到Go 1.4.3 compiler的2/3左右或是更为接近的水平。在Go 1.9版本引入并行编译后，Go team在提升工具性能方面的思路发生了些许变化：不再是一味地进行代码级的性能优化，而是选择通过Cache，重复利用中间结果，实现增量构建，来减少编译构建所用的时间。因此，笔者觉得这个功能是本次Go 1.10最大的变化之一。

1) 概述

Go 1.10版本以前，我们经常通过go build -i来加快Go项目源码的编译速度，其原因在于go build -i首次执行时会将目标所依赖的package安装到$GOPATH/pkg下面(.a文件)，这样后续执行go build时，构建过程将不会重新编译目标文件的依赖包，而是直接链接首次执行build -i时安装的依赖包，以实现加速编译！以gocmpp/examples/client为例，第二次构建所需时间仅为首次构建的四分之一左右：

➜  $GOPATH/src/github.com/bigwhite/gocmpp/examples/client git:(master) ✗ $time go build -i client.go
go build -i client.go  1.34s user 0.34s system 131% cpu 1.274 total
➜  $GOPATH/src/github.com/bigwhite/gocmpp/examples/client git:(master) ✗ $time go build -i client.go
go build -i client.go  0.38s user 0.16s system 116% cpu 0.465 total

只有当目标文件的依赖包的源文件发生变化时（比对源文件的修改时间与.a文件的修改时间作为是否重新编译的判断依据），才会重新编译安装这些依赖包。这有些像Makefile的原理：make工具会比较targets文件和prerequisites文件的修改日期，如果prerequisites文件的日期要比targets文件的日期要新，或者target不存在的话，那么，make就会执行后续定义的命令。

不过即便这样，依然至少有两个问题困扰着Go team和广大Gopher：

• 基于时间戳的比对，并不“合理”
  当某个目标文件的依赖包的源文件内容并未真正发生变化，但“修改时间”发生变化了，比如：添加了一行，保存了；然后又删除了这一行，保存。在这样的情况下，理想的操作是不需要重新编译安装这个依赖包，但目前的go build -i机制会重新编译并安装这个依赖包。

• 增量构建并未实现“常态化”
  以前版本中，默认的不带命令行参数的go build命令是不会安装依赖包的，因此每次执行go build，都会重新编译一次依赖包的源码，并将结果放入临时目录以供最终链接使用。也就是说最为常用的go build并未实现增量编译，社区需要常态化的“增量编译”，进一步提高效率。

Go 1.10引入cache机制来解决上述问题。从1.10版本开始，go build tool将维护一个package编译结果的缓存以及一些元数据，缓存默认位于操作系统指定的用户缓存目录中，其中数据用于后续构建重用；不仅go build支持“常态化”的增量构建，go test也支持在特定条件下缓存test结果，从而加快执行测试的速度。

b) go build with cache

我们先来直观的看看go 1.10 build带来的效果，初始情况cache为空：

以我的一个小项目gocmpp为例，用go 1.10第一次build该项目：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $time go build
go build  1.22s user 0.43s system 175% cpu 0.939 total

我们再来构建一次：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $time go build
go build  0.12s user 0.16s system 155% cpu 0.182 total

0.12s vs. 1.22s！通过cache进行的build将构建时间压缩为原来的1/10！为了弄清楚go build幕后行为，我们清除一下cache(go clean -cache)，再重新build，这次我们通过-v -x 输出详细构建过程：

首次编译的详细输出信息：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go build -x -v
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build735203690
github.com/bigwhite/gocmpp/vendor/golang.org/x/text/encoding/internal/identifier
mkdir -p $WORK/b033/
cat >$WORK/b033/importcfg << 'EOF' # internal
# import config
EOF
cd $(GOPATH)/src/github.com/bigwhite/gocmpp/vendor/golang.org/x/text/encoding/internal/identifier
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/compile -o $WORK/b033/_pkg_.a -trimpath $WORK/b033 -p github.com/bigwhite/gocmpp/vendor/golang.org/x/text/encoding/internal/identifier -complete -buildid iZWJNg2FYmWoSCXb640o/iZWJNg2FYmWoSCXb640o -goversion go1.10rc2 -D "" -importcfg $WORK/b033/importcfg -pack -c=4 ./identifier.go ./mib.go
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/buildid -w $WORK/b033/_pkg_.a # internal
cp $WORK/b033/_pkg_.a /Users/tony/Library/Caches/go-build/14/14223040d851359359b0e531555a47e22f5dbd4bf434acc136a7c70c1fc3663f-d # internal
github.com/bigwhite/gocmpp/vendor/golang.org/x/text/transform
mkdir -p $WORK/b031/
cat >$WORK/b031/importcfg << 'EOF' # internal
# import config
packagefile bytes=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/bytes.a
packagefile errors=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/errors.a
packagefile io=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/io.a
packagefile unicode/utf8=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/unicode/utf8.a
EOF

.... ....

cd $(GOPATH)/src/github.com/bigwhite/gocmpp
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p github.com/bigwhite/gocmpp -complete -buildid 6LaoHtjkFhandbEhv7zD/6LaoHtjkFhandbEhv7zD -goversion go1.10rc2 -D "" -importcfg $WORK/b001/importcfg -pack -c=4 ./activetest.go ./client.go ./conn.go ./connect.go ./deliver.go ./fwd.go ./packet.go ./receipt.go ./server.go ./submit.go ./terminate.go
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/buildid -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a /Users/tony/Library/Caches/go-build/e0/e02a5fec0835ca540b62053fdea82589e686e88bf48f18355ed38d41ad19f334-d # internal

再次编译的详细输出信息：

$go build -x -v
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build906548554

我们来分析一下。首次构建时，我们看到gocmpp依赖的每个包以及自身的包都会被编译，并被copy到/Users/tony/Library/Caches/go-build/下面的某个目录下，包括最终的gocmpp包也是这样。第二次build时，我们看到仅仅输出一行信息，这是因为go compiler在cache中找到了gocmpp包对应的编译好的缓存结果，无需进行实际的编译了。

前面说过，go 1.10 compiler决定是否重新编译包是content based的，而不是依照时间戳比对来决策。我们来修改一个gocmpp包中的文件fwd.go，删除一个空行，再恢复这个空行，保存退出。我们再来编译一下gocmpp:

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go build -x -v
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build857409409

可以看到go compiler并没有重新编译任何包。如果我们真实改变了fwd.go的内容，比如删除一个空行，保存后再次编译：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go build -x -v
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build437927548
github.com/bigwhite/gocmpp
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile bytes=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/bytes.a
packagefile crypto/md5=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/crypto/md5.a
packagefile encoding/binary=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/encoding/binary.a
packagefile errors=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/errors.a
packagefile fmt=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/fmt.a
packagefile github.com/bigwhite/gocmpp/utils=/Users/tony/Test/GoToolsProjects/pkg/darwin_amd64/github.com/bigwhite/gocmpp/utils.a
packagefile io=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/io.a
packagefile log=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/log.a
packagefile net=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/net.a
packagefile os=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/os.a
packagefile strconv=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/strconv.a
packagefile strings=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/strings.a
packagefile sync=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/sync.a
packagefile sync/atomic=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/sync/atomic.a
packagefile time=/Users/tony/.bin/go1.10rc2/pkg/darwin_amd64/time.a
EOF
cd /Users/tony/Test/GoToolsProjects/src/github.com/bigwhite/gocmpp
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/compile -o $WORK/b001/_pkg_.a -trimpath $WORK/b001 -p github.com/bigwhite/gocmpp -complete -buildid trn5lvvRTk_UP3LcT5CC/trn5lvvRTk_UP3LcT5CC -goversion go1.10rc2 -D "" -importcfg $WORK/b001/importcfg -pack -c=4 ./activetest.go ./client.go ./conn.go ./connect.go ./deliver.go ./fwd.go ./packet.go ./receipt.go ./server.go ./submit.go ./terminate.go
/Users/tony/.bin/go1.10rc2/pkg/tool/darwin_amd64/buildid -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a /Users/tony/Library/Caches/go-build/7a/7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d # internal

Go compiler发现了内容的变动，对gocmpp包的变动内容进行了重新compile。

c) 缓存目录探索

在增加cache机制时，go tools增加了GOCACHE变量，通过go env GOCACHE查看变量值：

$go env GOCACHE
/Users/tony/Library/Caches/go-build

如果未重设环境变量GOCACHE，那么默认在Linux上，GOCACHE=”~/.cache/go-build”; 在Mac OS X上，GOCACHE=”/Users/UserName/Library/Caches/go-build”。在 OS X上，我们进入$GOCACHE目录，映入眼帘的是：

➜  /Users/tony/Library/Caches/go-build $ls
00/        18/        30/        48/        60/        78/        90/        a7/        bf/        d7/        ef/
01/        19/        31/        49/        61/        79/        91/        a8/        c0/        d8/        f0/
02/        1a/        32/        4a/        62/        7a/        92/        a9/        c1/        d9/        f1/
03/        1b/        33/        4b/        63/        7b/        93/        aa/        c2/        da/        f2/
04/        1c/        34/        4c/        64/        7c/        94/        ab/        c3/        db/        f3/
05/        1d/        35/        4d/        65/        7d/        95/        ac/        c4/        dc/        f4/
06/        1e/        36/        4e/        66/        7e/        96/        ad/        c5/        dd/        f5/
07/        1f/        37/        4f/        67/        7f/        97/        ae/        c6/        de/        f6/
08/        20/        38/        50/        68/        80/        98/        af/        c7/        df/        f7/
09/        21/        39/        51/        69/        81/        99/        b0/        c8/        e0/        f8/
0a/        22/        3a/        52/        6a/        82/        9a/        b1/        c9/        e1/        f9/
0b/        23/        3b/        53/        6b/        83/        9b/        b2/        ca/        e2/        fa/
0c/        24/        3c/        54/        6c/        84/        9c/        b3/        cb/        e3/        fb/
0d/        25/        3d/        55/        6d/        85/        9d/        b4/        cc/        e4/        fc/
0e/        26/        3e/        56/        6e/        86/        9e/        b5/        cd/        e5/        fd/
0f/        27/        3f/        57/        6f/        87/        9f/        b6/        ce/        e6/        fe/
10/        28/        40/        58/        70/        88/        README        b7/        cf/        e7/        ff/
11/        29/        41/        59/        71/        89/        a0/        b8/        d0/        e8/        log.txt
12/        2a/        42/        5a/        72/        8a/        a1/        b9/        d1/        e9/        trim.txt
13/        2b/        43/        5b/        73/        8b/        a2/        ba/        d2/        ea/
14/        2c/        44/        5c/        74/        8c/        a3/        bb/        d3/        eb/
15/        2d/        45/        5d/        75/        8d/        a4/        bc/        d4/        ec/
16/        2e/        46/        5e/        76/        8e/        a5/        bd/        d5/        ed/
17/        2f/        47/        5f/        77/        8f/        a6/        be/        d6/        ee/

熟悉git原理的朋友一定觉得这个目录组织结构似曾相识！没错，在每个git项目的./git/object目录下，我们也能看到下面的结果：

.git/objects git:(master) $ls
00/    0c/    18/    24/    30/    3c/    48/    54/    60/    6c/    78/    84/    90/    9c/    a8/    b4/    c0/    cc/    d8/    e4/    f0/    fc/
01/    0d/    19/    25/    31/    3d/    49/    55/    61/    6d/    79/    85/    91/    9d/    a9/    b5/    c1/    cd/    d9/    e5/    f1/    fd/
02/    0e/    1a/    26/    32/    3e/    4a/    56/    62/    6e/    7a/    86/    92/    9e/    aa/    b6/    c2/    ce/    da/    e6/    f2/    fe/
03/    0f/    1b/    27/    33/    3f/    4b/    57/    63/    6f/    7b/    87/    93/    9f/    ab/    b7/    c3/    cf/    db/    e7/    f3/    ff/
04/    10/    1c/    28/    34/    40/    4c/    58/    64/    70/    7c/    88/    94/    a0/    ac/    b8/    c4/    d0/    dc/    e8/    f4/    info/
05/    11/    1d/    29/    35/    41/    4d/    59/    65/    71/    7d/    89/    95/    a1/    ad/    b9/    c5/    d1/    dd/    e9/    f5/    pack/
06/    12/    1e/    2a/    36/    42/    4e/    5a/    66/    72/    7e/    8a/    96/    a2/    ae/    ba/    c6/    d2/    de/    ea/    f6/
07/    13/    1f/    2b/    37/    43/    4f/    5b/    67/    73/    7f/    8b/    97/    a3/    af/    bb/    c7/    d3/    df/    eb/    f7/
08/    14/    20/    2c/    38/    44/    50/    5c/    68/    74/    80/    8c/    98/    a4/    b0/    bc/    c8/    d4/    e0/    ec/    f8/
09/    15/    21/    2d/    39/    45/    51/    5d/    69/    75/    81/    8d/    99/    a5/    b1/    bd/    c9/    d5/    e1/    ed/    f9/
0a/    16/    22/    2e/    3a/    46/    52/    5e/    6a/    76/    82/    8e/    9a/    a6/    b2/    be/    ca/    d6/    e2/    ee/    fa/
0b/    17/    23/    2f/    3b/    47/    53/    5f/    6b/    77/    83/    8f/    9b/    a7/    b3/    bf/    cb/    d7/    e3/    ef/    fb/

这里猜测go 1.10使用的应该是与git一类内容摘要算法以及组织存储模式。在前面的build详细输出中，我们找到这一行：

cp $WORK/b001/_pkg_.a /Users/tony/Library/Caches/go-build/7a/7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d # internal

这行命令是将gocmpp包复制到cache下，我们到cache的7a目录下一查究竟：

➜  /Users/tony/Library/Caches/go-build/7a $tree
.
└── 7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d

0 directories, 1 file

我们用nm命令查看一下该文件：

$go tool nm 7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d|more
1c319 T %22%22.(*Client).Connect
   2e279 T %22%22.(*Client).Connect.func1
   3fc22 R %22%22.(*Client).Connect.func1·f
   1c79f T %22%22.(*Client).Disconnect
   1c979 T %22%22.(*Client).RecvAndUnpackPkt
   1c807 T %22%22.(*Client).SendReqPkt
   1c8e2 T %22%22.(*Client).SendRspPkt
   1e417 T %22%22.(*Cmpp2ConnRspPkt).Pack
... ...

这个文件的确就是gocmpp.a文件。通过比对该文件size与go install后的文件size也可以证实这一点：

➜  /Users/tony/Library/Caches/go-build/7a $
-rw-r--r--    1 tony  staff  445856 Feb 15 22:34 7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499-d

vs.

➜  $GOPATH/pkg/darwin_amd64/github.com/bigwhite $ll
-rw-r--r--  1 tony  staff  445856 Feb 15 23:27 gocmpp.a

也就是说go compiler将编译后的package的.a文件求取摘要值后，将.a文件存储在$GOCACHE下的某个目录中，这个目录名即为摘要值的前两位（比如”7a”），.a文件名字被换成其摘要值，以便后续查找并做比对。

cache目录下还有一个重要文件：log.txt，这个文件是用来记录缓存管理日志的，其内容格式如下：

//log.txt
... ...

1518705271 get 7533a063cd8c37888b19674bf4a4bb7e25fa422041082566530d58538c031516
1518705271 miss b6b9f996fbd14e4fd43f72dc4f9082946cddd0d61d6c6143c88502c8a4001666
1518705271 put b6b9f996fbd14e4fd43f72dc4f9082946cddd0d61d6c6143c88502c8a4001666 7a5671578ed30b125257fd16d0f0b8ceaefd0acc3e44f082ffeecea9f1895499 445856
1518705271 put f5a641ca081a0d2d794b0b54aa9f89014dbb6ff8d14d26543846e1676eca4c21 e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 0
1518708456 get 899589360d856265a84825dbeb8d283ca84e12f154eefc12ba84870af13e1f63
1518708456 get 8a7fcd97a5f36bd00ef084856c63e4e2facedce33d19a5b557cc67f219787661

该日志文件更多的用途是帮助Russ Cox对其开发的cache进行调试和问题诊断的。当然，如果您对于cache的机制原理也很精通，那么也可以让log.txt帮你诊断涉及cache的问题。

d) go test with cache

go 1.10版的go test也会维护一个cache，这个cache缓存了go test执行的测试结果。同时在go 1.10中，go test被分为两种执行模式：local directory mode和package list mode，在不同模式下，cache机制的介入是不同的。

local directory mode，即go test以整个当前目录作为隐式参数的执行模式，比如在某个目录下执行”go test”，go test后面不带任何显式的package列表参数（当然可以带着其他命令行flag参数，如-v）。在这种模式下，cache机制不会介入，go test的执行过程与go 1.10版本之前没有两样。还是以gocmpp这个项目为例，我们以local directory mode执行go test：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test
PASS
ok      github.com/bigwhite/gocmpp    0.011s

如果缓存机制介入，输出的test结果中会出现cached字样，显然上面的go test执行过程并没有使用test cache。

package list mode，即go test后面显式传入了package列表，比如：go test math、go test .、go test ./…等，在这种模式下，test cache机制会介入。我们连续两次在gocmpp目录下执行go test .：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test .
ok      github.com/bigwhite/gocmpp    0.011s
➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test .
ok      github.com/bigwhite/gocmpp    (cached)

如果你此时想进一步看看go test执行的详细输出，你可以会执行go test -v .：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test -v .
=== RUN   TestTypeString
--- PASS: TestTypeString (0.00s)
=== RUN   TestCommandIdString
--- PASS: TestCommandIdString (0.00s)
=== RUN   TestOpError
--- PASS: TestOpError (0.00s)
... ...
=== RUN   TestCmppTerminateRspPktPack
--- PASS: TestCmppTerminateRspPktPack (0.00s)
=== RUN   TestCmppTerminateRspUnpack
--- PASS: TestCmppTerminateRspUnpack (0.00s)
PASS
ok      github.com/bigwhite/gocmpp    0.017s

你会发现，这次go test并没有使用cache。如果你再执行一次go test -v .：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test -v .
=== RUN   TestTypeString
--- PASS: TestTypeString (0.00s)
=== RUN   TestCommandIdString
--- PASS: TestCommandIdString (0.00s)
=== RUN   TestOpError
--- PASS: TestOpError (0.00s)
... ...
=== RUN   TestCmppTerminateRspPktPack
--- PASS: TestCmppTerminateRspPktPack (0.00s)
=== RUN   TestCmppTerminateRspUnpack
--- PASS: TestCmppTerminateRspUnpack (0.00s)
PASS
ok      github.com/bigwhite/gocmpp    (cached)

test cache又起了作用。似乎cache对于go test .和go test -v .是独立的。没错，release note中给出的go test cache的介入条件如下：

• 本次测试的执行程序以及命令行（及参数）与之前的一次test运行匹配；（这就能解释为何go test -v .没有使用go test .执行的cache了）；
• 上次测试执行时的文件和环境变量在本次没有发生变化；
• 测试结果是成功的；
• 以package list node运行测试；
• go test的命令行参数使用”-cpu, -list, -parallel, -run, -short和 -v”的一个子集时

就像前面我们看到的，cache介入的go test结果不会显示test消耗的时间，而是以(cached)字样替代。

绝大多数Gopher都是喜欢test with cache的，但总有一些情况，cache是不受欢迎的。其实前面的条件已经明确告知gopher们什么条件下test cache是可以不介入的。一个惯用的关闭test cache的方法是使用-count=1：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test -count=1  -v .
=== RUN   TestTypeString
--- PASS: TestTypeString (0.00s)
=== RUN   TestCommandIdString
--- PASS: TestCommandIdString (0.00s)
=== RUN   TestOpError
--- PASS: TestOpError (0.00s)
... ...
=== RUN   TestCmppTerminateRspPktPack
--- PASS: TestCmppTerminateRspPktPack (0.00s)
=== RUN   TestCmppTerminateRspUnpack
--- PASS: TestCmppTerminateRspUnpack (0.00s)
PASS
ok      github.com/bigwhite/gocmpp    0.012s

go 1.10中的go test与之前版本还有一个不同，那就是go test在真正执行test前会自动对被测试的包执行go vet，但这个vet只会识别那些最为明显的问题。并且一旦发现问题，go test将会视这些问题与build error同级别，阻断test的执行，并让其出现在test failure中。当然gopher可以通过go test -vet=off关闭这个前置于测试的vet检查。

4. pprof

go tool pprof做了一个较大的改变：增加了Web UI，以后可以和go trace一起通过图形化的方法对Go程序进行调优了。可视化的pprof使用起来十分简单，我们以gocmpp为例，试用一下go 1.10的pprof，首先我们生成cpu profile文件：

➜  $GOPATH/src/github.com/bigwhite/gocmpp git:(master) ✗ $go test -run=^$ -bench=. -cpuprofile=profile.out
goos: darwin
goarch: amd64
pkg: github.com/bigwhite/gocmpp
BenchmarkRecvAndUnpackPkt-4                1000000          1534 ns/op
BenchmarkCmppConnReqPktPack-4              1000000          1398 ns/op
BenchmarkCmppConnReqPktUnpack-4            3000000           450 ns/op
BenchmarkCmpp2DeliverReqPktPack-4          1000000          1156 ns/op
BenchmarkCmpp2DeliverReqPktUnpack-4        3000000           567 ns/op
BenchmarkCmpp3DeliverReqPktPack-4          1000000          1173 ns/op
BenchmarkCmpp3DeliverReqPktUnpack-4        3000000           465 ns/op
BenchmarkCmpp2FwdReqPktPack-4              1000000          2079 ns/op
BenchmarkCmpp2FwdReqPktUnpack-4            1000000          1276 ns/op
BenchmarkCmpp3FwdReqPktPack-4              1000000          2507 ns/op
BenchmarkCmpp3FwdReqPktUnpack-4            1000000          1286 ns/op
BenchmarkCmpp2SubmitReqPktPack-4           1000000          1845 ns/op
BenchmarkCmpp2SubmitReqPktUnpack-4         1000000          1251 ns/op
BenchmarkCmpp3SubmitReqPktPack-4           1000000          1863 ns/op
BenchmarkCmpp3SubmitReqPktUnpack-4         2000000           656 ns/op
PASS
ok      github.com/bigwhite/gocmpp    26.621s

启动pprof web ui：

$go tool pprof -http=:8080 profile.out

pprof会自动打开默认浏览器，进入下面页面：

在view菜单中，我们可以看到”top”、”graph”、”peek”、”source”和”disassemble”几个选项，这些选项可以帮助你在各种视图间切换，默认初始为graph view。不过目前view菜单中并没有”Flame Graph(火焰图)”选项，要想使用Flame Graph，我们需要使用原生的pprof工具，该工具可通过go get -u github.com/google/pprof获取，install后原生pprof将出现在$GOROOT/bin下面。

使用原生pprof启动Web UI：

$pprof -http=:8080 profile.out

原生pprof同样会自动打开浏览器，进入下面页面：

原生的pprof的web ui看起来比go 1.10 tool中的pprof更为精致，且最大的不同在于VIEW菜单下出现了”Flame Graph”菜单项！我们点击该菜单项，一幅Flame Graph便呈现在眼前：

关于如何做火焰图分析不是这里的主要任务，请各位Gopher自行脑补。更多关于Go性能调优问题，可以参考Go官方提供的诊断手册。

四、标准库

和之前的每次Go版本发布一样，标准库的改变是多且细碎的，这里不能一一举例说明。并且很多涉“专业领域”的包，比如加解密，需要一定专业深度，因此这里仅列举几个“通用”的变化^0^。

1、strings.Builder

strings包增加一个新的类型：Builder，用于在“拼字符串”场景中替代bytes.Buffer，由于使用了一些unsafe包的黑科技，在用户调用Builder.String()返回最终拼成的字符串时，避免了一些重复的、不必要的内存copy，提升了处理性能，优化了内存分配。我们用一个demo来看看这种场景下Builder的优势：

//go1.10-examples/stdlib/stringsbuilder/builer.go
package builder

import (
    "bytes"
    "strings"
)

type BuilderByBytesBuffer struct {
    b bytes.Buffer
}
func (b *BuilderByBytesBuffer) WriteString(s string) error {
    _, err := b.b.WriteString(s)
    return err
}
func (b *BuilderByBytesBuffer) String() string{
    return b.b.String()
}

type BuilderByStringsBuilder struct {
    b strings.Builder
}

func (b *BuilderByStringsBuilder) WriteString(s string) error {
    _, err := b.b.WriteString(s)
    return err
}
func (b *BuilderByStringsBuilder) String() string{
    return b.b.String()
}

针对上面代码中的BuilderByBytesBuffer和BuilderByStringsBuilder进行Benchmark的Test源文件如下：

//go1.10-examples/stdlib/stringsbuilder/builer_test.go
package builder

import "testing"

func BenchmarkBuildStringWithBytesBuffer(b *testing.B) {
    var builder BuilderByBytesBuffer

    for i := 0; i < b.N; i++ {
        builder.WriteString("Hello, ")
        builder.WriteString("Go")
        builder.WriteString("-1.10")
        _ = builder.String()
    }

}
func BenchmarkBuildStringWithStringsBuilder(b *testing.B) {

    var builder BuilderByStringsBuilder

    for i := 0; i < b.N; i++ {
        builder.WriteString("Hello, ")
        builder.WriteString("Go")
        builder.WriteString("-1.10")
        _ = builder.String()
    }
}

执行该Benchmark，查看结果：

$go test -bench . -benchmem
goos: darwin
goarch: amd64
pkg: github.com/bigwhite/experiments/go1.10-examples/stdlib/stringsbuilder
BenchmarkBuildStringWithBytesBuffer-4            100000        108471 ns/op      704073 B/op           1 allocs/op
BenchmarkBuildStringWithStringsBuilder-4       20000000           122 ns/op          80 B/op           0 allocs/op
PASS
ok      github.com/bigwhite/experiments/go1.10-examples/stdlib/stringsbuilder    13.616s

可以看到StringsBuilder在处理速度和分配优化上都全面强于bytes.Buffer，真实的差距就在Builder.String这个方法上。

2、bytes包

bytes包的几个方法Fields, FieldsFunc, Split和SplitAfter在底层实现上有变化，使得外部展现的行为有所变化，我们通过一个例子直观的感受一下：

// go1.10-examples/stdlib/bytessplit/main.go
package main

import (
    "bytes"
    "fmt"
)

// 来自github.com/campoy/gotalks/blob/master/go1.10/bytes/fields.go
func desc(b []byte) string {
    return fmt.Sprintf("len: %2d | cap: %2d | %q\n", len(b), cap(b), b)
}

func main() {
    text := []byte("Hello, Go1.10 is coming!")
    fmt.Printf("text:  %s", desc(text))

    subslices := bytes.Split(text, []byte(" "))
    fmt.Printf("subslice 0:  %s", desc(subslices[0]))
    fmt.Printf("subslice 1:  %s", desc(subslices[1]))
    fmt.Printf("subslice 2:  %s", desc(subslices[2]))
    fmt.Printf("subslice 3:  %s", desc(subslices[3]))
}

我们先用Go 1.9.2编译运行一下该demo:

$go run main.go
text:  len: 24 | cap: 32 | "Hello, Go1.10 is coming!"
subslice 0:  len:  6 | cap: 32 | "Hello,"
subslice 1:  len:  6 | cap: 25 | "Go1.10"
subslice 2:  len:  2 | cap: 18 | "is"
subslice 3:  len:  7 | cap: 15 | "coming!"

我们再用go 1.10rc2运行一下该demo：

$go run main.go
text:  len: 24 | cap: 32 | "Hello, Go1.10 is coming!"
subslice 0:  len:  6 | cap:  6 | "Hello,"
subslice 1:  len:  6 | cap:  6 | "Go1.10"
subslice 2:  len:  2 | cap:  2 | "is"
subslice 3:  len:  7 | cap: 15 | "coming!"

对比两次输出结果中cap那一列，你会发现go 1.10输出的结果中的每个subslice(除了最后一个)的len与cap值都是相等的，而不是将原slice剩下所有cap都作为subslice的cap。这个行为的改变是出于安全的考虑，防止共享一个underlying slice的各个subslice的修改对相邻的subslice造成影响，因此限制它们的capacity。

在Fields, FieldsFunc, Split和SplitAfter这几个方法的具体实现上，Go 1.10使用了我们平时并不经常使用的”Full slice expression“，即：a[low, high, max]来指定subslice的cap。

五、性能

对于静态编译类型语言Go来说，性能也一直是其重点关注的设计目标，这两年来发布的Go版本，几乎每个都给Gopher们带来惊喜。谈到Go性能，Gopher们一般关心的有如下这么几个方面：

1、编译性能

Go 1.10的编译性能正如我们前面所说的那样，最大的改变在于cache机制的实现。事实证明cache机制的使用在日常开发过程中，会很大程度上提升你的工作效率，越是规模较大的项目越是如此。

2、目标代码的性能

这些年Go team在不断优化编译器生成的目标代码的性能，比如在Go 1.7版本中引入ssa后端。Go 1.10延续着对目标代码生成的进一步优化，虽说动作远不如引入ssa这么大。

3、GC性能

GC的性能一直是广大Gopher密切关注的事情，Go 1.10在减少内存分配延迟以及GC运行时的负担两个方面做了许多工作，但从整体上来看，Go 1.10并没有引入传说中的TOC(Transaction Oritented Collector)，因此宏观上来看，GC变化不是很大。Twitter上的GC性能测试“专家”Brian Hatfield在对Go 1.10rc1的GC测试后，也表示与Go 1.9相比，变化不是很显著。

六、小结

Go 1.10版本又是一个Go team和Gopher社区共同努力的结果，让全世界Gopher都对Go保持着极大的热情和期望。当然Go 1.10中的变化还有许多许多，诸如：

• 对Unicode规范的支持升级到10.0；
• 在不同的平台上，Assembler支持更多高性能的指令；
• plugin支持darwin/amd64等；
• gofmt、go doc在输出格式上进一步优化和提升gopher开发者体验；
• cgo支持直接传递go string到C代码中;
  … …

很多很多！这里限于篇幅原因，不能一一详解了。通读一遍Go 1.10 Release Note是每个Gopher都应该做的。

以上验证在mac OS X, go 1.10rc2上测试，demo源码可以在这里下载。

七、参考资料

• Go 1.10 Release Notes
• The State of Go by campoy
• Go 1.10
• pprof user interface
• cmd/go content-based staleness submitted
• Go 1.10 cmd/go: build cache, test cache, go install, go vet, test vet

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

我的联系方式：

微博：http://weibo.com/bigwhite20xx
微信公众号：iamtonybai
博客：tonybai.com
github: https://github.com/bigwhite

微信赞赏：

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

第1期的“写Go代码时遇到的那些问题”一经发布后得到了很多Gopher的支持和赞赏，这也是我继续写下去的动力！不过这里依然要强调的是这一系列文章反映的是笔者在实践中对代码编写的认知以及代码的演化过程。这里的代码也许只是“中间阶段”，并不是什么最优的结果，我记录的只是对问题、对代码的一个思考历程。不过，十分欢迎交流与批评指正。

一、dep的日常操作

虽然dep在国内使用依然有init失败率较高（因为一些qiang外的第三方package）的坎儿，但我和主流Gopher社区和项目一样，义无反顾地选择在代码库中使用dep。本周dep刚刚发布了0.4.1版本，与之前版本最大的不同在于dep发布了其官网以及相对完整的文档（以替代原先在github项目主页上的简陋的、格式较low的FAQ），这也是dep继续走向成熟的一个标志。不过关于dep何时能merge到go tools链当中，目前还是未知数。不过dep会在相当长的一段时期继续以独立工具的形式存在，直到merge到Go tools中并被广泛接受。

包依赖管理工具在日常开发中并不需要太多的存在感，我们需要的这类工具特征是功能强大但接口“小”，对开发者体验好，不太需要太关心其运行原理，dep基本符合。dep日常操作最主要的三个命令：dep init、dep ensure和dep status。在《初窥dep》一文中，我曾重点说过dep init原理，这里就不重点说了，我们用一个例子来说说使用dep的日常workflow。

1、dep init empty project

我们可以对一个empty project或一个初具框架雏形的project进行init，这里init一个empty project，作为后续的示例基础：

➜  $GOPATH/src/depdemo $dep init -v
Getting direct dependencies...
Checked 1 directories for packages.
Found 0 direct dependencies.
Root project is "depdemo"
 0 transitively valid internal packages
 0 external packages imported from 0 projects
(0)   ✓ select (root)
  ✓ found solution with 0 packages from 0 projects

Solver wall times by segment:
  select-root: 68.406µs
        other:  9.806µs

  TOTAL: 78.212µs

➜  $GOPATH/src/depdemo $ls
Gopkg.lock    Gopkg.toml    vendor/

➜  $GOPATH/src/depdemo $dep status
PROJECT  CONSTRAINT  VERSION  REVISION  LATEST  PKGS USED

dep init有三个输出：Gopkg.lock、Gopkg.toml和vendor目录，其中Gopkg.toml（包含example，但注释掉了）和vendor都是空的，Gopkg.lock中仅包含了一些给gps使用的metadata：

➜  $GOPATH/src/depdemo git:(a337d5b) $cat Gopkg.lock
# This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.

[solve-meta]
  analyzer-name = "dep"
  analyzer-version = 1
  inputs-digest = "ab4fef131ee828e96ba67d31a7d690bd5f2f42040c6766b1b12fe856f87e0ff7"
  solver-name = "gps-cdcl"
  solver-version = 1

2、常规操作循环：for { 填代码 -> dep ensure }

接下来的常规操作就是我们要为project添加代码了。我们先来为工程添加一个main.go文件，源码如下：

// main.go
package main

import "fmt"

func main() {
    fmt.Println("depdemo")
}

这份代码的依赖只是std库的fmt，并没有使用第三方的依赖，因此当我们通过dep status查看当前状态、使用ensure去做同步时，发现dep并没有什么要做的：

➜  $GOPATH/src/depdemo $dep status
PROJECT  CONSTRAINT  VERSION  REVISION  LATEST  PKGS USED
➜  $GOPATH/src/depdemo $dep ensure -v
Gopkg.lock was already in sync with imports and Gopkg.toml

好吧。我们再来为main.go添点“有用”的内容：一段读取toml配置文件的代码。

//data.toml
id = "12345678abcdefgh"
name = "tonybai"
city = "shenyang"

// main.go
package main

import (
    "fmt"
    "log"

    "github.com/BurntSushi/toml"
)

type Person struct {
    ID   string
    Name string
    City string
}

func main() {
    p := Person{}
    if _, err := toml.DecodeFile("./data.toml", &p); err != nil {
        log.Fatal(err)
    }

    fmt.Println(p)
}

之后，再来执行dep status：

➜  $GOPATH/src/depdemo $dep status
Lock inputs-digest mismatch due to the following packages missing from the lock:

PROJECT                     MISSING PACKAGES
github.com/BurntSushi/toml  [github.com/BurntSushi/toml]

This happens when a new import is added. Run `dep ensure` to install the missing packages.
input-digest mismatch

我们看到dep status检测到项目出现”不同步”的情况（代码中引用的toml包在Gopkg.lock中没有），并建议使用dep ensure命令去做一次sync。

我们来ensure一下(ensure的输入输出见上图)：

$GOPATH/src/depdemo git:(master) $dep ensure -v
Root project is "depdemo"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)

(1)    ? attempt github.com/BurntSushi/toml with 1 pkgs; 7 versions to try
(1)        try github.com/BurntSushi/toml@v0.3.0
(1)    ✓ select github.com/BurntSushi/toml@v0.3.0 w/1 pkgs
  ✓ found solution with 1 packages from 1 projects

Solver wall times by segment:
     b-source-exists: 15.821158205s
... ...
  b-deduce-proj-root:       5.453µs

  TOTAL: 16.176846089s

(1/1) Wrote github.com/BurntSushi/toml@v0.3.0

我们来看看项目中的文件都发生了哪些变化：

$git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

    modified:   Gopkg.lock

Untracked files:
  (use "git add <file>..." to include in what will be committed)

    vendor/

可以看到Gopkg.lock文件和vendor目录下发生了变化：

$git diff

diff --git a/Gopkg.lock b/Gopkg.lock
index bef2d00..c5ae854 100644
--- a/Gopkg.lock
+++ b/Gopkg.lock
@@ -1,9 +1,15 @@
 # This file is autogenerated, do not edit; changes may be undone by the next 'dep ensure'.

+[[projects]]
+  name = "github.com/BurntSushi/toml"
+  packages = ["."]
+  revision = "b26d9c308763d68093482582cea63d69be07a0f0"
+  version = "v0.3.0"
+
 [solve-meta]
   analyzer-name = "dep"
   analyzer-version = 1
-  inputs-digest = "ab4fef131ee828e96ba67d31a7d690bd5f2f42040c6766b1b12fe856f87e0ff7"
+  inputs-digest = "25c744eb70aefb94032db749509fd34b2fb6e7c6041e8b8c405f7e97d10bdb8d"
   solver-name = "gps-cdcl"
   solver-version = 1

$tree -L 2 vendor
vendor
└── github.com
    └── BurntSushi

可以看到Gopkg.lock中增加了toml包的依赖条目(版本v0.3.0)，input-digest这个元数据字段的值也发生了变更；并且vendor目录下多了toml包的源码，至此项目又到达了“同步”状态。

3、添加约束

大多数情况下，我们到这里就算完成了dep work flow的一次cycle，但如果你需要为第三方包的版本加上一些约束条件，那么dep ensure -add就会派上用场，比如说：我们要使用toml包的v0.2.x版本，而不是v0.3.0版本，我们需要为github.com/BurntSushi/toml添加一条约束：

$dep ensure -v -add github.com/BurntSushi/toml@v0.2.0
Fetching sources...
(1/1) github.com/BurntSushi/toml@v0.2.0

Root project is "depdemo"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)    ? attempt github.com/BurntSushi/toml with 1 pkgs; at least 1 versions to try
(1)        try github.com/BurntSushi/toml@v0.3.0
(2)    ✗   github.com/BurntSushi/toml@v0.3.0 not allowed by constraint ^0.2.0:
(2)        ^0.2.0 from (root)
(1)        try github.com/BurntSushi/toml@v0.2.0
(1)    ✓ select github.com/BurntSushi/toml@v0.2.0 w/1 pkgs
  ✓ found solution with 1 packages from 1 projects

Solver wall times by segment:
... ...

  TOTAL: 599.252392ms

(1/1) Wrote github.com/BurntSushi/toml@v0.2.0

add约束后，Gopkg.toml中增加了一条记录：

// Gopkg.toml
[[constraint]]
  name = "github.com/BurntSushi/toml"
  version = "0.2.0"

Gopkg.lock中的toml条目的版本回退为v0.2.0：

diff --git a/Gopkg.lock b/Gopkg.lock
index c5ae854..a557251 100644
--- a/Gopkg.lock
+++ b/Gopkg.lock
@@ -4,12 +4,12 @@
 [[projects]]
   name = "github.com/BurntSushi/toml"
   packages = ["."]
-  revision = "b26d9c308763d68093482582cea63d69be07a0f0"
-  version = "v0.3.0"
+  revision = "bbd5bb678321a0d6e58f1099321dfa73391c1b6f"
+  version = "v0.2.0"

 [solve-meta]
   analyzer-name = "dep"
   analyzer-version = 1
-  inputs-digest = "25c744eb70aefb94032db749509fd34b2fb6e7c6041e8b8c405f7e97d10bdb8d"
+  inputs-digest = "9fd144de0cc448be93418c927b5ce2a70e03ec7f260fa7e0867f970ff121c7d7"
   solver-name = "gps-cdcl"
   solver-version = 1

$dep status
PROJECT                     CONSTRAINT  VERSION  REVISION  LATEST  PKGS USED
github.com/BurntSushi/toml  ^0.2.0      v0.2.0   bbd5bb6   v0.2.0  1

vendor目录下的toml包源码也回退到v0.2.0的源码。关于约束规则的构成语法，可以参考dep文档。

4、revendor/update vendor

使用vendor机制后，由于第三方依赖包修正bug或引入你需要的功能，revendor第三方依赖包版本或者叫update vendor会成为一个周期性的工作。比如：toml包做了一些bugfix，并发布了v0.2.1版本。在我的depdemo中，为了一并fix掉这些bug，我需要重新vendor toml包。之前我们加的constraint是满足升级到v0.2.1版本的，因此我们不需要重新设置constraints，我们只需要单独revendor toml即可，可以使用dep ensure -update 命令：

$dep ensure -v -update github.com/BurntSushi/toml
Root project is "depdemo"
 1 transitively valid internal packages
 1 external packages imported from 1 projects
(0)   ✓ select (root)
(1)    ? attempt github.com/BurntSushi/toml with 1 pkgs; 7 versions to try
(1)        try github.com/BurntSushi/toml@v0.3.0
(2)    ✗   github.com/BurntSushi/toml@v0.3.0 not allowed by constraint ^0.2.0:
(2)        ^0.2.0 from (root)
(1)        try github.com/BurntSushi/toml@v0.2.0
(1)    ✓ select github.com/BurntSushi/toml@v0.2.0 w/1 pkgs
  ✓ found solution with 1 packages from 1 projects

Solver wall times by segment:
  b-list-versions: 1m18.267880815s
  .... ...
  TOTAL: 1m57.118656393s

由于真实的toml并没有v0.2.1版本且没有v0.2.x版本，因此我们的dep ensure -update并没有真正获取到数据。vendor和Gopkg.lock都没有变化。

5、dep日常操作小结

下面这幅图包含了上述三个dep日常操作，可以直观地看出不同操作后，对项目带来的改变：

“工欲善其事，必先利其器”，熟练的掌握dep的日常操作流程对提升开发效率大有裨益。

二、“超时等待退出”框架的一种实现

很多时候，我们在程序中都要启动多个goroutine协作完成应用的业务逻辑，比如：

func main() {
    go producer.Start()
    go consumer.Start()
    go watcher.Start()
    ... ...
}

启动容易停止难！当程序要退出时，最粗暴的方法就是不管三七二十一，main goroutine直接退出；优雅些的方式，也是*nix系统通常的作法是：通知一下各个Goroutine要退出了，然后等待一段时间后再真正退出。粗暴地直接退出的方式可能会导致业务数据的损坏、不完整或丢失。等待超时的方式虽然不能完全避免“损失”，但是它给了各个goroutine一个“挽救数据”的机会，可以尽可能地减少损失的程度。

但这些goroutine形态很可能不同，有些是server，有些可能是client worker或其manager，因此似乎很难用一种统一的框架全面管理他们的启动、运行和退出，于是我们缩窄“交互面”，我们只做“超时等待退出”。我们定义一个interface：

type GracefullyShutdowner interface {
    Shutdown(waitTimeout time.Duration) error
}

这样，凡是实现了该interface的类型均可在程序退出时得到退出的通知，并有机会做退出前的最后清理工作。这里还提供了一个类似http.HandlerFunc的类型ShutdownerFunc ，用于将普通function转化为实现了GracefullyShutdowner interface的类型实例：

type ShutdownerFunc func(time.Duration) error

func (f ShutdownerFunc) Shutdown(waitTimeout time.Duration) error {
    return f(waitTimeout)
}

1、并发退出

退出也至少有两种类型，一种是并发退出，这种退出方式下各个goroutine的退出先后次序对数据处理无影响；另外一种则是顺序退出，即各个goroutine之间的退出是必须按照一定次序进行的。我们先来说并发退出。上代码！

// shutdown.go
func ConcurrencyShutdown(waitTimeout time.Duration, shutdowners ...GracefullyShutdowner) error {
    c := make(chan struct{})

    go func() {
        var wg sync.WaitGroup
        for _, g := range shutdowners {
            wg.Add(1)
            go func(shutdowner GracefullyShutdowner) {
                shutdowner.Shutdown(waitTimeout)
                wg.Done()
            }(g)
        }
        wg.Wait()
        c <- struct{}{}
    }()

    select {
    case <-c:
        return nil
    case <-time.After(waitTimeout):
        return errors.New("wait timeout")
    }
}

我们将各个GracefullyShutdowner接口的实现以一个变长参数的形式传入ConcurrencyShutdown函数。ConcurrencyShutdown函数实现也很简单，通过：

• 为每个shutdowner启动一个goroutine实现并发退出，并将timeout参数传入shutdowner的Shutdown方法中；
• sync.WaitGroup在外层等待每个goroutine的退出；
• 通过select一个退出指示channel和time.After返回的timer channel来决定到底是正常退出还是超时退出。

该函数的具体使用方法可以参考：shutdown_test.go。

//shutdown_test.go
func shutdownMaker(processTm int) func(time.Duration) error {
    return func(time.Duration) error {
        time.Sleep(time.Second * time.Duration(processTm))
        return nil
    }
}

func TestConcurrencyShutdown(t *testing.T) {
    f1 := shutdownMaker(2)
    f2 := shutdownMaker(6)

    err := ConcurrencyShutdown(time.Duration(10)*time.Second, ShutdownerFunc(f1), ShutdownerFunc(f2))
    if err != nil {
        t.Errorf("want nil, actual: %s", err)
        return
    }

    err = ConcurrencyShutdown(time.Duration(4)*time.Second, ShutdownerFunc(f1), ShutdownerFunc(f2))
    if err == nil {
        t.Error("want timeout, actual nil")
        return
    }
}

2、串行退出

有了并发退出作为基础，串行退出也很简单了！

//shutdown.go
func SequentialShutdown(waitTimeout time.Duration, shutdowners ...GracefullyShutdowner) error {
    start := time.Now()
    var left time.Duration

    for _, g := range shutdowners {
        elapsed := time.Since(start)
        left = waitTimeout - elapsed

        c := make(chan struct{})
        go func(shutdowner GracefullyShutdowner) {
            shutdowner.Shutdown(left)
            c <- struct{}{}
        }(g)

        select {
        case <-c:
            //continue
        case <-time.After(left):
            return errors.New("wait timeout")
        }
    }

    return nil
}

串行退出的一个问题是waitTimeout的确定，因为这个超时时间是所有goroutine的退出时间之和。在上述代码里，我把每次的lefttime传入下一个要执行的goroutine的Shutdown方法中，外部select也同样使用这个left作为timeout的值。对照ConcurrencyShutdown，SequentialShutdown更简单，这里就不详细说了。

3、小结

这是一个可用的、抛砖引玉式的实现，但还有很多改进空间，比如：可以考虑一下获取每个shutdowner.Shutdown后的返回值(error)，留给大家自行考量吧。

三、Testcase的setUp和tearDown

Go语言自带testing框架，事实证明这是Go语言的一个巨大优势之一，Gopher们也非常喜欢这个testing包。但Testing这个事情比较复杂，有些场景还需要我们自己动脑筋在标准testing框架下实现需要的功能，比如：当测试代码需要访问外部数据库、Redis或连接远端server时。遇到这种情况，很多人想到了Mock，没错。Mock技术在一定程度上可以解决这些问题，但如果使用mock技术，业务代码就得为了test而去做一层抽象，提升了代码理解的难度，在有些时候这还真不如直接访问真实的外部环境。

这里先不讨论这两种方式的好坏优劣，这里仅讨论如果在testing中访问真实环境我们该如何测试。在经典单元测试框架中，我们经常能看到setUp和tearDown两个方法，它们分别用于在testcase执行之前初始化testcase的执行环境以及在testcase执行后清理执行环境，以保证每两个testcase之间都是独立的、互不干扰的。在真实环境下进行测试，我们也可以利用setUp和tearDown来为每个testcase初始化和清理case依赖的真实环境。

setUp和tearDown也是有级别的，有全局级、testsuite级以及testcase级。在Go中，在标准testing框架下，我们接触到的是全局级和testcase级别。Go中对全局级的setUp和tearDown的支持还要追溯到Go 1.4，Go 1.4引入了TestMain方法，支持在诸多testcase执行之前为测试代码添加自定义setUp，以及在testing执行之后进行tearDown操作，例如：

func TestMain(m *testing.M) {
    err := setup()
    if err != nil {
        fmt.Println(err)
        os.Exit(-1)
    }

    r := m.Run()
    teardown()

    os.Exit(r)
}

但在testcase级别，Go testing包并没有提供方法上的支持。在2017年的GopherCon大会上，Hashicorp的创始人Mitchell Hashimoto做了题为：“Advanced Testing in Go”的主题演讲，这份资料里提出了一种较为优雅的为testcase进行setUp和teawDown的方法：

//setup-teardown-demo/foo_test.go
package foo_test

import (
    "fmt"
    "testing"
)

func setUp(t *testing.T, args ...interface{}) func() {
    fmt.Println("testcase setUp")
    // use t and args

    return func() {
        // use t
        // use args
        fmt.Println("testcase tearDown")
    }
}

func TestXXX(t *testing.T) {
    defer setUp(t)()
    fmt.Println("invoke testXXX")
}

这个方案充分利用了函数这个first-class type以及闭包的作用，每个Testcase可以定制自己的setUp和tearDown，也可以使用通用的setUp和tearDown，执行的效果如下：

$go test -v .
=== RUN   TestXXX
testcase setUp
invoke testXXX
testcase tearDown
--- PASS: TestXXX (0.00s)
PASS
ok      github.com/bigwhite/experiments/writing-go-code-issues/2nd-issue/setup-teardown-demo    0.010s

四、错误处理

本来想码一些关于Go错误处理的文字，但发现自己在2015年就写过一篇旧文《Go语言错误处理》，对Go错误处理的方方面面总结的很全面了。即便到今天也不过时，这当然也得益于Go1兼容规范的存在。因此有兴趣于此的朋友们，请移步到《Go语言错误处理》这篇文章吧。

注：本文所涉及的示例代码，请到这里下载。

微博：@tonybai_cn
微信公众号：iamtonybai
github.com: https://github.com/bigwhite

微信赞赏：