Go trace 怎样观察 goroutine 调度

Go 的 trace 不是只看某个函数耗时的计时器，而是记录一段时间内 goroutine 如何运行、阻塞、被唤醒，以及它和系统调用、GC、处理器之间的关系。要观察 goroutine 调度，通常先采集一个短窗口的执行追踪，再用 go tool trace 查看运行区间和等待区间；如果要找 CPU 热点，仍应转向 pprof。

先分清 trace 能回答什么

执行追踪适合回答“这段时间里 goroutine 在等什么”“处理器是否有空闲”“大量 goroutine 是否同时卡在 channel、锁或系统调用附近”。官方文档还把调度、系统调用、垃圾回收和堆大小等运行时事件列为可视化对象。

它不适合直接回答“哪个函数消耗了最多 CPU”或“哪一行分配最多内存”。前者用 CPU profile，后者用 heap profile；把这些问题混在一起，最后容易得到一张信息很多但结论不清楚的时间线。

用最小窗口采集 trace.out

测试是最容易复现的入口：

go test -trace=trace.out ./path/to/package

# 生成测试执行追踪文件，便于把一个具体用例的调度现象固定下来
go tool trace trace.out

如果要给独立程序加一个短采集窗口，可以把 trace.Start 和 trace.Stop 放在明确的生命周期边界内：

package main

import (
	"os"
	"runtime/trace"
)

func collectTrace() (func(), error) {
	// 文件只用于本次短窗口；调用方应在结束时执行返回的 stop 函数。
	f, err := os.Create("trace.out")
	if err != nil {
		return nil, err
	}
	if err := trace.Start(f); err != nil {
		_ = f.Close() // 启动失败时释放文件句柄。
		return nil, err
	}
	return func() {
		trace.Stop() // 先结束追踪，确保缓冲数据写完。
		_ = f.Close() // 再关闭文件，保留完整 trace.out。
	}, nil
}

采集窗口应围绕一个能复现的慢请求、批处理或并发测试，而不是让线上进程无限制地产生大文件。Go 1.22 对执行追踪的实现做过重构，追踪数据可分段处理，查看器也增加了线程视图；实际排查仍要记录构建版本和采集场景。

在时间线里观察 goroutine 调度

打开 trace.out 后，先用时间范围缩小到异常片段，再沿着 goroutine 的运行区间看它何时变为 runnable、何时因为 channel、锁、网络或系统调用等待。若多个 goroutine 的运行被同一个等待点切成许多短段，说明瓶颈更可能在共享资源或下游等待，而不是简单地“goroutine 数量不够”。

判断时可以按下面的对应关系记录证据：

用业务标记减少匿名时间线

只看 goroutine 编号通常不够。对一个跨多个 goroutine 的请求，可以建立 task；对同一个 goroutine 内的阶段，可以用 region；需要记录轻量线索时再用 log：

ctx, task := trace.NewTask(ctx, "order-sync")
defer task.End()

trace.WithRegion(ctx, "load-cache", func() {
	// region 表示同一个 goroutine 内的阶段，名称应保持少量且稳定。
	loadFromCache(ctx)
})
trace.Log(ctx, "order", orderID) // 只写不敏感的业务标识，方便在 trace 中筛选。

NewTask 通过 context.Context 把逻辑任务关联到多个 goroutine；WithRegion 的开始和结束仍属于调用它的 goroutine。标记名不要把用户隐私、令牌或完整请求内容写入追踪文件。

相关问题与边界

trace 能代替 pprof 吗？

不能。trace 解释一段时间里的调度和等待，pprof 更适合定位 CPU、内存和锁竞争热点，两者应按问题分工。

为什么 trace 文件不宜无限变大？

事件越多，解析和传输成本越高。优先缩短窗口、缩小复现范围，必要时再考虑持续追踪或飞行记录能力。

怎样确认看到的是调度问题？

把时间线中的等待点与代码中的 channel、锁、系统调用或 GC 证据对应起来；只有“运行区间变少”本身还不足以证明根因。