第 16 章工具与可观测性 on Go 语言原本

16.1 运行时死锁检查

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

16.1 运行时死锁检查

fatal error: all goroutines are asleep - deadlock!,几乎每个 Go 程序员都见过这条错误。它来自运行时内置的死锁检测器。这一节先讲清它怎么判定、何时被触发，再讲一件更要紧的事：它在理论上能保证什么、又有什么是它结构性地检测不了的。后者是许多线上「卡死」之谜的根源，理解了它，比记住那条错误信息更有价值。

我们先说结论，再看它如何从一段不到一百行的代码里得出。运行时的死锁检测器并不维护、也从不检查一张「谁在等谁」的等待图（wait-for graph）。它只问两个极粗的问题：还有没有 M 在运行？将来有没有计时器会触发？两个都答「没有」，它就宣告死锁。这种粗糙不是疏忽，它恰恰决定了检测器的能力边界, 本节后半会看到，正因为没有逐资源的等待边，它无法在一部分 goroutine 之间找出一个死锁环。

16.1.1 判据：只数运行中的 M，不看谁等谁

死锁检测逻辑藏在 runtime/proc.go 的 checkdead 里（9.8）。它的判据可以一句话概括：没有任何线程还在运行，且没有任何途径能让某个 goroutine 重新变得可运行，程序就死锁了。 落到代码，「没有线程在运行」是一次减法,用机器线程总数减去各类空闲与系统线程：

// checkdead：判定是否陷入全局死锁（裁剪后的速写）
// 调用时必须持有 sched.lock。
func checkdead() {
    // 作为 c-shared / c-archive 库被宿主程序嵌入时，没有运行中的 goroutine 是正常的,
    // 宿主仍在跑。panicking、cgo 额外 M 等情形也各自豁免（此处略）。
    if (islibrary || isarchive) && GOARCH != "wasm" {
        return
    }

    // run = 机器线程数 − 空闲 M − 持锁空闲 M − 系统 M，即「正在运行的 M」数。
    // run0 通常为 0（cgo 额外 M 存在时为 1）。只要还有 M 在运行，就不可能
    // 是全局死锁，立即返回。
    run := mcount() - sched.nmidle - sched.nmidlelocked - sched.nmsys
    if run > run0 {
        return
    }
    // ...（见下）
}

注意这里没有出现任何「锁」「channel」「WaitGroup」的字样。checkdead 不知道、也不关心每个 goroutine 究竟阻塞在哪个原语上,它只数还有几个 M 在跑。这是理解它全部行为的关键。

16.2 竞争检查

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

16.2 竞争检查

数据竞争（data race）是并发程序里最隐蔽、最难复现的一类 bug。它的定义很短：两个 goroutine 并发访问同一内存地址、其中至少一个是写、且二者之间没有任何同步把它们排序，那么程序的行为就是未定义的（11.9）。「未定义」不是「读到旧值」这么温和，它意味着编译器与处理器都被允许做出令人意外的重排，结果可能时对时错，可能只在压力负载下、只在某种 CPU 上、只在某个版本里偶发一次。靠人眼复查这种 bug 是没有指望的。Go 的 竞态检测器（-race）正是把这件事从「靠运气复现」变成「跑一遍就告诉你」的工具。这一节讲清它的原理、它背后的算法代价、以及它那两条必须记住的能力边界。

16.2.1 基于 happens-before 的动态检测

go test -race、go run -race、go build -race、go install -race 都能开启竞态检测。它的内核是 Google 在 LLVM compiler-rt 里维护的 ThreadSanitizer（TSan）运行时，Go 以预编译的 .syso 形式把它链进程序（见 runtime/race/，因此 -race 依赖 cgo）。它的工作原理是 动态的 happens-before 检测：程序运行时，编译器在每一次内存访问前插入一个回调，运行时则拦截每一个同步事件，二者合起来让 TSan 实时维护一张 happens-before 关系图（11.9 那条偏序）。当它发现两个 goroutine 访问了同一地址、至少一个是写、而二者之间不存在任何 happens-before 边，就报告一个数据竞争。

为什么「访问」与「同步」要分开拦截？因为这正是 happens-before 偏序的两个来源。访问告诉检测器「谁在何时碰了哪块内存」，同步告诉它「哪两条时间线之间被建立了次序」。Go 在 runtime/race.go 里暴露的这组钩子，恰好把这两类事件一一对应了出来：

