Go 的 time.Ticker 陷阱:定时任务里被忽略的内存泄漏与正确关闭
服务跑了几天,内存曲线一路缓慢爬升,pprof 一看 goroutine 数只增不减。翻代码发现一堆 time.Tick 和忘了 Stop() 的 time.Ticker------这是 Go 定时任务里最隐蔽、也最常见的一类泄漏。这篇把 Ticker、Timer、time.Tick、time.After 的坑一次讲清,给出能直接用的正确写法。
先看一个必漏的写法
需求很简单:每秒执行一次任务。很多人第一反应是 time.Tick:
go
func startWorker() {
// 看起来很简洁,但这是个陷阱
for range time.Tick(time.Second) {
doWork()
}
}time.Tick 返回一个 channel,每秒来一个值,写法确实优雅。问题在于:time.Tick 创建的底层 Ticker 永远无法被回收 。它没有返回 Ticker 对象,你拿不到句柄,也就没法调 Stop()。官方文档明确写着:「the underlying Ticker cannot be recovered by the garbage collector; it leaks」。
如果这个 for 循环因为某个条件退出了(比如函数返回),Ticker 还在后台每秒 tick,goroutine 和定时器都泄漏。time.Tick 只适合用在「整个程序生命周期都要 tick、永不停止」的场景,其余一律别用。
正确写法:显式创建并 Stop
用 time.NewTicker 拿到句柄,配合 defer Stop():
go
func startWorker(ctx context.Context) {
ticker := time.NewTicker(time.Second)
defer ticker.Stop() // 关键:函数退出时释放 Ticker
for {
select {
case <-ticker.C:
doWork()
case <-ctx.Done():
return // context 取消时优雅退出,defer 会 Stop
}
}
}两个要点:
defer ticker.Stop():Stop 会关闭底层定时器,让它能被 GC 回收。不调 Stop,即使 goroutine 退出了,Ticker 仍可能残留。- 用
context控制退出 :select同时监听ticker.C和ctx.Done(),外部一取消 context,循环就退出,defer 触发 Stop。这才是可控的定时任务。
Stop 之后,channel 里可能还有一个值
一个容易踩的细节:ticker.Stop() 不会关闭 channel,也不会清空已经投递的值。如果 Stop 的那一刻恰好有个 tick 已经进了 channel 缓冲区,你之后再读还能读到它。
对纯 Ticker 循环通常没影响(退出了不再读),但对 Timer 影响很大。看这个经典的「Reset 前必须排空」问题:
go
timer := time.NewTimer(time.Second)
if !timer.Stop() {
// Stop 返回 false 说明定时器已触发,channel 里可能有个值,排空它
<-timer.C
}
timer.Reset(2 * time.Second) // 现在 Reset 才安全Go 1.23 之前,Reset 一个没排空的 Timer 会导致读到旧的过期值,造成逻辑错乱。Go 1.23 起 Timer.Reset 和 Stop 的语义改进了:Stop/Reset 会保证之后不会再收到旧值,不再需要手动排空。但如果你的服务还在 1.23 以下,上面的排空写法仍是必须的。写代码前先确认 Go 版本。
time.After 在循环里的隐形泄漏
time.After 是另一个高频坑。它等价于 NewTimer(d).C,返回一个到点触发的 channel。单次用没问题,但放进 for 循环里做超时,就会持续创建 Timer:
go
// 有问题的写法:每次循环都新建一个 Timer
func consume(ch <-chan int) {
for {
select {
case v := <-ch:
handle(v)
case <-time.After(5 * time.Minute):
// 每次进 select 都创建一个 5 分钟的 Timer
// 只要 ch 一直有数据,这些 Timer 在触发前都不会释放
log.Println("idle timeout")
return
}
}
}问题在于:每次 select 求值都会调一次 time.After,新建一个 Timer。如果 ch 频繁来数据,time.After 分支从没命中,但那些 5 分钟的 Timer 会一直挂在时间堆里,直到各自到点才释放。高频循环下,这些未触发的 Timer 会堆积占用内存(注意:Go 1.23 起未被引用的 Timer 可以被 GC 提前回收,缓解了这个问题,但显式复用仍是更稳的写法)。
正确做法是在循环外建一个 Timer,循环内 Reset 复用:
go
func consume(ch <-chan int) {
timer := time.NewTimer(5 * time.Minute)
defer timer.Stop()
for {
select {
case v := <-ch:
handle(v)
// 收到数据,重置超时。Go 1.23+ 直接 Reset 即可;
// 更低版本需先 Stop 并排空(见上文)
timer.Reset(5 * time.Minute)
case <-timer.C:
log.Println("idle timeout")
return
}
}
}一个 Timer 从头用到尾,不再有堆积。
别在循环里 defer Stop
还有个组合坑:在 for 循环体里创建 Ticker 又 defer Stop。defer 是函数级的,不是循环级,它要等整个函数返回才执行:
go
// 错误:defer 攒到函数结束才一起 Stop,循环期间全泄漏
func loop(tasks []Task) {
for _, t := range tasks {
ticker := time.NewTicker(time.Second)
defer ticker.Stop() // 这些 Stop 全堆到 loop 返回时才执行
run(t, ticker)
}
}如果 tasks 有一万个,函数返回前会攒一万个未执行的 defer,一万个 Ticker 同时活着。要么把循环体抽成独立函数让 defer 随之退出,要么手动 Stop:
go
func loop(tasks []Task) {
for _, t := range tasks {
func() {
ticker := time.NewTicker(time.Second)
defer ticker.Stop() // 现在 defer 绑在这个匿名函数上,每轮都释放
run(t, ticker)
}()
}
}怎么确认没泄漏
上线前用 runtime.NumGoroutine() 或 pprof 观察 goroutine 数是否稳定:
go
import _ "net/http/pprof"
// 起一个 pprof 端口
go func() { log.Println(http.ListenAndServe("localhost:6060", nil)) }()
// 访问 http://localhost:6060/debug/pprof/goroutine?debug=1 看 goroutine 堆栈跑一段时间,如果 goroutine 数持续增长、且堆栈里堆着大量 time.NewTicker 相关的等待,基本可以锁定是 Ticker/Timer 没关。
小结
- 别用
time.Tick除非程序全程需要它------它拿不到句柄,无法 Stop,必然泄漏。 - Ticker 用
NewTicker+defer Stop(),并用context控制循环退出。 time.After不要放循环里,改成循环外建 Timer、循环内 Reset 复用。- Reset 前排空是 Go 1.23 以下的必修课;1.23+ 语义改进后可直接 Reset,但先确认版本。
- 别在 for 循环里
defer Stop,defer 是函数级的;抽匿名函数或手动 Stop。 - 上线前用 pprof 盯 goroutine 数是否稳定。
一句话记忆:能拿到句柄就一定 Stop,循环里的定时器一律复用而不是新建------Ticker 泄漏的根源,永远是「创建了却没人负责关」。