Go context.AfterFunc 怎样处理回调与取消竞态

如果把 context.AfterFunc 返回的 stop 函数理解成“等待回调结束”，取消竞态就很容易写错。它真正表达的是：这次调用是否成功解除回调关联；当返回 false 时，回调可能已经在自己的 goroutine 中启动，但 stop 本身不会等它收尾。

官方地址：https://pkg.go.dev/context

处理竞态的关键是把“阻止回调启动”和“等待已经启动的回调完成”拆开：先看 stop() 的结果，只有返回 false 时，再用通道、WaitGroup 或其他同步手段等待回调结束。

先看 AfterFunc 的接口承诺

context.AfterFunc(ctx, f) 会把 f 绑定到 ctx 的取消事件上，并返回一个 func() bool。Context 取消后，f 会在独立 goroutine 中执行；如果 Context 创建时已经取消，回调也会异步启动。

一个最小注册方式如下，回调里只放与取消直接相关的动作：

package main

import (
    "context"
    "log"
)

func registerCleanup(ctx context.Context) func() bool {
    return context.AfterFunc(ctx, func() {
        // 这里只处理取消触发的清理动作，不假设调用方仍在当前 goroutine。
        log.Println("释放取消后的资源")
    })
}

官方文档还明确了两点：同一个 Context 上多次调用 AfterFunc 彼此独立，不会互相替换；返回的 stop 也不负责等待回调完成。因此，注册次数和回调完成信号都应由调用方自己管理。

stop 返回 true 和 false 分别代表什么

stop() 返回 true，表示这次调用成功阻止了回调运行。此时可以认为回调不会再由这次注册启动，但这不代表其他地方注册的回调也会被取消。

返回 false 有两种常见原因：Context 已经取消并且回调已经启动，或者该回调此前已经被停止。它不能单独告诉你回调是否已经执行完，更不能当作“清理已经完成”的确认。

所以，如果回调会修改连接、文件、缓存或共享标志，调用方必须把“是否已启动”和“是否已完成”分别表示出来。

回调启动后，用 done 等待它收尾

下面这个模式适合取消后仍要恢复共享资源的场景。回调完成时关闭 done；正常路径调用 stop，若返回 false，就等待回调发出完成信号。

package main

import (
    "context"
    "sync"
)

func useResource(ctx context.Context, closeResource func()) {
    done := make(chan struct{})
    var once sync.Once

    stop := context.AfterFunc(ctx, func() {
        // 用 Once 保护清理入口，避免正常路径和取消路径重复释放。
        once.Do(closeResource)
        close(done)
    })

    // 这里代表实际业务工作；返回前必须处理 AfterFunc 的竞态。
    defer func() {
        if !stop() {
            // false 说明回调可能已启动，stop 不等待，所以由 done 负责等待。
            

这个写法的重点不是 sync.Once 本身，而是两个动作各司其职：stop 尝试阻止尚未启动的回调，done 等待已经启动的回调完成。若回调还没有启动且 stop 返回 true，就不需要等待 done。

回调中若还有异步工作，close(done) 必须放在全部收尾动作之后；否则调用方只等到了“回调开始”，仍可能抢先复用正在清理的资源。

共享状态和多条退出路径怎样设计

回调与主流程可能同时访问同一份状态，常见问题不在 AfterFunc 本身，而在清理函数不是幂等的。例如主流程关闭连接，取消回调也关闭连接；即使连接类型允许重复关闭，旁边的状态标志、计数器或对象池归还动作仍可能重复。

可以按下面的原则收敛边界：

• 把真正的释放动作封装成一个函数，用 sync.Once 或锁保证只执行一次。
• 需要知道回调结束时，用 done、WaitGroup 或明确的完成 Future；不要只看 stop。
• 如果回调会读写共享字段，给字段配套互斥锁或把状态转移集中到一个 goroutine。
• 同一个 Context 上注册多个回调时，每个回调都要有自己的停止和完成策略。

尤其要注意，stop 可以被多个 goroutine 同时调用，但这并不会替你协调回调里的业务状态；停止回调和关闭资源依然是两个层次的问题。

排查竞态时先问这几个问题

遇到“取消后偶尔清理两次”“请求返回了但资源仍在使用”这类现象，可以先按下面的顺序判断：

1. 回调是否可能已经因为 Context 取消而启动？如果可能，就不能把 stop=false 当成失败重试信号。
2. 回调是否有明确的完成通知？没有的话，调用方无法安全等待。
3. 正常退出和取消退出是否共用同一个幂等清理函数？如果没有，重复释放风险仍然存在。
4. 是否在 Context 上重复注册了多个 AfterFunc？多次注册不会自动覆盖前一个回调。

最后可以把语义记成一句话：stop 决定“还要不要让回调启动”，完成信号决定“已经启动的回调何时结束”。只要把这两个时刻分开，取消与回调的竞态就不会被一个布尔值掩盖。

相关问题

stop 返回 false 是不是说明回调执行失败？

不是。它只说明回调可能已经启动，或者之前已经停止；回调是否报错、是否完成，需要由回调自己的状态或同步信号表达。

AfterFunc 会阻塞调用方吗？

不会。回调在自己的 goroutine 中运行；如果调用方需要等待，必须显式使用通道、WaitGroup 或其他协调方式。

同一个 Context 注册两个 AfterFunc 会只执行最后一个吗？

不会。多个注册彼此独立，取消时各自的回调都可能启动，各自都需要考虑幂等和完成协调。