编译器 | Tony Bai

标签编译器下的文章

理解Golang包导入

三月 9, 2015
13 条评论

Golang使用包（package）这种语法元素来组织源码，所有语法可见性均定义在package这个级别，与Java 、python等语言相比，这算不上什么创新，但与C传统的include相比，则是显得“先进”了许多。

Golang中包的定义和使用看起来十分简单：

通过package关键字定义包：

package xxx

使用import关键字，导入要使用的标准库包或第三方依赖包。

import "a/b/c"
import "fmt"

c.Func1()
fmt.Println("Hello, World")

很多Golang初学者看到上面代码，都会想当然的将import后面的"c"、"fmt"当成包名，将其与c.Func1()和 fmt.Println()中的c和fmt认作为同一个语法元素：包名。但在深入Golang后，很多人便会发现事实上并非如此。比如在使用实时分布式消息平台nsq提供的go client api时：

我们导入的路径如下：

import “github.com/bitly/go-nsq”

但在使用其提供的export functions时，却用nsq做前缀包名：

q, _ := nsq.NewConsumer("write_test", "ch", config)

人们不禁要问：import后面路径中的最后一个元素到底代表的是啥? 是包名还是仅仅是一个路径？我们一起通过试验来理解一下。实验环境：darwin_amd64 , go 1.4。

初始试验环境目录结果如下：

GOPATH = /Users/tony/Test/Go/pkgtest/
pkgtest/
    pkg/
    src/
     libproj1/
           foo/
        foo1.go
       app1/
         main.go

一、编译时使用的是包源码还是.a

我们知道一个非main包在编译后会生成一个.a文件（在临时目录下生成，除非使用go install安装到$GOROOT或$GOPATH下，否则你看不到.a），用于后续可执行程序链接使用。

比如Go标准库中的包对应的源码部分路径在：$GOROOT/src，而标准库中包编译后的.a文件路径在$GOROOT/pkg/darwin_amd64下。一个奇怪的问题在我脑袋中升腾起来，编译时，编译器到底用的是.a还是源码？

我们先以用户自定义的package为例做个小实验。

$GOPATH/src/
    libproj1/foo/
            – foo1.go
    app1
            – main.go

//foo1.go
package foo

import "fmt"

func Foo1() {
fmt.Println("Foo1")
}

// main.go
package main

import (
"libproj1/foo"
)

func main() {
foo.Foo1()
}

执行go install libproj1/foo，Go编译器编译foo包，并将foo.a安装到$GOPATH/pkg/darwin_amd64/libproj1下。
编译app1：go build app1，在app1目录下生成app1*可执行文件，执行app1，我们得到一个初始预期结果：

$./app1
Foo1

现在我们无法看出使用的到底是foo的源码还是foo.a，因为目前它们的输出都是一致的。我们修改一下foo1.go的代码：

//foo1.go
package foo

import "fmt"

func Foo1() {
fmt.Println("Foo1 – modified")
}

重新编译执行app1，我们得到结果如下：

$./app1
Foo1 – modified

实际测试结果告诉我们：(1)在使用第三方包的时候，当源码和.a均已安装的情况下，编译器链接的是源码。

那么是否可以只链接.a，不用第三方包源码呢？我们临时删除掉libproj1目录，但保留之前install的libproj1/foo.a文件。

我们再次尝试编译app1，得到如下错误：

$go build app1
main.go:5:2: cannot find package "libproj1/foo" in any of:
/Users/tony/.Bin/go14/src/libproj1/foo (from $GOROOT)
/Users/tony/Test/Go/pkgtest/src/libproj1/foo (from $GOPATH)

编译器还是去找源码，而不是.a，因此我们要依赖第三方包，就必须搞到第三方包的源码，这也是Golang包管理的一个特点。

其实通过编译器的详细输出我们也可得出上面结论。我们在编译app1时给编译器传入-x -v选项：

$go build -x -v app1
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build797811168
libproj1/foo
mkdir -p $WORK/libproj1/foo/_obj/
mkdir -p $WORK/libproj1/
cd /Users/tony/Test/Go/pkgtest/src/libproj1/foo
/Users/tony/.Bin/go14/pkg/tool/darwin_amd64/6g -o $WORK/libproj1/foo.a -trimpath $WORK -p libproj1/foo -complete -D _/Users/tony/Test/Go/pkgtest/src/libproj1/foo -I $WORK -pack ./foo1.go ./foo2.go
app1
mkdir -p $WORK/app1/_obj/
mkdir -p $WORK/app1/_obj/exe/
cd /Users/tony/Test/Go/pkgtest/src/app1
/Users/tony/.Bin/go14/pkg/tool/darwin_amd64/6g -o $WORK/app1.a -trimpath $WORK -p app1 -complete -D _/Users/tony/Test/Go/pkgtest/src/app1 -I $WORK -I /Users/tony/Test/Go/pkgtest/pkg/darwin_amd64 -pack ./main.go
cd .
/Users/tony/.Bin/go14/pkg/tool/darwin_amd64/6l -o $WORK/app1/_obj/exe/a.out -L $WORK -L /Users/tony/Test/Go/pkgtest/pkg/darwin_amd64 -extld=clang $WORK/app1.a
mv $WORK/app1/_obj/exe/a.out app1

