第 3 章程序的生命周期 on Go 语言原本

3.1 从 `go` 命令谈起

Mon, 01 Jan 0001 00:00:00 +0000

3.1 从 `go` 命令谈起

Go 程序的生命周期要从执行 go 命令开始谈起。读者每天敲下的 go build、go test、go run，看上去只是「把源码变成二进制」，背后却藏着一个常被误解的事实：go 本身并不是编译器。它是一个 构建编排器（build orchestrator），负责把一次构建分解成许多道工序，安排它们的先后与并行，再逐道调用真正的工具，编译器 compile（3.2）、汇编器 asm、链接器 link （3.4）。本节先把这层编排关系讲清楚，它是后续几节的总纲：读懂了 go 如何把一次构建拆成一张图、如何用内容寻址的缓存避免重复劳动，再去看编译与链接的细节，就有了落脚的框架。

3.1.1 `go` 是构建编排器，不是编译器

把一个最小程序的构建过程摊开，最直接的办法是 go build -x，它会打印出 go 实际执行的每一条子命令。对一个只有一行 fmt.Println 的 main 包，输出的骨架是这样：

$ go build -x -o /dev/null .
WORK=/tmp/go-build1449454186
mkdir -p $WORK/b001/
cat >$WORK/b001/importcfg << 'EOF' # internal
# import config
packagefile fmt=/Users/.../go-build/7d/7d74...-d
packagefile runtime=/Users/.../go-build/60/60cb...-d
EOF
# 调用编译器，把 main.go 编成归档 _pkg_.a
.../pkg/tool/darwin_arm64/compile -o $WORK/b001/_pkg_.a -p main -lang=go1.26 \
    -complete -buildid ... -importcfg $WORK/b001/importcfg -pack ./main.go
.../pkg/tool/darwin_arm64/buildid -w $WORK/b001/_pkg_.a # internal
cp $WORK/b001/_pkg_.a /Users/.../go-build/82/8256...-d # internal
# 写出链接配置，再调用链接器
cat >$WORK/b001/importcfg.link << 'EOF' # internal
packagefile demo=$WORK/b001/_pkg_.a
packagefile fmt=/Users/.../go-build/7d/7d74...-d
...
EOF
.../pkg/tool/darwin_arm64/link -o $WORK/b001/exe/a.out -importcfg ... $WORK/b001/_pkg_.a

go 自己做的事，是建一个临时工作目录、写出一份份 importcfg（告诉编译器与链接器每个依赖包的归档在磁盘何处），然后 exec 出 compile 与 link 这两个独立的可执行文件。源文件到目标代码的真正翻译，发生在 go 之外的工具里。这种「主程序只负责编排、把脏活交给独立工具」的结构，在 go 命令的内部用两个数据类型承载：Builder 持有整次构建的共享状态（工作目录、各类缓存、并行度控制），Action 则是构建图上的一个节点，描述「一道要做的工序」：

3.2 Go 程序编译流程

Mon, 01 Jan 0001 00:00:00 +0000

3.2 Go 程序编译流程

3.1 说 go build 背后真正干活的是 compile 与 link 两支程序。这一节把镜头推近到 compile，给出它从一份 .go 源文件到一个 .o 目标文件之间走过的全程：每个阶段拿到什么、吐出什么、为什么这样切分。本节是编译流水线的全景图，每个阶段的内部机理（文法如何设计、类型检查用什么算法、SSA 的优化规则）留给第 15 章逐一展开，这里只负责把它们串成一条线，并指出两条贯穿始终的暗线。

为避免落回逐字翻译编译器目录结构的窠臼，下文用一个贯穿全程的小例子来串起所有阶段。请记住这段函数，它会被流水线反复揉捏，直到变成机器码：

func send(ch chan int) {
	go work() // 启动一个新 goroutine
	ch <- 1   // 向 channel 发送
}

它只有两行，却恰好藏着本节要强调的第二条暗线：go 与 <- 这样的语言关键字，最终都不是靠 CPU 指令直接实现的，而是被编译器翻译成对运行时的函数调用。先把流水线看完，再回头解剖这两行。

3.2.1 两条暗线：为何要先讲它们

把流水线的细节铺开之前，先点明两个贯穿全程的设计取向，后面每个阶段都在为它们服务。

第一条暗线是编译速度本身是一等约束。Go 从设计之初就把「编译要快」当作语言目标而非事后优化（1.1）。这个目标渗进了语法、依赖管理与编译器结构的每一层：文法被设计成可以不回溯地快速解析，依赖以编译期产出的紧凑导出数据而非源码传递，且不存在 C/C++ 那种会层层传染的 #include。Rob Pike 在《Go at Google》里把这一点列为 Go 诞生的直接动机，当年 Google 一次大型 C++ 构建动辄以小时计，而 Go 要做到「按一下回车就编译完」。

3.3 语言的自举

Mon, 01 Jan 0001 00:00:00 +0000

3.3 语言的自举

