Go ticker 不 Stop 为什么服务运行久了资源增加

我在排查 Go 服务的常驻资源曲线时，遇到过一个很容易误判的现象：每次刷新配置或创建一个后台任务，服务都多出一个 time.Ticker，运行时间一长，内存、goroutine 或定时任务数量一起往上走。很多文章会直接说“ticker 不 Stop 就一定泄漏”，但这个结论太粗。

真正需要修复的是生命周期不匹配：创建 ticker 的任务已经结束，ticker 或消费它的 goroutine 却仍然被引用。Stop 应该跟着任务的结束路径执行；在 Go 1.23 及以后，GC 能回收已经没有引用的 ticker，但它不会替业务代码停止后台工作。

官方依据：https://pkg.go.dev/time

先分清 Stop 到底负责什么

time.NewTicker(d) 返回一个带有只读通道 C 的 ticker，周期必须大于零。Stop 会让 ticker 不再发送 tick，但不会关闭 C。因此，消费循环不能把“读到 channel 关闭”当作停止条件，而应该同时监听明确的退出信号。

ticker := time.NewTicker(time.Second)
defer ticker.Stop() // 任务返回时停止后续 tick，避免生命周期悬空

for {
    select {
    case now := 

这段写法的关键不是把 Stop 当成“关闭通道”，而是让它与函数返回绑定。只要函数可能因为取消、错误或服务关闭而返回，defer 就能覆盖这些退出路径。

为什么服务运行久了资源会增加

最常见的情况不是单独漏写一行 Stop，而是下面几件事叠加：请求或配置事件重复调用 NewTicker；新 ticker 被闭包、结构体或 goroutine 保存；旧的 worker 没有退出分支；任务只在正常返回时清理，取消和错误路径没有清理。

例如下面的结构会持续制造后台工作者。每次调用都启动一个新的 goroutine，而调用方没有保存取消函数，也没有任何结束条件：

func startWorker() {
    ticker := time.NewTicker(time.Minute)
    go func() {
        for range ticker.C {
            refreshCache() // 每个 worker 都会长期占用一个执行路径
        }
    }()
}

即使当前 Go 版本的 GC 能回收“没有引用”的 ticker，这里的 goroutine 仍然持有 ticker，而且它自己也没有退出条件，所以引用并没有消失。此时应该优先修正 worker 的拥有关系，而不是只在外层追加一次 Stop。

正确写法：让 ticker 跟着任务一起结束

常驻任务最好由调用方持有一个明确的取消入口。让 context 负责表达“业务不再需要”，让 ticker.Stop 负责停止计时器，让 worker 在同一个退出分支结束。

func runRefresh(ctx context.Context) {
    ticker := time.NewTicker(30 * time.Second)
    defer ticker.Stop() // 无论取消还是异常返回，都释放计时器的业务使用权

    for {
        select {
        case 

如果任务需要重新配置周期，可以调用 Reset，但新周期也必须大于零。不要通过“再创建一个 ticker”来替换旧对象，否则旧 worker 仍可能在后台运行。

Go 1.23 之后还要不要写 Stop

Go 官方源码说明：Go 1.23 之前，尚未到期且没有调用 Stop 的 ticker 不能被 GC 回收，因此旧代码通常会在创建后立即 defer t.Stop()。从 Go 1.23 起，GC 可以回收已经没有引用的 ticker，所以“不 Stop”不再自动等于运行时对象永久泄漏。

但这不意味着可以删除所有 Stop：

• 业务任务还在运行时，ticker 仍会继续提供 tick；
• worker 可能持有 ticker、context 或闭包引用，GC 无法替你判断业务何时结束；
• Stop 是明确的生命周期表达，能阻止后续 tick，也能让代码阅读者知道资源何时停止。

排查资源增加时先看哪几处

第一，搜索所有 time.NewTicker 和 time.Tick 的创建点，确认它们是否发生在请求、重试或配置刷新路径。第二，沿着每个创建点找到对应的 goroutine，确认是否有 ctx.Done()、错误返回或关闭信号。第三，检查退出分支是否包含 Stop，以及是否可能重复创建而不替换旧 worker。

如果只能观察运行指标，可以分别记录 goroutine 数量、任务实例数和配置刷新次数；三者同步增长通常说明是生命周期重复创建。不要把一次 GC 后内存下降当成任务已经停止的证据，真正的判断是 worker 数量是否回到预期、取消后是否仍有周期性业务动作。

相关问题

Stop 会关闭 ticker.C 吗？不会。Stop 只停止发送，代码应监听 context 或其他退出信号。

可以用 time.Tick 替代 NewTicker 吗？需要可控生命周期时不建议。NewTicker 返回对象，可以明确调用 Stop 和 Reset。

服务重启时还需要 Stop 吗？进程退出会结束运行时资源，但在测试、热更新、配置刷新和可复用 worker 中，仍应显式管理任务生命周期。