//go:build race

// 访问事件：编译器在每次读/写内存前自动插桩调用
func RaceRead(addr unsafe.Pointer)
func RaceWrite(addr unsafe.Pointer)
func RaceReadRange(addr unsafe.Pointer, len int)  // 切片、memmove 等成片访问
func RaceWriteRange(addr unsafe.Pointer, len int)

// 同步事件：在 addr 上建立跨 goroutine 的 happens-before 关系
// 注释原文：establish happens-before relations between goroutines
func RaceAcquire(addr unsafe.Pointer)       // ≈ C11 atomic_load(acquire)
func RaceRelease(addr unsafe.Pointer)        // ≈ C11 atomic_store(release)
func RaceReleaseMerge(addr unsafe.Pointer)   // ≈ C11 atomic_exchange(release)

RaceRead/RaceWrite 是访问点，运行时里 channel 收发、sync.Mutex 的加解锁、sync/atomic 的每个原子操作、goroutine 的创建与退出，则在内部调用 raceacquire/racerelease 这对原语把 happens-before 边「焊」上去。换句话说，11.9 里规定的每一条建立次序的语义（channel 发送 happens-before 对应接收完成、解锁 happens-before 后续加锁、原子写以 release 顺序同步原子读的 acquire），在 TSan 这里都落成一条具体的图上的边。内存模型那句抽象的「无 happens-before 即竞争」，于是变成了一个能实际抓现行的判定。

16.3 性能追踪

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

16.3 性能追踪

pprof（16.5）回答的是「时间花在哪些函数上」。它把一段时间里的 CPU 采样聚合成一棵调用树，告诉你 json.Marshal 占了 30% 的 CPU。但它答不了另一类问题：一个请求耗了 50ms，其中 45ms 这个 goroutine 根本没在跑，它在等。等什么？等锁？等网络？被 GC 打断？还是想跑却没有 P 可用（9.2）？CPU 画像对「等待」一无所知，因为它只采样正在执行的栈，一个阻塞的 goroutine 不在任何 CPU 上，自然不会被采到。

回答「为什么等」要靠另一件工具，执行追踪器（execution tracer）。它不做统计抽样，而是 逐条记录运行时事件，按纳秒级时间戳排成一条时间线：哪个 goroutine 在哪一刻被创建、开始跑、阻塞、被唤醒、结束;每个 P 何时开始与停止调度;每次 GC 走到哪个阶段;每个系统调用何时进出。把这条时间线交给 go tool trace 渲染，你能逐毫秒地看清程序里发生了什么。这一节讲它记录什么、怎么用、以及它近年从「重而全」走向「轻而按需」的演进。

16.3.1 追踪器记录什么：运行时事件的时间线

执行追踪器内建在运行时里（runtime/trace.go），它捕获的不是用户代码的函数调用，而是 运行时与调度器层面的状态转移。runtime/trace.go 的设计注释把这份事件清单列得很清楚：

goroutine 生命周期：创建（go 语句）、开始运行、阻塞、被唤醒、退出;
阻塞的原因：在 channel 收发、在 sync.Mutex、在网络 I/O（netpoller，9.9 网络轮询器）、在 select 上各是不同的事件类型;
每个 P 的调度活动：P 何时启动、停止、被抢占;
GC 相关事件：标记开始、标记结束、各 STW（stop-the-world）停顿、堆大小的变化（13.3）;
系统调用：进入、返回、以及因系统调用阻塞而交还 P 的时刻。

大多数事件都附带一个纳秒精度的时间戳和一份栈回溯。这意味着 trace 不仅告诉你「这里发生了一次阻塞」，还告诉你「是哪一行代码、在哪个调用栈深处阻塞的」。把这些事件按 P、按 goroutine 在时间轴上铺开，go tool trace 画出一张可交互的时间线，你能直接读出：这一刻有几个 P 在干活、哪个 goroutine 跑在哪个 P 上、它为什么停下、GC 是不是正在和业务抢 CPU。

16.4 代码测试

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

16.4 代码测试

测试在 Go 里不是外挂，而是语言工具链的一等公民。go test 内建，testing 包标准，约定取代配置。这套设计上的选择，深刻塑造了 Go 的工程文化：在别的语言里「要不要写测试、用哪个框架」是一道需要权衡的决策，在 Go 里它是默认动作。这一节讲清这套机制如何运转、为何如此设计，以及它从单元测试一路长到 Go 1.18 模糊测试的谱系。

