登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  Golang >  Go问答

time.Ticker 未停止导致 goroutine 泄漏的排查方案

来源:17golang原创

时间:2026-11-13 01:35:54 494浏览 收藏

先给结论:time.Ticker.Stop() 负责停止继续产生 tick,但它不会自动结束一个仍在运行的 goroutine。真正的泄漏通常是“后台 goroutine 没有退出信号”与“ticker 没有明确的生命周期拥有者”叠加造成的。修复时应让同一个组件同时负责创建 ticker、监听 context.Done()、退出循环,并在退出路径上调用 Stop()。

排查顺序可以固定为:先看 goroutine 栈是否卡在 ,再确认启动方有没有取消入口,最后检查 ticker 是否在拥有者结束时停止。Go 1.23 之后,已经不可达的 ticker 可以被垃圾回收,但这不等于仍在工作的 goroutine 会自动退出,也不等于可以省略业务语义上的 Stop。

先分清 Ticker 未停止和 goroutine 泄漏

NewTicker 返回一个带有周期通道的对象,Stop 关闭后续 tick,但不会关闭 Ticker.C。因此,下面这种写法的问题不只是少了一行 Stop:启动的 goroutine 没有任何结束条件,业务对象也没有保存停止入口。

func startRefresh() {
    ticker := time.NewTicker(time.Second)
    go func() {
        for range ticker.C {
            refreshCache()
            // 这里没有取消信号,goroutine 会持续等待下一次 tick。
        }
    }()
}

如果 startRefresh 被请求重试、配置热加载或定时任务反复调用,就会出现多个相同循环。用 runtime/pprof 查看 goroutine 栈时,常见特征是同一函数出现很多份,并且都停在读取 ticker 通道或它调用的工作函数上。此时只把 ticker.Stop() 加到启动函数末尾也不够,因为它既没有等待 goroutine 退出,也没有告诉循环如何结束。

time.Ticker 所有权、tick 通道与 goroutine 退出信号的静态关系说明图
图1:time.Ticker 所有权说明图,展示 ticker、ticker.C、worker goroutine、context.Done 与 Stop 的职责关系;这是静态说明图,不是运行截图。

对比三种方案:Stop、取消信号和重复启动

把候选方案放在同一张对比表里,更容易判断修复范围:

方案能解决什么不能解决什么适用场景
只调用 Stop停止后续 tick不负责让读取 goroutine 结束已有独立退出机制,只补资源释放
只监听 context让循环能返回可能遗留仍在工作的 tickerticker 由外层统一管理
context + defer Stop同时覆盖 goroutine 和 ticker 生命周期不能替代启动去重请求级、组件级后台循环

推荐把生命周期收拢到一个函数里。defer ticker.Stop() 与 case 分别承担资源停止和 goroutine 返回两个职责:

func runRefresh(ctx context.Context, refresh func()) {
    ticker := time.NewTicker(time.Second)
    defer ticker.Stop() // 函数返回时停止后续 tick,释放明确的资源生命周期。

    for {
        select {
        case 

调用方还要保存并调用取消函数,不能只创建一个永不结束的 context.Background()。如果刷新任务本身可能阻塞,也要把同一个 ctx 继续传给下层 I/O;否则外层循环虽然返回,里面启动的工作 goroutine 仍可能泄漏。

Ticker Stop、context Done、worker goroutine 与 goroutine profile 的静态对比关系图
图2:修复方案对比说明图,展示 Stop、context.Done、worker goroutine 与 profile 观察点的边界;这是静态结构图,不是运行结果。

用 goroutine 栈定位泄漏的真正入口

排查时不要把“goroutine 数量上涨”直接等同于 ticker 泄漏。先按栈形态分组:

  • 大量栈停在 select 或 :优先找重复启动、缺失取消入口和没有 owner 的后台循环。
  • 栈停在刷新函数内部:ticker 可能正常,但刷新任务没有响应 context,需继续向下传递取消信号。
  • goroutine 已返回但对象仍被长期持有:检查组件字段、定时器集合和关闭顺序,必要时在关闭方法中显式调用 Stop。

可以打开 pprof 的 goroutine 端点并读取栈信息:

go tool pprof http://127.0.0.1:6060/debug/pprof/goroutine
# 该命令用于查看栈分组;地址仅表示本地诊断入口,不代表线上页面。

修复后应回到启动路径检查:一次组件初始化是否只创建一个循环,关闭动作是否只触发一次,cancel 是否覆盖所有返回分支,刷新函数是否也能结束。若这些条件没有同时满足,单独增加 Stop 只能掩盖症状。

什么时候不该把 Stop 当成唯一修复

Go 1.23 的 time 文档说明,不再被引用的 ticker 可以被垃圾回收,所以“忘记 Stop 必然造成 ticker 永久泄漏”的旧判断需要收窄。仍然需要 Stop 的理由是业务语义:组件关闭时不再触发任务、减少无意义唤醒,并让代码清楚表达资源边界。若 goroutine 还持有 ticker 或一直在循环,垃圾回收不会替你完成取消。

最终可以记住一句话:Stop 管 tick,context 管退出,owner 管启动次数。这三个责任分别明确后,再根据 profile 栈确认泄漏点,才能避免把正常的周期任务误判成 goroutine 泄漏。

常见问题

调用 Stop 后为什么 goroutine 还不退出?因为 Stop 不关闭 ticker 通道,也不向循环发送取消信号;循环需要同时选择 ctx.Done() 或另一个明确的退出通道。

用 time.Tick 能不能避免忘记 Stop?time.Tick 只返回通道,无法表达主动停止。需要组件关闭、请求取消或测试可控生命周期时,优先使用 NewTicker 并保留 ticker 对象。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>