Go 定时任务如何避免重入执行：Ticker、单次触发与可观测状态设计

定时任务每分钟触发一次，看起来只是创建一个 time.Ticker；真正上线后，麻烦通常出在任务本身偶尔要跑两分钟。若下一次触发仍然直接启动 goroutine，就会出现同一份账单重复处理、缓存刷新相互覆盖，或者重试把下游服务压得更慢。进程内任务要先明确一个规则：任务未结束时，下一次触发是跳过、排队，还是合并成一次补做。

先把重入规则说清楚

同一个任务遇到慢查询、远程接口抖动或大批量数据时，周期触发一定可能追上执行中的任务。常见的三种规则如下：

• 跳过：本轮发现任务忙，记录一次 skipped，等待下一次周期。
• 排队：本轮不丢弃，但交给队列按顺序处理，适合每次触发都代表一份独立工作。
• 合并：只保留“需要再跑一次”的状态，当前任务结束后补做一轮，适合刷新索引、同步配置这类可合并工作。

本文剩下的示例都假设一个 Go 进程内只有一个调度器。多实例部署时，进程内标记不能代替跨实例协调，需要把任务状态放到队列或数据库中。

Ticker 适合“到点尝试”，不负责排队

Ticker 会按固定间隔向通道发送时间值。它适合表达“到点检查一次”，但不应该被理解成“保证每个时间点都生成一份任务”。下面的写法在任务忙时直接记一条跳过记录：

type Runner struct {
    busy atomic.Bool
}

func (r *Runner) Start(ctx context.Context, every time.Duration) {
    ticker := time.NewTicker(every)
    defer ticker.Stop()

    for {
        select {
        case 

这里的关键不是把工作放进 goroutine，而是 CompareAndSwap(false, true) 把“抢到执行权”和“标记忙碌”合成一个原子动作。任务无论成功还是失败，都要在 defer 中清掉标记，否则一次异常就可能让调度器永久停摆。

三种方案怎么选

可以先按任务语义选，再按实现复杂度收敛：

• 允许偶尔跳过：选择 Ticker + atomic.Bool。例如定时刷新内存配置，下一轮仍会读取最新值。
• 每轮都不能丢：选择有界队列或串行 worker。不要把每次 Ticker 信号都直接变成 goroutine。
• 只需补做一次：使用“当前运行 + 待补做”两个状态。新信号到来时只设置待补做，当前任务结束后再执行一次。

如果任务平均耗时接近周期，跳过计数会持续升高，这不是调度器自动变聪明了，而是周期与工作量不匹配。此时应延长周期、拆小任务，或明确引入队列。

需要补做时，用单次 Timer 表达下一次时间

缓存刷新常见的需求是：运行期间来了多少次触发都不重要，但结束后至少再刷新一次。这个语义不适合无限累积通道，可以用一个布尔状态合并信号：

type CoalescingRunner struct {
    mu      sync.Mutex
    running bool
    pending bool
}

func (r *CoalescingRunner) Trigger() {
    r.mu.Lock()
    if r.running {
        r.pending = true
        r.mu.Unlock()
        return
    }
    r.running = true
    r.mu.Unlock()
    go r.run()
}

func (r *CoalescingRunner) run() {
    for {
        refreshOnce()
        r.mu.Lock()
        if !r.pending {
            r.running = false
            r.mu.Unlock()
            return
        }
        r.pending = false
        r.mu.Unlock()
    }
}

这个版本没有保留十个、二十个待处理副本，而是只保留一个“结束后要再跑”的事实。若刷新动作本身不可合并，就不要套用它，改成带容量和拒绝策略的队列。

可观测状态决定了方案是否能维护

只打“任务开始”和“任务结束”两条日志，排查跳过问题仍然不够。至少记录：

• running：当前是否有任务在运行。
• last_started_at、last_finished_at：最近一次开始和完成时间。
• last_duration_ms：最近一次耗时，用来和周期比较。
• skipped_total、pending：被跳过的次数或是否有待补做。
• last_error：最近一次错误摘要，避免只在控制台短暂出现。

验收时可以人为把 refreshOnce 延迟到两个周期以上，然后确认：跳过方案的并发运行数始终为 1，跳过计数增长；合并方案的 pending 最终会归零，并且完成次数比触发次数少但不会长期停留在运行中。

几个容易误用的边界

不要用 sleep 代替调度状态

在循环末尾休眠只能改变下一次触发时间，不能告诉监控系统当前是否忙，也不能处理关闭信号。用 context.Context 控制生命周期，把结束状态放在明确的状态字段里。

不要让无界 goroutine 承担排队

每次收到 Ticker 信号就启动 goroutine，短期看起来没有阻塞，长期会把下游连接数、内存和重试压力一起放大。需要保留每轮工作的任务，应使用有界队列并给出满载时的结果。

不要把进程内标记当成分布式锁

两个副本各自拥有一个 atomic.Bool，它们仍会同时处理同一业务对象。多副本场景必须把唯一性边界放在共享存储、任务队列或业务幂等键上。

发布前的最小决策表

把“到点触发”和“工作是否完成”拆成两个概念，Go 定时任务就不会被 Ticker 的表面简单性带偏。先写清楚跳过、排队或合并的业务语义，再决定使用原子标记、队列还是待补做状态，后续的日志和监控也会自然落到正确位置。

相关问题

Ticker 停止后还会不会执行一次？

停止只会阻止后续周期信号，已经取出的信号和已经开始的任务仍需由业务代码自行收尾。

任务失败后应该立刻重试吗？

先区分可重试错误和业务拒绝；重试要有上限和退避，不能在失败分支里无限启动新 goroutine。

如何确认定时任务没有重入？

给每次运行记录唯一 run_id，同时暴露当前运行数、跳过数和最近耗时，用延迟超过周期的测试场景验证并发数始终符合规则。