Go time.AfterFunc 停止与重置怎么判断：定时回调的竞态边界

线上有个“延迟刷新”任务，调用 time.AfterFunc 后又想在用户再次操作时取消旧任务。最容易误判的是：Timer.Stop 返回 false，并不等于回调已经执行完；它只说明定时器已经触发或已经被停止。真正要防的是旧 callback 和新任务同时修改状态。

先看清 AfterFunc 到底返回了什么

time.AfterFunc(d, f) 创建定时器并返回 *time.Timer。时间到达后，f 会在自己的 goroutine 中运行；它不像 time.NewTimer 那样通过 channel 交付一次事件。因此，回调内部的读写和外部的取消代码天然存在并发关系。

timer := time.AfterFunc(200*time.Millisecond, func() {
    refreshCache()
})

if timer.Stop() {
    // 尚未触发，旧 callback 没有被启动
}

这里的成功判断只覆盖“尚未触发”的窗口。定时器已经进入回调后，Stop 没有办法把正在运行的函数从中途撤回。

Stop 返回 false 时不要直接复用共享状态

下面这种写法看起来像是“取消失败就立刻覆盖旧任务”，但旧回调可能还在使用同一份数据：

var current *time.Timer

func schedule(key string) {
    if current != nil {
        current.Stop()
    }
    current = time.AfterFunc(time.Second, func() {
        save(key)
    })
}

如果旧 callback 已经开始，新的 schedule 会和它并发执行。问题不在于 Timer 指针本身，而在于旧任务没有携带“我还是当前任务”的证明。用互斥锁只能保护指针赋值，不能自动取消已经进入回调的业务代码。

用版本号挡住迟到的 callback

更稳妥的方式是为每次调度生成递增版本。回调真正提交结果前，再检查自己是否仍是最新版本；检查和提交放在同一把锁下。

type Scheduler struct {
    mu      sync.Mutex
    version uint64
    timer   *time.Timer
}

func (s *Scheduler) Schedule(key string) {
    s.mu.Lock()
    if s.timer != nil {
        s.timer.Stop()
    }
    s.version++
    version := s.version
    s.timer = time.AfterFunc(time.Second, func() {
        s.mu.Lock()
        defer s.mu.Unlock()
        if version != s.version {
            return
        }
        save(key)
    })
    s.mu.Unlock()
}

这段代码的关键不是假设 Stop 总能成功，而是把“旧任务仍可运行”当成正常情况处理。旧 callback 到达检查点时，如果版本不相等，就直接丢弃结果。

Reset 适合延后同一个任务，不适合改变任务身份

当任务本身没有变化，只是用户每次输入都要把等待时间重新计算，Reset 比不断创建新定时器更直观。但它不会替你解决回调已经开始后的并发写入，回调中仍要遵守同样的状态保护。

type Debouncer struct {
    mu    sync.Mutex
    timer *time.Timer
}

func (d *Debouncer) Touch() {
    d.mu.Lock()
    defer d.mu.Unlock()
    if d.timer == nil {
        d.timer = time.AfterFunc(300*time.Millisecond, func() {
            rebuildIndex()
        })
        return
    }
    d.timer.Reset(300 * time.Millisecond)
}

使用 Reset 时要先读清当前 Go 版本的 time.Timer 文档和调用前提。尤其不能把“延后触发”理解成“旧回调一定没有开始”；如果回调可能执行较久，应额外使用版本号、取消通道或任务状态。

把竞态验收写进测试

不要只测“等待一秒后函数执行”。更有价值的测试是反复在触发边界调用 Stop 或 Reset，并断言最终只有最新版本能够提交。运行竞态检测器可以帮助发现共享字段的未保护访问，但业务层仍需要自己核对提交次数。

go test -race ./...

// 测试观察点：
// 1. 多次 Touch 后旧 callback 不提交；
// 2. Stop 返回 false 时，任务仍能安全收尾；
// 3. 最终 save 次数与最新版本一致。

常见误区

Stop 返回 false 就当作回调完成

错误。它只表示没有成功阻止尚未触发的回调，回调可能正在执行，也可能已经执行结束。

Reset 后就不需要锁

错误。Reset 管理的是定时器触发时间，业务数据的读写仍需按照共享状态的并发规则保护。

用一个布尔值就能取消所有旧任务

如果新旧任务交错执行，单个布尔值很容易在旧回调收尾时被误读。版本号能明确区分每一代任务。

相关问题

AfterFunc 的回调会阻塞调用方吗？

不会，回调会在单独的 goroutine 中运行；但回调内部访问共享数据时仍然要遵守并发安全规则。

Stop 成功后还要等待回调吗？

尚未触发的回调被成功阻止时通常不需要等待；如果 Stop 返回 false，就应把回调可能仍在运行纳入设计。

什么时候应该换成 NewTimer？

如果业务需要显式接收事件、统一处理退出和消费顺序，NewTimer 的 channel 模型通常更容易组织；选择前仍要按实际生命周期设计。

最后只记住一条判断

Stop 和 Reset 解决的是定时器的时间控制，不是业务结果的所有权。只要回调可能跨过取消边界，就让每次任务带上版本或取消状态，并在提交结果前再次核验；这比赌一次 Stop 返回值可靠得多。