一个问题听起来像悖论：Go 的编译器、汇编器、链接器与运行时如今都用 Go 写成，那么第一个能编译 Go 的程序是从哪里来的？没有 Go 编译器，怎么编译出 Go 编译器？这就是自举（bootstrapping）。它既是「先有鸡还是先有蛋」的经典困局，也是 Go 工具链演化史上一段可被精确复述的工程。本节回答三件事：这只蛋最初是怎么孵出来的；自举之后，构建一个新版 Go 的链条如何运转，以及它对引导版本的要求为何逐年抬升；最后，为什么一门语言「用自己实现自己」值得郑重对待。

3.3.1 先有蛋：从 C 写的工具链到 Go 写的工具链

自举的前提，是先有一个不依赖自身的起点。Go 工具链最初（到 Go 1.4，2014 年）的编译器、汇编器、链接器与 cmd/dist 都是用 C 写的，编译器沿用了 Plan 9 的命名（5c、6c、8c、 9c 等，数字对应不同的目标架构）。这套 C 程序由系统自带的 gcc 或 clang 编译，于是构建 Go 不需要任何已存在的 Go,这便是那只「蛋」。

从 Go 1.5（2015 年 8 月）起，Go 完成了一次里程碑式的转变：编译器与运行时被整体用 Go 重写，C 工具链被删除，工具链从此可以自我引导。这步棋的代价与收益都很实在。收益是，编译器开发者从此用 Go 这门内存安全、并发友好、自带测试与剖析工具的语言来维护工具链，编译器里的 bug 可以用 Go 自己的调试手段去查；运行时与编译器共用一套语言，跨边界的协作（如逃逸分析与栈管理）也更顺。代价是，构建 Go 不再像编译一段 C 那样自给自足，它现在需要「另一个已经能用的 Go」。如何用一个旧的 Go 造出一个新的 Go，就成了此后每个版本都要回答的问题。

3.4 模块链接

Mon, 01 Jan 0001 00:00:00 +0000

3.4 模块链接

编译器（3.2）把每个包变成一个目标文件，但目标文件还不能直接运行。它们彼此引用着对方的函数与变量，地址尚未确定，还缺运行时的支撑。把这些碎片拼成一个完整、可加载执行的程序，是链接器（cmd/link，通常以 go tool link 的形式被 go build 调起）的活。这一节看链接器做了哪几件事，以及 Go 在链接上的几处独特选择,它们一同解释了为什么一个 Go 程序往往是一个「拷过去就能跑」的自包含文件。

3.4.1 链接器做的事

链接器的输入是一个 main 包的目标文件，加上它递归依赖的所有包（含整个运行时）的目标文件；输出是一个可被操作系统加载执行的二进制。中间它要顺序完成几件关键工作：

符号解析（symbol resolution）：把每一处对外部符号的引用，绑定到它在某个目标文件里的唯一定义。一个符号就是一个有名字的地址,某个函数的入口、某个全局变量的存储。A 包里写 fmt.Println(...)，编译 A 时并不知道 fmt.Println 在哪，只留下一个待解析的引用；链接器把它接到 fmt 包目标文件里那份定义上。
布局（layout）：把所有符号的机器码与数据，按种类安排进可执行文件的各个段,代码进 text、可读写数据进 data、只读数据（字符串字面量、类型信息）进 rodata 等。布局一旦定下，每个符号的最终地址也就确定了。
重定位（relocation）：地址定下后，回头修正所有引用处填的临时地址。
死代码消除（dead-code elimination）：从入口出发不可达的函数与变量，根本不写进最终二进制。

最后产出的，是一个静态布局完毕、地址全部填实的文件。下面三节分别细看其中最值得说的三处：重定位（3.4.2）、死代码消除（3.4.3）、以及「运行时也被一并链接进来」这一 Go 的标志性后果（3.4.4）。

flowchart LR
    OBJ["main.a + 依赖包目标文件<br/>(含整个 runtime)"] --> LOAD["装载符号<br/>loader 读入"]
    LOAD --> RESOLVE["符号解析<br/>引用 → 定义"]
    RESOLVE --> DEAD["死代码消除<br/>从 main.main 标记可达"]
    DEAD --> LAYOUT["段布局<br/>text/data/rodata"]
    LAYOUT --> RELOC["重定位<br/>填实地址"]
    RELOC --> BIN["可执行二进制"]

3.4.2 符号解析与重定位

这两步是链接的核心机制，值得稍微形式化一点。

3.5 Go 程序启动引导

Mon, 01 Jan 0001 00:00:00 +0000

3.5 Go 程序启动引导

读者写下的 main 函数，并不是程序真正的第一条指令。当操作系统把控制权交给一个 Go 可执行文件时，跑起来的是运行时（runtime）：它要在主线程上铺好执行栈、绑定线程本地存储、量出 CPU 核心数与内存物理页大小，把内存分配器、垃圾回收器、调度器逐一唤醒，最后才创建那个承载 main 的 goroutine，交由调度循环去运行。换言之，一个 Go 二进制文件里随身带着一个微型操作系统（1.2），它先于用户代码自行启动。本节顺着这条引导链走一遍，从操作系统的入口符号，到第一个 goroutine 被调度，看清楚「在 main 之前」究竟发生了什么。