可以看到编译器6g首先在临时路径下编译出依赖包foo.a，放在$WORK/libproj1下。但我们在最后6l链接器的执行语句中并未显式看到app1链接的是$WORK/libproj1下的foo.a。但是从6l链接器的-L参数来看：-L $WORK -L /Users/tony/Test/Go/pkgtest/pkg/darwin_amd64，我们发现$WORK目录放在了前面，我们猜测6l首先搜索到的时$WORK下面的libproj1/foo.a。

为了验证我们的推论，我们按照编译器输出，按顺序手动执行了一遍如上命令，但在最后执行6l命令时，去掉了-L $WORK：

/Users/tony/.Bin/go14/pkg/tool/darwin_amd64/6l -o $WORK/app1/_obj/exe/a.out -L /Users/tony/Test/Go/pkgtest/pkg/darwin_amd64 -extld=clang $WORK/app1.a

这样做的结果是：

$./app1
Foo1

编译器链接了$GOPATH/pkg下的foo.a。(2)到这里我们明白了所谓的使用第三方包源码，实际上是链接了以该最新源码编译的临时目录下的.a文件而已。

Go标准库中的包也是这样么？对于标准库，比如fmt而言，编译时，到底使用的时$GOROOT/src下源码还是$GOROOT/pkg下已经编译好的.a呢？

我们不妨也来试试，一个最简单的hello world例子：
//main.go
import "fmt"

func main() {
fmt.Println("Hello, World")
}

我们先将$GOROOT/src/fmt目录rename 为fmtbak，看看go compiler有何反应？
go build -x -v ./

$go build -x -v ./
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build957202426
main.go:4:8: cannot find package "fmt" in any of:
/Users/tony/.Bin/go14/src/fmt (from $GOROOT)
/Users/tony/Test/Go/pkgtest/src/fmt (from $GOPATH)

找不到fmt包了。显然标准库在编译时也是必须要源码的。不过与自定义包不同的是，即便你修改了fmt包的源码（未重新编译GO安装包），用户源码编译时，也不会尝试重新编译fmt包的，依旧只是在链接时链接已经编译好的fmt.a。通过下面的gc输出可以验证这点：

$go build -x -v ./
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build773440756
app1
mkdir -p $WORK/app1/_obj/
mkdir -p $WORK/app1/_obj/exe/
cd /Users/tony/Test/Go/pkgtest/src/app1
/Users/tony/.Bin/go14/pkg/tool/darwin_amd64/6g -o $WORK/app1.a -trimpath $WORK -p app1 -complete -D _/Users/tony/Test/Go/pkgtest/src/app1 -I $WORK -pack ./main.go
cd .
/Users/tony/.Bin/go14/pkg/tool/darwin_amd64/6l -o $WORK/app1/_obj/exe/a.out -L $WORK -extld=clang $WORK/app1.a
mv $WORK/app1/_obj/exe/a.out app1

可以看出，编译器的确并未尝试编译标准库中的fmt源码。

二、目录名还是包名？

从第一节的实验中，我们得知了编译器在编译过程中依赖的是包源码的路径，这为后续的实验打下了基础。下面我们再来看看，Go语言中import后面路径中最后的一个元素到底是包名还是路径名？

本次实验目录结构：
$GOPATH
    src/
       libproj2/
             foo/
               foo1.go
       app2/
             main.go

按照Golang语言习惯，一个go package的所有源文件放在同一个目录下，且该目录名与该包名相同，比如libproj1/foo目录下的package为foo，foo1.go、 foo2.go…共同组成foo package的源文件。但目录名与包名也可以不同，我们就来试试不同的。

我们建立libproj2/foo目录，其中的foo1.go代码如下：

//foo1.go
package bar

import "fmt"

func Bar1() {
fmt.Println("Bar1")
}

注意：这里package名为bar，与目录名foo完全不同。

接下来就给app2带来了难题：该如何import bar包呢？

