行业动态

Go并发编程中timer和ticker怎么用_定时并发任务说明

作者:P粉6029986702026-01-12 00:00:00

Timer用于一次性定时，Ticker用于周期性定时；Timer的channel只发一次信号，Ticker则持续发送直至Stop；误用Ticker当Timer会导致逻辑错误。

Go 里 time.Timer 和 time.Ticker 不是“定时执行函数”的工具，它们只负责按时间发送信号——你得自己接住 channel 并处理逻辑，否则会漏触发、阻塞或 panic。

什么时候该用 `Timer`，什么时候用 `Ticker`

Timer 是一次性倒计时：启动后只向 C 字段的 chan time.Time 发一次信号；Ticker 是周期性节拍器：从启动起每隔固定间隔发一次信号，直到被显式 Stop()。

需要“5 秒后做一次清理” → 用 Timer
需要“每 2 秒检查一次服务健康状态” → 用 Ticker
误把 Ticker 当 Timer 用（比如只读一次 ），会导致 goroutine 泄漏 —— 它还在后台持续发信号，没人收
反过来，用 Timer 做轮询，就得每次 Reset()，但要注意：如果旧 timer 还没触发就 Reset()，它会先 Stop() 再重启，不会重复触发

`Timer` 的常见误用和修复方式

最典型错误是忽略 Timer 的可重用性与生命周期管理。它不是“用完即焚”，但也不是线程安全的，不能并发调用 Reset() 或 Stop()。

启动后不读 timer.C → 定时器触发后，time.Time 值会永久卡在 channel 中，下次 Reset() 或 Stop() 可能 panic
在 select 中直接写 case 而不先 timer.Reset() → 第二次定时永远不会开始
并发调用 timer.Reset() → 可能 panic：“timer already fired” 或 “send on closed channel”

timer := time.NewTimer(3 * time.Second)
// ✅ 正确：select 中收信号，并在需要时 Reset
go func() {
    for {
        select {
        case <-timer.C:
            fmt.Println("timeout!")
            timer.Reset(3 * time.Second) // 下次再等 3 秒
        }
    }
}()

`Ticker` 的资源泄漏和停止时机

Ticker 启动后会持续往 C channel 发送时间值，**必须手动 Stop()**，否则 goroutine 和 channel 会一直存在，GC 不回收。

在 for range ticker.C 循环中 break，但没调 ticker.Stop() → 泄漏
在 select 中监听 ticker.C，但程序退出前忘记 Stop() → 同样泄漏
ticker.Stop() 后继续读 ticker.C → 永远阻塞（channel 已关闭，但没人发值）
不要用 time.AfterFunc() 替代 Ticker 做轮询：它是单次的，且内部用 Timer 实现，无法复用

ticker := time.NewTicker(1 * time.Second)
defer ticker.Stop() // 确保退出前停止
go func() {
for {
select {
case t := <-ticker.C:
fmt.Printf("tick at %v\n", t)
}
}
}()

并发任务中怎么避免时间精度丢失和堆积

Go 的 Timer/Ticker 底层依赖系统调度，**不保证绝对准时**。尤其在 GC STW、高负载或大量 goroutine 竞争时，可能延迟数百毫秒甚至更久。更严重的是：如果你的处理逻辑耗时 > 间隔，Ticker 会“攒着”多个未消费的 tick，导致后续集中爆发。

对实时性要求高的场景（如游戏帧同步），别依赖 Ticker 的“节奏”，改用自适应 sleep：time.Sleep(nextTick.Sub(time.Now()))
用 select + default 非阻塞读 ticker.C，防止一次处理太久导致积压
不要在 ticker.C 的接收逻辑里做阻塞 IO 或长耗时计算 —— 开新 goroutine 处理，但注意控制并发数
Timer 的 Reset() 在 timer 已触发后返回 false，记得判断返回值，否则可能误以为重置成功