time.Timer和time.Ticker本身不直接内存泄漏，但未Stop或未Reset会导致底层timer对象无法被GC回收，引发goroutine积压和内存持续增长；time.After()在循环中滥用会堆积大量未触发Timer。

time.Timer 和 time.Ticker 本身不会“泄漏内存”，但它们会阻止底层 runtime timer 对象被 GC 回收，直到触发、显式 Stop() 或所属 goroutine 退出 —— 这是造成 Goroutine 积压和内存持续增长的常见根源。

---

time.After() 在循环中反复调用会堆积 Timer 对象

time.After() 每次都等价于 time.NewTimer().C，返回一个只读 channel。它不提供 Stop() 接口，且只要还没到期，对应的 *Timer 就不会被 GC。

• 常见错误写法：

  for {
      select {
      case <-time.After(5 * time.Second):
          doWork()
      }
  }

• 问题：每次循环都新建一个 Timer，若循环快、duration 长（比如 10 分钟），大量未触发的 Timer 会常驻内存，GC 不会回收。
• 正确做法：
  • 复用单个 Timer，用 Reset() 替代重复创建
  • 或改用 time.AfterFunc() + 显式控制生命周期（适合一次性延迟）

---

Timer.Stop() 后仍从 C 读取可能阻塞 goroutine

Timer.Stop() 只取消定时器，不关闭其 C channel，也不消费已写入的值（因为 C 是带缓冲的 1 容量 channel）。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 典型陷阱：

  timer := time.NewTimer(3 * time.Second)
  go func() {
      <-timer.C // 若 timer 已 Stop，这里永远阻塞
      fmt.Println("done")
  }()
  timer.Stop()

• 结果：goroutine 永久挂起，无法退出，导致关联资源（如闭包变量、栈内存）无法释放。
• 安全模式：
  • 总配合 select + default 或超时分支读取
  • 或在 Stop() 后立即尝试非阻塞接收（select with default）
  • 更稳妥：用 timer.Reset(0) 强制触发，再读一次 C 消费残留值

---

time.Ticker 忘记 Stop() 是最隐蔽的泄漏源

time.Ticker 是长周期运行对象，底层持续注册 runtime timer 并反复重置。只要没调用 Stop()，它就一直存活，且其 C channel 永远可读。

立即学习“go语言免费学习笔记（深入）”；

• 错误示例：

  func startHeartbeat() {
      ticker := time.NewTicker(30 * time.Second)
      go func() {
          for range ticker.C {
              sendPing()
          }
      }()
      // ticker 变量作用域结束，但底层 timer 仍在跑
  }

• 后果：goroutine 持续运行，ticker 对象无法被 GC，内存与 goroutine 数量线性增长。
• 必须做到：
  • Ticker 的生命周期必须有明确 owner（如 struct 字段或 context）
  • 在 owner 销毁时（例如 Close() 方法、context.Done() 触发）调用 ticker.Stop()
  • 避免在闭包中直接引用未管理的 Ticker

---

Timer 和 Ticker 的泄漏本质不是“内存没被清空”，而是“runtime timer 注册未注销 + goroutine 未退出”。它们卡在调度器里，拖着整个 goroutine 栈和所有闭包变量，比单纯堆内存更难被 pprof heap 抓到 —— 往往先爆 goroutine 数量，再连带耗尽内存。