引导链的脉络可以先记住三段：汇编入口在主线程上手工搭出 g0 与 m0（3.5.1）， schedinit 按依赖次序点亮各个子系统（3.5.2），随后 newproc 造出第一个 goroutine、mstart 进入调度循环把它跑起来（3.5.3）。

3.5.1 汇编入口：g0、m0 与 TLS

运行时的真正入口由 runtime 包以汇编写就。以 AMD64 为例，Linux 与 macOS 的入口符号分别位于 runtime/rt0_linux_amd64.s 与 runtime/rt0_darwin_amd64.s，两者都只是一跳，转入共用的 _rt0_amd64：

TEXT _rt0_amd64_linux(SB),NOSPLIT,$-8
	JMP	_rt0_amd64(SB)
TEXT _rt0_amd64_darwin(SB),NOSPLIT,$-8
	JMP	_rt0_amd64(SB)

为何按「架构 + 操作系统」两维拆分入口？因为程序编译为机器码后，指令集只取决于 CPU 架构，而操作系统的差异体现在系统调用等系统级操作上。一份 _rt0_amd64 可被多个操作系统共用，各操作系统再以自己的入口符号跳进来。rt0 是 runtime0 的缩写，意指运行时的创生，此后所有派生出来的同类对象都以 1 为后缀，g0、m0 即得名于此。

3.6 主 Goroutine 的生与死

Mon, 01 Jan 0001 00:00:00 +0000

3.6 主 Goroutine 的生与死

3.5 里 schedinit 把运行时的家底备齐之后并不直接调用 runtime.main，而是把它的入口地址压栈、交给 newproc 造出第一个 Goroutine，再由 mstart 启动调度循环、把这个 Goroutine 挑出来执行。调度的细节留到 9 调度器详谈，本节只把镜头对准一个时刻：第一个 Goroutine 已经在跑，它正要执行 runtime.main。

这只 Goroutine 与众不同。它是程序里诞生的第一个，承载着用户的 main.main，也独自掌握着整个进程的生杀大权：它一返回，进程就结束，哪怕别处还有上千个 Goroutine 正忙。理解它做了什么、以及它何时收手，是理解「一个 Go 程序如何开始、又如何整体退出」的最后一块拼图。

3.6.1 `runtime.main`：用户代码之前的铺垫

运行时包里的 main 函数（即 runtime.main）与用户的 main.main 跑在同一个 Goroutine 上，但在把控制权交给用户之前，它先料理了几桩只能由「第一个 Goroutine」来做的事。下面是裁剪后的速写，只留与生命周期相关的骨架：

// 主 Goroutine 入口（裁剪自 runtime/proc.go）
func main() {
	mp := getg().m

	// 执行栈上限：64 位 1GB，32 位 250MB（用十进制，崩溃信息里更好看）
	if goarch.PtrSize == 8 {
		maxstacksize = 1000000000
	} else {
		maxstacksize = 250000000
	}

	mainStarted = true            // 允许 newproc 启动新的 M

	if haveSysmon {               // 启动系统监控线程（见 9.8）
		systemstack(func() {
			newm(sysmon, nil, -1)
		})
	}

	lockOSThread()                // 初始化期间把主 G 锁在主 OS 线程上
	if mp != &m0 {
		throw("runtime.main not on m0")
	}

	runtimeInitTime = nanotime()  // 记下「世界开始」的时刻，须在 doInit 之前

	doInit(runtime_inittasks)     // 运行运行时自身的 init（含 GC、defer 类型等）

	gcenable()                    // 启用垃圾回收器（见 13）

	// 按依赖顺序运行所有模块（含用户包）的 init 任务
	last := lastmoduledatap
	for m := &firstmoduledata; true; m = m.next {
		doInit(m.inittasks)
		if m == last {
			break
		}
	}

	unlockOSThread()

	fn := main_main               // 间接调用：链接器此时不知道 main 包的地址
	fn()

	exit(0)                       // 主 G 一返回，整个进程退出
}

这段骨架里有几处值得停下来看。

第 3 章 程序的生命周期 on Go 语言原本

3.1 从 `go` 命令谈起

3.1 从 go 命令谈起

3.1.1 go 是构建编排器，不是编译器

3.2 Go 程序编译流程

3.2 Go 程序编译流程

3.2.1 两条暗线：为何要先讲它们

3.3 语言的自举

3.3 语言的自举

3.3.1 先有蛋：从 C 写的工具链到 Go 写的工具链

3.4 模块链接

3.4 模块链接

3.4.1 链接器做的事

3.4.2 符号解析与重定位

3.5 Go 程序启动引导

3.5 Go 程序启动引导

3.5.1 汇编入口：g0、m0 与 TLS

3.6 主 Goroutine 的生与死

3.6 主 Goroutine 的生与死

3.6.1 runtime.main：用户代码之前的铺垫

第 3 章程序的生命周期 on Go 语言原本

3.1 从 `go` 命令谈起

3.1.1 `go` 是构建编排器，不是编译器

3.6.1 `runtime.main`：用户代码之前的铺垫