Go time.Ticker 用完要不要 Stop：长期服务中的计时器泄漏与退出清理

一个每分钟刷新配置的 Go 服务，运行几天后 goroutine 数量慢慢上涨，最后在发布重启时还要等一批任务自己结束。排查这类问题时，先记住一个边界：time.Ticker 应该在不再使用时调用 Stop，但它只停止后续 tick，不会替你结束消费循环，也不会取消正在执行的任务。真正可靠的收尾，需要把计时器、循环、任务和下游资源放进同一条退出路径。

跑常驻Go服务的同学大概率都碰到过进程运行越久占用越高、定时任务莫名重复执行的诡异情况，不少这类问题最后排查下来都和Ticker没有正确停止有关，答案很明确：只要Ticker的生命周期不需要维持到整个进程完全退出，就必须手动调用Stop，不少人踩坑是因为搞错了Stop的实际效果边界，以为调用了就万事大吉，反而引发更隐蔽的泄漏。

不要默认依赖进程退出自动清理计时器，只要你写的代码里会动态启停周期任务，就必须明确设计停止逻辑，不能等资源泄漏了再补补丁。

为什么服务运行久了，计时器问题才暴露

跑一次性的命令行程序时进程很快就结束，哪怕把 ticker 留在函数里没处理，短时间内根本看不出明显异常。常驻服务完全不同：配置刷新、缓存检查、指标采样都可能被封装成单独的启动函数，每次重载时就会被再次调用。如果旧的定时循环没有正常退出，新的循环又被启动，任务实例数量就会一层层叠加。

下面这个写法看起来简单直观，实际上完全没有预留退出入口：

func startRefresh(ctx context.Context, load func() error) {
    ticker := time.NewTicker(time.Minute)
    go func() {
        for range ticker.C {
            _ = load()
        }
    }()
}

这里有三个独立问题：ctx 没被使用；循环只能等待下一个 tick；ticker 没有明确的停止位置。调用方即使取消了上下文，这个 goroutine 也不知道。

先分清 Stop、退出循环和任务取消

ticker.Stop() 的作用是停止 ticker，不会关闭 ticker.C，也不会向接收方发送一个“结束”值。因此，下面这种改法仍然可能让循环卡住：

ticker := time.NewTicker(time.Minute)
defer ticker.Stop()

for range ticker.C {
    if err := load(); err != nil {
        return err
    }
}

当外层函数返回时，defer 会调用 Stop，但如果这个循环跑在独立 goroutine 里，外层函数早已返回，循环本身仍然没有收到退出通知。更稳妥的判断是：

用退出信号让周期循环真正停下来

一个可正常复用的周期任务至少要有两条监听分支：一条处理定时触发的任务逻辑，一条处理外部取消信号。把停止动作放在循环所属的函数内部，资源的所有权逻辑才足够清晰。

