Go语言time.Tick内运行超间隔任务时time.Sleep失效相关问题咨询

问题1成因说明 #

你观察到的time.Sleep被提前结束是错觉，本质是time.Tick返回的定时器通道事件堆积导致的任务启动间隔变短，time.Sleep本身并不会被定时器事件中断，会完整执行你设定的时长。
具体逻辑如下：

• time.Tick返回的是一个只读<-chan time.Time类型的通道，定时器每达到设定间隔，就会往这个通道里发送一个当前时间事件
• 当你的任务耗时超过定时器间隔时，通道里的事件不会自动消失，会先堆积（定时器通道默认有1个缓冲位），超出缓冲的后续事件会被定时器直接丢弃
• 等你上一次任务（包括time.Sleep）执行完成后，下一次循环会立刻读取到通道里堆积的事件，马上启动下一轮任务，从外部时间观测上，就会产生“上一次的sleep没跑完就开始下一轮任务”的错觉，实际上sleep已经完整执行了。

问题2场景说明 #

真实业务逻辑未使用time.Sleep的场景下，最终表现完全取决于你的代码写法：

• 串行处理任务（默认写法）：如果收到tick事件后直接在当前goroutine执行业务逻辑，没有额外开goroutine，那么不会出现任务并发的情况，上一个任务没执行完时，不会处理新的tick事件，定时器最多堆积1个事件，多余事件直接丢弃，最终任务的实际执行间隔为max(定时器间隔, 单次任务耗时)，所有任务串行执行，不会被打断。
• 每tick开独立goroutine处理：如果每次收到tick事件就启动一个新goroutine跑业务，那么当任务耗时超过间隔时，会有越来越多的goroutine同时运行，逐步占用更多CPU、内存等资源，严重时会导致程序资源耗尽崩溃。

额外建议 #

生产环境不推荐直接使用time.Tick，它底层的定时器没有对外暴露停止方法，只要程序不退出就会一直运行，容易造成内存泄漏，建议用time.NewTicker创建定时器，使用完毕后调用Stop()方法释放资源。

内容的提问来源于stack exchange，提问作者user8285681