Go time.Ticker周期任务跳过重叠执行的调度方案

周期任务最容易出现的隐患，不是 time.Ticker 本身，而是每次收到 tick 都直接启动一个 goroutine：当任务耗时超过周期，同一份同步、清理或探活逻辑就会并发执行。更稳妥的做法是让 ticker 只负责发出触发信号，再交给一个容量为 1 的缓冲和一个单 worker 串行处理。任务运行期间只保留一个下一次触发，后续信号跳过，既不重叠，也不会因为一次慢执行永久错过下一轮。

先把 time.Ticker 和任务执行拆开

time.NewTicker 会按周期向 C 发送时间值，但它不理解业务是否已经完成。常见错误写法是在接收处直接启动 goroutine，周期一到就继续派发。修复的关键是增加一个“触发入口”：ticker 只尝试向这个入口放入信号，真正的任务由唯一 worker 读取。

用单槽缓冲跳过重叠触发

下面的 schedule 只允许一个 worker 执行 runJob。worker 忙碌时，缓冲槽可以留下一个信号；槽已经有信号时，新的周期直接丢弃。

package scheduler

import (
    "context"
    "log"
    "sync"
    "time"
)

func schedule(ctx context.Context, period time.Duration, runJob func(context.Context) error) {
    ticker := time.NewTicker(period)
    defer ticker.Stop() // 退出调度循环时释放 ticker

    trigger := make(chan struct{}, 1) // 只保留一个待处理触发
    var workers sync.WaitGroup
    workers.Add(1)

    go func() {
        defer workers.Done() // 确保调用方能等待 worker 收尾
        for {
            select {
            case 

这里的“跳过”发生在信号层，而不是杀掉正在运行的任务。worker 只有一个，因此 runJob 尚未返回时绝不会再次进入；任务完成后若槽中有信号，下一轮 select 会立即消费它。

单槽策略的参数、结果与边界

要注意 ticker 自身也可能在接收方繁忙时合并或丢弃节拍，所以不要把时间值当作“每一次发生的可靠事件”。如果业务要求补齐次数，应记录待处理数量或把任务写入可靠队列；如果只是希望慢任务结束后再做一次最新刷新，单槽缓冲更简单。

停止、回滚与告警检查清单

生产接入时先用短周期或手动触发验证：任务日志里同一批次不应出现重叠开始；任务失败应记录错误并继续等待下一次触发；取消时应让 runJob 检查 ctx.Done()，否则 workers.Wait() 可能长期等待。回滚可以把单槽容量改为零并暂时停用调度入口，但不要为了“追上进度”直接恢复每 tick 一个 goroutine 的写法。

建议监控运行耗时、任务失败数、取消耗时和“跳过触发数”。跳过数持续升高通常说明周期小于任务处理时间，应该调整周期、拆分任务，或改用队列，而不是盲目扩大缓冲。

常见问题

为什么不直接用互斥锁包住任务？

互斥锁能阻止并发，但每个 tick 仍可能创建 goroutine，等待者会堆积。单 worker 从源头限制了 goroutine 数量，背压语义更清楚。

容量改成 10 是否更保险？

不一定。容量越大，越像排队而不是跳过重叠；如果任务不可重复或触发不能丢，应使用明确的队列和持久化策略。

任务失败后要不要停止 ticker？

可恢复的业务错误通常只记录并继续；配置错误、数据损坏或连续失败则应由告警策略决定是否取消 context，避免静默重试。

官方资料：https://pkg.go.dev/time