Golang并发任务调度器实现方法

标准 time.Ticker 不适合复杂任务调度，因其仅定时发信号，不管理任务生命周期、不处理 panic/阻塞/超时，无法动态增删任务，且多任务共用通道易导致堆积或静默丢失；应改用 sync.Map + time.AfterFunc 实现可注册注销的任务池，并结合 context.WithTimeout 和 errgroup.Group 确保超时控制与 goroutine 干净退出。

为什么标准 time.Ticker 不适合复杂任务调度

它只负责“按时发信号”，不管理任务生命周期，也不处理 panic、阻塞或超时。一旦某个 goroutine 挂住或 panic，整个 ticker 循环可能卡死或静默丢失任务。

• 多个任务共用一个 ticker.C 时，无法独立启停
• 任务执行时间超过 tick 间隔，会堆积 goroutine（无并发控制）
• 没有错误传播机制，recover() 必须手动加在每处任务里
• 无法动态增删任务，所有逻辑得写死在 for-select 里

用 sync.Map + time.AfterFunc 实现可注册/注销的任务池

避免全局 ticker 压力，每个任务用独立的定时触发，靠 sync.Map 管理活跃句柄，注销时调用 Stop() 清理资源。

type Scheduler struct {
	tasks sync.Map // map[string]*time.Timer
}

func (s *Scheduler) Add(name string, delay time.Duration, f func()) {
	timer := time.AfterFunc(delay, func() {
		defer func() {
			if r := recover(); r != nil {
				log.Printf("task %s panicked: %v", name, r)
			}
		}()
		f()
		s.Add(name, delay, f) // 自动重入（周期任务）
	})
	s.tasks.Store(name, timer)
}

func (s *Scheduler) Remove(name string) {
	if v, ok := s.tasks.Load(name); ok {
		if timer, ok := v.(*time.Timer); ok {
			timer.Stop()
		}
		s.tasks.Delete(name)
	}
}

• Add 是“一次性+自动重入”模式，适合固定间隔任务；如需单次执行，去掉递归调用即可
• Remove 必须调用 timer.Stop()，否则即使删除 key，timer 仍会触发并写入已失效的 map
• 任务名（name）必须唯一，否则后注册的会覆盖前一个

用 context.WithTimeout 控制单个任务执行时长

防止某个任务长期阻塞，拖垮整个调度器。不能只依赖外部超时，要在任务内部主动检查 context。

func withTimeout(ctx context.Context, timeout time.Duration, f func(context.Context)) {
	ctx, cancel := context.WithTimeout(ctx, timeout)
	defer cancel()
	f(ctx)
}

// 使用示例：
sched.Add("fetch-api", 5*time.Second, func() {
	withTimeout(context.Background(), 3*time.Second, func(ctx context.Context) {
		resp, err := http.DefaultClient.GetContext(ctx, "https://api.example.com")
		if err != nil {
			if ctx.Err() == context.DeadlineExceeded {
				log.Println("fetch-api timed out")
			}
			return
		}
		defer resp.Body.Close()
		// ...
	})
})

• 不要把 context.WithTimeout 放在 Add 外层——那只会限制“启动任务”这一步，不是执行
• 任务函数内必须显式传入 ctx 并在 I/O 调用中使用（如 http.Client.GetContext），否则超时无效
• 注意：time.AfterFunc 创建的 goroutine 无法被外部 context 取消，所以超时逻辑必须收口到任务内部

goroutine 泄漏的两个隐蔽点

一是未清理的 time.Timer，二是任务中启动了子 goroutine 却没做生命周期绑定。

• 所有通过 time.NewTimer 或 time.AfterFunc 启动的 timer，只要没调用 Stop() 或触发过，就一直持有 goroutine 引用
• 任务里用 go func() {...}() 启动的子协程，若父任务被 Remove，子协程仍在运行且无法感知——必须用 context.WithCancel 显式传递取消信号
• 建议统一用 errgroup.Group 管理子任务，便于等待和传播 cancel

真正难的不是启动一堆 goroutine，而是让它们在该停的时候干净退出。多数调度器崩掉，都是因为某次注销漏掉了一个 timer 或一个 goroutine。