我们假设import路径中的最后一个元素是包名，而非路径名。

//app2/main.go

package main

import (
"libproj2/bar"
)

func main() {
bar.Bar1()
}

编译app2：

$go build -x -v app2
WORK=/var/folders/2h/xr2tmnxx6qxc4w4w13m01fsh0000gn/T/go-build736904327
main.go:5:2: cannot find package "libproj2/bar" in any of:
/Users/tony/.Bin/go14/src/libproj2/bar (from $GOROOT)
/Users/tony/Test/Go/pkgtest/src/libproj2/bar (from $GOPATH)

编译失败，在两个路径下无法找到对应libproj2/bar包。

我们的假设错了，我们把它改为路径：

//app2/main.go

package main

import (
"libproj2/foo"
)

func main() {
bar.Bar1()
}

再编译执行：

$go build app2
$app2
Bar1

这回编译顺利通过，执行结果也是OK的。这样我们得到了结论：(3)import后面的最后一个元素应该是路径，就是目录，并非包名。

go编译器在这些路径(libproj2/foo)下找bar包。这样看来，go语言的惯例只是一个特例，即恰好目录名与包名一致罢了。也就是说下面例子中的两个foo含义不同：

import "libproj1/foo"

func main() {
foo.Foo()
}

import中的foo只是一个文件系统的路径罢了。而下面foo.Foo()中的foo则是包名。而这个包是在libproj1/foo目录下的源码中找到的。

再类比一下标准库包fmt。

import "fmt"
fmt.Println("xxx")

这里上下两行中虽然都是“fmt"，但同样含义不同，一个是路径，对于标准库来说，是$GOROOT/src/fmt这个路径。而第二行中的fmt则是包名。gc会在$GOROOT/src/fmt路径下找到fmt包的源文件。

三、import m "lib/math"

Go language specification中关于import package时列举的一个例子如下：

Import declaration Local name of Sin

import   "lib/math"         math.Sin
import m "lib/math"         m.Sin
import . "lib/math"         Sin

我们看到import m "lib/math" m.Sin一行。我们说过lib/math是路径，import语句用m替代lib/math，并在代码中通过m访问math包中的导出函数Sin。

那m到底是包名还是路径呢？既然能通过m访问Sin，那m肯定是包名了，Right！那import m "lib/math"该如何理解呢？

根据上面一、二两节中得出的结论，我们尝试理解一下m：(4)m指代的是lib/math路径下唯一的那个包。

一个目录下是否可以存在两个包呢？我们来试试。

我们在libproj1/foo下新增一个go源文件，bar1.go：

package bar

import "fmt"

func Bar1() {
fmt.Println("Bar1")
}

我们重新构建一下这个目录下的包：

$go build libproj1/foo
can't load package: package libproj1/foo: found packages bar1.go (bar) and foo1.go (foo) in /Users/tony/Test/Go/pkgtest/src/libproj1/foo

我们收到了错误提示，编译器在这个路径下发现了两个包，这是不允许的。

我们再作个实验，来验证我们对m含义的解释。

我们建立app3目录，其main.go的源码如下：

//main.go
package main

import m "libproj2/foo"

func main() {
m.Bar1()
}

libproj2/foo路径下的包的包名为bar，按照我们的推论，m指代的就是bar这个包，通过m我们可以访问bar的Bar1导出函数。

编译并执行上面main.go：

$go build app3
$app3
Bar1

执行结果与我们推论完全一致。

附录：6g, 6l文档位置：

6g – $GOROOT/src/cmd/gc/doc.go
6l – $GOROOT/src/cmd/ld/doc.go

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

十一月 4, 2014
1 条评论

在Go 1.3发布半年过去后，Go核心项目组于本月初发布了Go 1.4 Beta1版本。这个版本的几个变化点虽然不是革命性的，但对后续Go语言的发展来说，打下了基础，定下了基调。这里就几个值得关注的变化点结合Go 1.4代码进行一些简单描述，希望大家能对Go 1.4有个感性的认知和了解。