func startRefresh(ctx context.Context, interval time.Duration, load func(context.Context) error) func() {
    ticker := time.NewTicker(interval)
    done := make(chan struct{})

    go func() {
        defer ticker.Stop()
        defer close(done)

        for {
            select {
            case 

调用方先取消上下文，再等待返回的收尾执行完成：

waitRefresh := startRefresh(ctx, time.Minute, refreshConfig)

cancel()
waitRefresh() // 确认循环已退出

这段代码有一个实用的顺序：取消信号阻止新的业务轮次进入；循环从 select 返回后执行 ticker.Stop；done 关闭，调用方才知道可以继续关闭连接或退出进程。

任务本身也要响应取消

如果 load 内部执行一个不检查上下文的慢操作，那么 ticker 循环虽然已经收到取消信号，当前调用仍可能拖住退出。网络请求、数据库查询和批量文件处理都应该把同一个上下文继续传下去。

func refreshConfig(ctx context.Context, db *sql.DB) error {
    rows, err := db.QueryContext(ctx, `select key, value from app_config`)
    if err != nil {
        return err
    }
    defer rows.Close()

    for rows.Next() {
        if err := ctx.Err(); err != nil {
            return err
        }
        // 读取并校验一条配置
    }
    return rows.Err()
}

这里别只检查 ctx.Err() 就下结论：数据库驱动是否支持取消、业务循环是否在每个批次边界检查、当前任务是否能安全重试，都要单独确认。停止 ticker 只是“不再开始新任务”，不是“当前任务立即消失”。

重载场景怎么避免启动第二条循环

配置热加载场景最容易重复启动周期任务。推荐把周期任务作为独立的明确组件，由一个全局拥有者统一保存对应的停止函数；重载的时候先停止旧组件并等它完全收尾，再创建新的组件实例。

type Refresher struct {
    mu   sync.Mutex
    stop context.CancelFunc
    wait func()
}

func (r *Refresher) Replace(parent context.Context, load func(context.Context) error) {
    r.mu.Lock()
    oldStop, oldWait := r.stop, r.wait
    r.stop, r.wait = nil, nil
    r.mu.Unlock()

    if oldStop != nil {
        oldStop()
        oldWait()
    }

    ctx, cancel := context.WithCancel(parent)
    wait := startRefresh(ctx, time.Minute, load)
    r.mu.Lock()
    r.stop, r.wait = cancel, wait
    r.mu.Unlock()
}

生产代码还要处理并发替换的竞态问题，比如用组件状态标识或者更严格的锁来保护「旧任务完全结束、新任务才允许创建」的执行顺序。核心不是把所有代码都塞进一个锁里，而是明确谁拥有停止权限、谁负责等待任务退出、谁允许创建下一轮新任务。

用可观察证据确认真的收尾

做完逻辑修复后至少要做一轮短间隔测试，没必要真的把定时间隔设成一分钟等很久。把 interval 参数注入成 50 毫秒，连续执行启动、取消、等待的流程，重复几轮之后观察任务计数是不是能回到初始零值。

ctx, cancel := context.WithCancel(context.Background())
var running atomic.Int64

wait := startRefresh(ctx, 50*time.Millisecond, func(ctx context.Context) error {
    running.Add(1)
    defer running.Add(-1)
    select {
    case 

线上排查验证的时候要把观测证据分成三类：goroutine 数量有没有持续上涨；刷新任务在触发取消之后有没有新的执行日志；数据库连接、文件句柄和 HTTP 请求这类下游资源的占用有没有在任务收尾后回落。只看控制台没有报错说明不了问题，因为泄漏大多是资源曲线缓慢变坏的，很难一眼发现。

常见问题

调用 ticker.Stop 后还能从 ticker.C 读到值吗？

Stop 会阻止后续的 tick 事件发送，但不会主动关闭内部通道。不要依赖从通道读到零值来判断任务已经结束，应该通过 context、专属 done 通道或者其他明确的退出信号离开循环逻辑。

每次创建 ticker 都必须调用 Stop 吗？

只要 ticker 的生命周期可能早于进程结束，就应该安排调用 Stop。短生命周期函数里可以直接用 defer 来做清理，常驻 goroutine 里则要把 Stop 动作放在 goroutine 自身的退出路径里执行。

任务执行时间超过 tick 间隔会发生什么？

Ticker 不会为每个时间点无限缓存排队待处理的事件；消费端应该把任务是否允许并发、是否可以跳过过期的旧 tick 逻辑写清楚。需要串行刷新的场景，先完整执行完当前任务再接收下一轮定时事件，整体逻辑更容易控制。

为什么取消 context 后程序还没有马上退出？

取消操作只是发出一个信号。正在执行的业务函数必须主动检查 context 状态，底层 I/O 操作也要使用原生支持取消的 API；最后再用等待机制确认 goroutine 已经完全退出。

收尾检查清单

• ticker 的创建者是否拥有唯一的 Stop 权限。
• 周期循环是否同时监听 tick 事件和退出信号。
• 当前业务任务是否把 context 传给数据库、HTTP 或文件操作逻辑。
• 重载流程是否先停止并等待旧循环完全退出，再创建新的循环。
• 测试和监控指标能不能证明 goroutine、任务数和下游资源占用都正常回落。