16.4.1 一等公民：约定取代配置

Go 的测试靠约定运转，几乎零配置。三条规则就是全部：测试文件以 _test.go 结尾，测试函数形如 func TestXxx(t *testing.T)，与被测代码放在同一个包里。go test 会自动发现并运行它们，不需要 XML 配置、不需要外部 runner、不需要注解。一个项目无论多大，go test ./... 一行就跑遍全部测试：

// strings_test.go，与被测包 strings 同目录、同包
package strings

import "testing"

func TestIndex(t *testing.T) {
    got := Index("chicken", "ken")
    if got != 4 {
        t.Errorf("Index = %d, want 4", got) // 报告失败，但不中断
    }
}

「约定优于配置」带来两层收益。其一是零门槛：写测试不需要先学一套框架，函数签名对了就能跑。其二，也是更深远的一层，是整个生态的统一。所有 Go 项目的测试方式完全一致，于是 CI、覆盖率工具、IDE、go vet 都只需面对一种约定，无需为各色框架各写一套适配。这与别家形成鲜明对照： Java 世界有 JUnit 4 / JUnit 5 / TestNG 之分，注解与 runner 各不相同；Python 有 unittest、 pytest、nose 并存，发现规则与 fixture 机制互不兼容。框架的多样性把「跑某项目的测试」变成一件需要先读文档的事。Go 用一套内建约定把这件事抹平到了零。

16.5 基准测试与性能画像

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

16.5 基准测试与性能画像

优化的第一原则是先测量，再动手。凭直觉猜瓶颈往往猜错，真正的热点常常不在你以为的地方。Go 把这套纪律所需的工具全部做进了工具链：基准测试（benchmark）回答「多快」，性能画像（profiling）回答「慢在哪、内存花在哪」，而 benchstat 用统计方法回答「这次改动到底是真的快了，还是只是噪声」。这一节把这三件工具讲透，并把它们串成一条「画像找热点 → 改 → 基准验证」的测量驱动闭环, 这条闭环再往上，便与 PGO（15.3）和执行追踪（16.3）合流，构成 Go 完整的性能工程方法论。

16.5.1 基准测试：让「多快」可复现

基准测试用 func BenchmarkXxx(b *testing.B) 写，go test -bench 运行。它要解决的核心难题是 测量精度：单次调用一个纳秒级函数，时钟分辨率与调用开销会把信号淹没。Go 的办法是把待测代码放进循环跑很多次，再除以次数得到「每次操作的耗时」（ns/op）。但循环要跑多少次？跑少了不稳定，跑多了浪费时间。早期写法是手写一个从 0 到 b.N 的循环，框架自动反复调整 b.N、多跑几轮，直到测量窗口足够长、结果足够稳定为止：

func BenchmarkFib(b *testing.B) {
    for i := 0; i < b.N; i++ { // 框架反复加大 b.N 直到耗时稳定
        fib(30)
    }
}

这套 b.N 机制朴素可靠，却有两处长期为人诟病的坑。其一是计时边界：若基准函数里有昂贵的准备工作，它会被算进每次测量，得手动 b.ResetTimer()/b.StopTimer() 把它摘出去（见 16.5.3）。其二是死代码消除：编译器看到 fib(30) 的返回值没人用，可能直接把整个调用优化掉，于是你测了个寂寞。

16.6 运行时统计量

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

16.6 运行时统计量

画像（16.5）与追踪（16.3）属于「出事时拉来诊断」的工具：它们成本偏高、产出庞大，适合在你已经怀疑某处有问题时，针对一段时间或一次请求采下来细看。但生产环境里更常见的问题不是「现在帮我剖析一下」，而是「这个服务过去一周健康吗、什么时候开始劣化的、该不该半夜把人叫起来」。回答这类问题靠的不是一次性的深剖，而是持续的、低成本的、可长期保留的数值：堆有多大、GC 多频繁、goroutine 数量是否在涨、调度延迟的尾部有没有抬头。这类数值就是运行时指标（metrics）。

