Go 的 time.Ticker 陷阱:定时任务里被忽略的内存泄漏与正确关闭-港品优选

Go 的 time.Ticker 陷阱:定时任务里被忽略的内存泄漏与正确关闭

服务跑了几天,内存曲线一路缓慢爬升,pprof 一看 goroutine 数只增不减。翻代码发现一堆time.Tick和忘了Stop()的time.Ticker——这是 Go 定时任务里最隐蔽、也最常见的一类泄漏。这篇把Ticker、Timer、time.Tick、time.After的坑一次讲清,给出能直接用的正确写法。

先看一个必漏的写法

需求很简单:每秒执行一次任务。很多人第一反应是time.Tick:

funcstartWorker(){// 看起来很简洁,但这是个陷阱forrangetime.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():

funcstartWorker(ctx context.Context){ticker:=time.NewTicker(time.Second)deferticker.Stop()// 关键:函数退出时释放 Tickerfor{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 前必须排空」问题:

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:

// 有问题的写法:每次循环都新建一个 Timerfuncconsume(ch<-chanint){for{select{casev:=<-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 复用:

funcconsume(ch<-chanint){timer:=time.NewTimer(5*time.Minute)defertimer.Stop()for{select{casev:=<-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是函数级的,不是循环级,它要等整个函数返回才执行:

// 错误:defer 攒到函数结束才一起 Stop,循环期间全泄漏funcloop(tasks[]Task){for_,t:=rangetasks{ticker:=time.NewTicker(time.Second)deferticker.Stop()// 这些 Stop 全堆到 loop 返回时才执行run(t,ticker)}}

如果tasks有一万个,函数返回前会攒一万个未执行的 defer,一万个 Ticker 同时活着。要么把循环体抽成独立函数让 defer 随之退出,要么手动 Stop:

funcloop(tasks[]Task){for_,t:=rangetasks{func(){ticker:=time.NewTicker(time.Second)deferticker.Stop()// 现在 defer 绑在这个匿名函数上,每轮都释放run(t,ticker)}()}}

怎么确认没泄漏

上线前用runtime.NumGoroutine()或 pprof 观察 goroutine 数是否稳定:

import_"net/http/pprof"// 起一个 pprof 端口gofunc(){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 泄漏的根源,永远是「创建了却没人负责关」。

企业官网建设流程全解析