Go Ticker Stop 后引用未释放的生命周期

Ticker.Stop 只停止节拍，不会关闭 Ticker.C，也不会让接收它的协程自动退出，更不会删除业务容器里的引用。停止后仍发现任务对象存活，应分别检查接收循环、任务函数和外部登记表。让循环响应取消、等待任务结束，再移除登记，才是完整的业务生命周期。

官方文档：https://pkg.go.dev/time#Ticker.Stop

影响面：停止节拍不等于任务结束

下面按一个假设的周期任务故障展开：服务为每个订阅建立刷新任务，移除订阅时只调用 Stop。刷新日志消失了，但接收循环仍等待通道，登记表也保留着任务句柄。这不是实测事故记录，而是用于解释三种生命周期混在一起时的典型代码问题。

直接影响不一定是持续占用 CPU。阻塞等待的协程可能很安静，但它尚未结束；闭包、任务参数或业务容器中仍然可达的对象，也不会因为停止节拍自动失去引用。要解释内存现象，必须找到实际仍可达的引用链，不能只看到 Stop 就断言释放完成。

时间线：从停止调用找到仍存活的拥有者

在这个示例场景中，启动阶段同时发生了三件事：创建节拍源、启动工作协程、向任务登记表写入句柄。停止分支却只对应第一件事。随后，等待节拍的循环没有新的值，也没有关闭事件；而登记表中的键仍存在。问题来自启动责任与退出责任不对称。

触发条件与根因：通道、协程和引用分别存在

若循环只用 for range ticker.C 接收，调用 Stop 并不会使 range 结束。Ticker.C 不是调用方可以关闭的任务完成通道。即使把某个变量设为 nil，也只改变那个变量：其他副本、登记项或闭包仍可能保持可达。

因此应当把节拍源、工作协程和业务拥有者作为三个对象来理解。节拍源提供触发；工作协程决定何时返回；业务拥有者负责登记、取消和等待。不能让一个 Stop 调用同时承担这三层语义。

修复动作：取消并等待，再删除任务登记

下面提供一个最小的单协程工作器：节拍由内部持有，任务按顺序执行；外部调用 StopAndWait 发出取消并等待完成。代码是原创示例，未提供实际运行日志。

package periodic

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

// Worker 只对外暴露取消与完成通知，不泄露 Ticker。
type Worker struct {
    cancel context.CancelFunc
    done   chan struct{}
}

func Start(parent context.Context, interval time.Duration,
    job func(context.Context)) (*Worker, error) {
    // 在创建协程前拒绝无效周期和空任务。
    if interval 

Start 的 parent 必须是非 nil 的 Context。示例没有恢复 job 的 panic，也没有替任务设置单次超时；这两项应由实际服务按错误处理约定设计。job 内部的网络、数据库等操作应使用传入的 ctx 或明确的超时，并确保最终返回。

这里把停止节拍放在工作协程的 defer 中，并让完成通知最后关闭。StopAndWait 成功返回后，该协程的任务调用与清理已经结束。取消函数本身不会等待，所以 done 是独立且必要的确认机制。外部不要直接操作内部的 Ticker。

任务登记表的拥有者可以将任务标记为“停止中”，在不持有登记表互斥锁的情况下调用 StopAndWait；成功后再加锁删除仍对应同一 Worker 的条目。若同一个键允许重新启动，删除前比较句柄身份，避免误删替换后的任务。应把重新启动与停止中的并发规则写清楚。

如果等待超时，应保留停止中的句柄与可重试的等待入口，报告尚未完成。超时不代表协程已经结束；此时不能销毁仍被 job 使用的业务资源。上层可以稍后用新的等待 Context 再调用 StopAndWait。

防复发：区分可回收对象与仍有业务引用

Go 1.23 引入了对未被引用的 Ticker 的回收支持，因此不能再笼统地说“忘记 Stop 就永远不能回收”。在相应的新语义下，不再需要仅为帮助垃圾回收而调用 Stop；业务上需要停止触发时，Stop 仍有作用。

Go 1.23 的发布说明还规定，新行为受主模块 go.mod 的 go 版本以及兼容设置影响。排查历史程序时应结合构建与运行配置，而不是只看机器安装的工具链版本。不要把回收能力的变化解释为协程能自动退出。

从工程上说，未被引用的计时对象可以回收，与“登记表还持有任务”“job 尚未返回”是不同问题。本文示例始终显式取消、等待和停止，不依赖垃圾回收完成业务退出，也不承诺某一时刻 RSS 立即下降。

防止同类问题，应在设计时明确：谁启动任务，谁持有句柄，谁请求取消，谁等待完成，谁移除登记。诊断时可观察任务登记数量与未完成任务数量，并在相同工作负载下比较停止前后的状态；没有这些证据，不应凭一次内存波动下结论。

相关问题：关闭通道、取消竞争与退出等待

能否自行 close(ticker.C) 来让 range 结束？

不要这样设计。Ticker.C 是只接收通道，关闭不属于使用方的职责。使用自己的取消信号或 Context，并在循环中明确处理。

取消返回之后，还可能执行一次 job 吗？

可能存在取消与节拍竞争。示例在接到节拍后再次检查 ctx.Err，但检查与 job 调用之间仍不是原子操作。需要“停止完成后没有在途任务”的保证时，以 StopAndWait 成功返回为完成界限；若要求更强的启动授权规则，应增加显式同步协议。

为什么等待可能一直没有完成？

job 如果阻塞在不支持取消的操作中，循环就暂时无法再次处理退出分支。等待 Context 可以限制调用方等待时间，但不能强制终止 job。应修复任务内部的取消和超时处理。

资料：Ticker.Stop；CancelFunc；Go 1.23 发布说明。