Golang定时器与Ticker在并发中的应用

timer.After 不能用于循环重置定时任务，因其返回单次通道、读完即关闭；应改用 time.NewTicker 或 time.NewTimer 配合 Reset。

为什么 timer.After 不能直接用于循环重置定时任务

很多人想用 timer.After 实现“每 N 秒执行一次”，结果发现逻辑只跑了一次就停了。这是因为 timer.After 返回的是单次 的 chan，读完一次就关闭，无法复用。

正确做法是用 time.NewTimer 配合 Reset()，或更常见的——直接用 time.Ticker。

• time.After(d)：适合「延迟一次」，比如超时控制、延后启动
• time.NewTimer(d)：适合「延迟一次 + 可手动重置」，比如带取消逻辑的单次任务
• time.NewTicker(d)：适合「周期性触发」，底层复用同一个定时器，比反复 new Timer 更轻量

在 goroutine 中使用 Ticker 必须显式 stop

不调用 ticker.Stop() 会导致 goroutine 和底层 ticker 持续运行，即使外层逻辑已退出。Go runtime 不会自动回收活跃的 time.Ticker，它会一直向 ticker.C 发送时间点，造成 goroutine 泄漏和内存缓慢增长。

典型错误写法：

立即学习“go语言免费学习笔记（深入）”；

go func() {     ticker := time.NewTicker(5 * time.Second)     for range ticker.C {         doWork()     } }()

正确写法（带退出控制）：

done := make(chan struct{}) go func() {     defer close(done)     ticker := time.NewTicker(5 * time.Second)     defer ticker.Stop() // 关键：确保退出前释放资源     for {         select {         case <-ticker.C:             doWork()         case <-done:             return         }     } }()

并发场景下 Ticker 与 channel select 的配合要点

多个定时器或混合 I/O 事件时，select 是标准解法，但要注意几个易错点：

• 如果 ticker.C 和其它 channel 同时就绪，select 是伪随机选择，不能依赖顺序
• 不要在 case 分支里做耗时操作，否则会拖慢下一次 tick —— Ticker 不跳过未消费的 tick，而是累积在 channel 缓冲区（默认缓冲 1），若持续阻塞，可能引发堆积或 panic（当缓冲满且无 receiver）
• 如需严格节拍（如心跳、采样），应把耗时逻辑扔进新 goroutine，或用带缓冲的 channel 解耦

例如安全的节拍处理：

ticker := time.NewTicker(1 * time.Second) defer ticker.Stop() for {     select {     case <-ticker.C:         go doWork() // 避免阻塞 ticker     case <-quit:         return     } }

Timer.Reset 和 Ticker.Reset 的行为差异

两者都支持 Reset(d)，但语义不同：

• Timer.Reset(d)：停止当前计时，重新以 d 开始倒计时；若原 timer 已触发，Reset 仍有效；若原 timer 未触发但已 Stop()，Reset 会重新激活它
• Ticker.Reset(d)：立即停止当前 ticker，并以新间隔 d 创建一个全新 ticker；旧的 ticker.C channel 不再有值，必须用新的 channel（但通常没人这么干，因为 Reset 对 ticker 很少必要）

所以实际中：Timer.Reset 常见于动态超时调整；Ticker.Reset 几乎不用，改用 Stop() + NewTicker() 更清晰。

真正容易被忽略的是：所有 Reset 调用前，必须确保原 timer/ticker 没有处于已触发但尚未读取的状态，否则可能 panic 或行为异常 —— 尤其在多 goroutine 并发调用 Reset 时，务必加锁或通过 channel 协作。