Go runtime/trace Start 后忘记 Stop 会影响什么

如果调用了 runtime/trace.Start 却忘记 trace.Stop，最直接的后果不是“立刻崩溃”，而是当前进程的执行追踪会一直保持开启：后续运行时事件继续写入传入的 io.Writer，直到进程结束或其他代码调用 Stop。短命命令可能只留下收尾不完整的追踪文件；长驻服务则会持续承担追踪开销，并且下一次 Start 会因为已有追踪而失败。

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

把 Stop 当成“结束采集并等待写入完成”的动作，把文件关闭当成另一个独立动作。正确顺序是先停止追踪，再关闭 Writer；最稳妥的写法是用两个 defer，并让 trace.Stop 后注册、先执行。

先看清需要保护的三个资产

这类问题容易被笼统地称为“资源泄漏”，但排查时应该拆成三个资产：第一是 runtime 的全局追踪状态，第二是 Start 接收的 Writer，第三是 Writer 背后的文件或网络输出。Start 开始后，追踪数据会被缓冲并写向 Writer；Stop 返回前会等待追踪写入完成。它不会替你创建或关闭文件，因此文件句柄的关闭仍由调用方负责。

短命命令：更可能得到不完整的尾部

如果程序启动追踪后很快返回，忘记 Stop 的表现取决于进程结束时机和 Writer 的实现。程序退出前没有显式完成追踪收尾，就不能把输出文件当作“已经完整写完”的证据：最后一批事件、索引或结束标记可能没有被完整写出，后续用 go tool trace 打开时可能得到缺失信息或解析错误。

这里要注意边界：忘记 Stop 不等于每次都会生成坏文件。如果程序运行时间足够长、Writer 没有提前关闭，部分数据仍可能已经写入；但这种偶然可读不能替代明确的生命周期保证。排错时应先看程序是否在 Stop 返回前关闭了文件，而不是反复重试查看器。

长驻服务：追踪状态和持续开销才是重点

在服务、测试守护进程或常驻 worker 中，漏掉 Stop 的影响更明显。追踪不会因为某个函数返回就自动结束，后续 goroutine 的创建、阻塞、系统调用、GC 和处理器事件仍可能进入追踪输出。采集范围越长，Writer 接收的数据越多，追踪本身也会带来持续的 CPU、内存和 I/O 压力。

另一个常见症状是“第二次 Start 不生效”。官方契约规定，追踪已启用时再次调用 Start 会返回错误。因此，代码若把 Start 放在按请求或按任务触发的函数里，却没有在同一生命周期中 Stop，第一次任务结束后，后续任务就可能只看到 tracing is already enabled，却误以为是输出文件权限问题。

正确写法：让 Stop 先于 Close 执行

下面的关键不是多写一个 defer，而是注册顺序。Go 的 defer 按后进先出执行，因此先注册文件关闭，再注册 trace.Stop，退出时就会先 Stop、后 Close，给追踪器完成最后写入的机会。

package main

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

func main() {
	f, err := os.Create("trace.out")
	if err != nil {
		log.Fatalf("创建追踪文件失败: %v", err)
	}
	// 先注册 Close；defer 后进先出，Close 会晚于 Stop 执行。
	defer func() {
		if err := f.Close(); err != nil {
			log.Printf("关闭追踪文件失败: %v", err)
		}
	}()

	if err := trace.Start(f); err != nil {
		log.Fatalf("启动执行追踪失败: %v", err)
	}
	// 最后注册 Stop，因此退出时先等待追踪数据写完。
	defer trace.Stop()

	runWork()
}

func runWork() {
	// 这里放需要采集的业务逻辑；不要在 Stop 前关闭 f。
}

如果追踪只覆盖一个明确的操作，也可以把 Start、业务调用和 Stop 放在同一个函数中，避免把全局追踪状态藏在多个层级之间。对于测试和基准，则优先使用 go test -trace=trace.out 这类测试工具链入口，让测试框架负责边界。

按证据分级排查，而不是先归因于“内存泄漏”

复查时可以在采集入口记录开始原因，在 Stop 紧邻的位置记录结束原因，并把输出文件路径与任务 ID 绑定。不要在多个并发请求里无保护地调用 Start/Stop；追踪是进程级能力，采集窗口应由一个明确的协调者管理。

结论

Start 后忘记 Stop 的核心问题，是追踪生命周期没有闭合：短进程可能缺少完整尾部，长进程会继续采集并承担开销，后续 Start 还会被已启用状态拒绝。修复时只记住两点：先让 trace.Stop 等待写入完成，再关闭它使用的 Writer；并把这两个动作放进同一个拥有采集生命周期的函数。

相关问题

Stop 会不会关闭文件？ 不会。Stop 负责结束当前追踪并等待追踪写入完成，文件由调用方关闭。

忘记 Stop 一定会导致崩溃吗？ 不一定。更常见的是输出收尾不完整、追踪窗口过长或下一次 Start 失败。

为什么 Close 必须放在 Stop 后面？ 因为 Stop 还可能需要向 Writer 写最后一批数据，过早 Close 会破坏这个生命周期假设。