Go ticker 没有 Stop 怎样形成长期资源泄漏

先把结论说清楚：time.NewTicker 没有调用 Stop()，不一定在 Go 1.23 及以后直接造成 GC 意义上的永久泄漏；如果 ticker 已经完全失去引用，运行时可以回收它。但在服务代码里，ticker 往往被后台 goroutine、闭包或长生命周期对象持有，这时不退出消费循环，任务就会一直活着，定时工作也会持续累积。真正要修的是“谁拥有 ticker、谁负责退出”。

一、先判断 ticker 是否真的失去引用

容易误判的写法是把所有问题都归因于“少写了一行 Stop”。官方文档已经说明，Go 1.23 起，未被引用的 ticker 即使没有 Stop 也能被垃圾回收。换句话说，下面这种短函数返回后，局部 ticker 没有被其他对象保存，通常不会因为“没 Stop”一直留在堆上：

func startOnce() {
	ticker := time.NewTicker(time.Minute)
	// 函数很快返回，且没有 goroutine 或闭包继续保存 ticker。
	_ = ticker
}

风险出现在另一条引用链：函数把 ticker 交给 goroutine，goroutine 又长期读取 ticker.C，或者把 ticker 放进服务对象字段。此时对象仍然可达，GC 没有理由替你结束业务。图1是这条关系的静态说明图，不是运行截图。

二、长期资源泄漏通常来自“创建”和“退出”不对称

生产代码最常见的形态是某个请求、重连回调或配置刷新路径反复调用启动函数。每次调用都创建一个 ticker 和一个 goroutine，但停止服务时只有外层对象被标记为关闭，没有让这些 goroutine离开 select。这样即使每个 ticker 的单次开销不大，创建次数增加后，goroutine、定时回调和它们捕获的业务对象都会长期存在。

可以先沿着三个问题排查：创建入口是否只执行一次、退出条件是否能被消费循环收到、拥有 ticker 的对象是否保存了停止责任。如果 goroutine dump 中反复出现同一业务函数停在 ，再去看“有没有 Stop”才有意义；单看堆上 ticker 数量，无法说明是哪一条引用链没有断。

三、把 Stop 放在拥有 ticker 的生命周期里

一个可复用的写法是让启动函数内部同时负责 ticker 和 goroutine 的退出。done 收到关闭信号后，循环返回；函数返回前由 defer 调用 Stop。两者缺一不可：只 Stop 不保证消费 goroutine 结束，只 return 而不 Stop 又会留下不必要的定时器调度责任。

func runRefresh(done 

这里不要手动关闭 ticker.C。官方定义是 Stop 关闭 ticker 的发送行为，但不会关闭这个只读通道；调用方应通过 done 或上下文控制消费循环，而不是等待通道关闭。图2把这个边界单独画出来。

四、排查与修复的最小清单

修复线上疑似泄漏时，我会先做低成本的计数：记录启动函数调用次数、当前活跃 worker 数和服务关闭时收到的退出信号。再用 goroutine profile 看同一调用栈是否持续增加，最后检查重载、重连和失败重试路径是否重复创建 ticker。不要用“内存暂时下降了”作为唯一结论，因为 goroutine 未退出、任务仍在执行和引用链仍然存在，可能在下一轮配置变更后再次暴露。

相关问题

Go 1.23 后还要不要写 ticker.Stop？

要。它仍然表达业务上的“停止继续产生 tick”，也让生命周期边界明确；只是它不再是帮助 GC 回收无引用 ticker 的唯一手段。

Stop 会不会关闭 ticker.C？

不会。不要把读取循环写成等待通道关闭；用退出信号、context 或明确的 return 结束 goroutine。

只写 Stop 仍然看到 goroutine 增长怎么办？

重点转向创建入口和退出分支：确认每次启动是否只对应一个 worker，并检查 worker 是否真的能收到退出信号。