Go 1.4依旧保持了Go 1兼容性的承诺，你的已有代码几乎无需任何改动就可以通过Go 1.4的编译并运行。(以下是我的测试环境：go version go1.3 darwin/amd64 vs. go version go1.4beta1 linux/amd64）

一、语言变化

1、For-range循环

在Go 1.3及以前，for-range循环具有两种形式：

for k, v := range x {
…
}

和

for k := range x {
…
}

问题：如果我们不关心循环中的值，我们只关心循环本身，我们仍然要提供一个变量，或用_占位。

for _ = range x {
…
}

下面这样的语法在Go 1.3及以前是无法编译通过的：

for range x {
…
}

不过Go 1.4支持这种形式的语法，它使得代码更加clean，虽然它可能很少会被使用到。

例子：

//testforrange.go

package main

import "fmt"

func main() {
        var a [5]int = [5]int{2, 3, 4, 5, 6}
        for k, v := range a {
                fmt.Println(k, v)
        }

        for k := range a {
                fmt.Println(k)
        }

        for _ = range a {
                fmt.Println("print without care about the key and value")
        }

        for range a {
                fmt.Println("new syntax – print without care about the key and value")
        }
}

Go 1.3编译出错：

$go run testforrange.go
# command-line-arguments
./testforrange.go:19: syntax error: unexpected range, expecting {
./testforrange.go:22: syntax error: unexpected }

Go 1.4编译成功并输出正确结果：

0 2
1 3
2 4
3 5
4 6
0
1
2
3
4
print without care about the key and value
print without care about the key and value
print without care about the key and value
print without care about the key and value
print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value
new syntax – print without care about the key and value

2、通过**T调用方法

下面这个例子：

package main

import "fmt"

type T int

func (T) M() {
fmt.Println("Call M")
}

var x **T

func main() {
x.M()
}

按照Go 1.4官方release note的说法，1.3版本及以前的gc和gccgo都会正常接受这种调用方式。但Go 1规范只允许自动在x前面加一个解引用，而不是两个，因此这个是有悖于定义的。Go 1.4强制禁止这种调用。

不过根据我实际的测试，Go 1.3和Go 1.4针对上面代码都会出现同样地编译错误。

$go run testdoubledeferpointer.go
# command-line-arguments
./testdoubledeferpointer.go:14: calling method M with receiver x (type **T) requires explicit dereference

二、支持的操作系统以及处理器体系架构的变化

这个无法演示。不过一个主要的变化就是Go 1.4可以构建出运行于ARM处理器Android操作系统上的二进制程序了。使用go.mobile库中的支持包，Go 1.4也可以构建出可以被Android应用加载的.so库。

三、兼容性变化

人们通过unsafe包并利用Go的内部实现细节和数据的机器表示形式来绕过Go语言类型系统的约束。Go的设计者们认为这是对Go兼容性规范的不尊重，在Go 1.4中，Go核心组正式宣布unsafe code不再保证其兼容性。这次Go 1.4并没有针对此做任何代码变动，只是一个clarification而已。

四、实现和工具的变化

1、运行时(runtime)的变化

Go 1.3及以前版本，Go语言的runtime（垃圾收集、并发支持、interface管理、maps、slices、strings等）主要由C语言和少量汇编语言实现的。在1.4版本中，很多代码被替换成了用Go自身实现，这样垃圾回收器可以扫描程序运行时栈，获取活跃变量的精确信息。这个变化很大，但对程序应该没有语义上的影响。

这次重写使得垃圾回收器变得更加精确，这意味着它知道所有程序中活跃指针的位置。这些相关改变将减小heap的大小，总体上大约减少 10%~30%。

这样做的结果是栈也不再需要是分段的(segmented)了，消除了“hot split”的问题。如果一个stack到达了使用上限，Go将分配一个新的更大的stack，相应goroutine中的所有活跃的栈帧将被复制到新 stack上，所有指向栈的指针将被更新。在某些场景下，其性能将会变得显著提升，并且这样修改后，其性能更具可预测性。

连续栈(contiguous stacks)的使用使得栈的初始Size可以更小，在Go 1.4中goroutine的初始栈大小从8192字节缩小为2048字节。（正式发布时也许会改为4096）。

interface值类型的实现也做了调整。在之前的发布版中，interface值内部用一个字(word)来承载，要么是一个指针，要么是一个单字（one-word）大小的纯量值，这取决于interface值变量中具体存储的是什么对象。这个实现会给垃圾收集器带来诸多困难，因此在Go 1.4版本中interface值内部就用指针表示。在运行的程序中，绝大多数interface值都是指针，因此这个影响很小。不过那些在 interface值类型变量中存储整型值的程序将会有更多的内存分配。

2、gccgo的状态

Gcc和Go两个项目的发布计划不是同步的，GCC 4.9版本包含了实现了1.2规范的gccgo，下一个发布版gcc 5.0将可能包含实现了1.4规范的gccgo。

3、internal包（内部包）

Go以package为基本逻辑单元组织代码。Go 1.3及之前版本的Go语言实际上只支持两种形式Package内符号的可见性：本地的(unexported)和全局的(exported)。有些时候我们希望一些包并非能被所有外部包所导入，但却能被其“临近”的包所导入和访问。但之前的Go语言不具备这种特性。Go 1.4引入了"internal"包的概念，导入这种internal包的规则约束如下：

如果导入代码本身不在以"internal"目录的父目录为root的目录树中，那么不允许其导入路径(import path)中包含internal元素。

例如：
    – a/b/c/internal/d/e/f只可以被以a/b/c为根的目录树下的代码导入，不能被a/b/g下的代码导入。
    – $GOROOT/src/pkg/internal/xxx只能被标准库($GOROOT/src)中的代码所导入。（注：Go 1.4 取消了$GOROOT/src/pkg，标准库都移到$GOROOT/src下了)。
    – $GOROOT/src/pkg/net/http/internal只能被net/http和net/http/*的包所导入
    – $GOPATH/src/mypkg/internal/foo只能被$GOPATH/src/mypkg包的代码所导入

对于Go 1.4该规则首先强制应用于$GOROOT下。Go 1.5将扩展应用到$GOPATH下。

4、权威导入路径(import paths)

我们经常使用托管在公共代码托管服务中的代码，诸如github.com，这意味着包导入路径包含托管服务名，比如github.com/rsc /pdf。一些场景下为了不破坏用户代码，我们用rsc.io/pdf，屏蔽底层具体哪家托管服务，比如rso.io/pdf的背后可能是 github.com也可能是bitbucket。但这样会引入一个问题，那就是不经意间我们为一个包生成了两个合法的导入路径。如果一个程序中使用了这两个合法路径，一旦某个路径没有被识别出有更新，或者将包迁移到另外一个不同的托管公共服务下去时，使用旧导入路径包的程序就会报错。

Go 1.4引入一个包字句的注释，用于标识这个包的权威导入路径。如果使用的导入的路径不是权威路径，go命令会拒绝编译。语法很简单：

package pdf // import "rsc.io/pdf"

如果pdf包使用了权威导入路径注释，那么那些尝试使用github.com/rsc/pdf导入路径的程序将会被go编译器拒绝编译。

这个权威导入路径检查是在编译期进行的，而不是下载阶段。

我们举个例子：

我们的包foo以前是放在github.com/bigwhite/foo下面的，后来主托管站换成了tonybai.com/foo，最新的 foo包的代码：

package foo // import "tonybai.com/foo"

import "fmt"

func Echo(a string) {
fmt.Println("Foo:, a)
}

某个应用通过旧路径github.com/bigwhite/foo导入了该包：

//testcanonicalimportpath.go
package main

import "github.com/bigwhite/foo"

func main() {
foo.Echo("Hello!")
}

我们编译该go文件，得到以下结果：

code in directory /home/tonybai/Test/Go/src/github.com/bigwhite/foo expects import "tonybai.com/foo"

5、go generate子命令

go 1.4中go工具集合新引入一个子命令：go generate，用于在编译前自动化生成某类代码。例如在.y上运行yacc编译器生成实现该语法的.go源文件。或是使用stringer工具自动为常量生成String方法。这个命令并非由go tools(build, get等)自动执行，而必须显式执行。

不过我简单测试了一下，似乎这个命令设计文档中的：

// +build generate

并不好用啊。即便将其作为generate directive放入go源文件，该文件依旧会被go编译器当做正常go文件编译。Go 1.4标准库中使用go generate directive的有三个地方：

strconv/quote.go://go:generate go run makeisprint.go -output isprint.go
time/zoneinfo_windows.go://go:generate go run genzabbrs.go -output zoneinfo_abbrs_windows.go
unicode/letter.go://go:generate go run maketables.go -tables=all -output tables.go

通过go generate来实现泛型(generics)似乎不那么优雅啊。虽然设计者并非将其作为Go泛型的实现^_^。

6、源码布局变化

在Go自身源码库($GOROOT下)中，包的源码放在src/pkg中，这样做与其他库不同，包括Go自己的子库，比如go.tools。因此在Go 1.4中，pkg这一层目录树将被去除，比如fmt包的源码曾经放在src/pkg/fmt下，现在则放在src/fmt下。

五、性能

绝大多数程序使用1.4编译后的运行速度会与1.3的一致或略有提升，有些可能也会变得慢些。这次修改的较多，很难准确预测。

这次许多runtime的代码由C变为Go，这将导致一些heap大小有所缩减。另外这样做后有利于Go编译器的优化，诸如内联，会带来性能上的小幅提升。

垃圾回收器一方面得到了加速，使得重度依赖垃圾收集的程序得到可衡量的提升。但另外一方面，新的write barrier又引起了性能下降。提升和下降的量的多少取决于程序的行为。