goroutine泄漏是定时任务过多的首要隐患，源于未停止time.Ticker/AfterFunc导致goroutine持续存活；需显式Stop、用context控制生命周期、singleflight去重、改用时间轮调度器，并监控goroutine与timer数量。
goroutine 泄漏是定时任务过多的首要隐患
每个 time.Ticker 或 time.AfterFunc 都会隐式启动 goroutine；若未显式停止，它们会持续存活，哪怕业务逻辑早已退出。常见于循环中反复创建 time.NewTicker 却忘记调用 ticker.Stop()。
- 检查所有
time.Ticker/time.Timer实例，确保在任务结束或服务关闭时调用Stop() - 避免在 for 循环内直接新建 ticker：错误写法
for range jobs {—— 这会导致 ticker 永不释放
t := time.NewTicker(interval)
go func() { /* ... */ }()
} - 用
context.WithCancel控制生命周期，把ticker.C与ctx.Done()一起 select 监听
用 singleflight + cache 缓解高频重叠调度
当多个定时任务触发相同耗时操作（如每 5 秒拉一次配置、每 10 秒查一次下游健康），并发执行会造成资源浪费甚至下游压垮。Go 标准库不提供内置去重机制，需手动介入。
- 引入
golang.org/x/sync/singleflight，对相同 key 的请求做合并等待 - 搭配内存缓存（如
sync.Map或简单 struct 字段）存储上次执行时间与结果，加读写锁控制更新 - 示例场景：每 3 秒检查数据库连接，但实际只需保证「最近 10 秒内至少成功一次」，可改用「首次失败后才重试，成功则重置计时器」
从 time.Ticker 切换到基于时间轮的轻量调度器
time.Ticker 在任务数超千级时，底层会维护大量定时器对象，导致 runtime.timer 堆内存增长和调度延迟升高。此时应放弃“为每个任务配一个 ticker”的做法。
- 改用
github.com/RichardKnop/machinery/v2（支持 Redis 后端）或更轻量的github.com/robfig/cron/v3（纯内存，支持秒级、跳过重叠） - 若必须自研，推荐分层时间轮（hierarchical timing wheel）：毫秒级精度用数组槽位，分钟级用 map 分桶，避免 O(n) 遍历扫描
- 注意
cron.ParseStandard("*/5 * * * * ?")和time.ParseDuration("5s")语义不同，前者是 cron 表达式，后者是固定间隔，别混用
监控 goroutine 数与 timer 数是优化落地的关键验证点
光看 CPU 和内存不够——goroutine 泄漏初期可能只表现为 runtime.GOMAXPROCS(0) 翻倍、debug.ReadGCStats 中 NumGC 异常上升，而 runtime.NumGoroutine() 已突破 10k+。
立即学习“go语言免费学习笔记（深入）”；
- 在 HTTP pprof 端点暴露
/debug/pprof/goroutine?debug=1，定期抓取并 grep"time.Sleep"或"timer"调用栈 - 用
go tool trace录制运行时 trace，重点关注TimerGoroutines和Goroutine analysis视图 - 上线前压测时，强制设置
GODEBUG=gctrace=1观察 GC 频率是否随定时任务数线性增长
真正难的不是加调度器，而是让每个定时逻辑清楚自己该不该跑、能不能跳过、失败后要不要退避。多数性能问题，根子在任务边界模糊，而不是技术选型。
