Go 计时器Ticker 不停止造成 goroutine 持续增加怎么办

Ticker 相关的 goroutine 持续增长，不能只补一行 Stop 就宣告修复。先看增长的协程停在哪：是还在等待 ticker.C，还是每次 tick 都启动了没有结束的业务协程。Stop 只停止计时器，不关闭它的 C 通道；接收循环必须有独立退出条件，业务回调也必须能够返回。

下面用一个假设的巡检服务展开：每次启用巡检都会启动周期任务，停用后原来的任务却仍被保留。这个场景用于说明排查思路，不是已经发生并测量过的事故复盘；代码和回归建议没有在本文环境实际执行。

官方地址：https://pkg.go.dev/time#Ticker.Stop

任务结束后，留下的可能是接收循环

假设业务界面已经显示“巡检停用”，但重复启停后，同一任务函数的 goroutine 栈不断累积。此时应先对齐任务的实际生命周期：启用时创建了什么，停用时仅改了业务标志，还是同时发出取消并等待循环结束？

单独的总 goroutine 数只能说明进程当前数量，不能证明每次创建 Ticker 都新增一个专属 goroutine。应用自己显式启动的接收循环、回调内部的协程和其他组件都可能贡献增长。需要结合增长栈里的应用函数和阻塞位置，才能确定是哪项工作没有退出。

沿着启动、停表和等待位置找触发条件

按这个假设场景梳理，容易出现的关系是：启用入口启动循环；停用入口只调用 ticker.Stop；循环仍然使用 range ticker.C 等待下一次接收。由于通道没有关闭，range 不会因为停表自动结束。下一次启用再建一个循环，就又多留下一份等待。

另一种关系是循环本身正常，但每一拍都执行 go work。只要工作的完成速度跟不上启动速度，或 work 被无期限 I/O 卡住，就会积压业务协程。此时仅修复外层循环还不够，需要限制工作并发、明确忙时跳过或排队的策略，并让已启动工作可以收尾。

在授权的诊断环境中，可以用 goroutine profile 对比启停前后的同类栈数量，关注接收位置、工作回调及其下游等待。使用已有受控诊断入口即可，不要为了排错把 pprof 服务直接暴露到公网，也不要公开包含业务信息的原始栈记录。

Stop 不关闭 C，垃圾回收也不结束任务

需要分清三项责任：Stop 停止后续 tick；取消信号让循环有机会返回；调用方等待任务结束，才能确认收尾已完成。Stop 不会替你跳出 for，也不会中断正在执行的业务函数。ticker.C 是接收端，调用方不应自行关闭它。

版本差异也不能省略。Go 1.23 引入的新计时器实现允许回收不再被引用、即便未停止的 Ticker；新实现的启用还与主模块 go.mod 的 go 版本以及 asynctimerchan 设置有关。旧行为不能直接套用新回收结论。排查实际程序时应核对构建与运行配置，而不是只看机器上某个 Go 命令的版本。

但回收变化不等于 goroutine 生命周期管理：一个仍在等待通道的应用协程不会因为“计时器可以被回收”而自动从函数返回。不要把等待垃圾回收当作任务停止协议。明确调用 Stop 仍可以表达“不再需要继续计时”，而取消与等待解决的是另外两件事。

把周期任务改成可取消的同步循环

下面给出一个完整程序。周期循环不额外创建 goroutine，每次工作同步执行；上下文取消或工作返回错误时退出，函数的 defer 再停止 Ticker。示例选择“第一次工作错误即结束”，项目若要继续执行，应在回调或任务层设计明确的错误策略。

package main

import (
    "context"
    "errors"
    "fmt"
    "time"
)

// runPeriodic 不额外启动协程；work 必须同步返回并遵守 ctx 的取消约定。
func runPeriodic(ctx context.Context, interval time.Duration,
    work func(context.Context) error) error {
    if ctx == nil || interval 

这段示例没有伪造运行输出。它的预期是有限时间后因上下文截止返回，最后输出循环已返回的提示；工作次数受调度影响，不应固定断言为某个整数。检查正数周期，是为了避免把不合法配置交给 NewTicker。

如果现有组件需要 go runPeriodic，应由组件保存取消函数和完成通知；停用时先 cancel，再等待该次循环返回。重启下一次任务前确认上一次已经退出，避免把“重复启用”变成两个独立循环。完成通知最好携带任务返回错误，并设置由谁读取的明确约定。

这里有两个限制。第一，select 在多个分支就绪时不保证先选取消，额外的 ctx.Err 检查也不是能撤销外部副作用的原子屏障。若业务要求停用确认之后绝不再产生副作用，需要把提交操作与停止确认纳入更严格的同步协议。第二，work 必须返回；如果它忽略 ctx 并永久阻塞，外层 select 也无法代替它退出。

收尾以后还要观察哪些现象

修复不应只看“Stop 已经被调用”。应在项目测试中重复启动和停止任务，等待每次循环返回，再观察相同工作栈是否残留；分别覆盖取消发生在等 tick、回调执行期间和回调报错时。诊断结果应允许其他系统协程造成的小范围波动，不把整个进程数量必须精确回到某个值当作唯一标准。

慢工作也需要单独观察。本例串行执行，不会因每个 tick 都起一个新业务协程而无限叠加；但 Ticker 可能调整间隔或丢弃 tick 来适应慢接收者，不保证每个周期都执行一遍任务。如果业务要求固定数量、严格排队或“工作结束后再等一个周期”，就需要不同的调度契约。

把 defer Stop 放在循环外就够了吗？

只有函数能够返回，defer 才会在正常返回路径上执行。无限接收循环没有退出条件时，写了 defer 也只是把清理挂在那里。若创建位置在长生命周期函数的循环内，还可能让清理堆到该函数结束才发生，应调整资源作用域。

换成 time.Tick 能避免 goroutine 泄漏吗？

不能把接口替换当作生命周期修复。无论选哪种 tick 通道写法，应用接收循环和下游任务都需要退出设计。这里使用 NewTicker，是为了让停表动作有明确的持有者，不是在声称 time.Tick 在所有现代 Go 程序中都必然泄漏。

Stop 后还需要主动读一次 C 吗？

不要照搬一次性 Timer 的旧式清空模板到 Ticker。Ticker.Stop 没有返回布尔值；无条件接收反而可能阻塞。本文不依赖清空 tick 来退出，而是用 ctx.Done 和任务返回确认生命周期。

防复发最有用的约定是：每个周期任务都要能回答谁创建、谁取消、谁等待、谁处理工作错误。四个角色明确后，停止计时和退出协程才不会再次脱节。

官方资料

Ticker、Stop 与慢接收者：https://pkg.go.dev/time

Go 1.23 计时器实现边界：https://go.dev/wiki/Go123Timer

goroutine profile：https://pkg.go.dev/runtime/pprof