Go runtime/trace 观察阻塞区域的阅读方式

Go 程序出现“CPU 不高但请求很慢”时，先别急着加 goroutine。runtime/trace 记录的是一段时间内 goroutine 的运行、阻塞与唤醒、系统调用、GC 和调度事件；阅读阻塞区域的关键，是先固定复现窗口，再把等待类型和调用栈对应起来。这样才能判断是 channel/锁等待、网络等待，还是调度延迟。

官方地址：https://pkg.go.dev/runtime/trace

最小可行的判断路径是：用 go test -trace 采集一份短 trace，在 go tool trace 中定位等待类型和关联 goroutine，最后用对应的 -pprof 类型复查；trace 适合回答“什么时候没有运行、在等什么”，不适合单独替代 CPU 或内存剖析。

先把阻塞观察范围固定下来

排查时优先选择一个能稳定复现的测试，而不是给整个服务长时间打开 trace。测试包可以直接输出执行轨迹：

# 只覆盖目标测试，trace.out 便于后续反复阅读
go test -run '^TestQueueWait$' -count=1 -trace=trace.out ./internal/queue

# 打开执行轨迹阅读器；这是静态分析入口，不代表浏览器页面本身是证据
go tool trace trace.out

独立程序则用 runtime/trace.Start 和 trace.Stop 包住一个短窗口。Stop 返回时，轨迹写入已经完成，适合在退出前确保文件可读：

package main

import (
	"log"
	"os"
	"runtime/trace"
)

func main() {
	f, err := os.Create("trace.out")
	if err != nil {
		log.Fatal(err) // 文件创建失败时不要继续运行未记录的实验
	}
	defer f.Close() // 释放文件句柄，避免轨迹文件尾部未关闭
	if err := trace.Start(f); err != nil {
		log.Fatal(err) // 已有 trace 活动时，当前窗口不能重复开启
	}
	defer trace.Stop() // 等待 trace 写完后再结束进程
	runTargetWork()
}

func runTargetWork() {
	// 这里放能复现等待的最小业务片段，而不是整套服务。
}

用 task 和 region 让阻塞对象可读

只有一堆匿名 goroutine 时，阅读器里的等待关系很快会失去上下文。trace.NewTask 适合代表一次请求、一次消费或一个本地操作，它返回带任务信息的 context；trace.WithRegion 适合标记同一 goroutine 内的阶段。region 必须在创建它的 goroutine 中结束，跨 goroutine 的逻辑边界应使用 task。

func process(ctx context.Context, jobID string, input 

region 类型不要按订单号无限创建；订单号应放在 trace.Log 的消息中，而 region 类型保持少量稳定值。这样按阶段聚合时，名称不会被业务数据冲垮。

在阅读器里识别真正的阻塞区域

进入 trace 页面后，先找目标 task 或 region，再观察关联 goroutine 在哪些区间处于等待状态。一个区域“没有 CPU 活动”只能说明它在等待，不能直接说明是锁竞争：要继续看它对应的调用栈、唤醒方和等待类别。长时间执行的计算通常应转到 CPU profile，trace 更擅长揭示并发被串行化、channel 没有接收方、网络或 syscall 卡住等现象。

用 pprof 导出把判断变成可复查结果

go tool trace 可以把一份 trace 转成针对性的剖析输入。不要一次导出所有类型；先根据阅读器中看到的等待类别选择一种，减少无关信息：

# 同步阻塞：用于观察锁、channel 等等待关系
go tool trace -pprof=sync trace.out > sync.pprof

# 网络阻塞：用于进一步检查网络等待栈
go tool trace -pprof=net trace.out > net.pprof

# 用 pprof 阅读导出的文件；输入文件名要和前面的类型保持一致
go tool pprof sync.pprof

官方工具还支持 syscall 和 sched。导出结果的排序只能帮助你缩小范围，不能替代对复现条件的解释。例如同步等待排名靠前时，还要确认它是否只发生在压测收尾、测试清理或故意的背压阶段。

修复后用对照 trace 收尾

一次 trace 只能说明采集窗口内发生了什么。修改缓冲区、锁粒度、超时或并发度后，应保持相同测试入口和近似输入，再采集第二份 trace。对照时重点看四件事：目标 task 的总延迟是否下降、等待区域是否缩短、等待是否转移到另一个资源、吞吐提升是否伴随 GC 或调度开销增加。

还要注意诊断工具之间可能互相影响：官方诊断文档提醒，精确内存剖析、CPU 剖析和阻塞剖析的组合可能改变被观察程序的行为。生产问题宜用短窗口或 Flight Recorder 留住现场，实验结论则用同一套负载做前后对照。

相关问题

runtime/trace 能直接找到最耗 CPU 的函数吗？

不适合单独做这件事。它主要解释运行时事件和延迟组成；热点函数应配合 CPU profile 阅读。

region 可以在一个 goroutine 创建、另一个 goroutine 结束吗？

不可以。region 要在创建它的 goroutine 中结束；需要跨 goroutine 表达逻辑操作时，用 NewTask 返回的 task。

为什么 trace 文件不宜覆盖很长时间？

长窗口会放大文件和阅读成本，也会把不相关的请求混在一起。先缩小到可复现的测试或短请求窗口，结论更容易复查。