指标和画像的区别，本质是「聚合 vs 明细」与「常驻 vs 按需」。画像把每一次分配、每一段 CPU 归因到具体调用栈，信息量大、采集贵；指标只保留聚合后的标量或分布，单次读取近乎免费，因而可以每隔几秒采一次、连续采上几个月。这一节讲清 Go 暴露指标的两套接口、它们的演进，以及指标如何接入完整的可观测性体系。

16.6.1 从 MemStats 到 runtime/metrics

历史上，程序读运行时内存指标的唯一入口是 runtime.ReadMemStats，它填充一个 MemStats 结构（12.8）：

// runtime.MemStats：字段写死在结构体里（节选）
type MemStats struct {
    Alloc      uint64 // 当前存活对象占用的堆字节
    HeapInuse  uint64 // 含已用 span 的堆字节
    NumGC      uint32 // 已完成的 GC 轮数
    PauseTotalNs uint64       // 累计 STW 停顿（纳秒）
    PauseNs    [256]uint64    // 最近 256 次停顿的环形缓冲
    // ... 还有约三十个字段
}

var m runtime.MemStats
runtime.ReadMemStats(&m) // 读取时需短暂 stop-the-world

这套接口有三处硬伤。其一，字段写死在结构体里：运行时想暴露一个新指标，就得往 MemStats 里加字段、改公开 API，受 Go 兼容性承诺约束，加得很慎重，于是许多内部状态根本没有出口。其二，ReadMemStats 为了取得自洽快照，读取时要短暂 stop-the-world，在高频采集下成本不可忽略。其三，停顿信息只有一个 PauseNs 环形数组和累计值，想知道「停顿的 P99 是多少」得自己从原始数组里算，而那个数组只存最近 256 次，早就漏掉了长期分布。

16.7 语言服务协议

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

16.7 语言服务协议

自动补全、跳转定义、实时报错、重构,现代编辑器里这些功能，在 Go 这边由 gopls（Go language server，读作「go please」）提供。它背后是语言服务器协议（Language Server Protocol，LSP）。本节讲清三件事：LSP 解开的那个组合爆炸结、gopls 如何建立在编译器前端的可复用库之上、以及它为何称得上 Go 工具链思想的集大成者。

16.7.1 LSP：解开 M×N 的结

设想没有 LSP 的世界。要让 M 个编辑器都支持 N 种语言的智能功能，朴素的做法是为每一对「编辑器 × 语言」单独写一套集成：VS Code 要懂 Go、懂 Rust、懂 Python，Vim 也要各懂一遍,补全、跳转、报错的逻辑在每一对里都重写。代价是 M×N 套实现，且任何一门语言的语义更新，都要在 M 个编辑器里各自跟进。这条增长曲线注定走不远。

LSP 把它解成 M+N。微软在 2016 年 6 月为 Visual Studio Code 提出这套协议(后与 Red Hat、 Codenvy 合作开放，现已成行业标准)。它的关键是定义一套与语言、与编辑器都无关的标准协议：每门语言只需写一个语言服务器（实现协议），每个编辑器只需写一个 LSP 客户端,此后任意编辑器配任意语言，自动打通。语言服务器是一个独立进程，编辑器通过标准输入输出或套接字与它通信。

协议本身建立在 JSON-RPC 之上,只有三类消息：客户端发请求（request）等服务器回响应（response），以及单向的通知（notification）。位置用「文档 URI + 行列号」表示，刻意避开任何语言特有的抽象（如某语言的 AST 节点），这正是它能跨语言通用的前提。一次「跳转到定义」的往返是这样：

第 16 章 工具与可观测性 on Go 语言原本

16.1 运行时死锁检查

16.1 运行时死锁检查

16.1.1 判据：只数运行中的 M，不看谁等谁

16.2 竞争检查

16.2 竞争检查

16.2.1 基于 happens-before 的动态检测

16.3 性能追踪

16.3 性能追踪

16.3.1 追踪器记录什么：运行时事件的时间线

16.4 代码测试

16.4 代码测试

16.4.1 一等公民：约定取代配置

16.5 基准测试与性能画像

16.5 基准测试与性能画像

16.5.1 基准测试：让「多快」可复现

16.6 运行时统计量

16.6 运行时统计量

16.6.1 从 MemStats 到 runtime/metrics

16.7 语言服务协议

16.7 语言服务协议

16.7.1 LSP：解开 M×N 的结

第 16 章工具与可观测性 on Go 语言原本