Go语言中通过goroutine与Timer/Ticker结合实现定时任务,一次性任务用Timer,周期性任务用Ticker,配合通道和goroutine实现非阻塞执行与优雅停止,避免资源泄露。

在Go语言中,结合goroutine和Timer(或Ticker)是实现定时任务的核心模式。简单来说,goroutine提供了执行任务的并发能力,而Timer或Ticker则负责在指定的时间点或间隔触发这些任务的执行。这种组合既能保证任务的准时执行,又能避免阻塞主程序,是Go并发模型在定时任务场景下的典型应用。
实现定时任务,我们通常会用到
time
time.Timer
time.Ticker
time.After
最简单的一次性任务,可以用
time.After
go func() {
fmt.Println("开始等待5秒...")
<-time.After(5 * time.Second)
fmt.Println("5秒后执行了一次任务。")
}()
// 为了让主程序不立即退出,通常需要一个等待机制,比如time.Sleep或一个select{}
// time.Sleep(6 * time.Second)但
time.After
time.NewTimer
*time.Timer
立即学习“go语言免费学习笔记(深入)”;
timer := time.NewTimer(10 * time.Second)
go func() {
fmt.Println("NewTimer开始等待10秒...")
<-timer.C // 等待计时器触发
fmt.Println("10秒后执行了一次任务,通过NewTimer。")
}()
// 假设我们可以在某个点取消它,比如在5秒后
// time.Sleep(5 * time.Second)
// if timer.Stop() { // 尝试停止计时器
// fmt.Println("Timer被提前停止了。")
// } else {
// // 如果Stop返回false,说明计时器已经触发或正在触发
// // 此时需要从通道中读取一次,以清空通道,避免后续的读取阻塞
// select {
// case <-timer.C:
// default:
// }
// fmt.Println("Timer已触发,无法停止。")
// }
// time.Sleep(6 * time.Second) // 确保有足够时间观察结果对于周期性任务,
time.NewTicker
Stop()
ticker := time.NewTicker(2 * time.Second)
stopSignal := make(chan struct{}) // 用于优雅停止任务
go func() {
defer ticker.Stop() // 确保Ticker在goroutine退出时停止
fmt.Println("Ticker开始每2秒执行任务...")
for {
select {
case t := <-ticker.C:
fmt.Printf("每2秒执行一次任务,当前时间: %s\n", t.Format("15:04:05"))
// 模拟一个可能耗时的任务,但通常不应该在这里阻塞太久
// time.Sleep(500 * time.Millisecond)
case <-stopSignal:
fmt.Println("收到停止信号,Ticker任务即将退出。")
return // 退出goroutine
}
}
}()
// 主协程中,等待一段时间后发送停止信号
// time.Sleep(10 * time.Second)
// close(stopSignal) // 发送停止信号
// fmt.Println("主程序已发送停止信号给Ticker任务。")
// time.Sleep(1 * time.Second) // 给goroutine一点时间处理退出核心思路是,将定时任务的逻辑封装在一个独立的goroutine中。这个goroutine监听Timer或Ticker的通道,一旦接收到事件,就执行任务。这种模式天然地将任务执行与主程序的流程解耦,避免阻塞,同时通过通道机制实现了任务的启动、执行与停止的协调。
time.Timer
time.Ticker
选择
time.Timer
time.Ticker
time.Sleep
time.Timer
time.NewTimer
Stop()
Reset()
而
time.Ticker
Ticker
Stop()
我经常看到有人用
time.NewTimer
Reset
Ticker
time.NewTicker
Ticker
停止定时任务,特别是那些在独立goroutine中运行的周期性任务,是个需要细致处理的问题。如果处理不好,轻则资源泄露,重则程序崩溃。我见过不少生产环境的代码,因为没有正确停止goroutine和Timer/Ticker,导致服务长时间运行后性能下降。
最关键的策略是使用一个
done
stop
close(stopChan)
select
对于
time.Ticker
ticker.Stop()
// 示例:优雅停止周期性任务
func StartPeriodicTask(interval time.Duration, stopChan <-chan struct{}) {
ticker := time.NewTicker(interval)
defer ticker.Stop() // 确保Ticker在函数退出时停止
fmt.Printf("周期性任务启动,间隔 %v\n", interval)
for {
select {
case <-ticker.C:
fmt.Println("执行周期性任务...")
// 实际任务逻辑
case <-stopChan:
fmt.Println("收到停止信号,任务即将退出。")
return // 退出goroutine
}
}
}
// 调用示例
/*
func main() {
stop := make(chan struct{})
go StartPeriodicTask(1 * time.Second, stop)
time.Sleep(5 * time.Second) // 运行一段时间
close(stop) // 发送停止信号
fmt.Println("主程序已发送停止信号。")
time.Sleep(50 * time.Millisecond) // 给goroutine一点时间处理退出
fmt.Println("主程序退出。")
}
*/对于
time.Timer
timer.Stop()
Stop()
false
timer.C
select
// 示例:优雅停止一次性任务的等待
func StartOneOffTask(delay time.Duration, stopChan <-chan struct{}) {
timer := time.NewTimer(delay)
defer func() {
// 确保timer被停止或其通道被清空
if !timer.Stop() {
select {
case <-timer.C: // 清空通道
default:
}
}
}()
fmt.Printf("一次性任务启动,等待 %v\n", delay)
select {
case <-timer.C:
fmt.Println("Timer触发了,执行一次性任务。")
case <-stopChan: // 同样可以用stopChan来停止等待中的Timer
fmt.Println("收到停止信号,一次性任务被外部停止,未触发。")
}
}
// 调用示例
/*
func main() {
stop := make(chan struct{})
go StartOneOffTask(5 * time.Second, stop)
time.Sleep(2 * time.Second) // 在Timer触发前发送停止信号
close(stop)
fmt.Println("主程序已发送停止信号给一次性任务。")
time.Sleep(1 * time.Second) // 给goroutine一点时间处理退出
fmt.Println("主程序退出。")
}
*/总结一下,
defer ticker.Stop()
stop
timer.Stop()
长时间运行的定时任务,尤其是在Go这种高并发语言中,如果设计不当,很容易引入性能瓶颈或资源问题。核心在于,定时任务本身应该尽可能地“非阻塞”和“自包含”。
避免阻塞: 首先,定时任务的执行体本身不应该是一个长时间的、同步阻塞的操作。如果你的任务逻辑需要执行很长时间(比如网络请求、大数据处理、复杂的计算),那么不应该直接在
ticker.C
timer.C
select
// 错误示范(可能阻塞定时器goroutine)
/*
case <-ticker.C:
// 这里执行一个需要10秒的任务,如果ticker是每1秒触发,就会以上就是Golanggoroutine与Timer结合实现定时任务的详细内容,更多请关注php中文网其它相关文章!
每个人都需要一台速度更快、更稳定的 PC。随着时间的推移,垃圾文件、旧注册表数据和不必要的后台进程会占用资源并降低性能。幸运的是,许多工具可以让 Windows 保持平稳运行。
Copyright 2014-2025 https://www.php.cn/ All Rights Reserved | php.cn | 湘ICP备2023035733号