本文的操作环境:Windows10系统、go1.20版本、dell g3电脑。
Golang中通过go关键字就可开启一个goroutine,因此,在Go中可以轻松写出并发代码。但是,如何对这些并发执行的groutines有效地控制?
提到并发控制,很多人可能最先想到的是锁。Golang中同样提供了锁的相关机制,包括互斥锁sync.Mutex,和读写锁sync.RWMutex。除了锁,还有原子操作sync/atomic等。但是,这些机制关注的重点是goroutines的并发数据安全性。而本文想讨论的是goroutine的并发行为控制。
在goroutine并发行为控制中,有三种常见的方式,分别是WaitGroup、channel和Context。
WaitGroup
WaitGroup位于sync包下,它的使用方法如下。
func main() { var wg sync.WaitGroup wg.Add(2) //添加需要完成的工作量2 go func() { wg.Done() //完成工作量1 fmt.Println("goroutine 1 完成工作!") }() go func() { wg.Done() //完成工作量1 fmt.Println("goroutine 2 完成工作!") }() wg.Wait() //等待工作量2均完成 fmt.Println("所有的goroutine均已完成工作!")}输出: //goroutine 2 完成工作! //goroutine 1 完成工作! //所有的goroutine均已完成工作!
WaitGroup这种并发控制方式尤其适用于:某任务需要多 goroutine 协同工作,每个 goroutine 只能做该任务的一部分,只有全部的 goroutine 都完成,任务才算是完成。因此,WaitGroup同名字的含义一样,是一种等待的方式。
但是,在实际的业务中,有这么一种场景:当满足某个要求时,需主动的通知某一个 goroutine 结束。比如我们开启一个后台监控goroutine,当不再需要监控时,就应该通知这个监控 goroutine 结束,不然它会一直空转,造成泄漏。
Channel
对于上述场景,WaitGroup无能为力。那能想到的最简单的方法:定义一个全局变量,在其它地方通过修改这个变量进行通知,后台 goroutine 会不停的检查这个变量,如果发现变量发生了变化,即自行关闭,但是这个方法未免有些笨拙。这种情况,channel+select可派上用场。
func main() { exit := make(chan bool) go func() { for { select { case <-exit: fmt.Println("退出监控") return default: fmt.Println("监控中") time.Sleep(2 * time.Second) } } }() time.Sleep(5 * time.Second) fmt.Println("通知监控退出") exit <- true //防止main goroutine过早退出 time.Sleep(5 * time.Second)}输出: //监控中 //监控中 //监控中 //通知监控退出 //退出监控
这种 channel+select 的组合,是比较优雅的通知goroutine 结束的方式。
但是,该方案同样存在局限性。试想,如果有多个 goroutine 都需要控制结束怎么办?如果这些 goroutine 又衍生了其它更多的goroutine 呢?当然我们可以定义很多 channel 来解决这个问题,但是 goroutine 的关系链导致这种场景的复杂性。
Context
以上场景常见于CS架构模型下。在Go中,常常为每个client开启单独的goroutine(A)来处理它的一系列request,并且往往单个A中也会请求其他服务(启动另一个goroutine B),B也可能会请求另外的goroutine C,C再将request发送给例如Databse的server。设想,当client断开连接,那么与之相关联的A、B、C均需要立即退出,系统才可回收A、B、C所占用的资源。退出A简单,但是,如何通知B、C也退出呢?
这个时候,Context就出场了。
func A(ctx context.Context, name string) { go B(ctx ,name) //A调用了B for { select { case <-ctx.Done(): fmt.Println(name, "A退出") return default: fmt.Println(name, "A do something") time.Sleep(2 * time.Second) } }}func B(ctx context.Context, name string) { for { select { case <-ctx.Done(): fmt.Println(name, "B退出") return default: fmt.Println(name, "B do something") time.Sleep(2 * time.Second) } }}func main() { ctx, cancel := context.WithCancel(context.Background()) go A(ctx, "【请求1】") //模拟client来了1个连接请求 time.Sleep(3 * time.Second) fmt.Println("client断开连接,通知对应处理client请求的A,B退出") cancel() //假设满足某条件client断开了连接,那么就传播取消信号,ctx.Done()中得到取消信号 time.Sleep(3 * time.Second)}输出: //【请求1】 A do something //【请求1】 B do something //【请求1】 A do something //【请求1】 B do something //client断开连接,通知对应处理client请求的A,B退出 //【请求1】 B退出 //【请求1】 A退出
示例中模拟了客户端来了连接请求,相应开启Goroutine A进行处理,A同时开启了B处理,A和B都使用了 Context 进行跟踪,当我们使用 cancel 函数通知取消时,这 2个 goroutine 都会被结束。
这就是 Context 的控制能力,它就像一个控制器一样,按下开关后,所有基于这个 Context 或者衍生的子 Context 都会收到通知,这时就可以进行清理操作了,最终释放 goroutine,这就优雅的解决了 goroutine 启动后不可控的问题。
关于Context的详细用法,不在本文讨论范围之内。后续会出专门对Context包的讲解文章,敬请关注。
总结
本文列举了三种Golang中并发行为控制模式。模式之间没有好坏之分,只在于不同的场景用恰当的方案。实际项目中,往往多种方式混合使用。
- WaitGroup:多个goroutine的任务处理存在依赖或拼接关系。
- channel+select:可以主动取消goroutine;多groutine中数据传递;channel可以代替WaitGroup的工作,但会增加代码逻辑复杂性;多channel可以满足Context的功能,同样,也会让代码逻辑变得复杂。
- Context:多层级groutine之间的信号传播(包括元数据传播,取消信号传播、超时控制等)。
Golang中通过go关键字就可开启一个goroutine,因此,在Go中可以轻松写出并发代码。但是,如何对这些并发执行的groutines有效地控制?
提到并发控制,很多人可能最先想到的是锁。Golang中同样提供了锁的相关机制,包括互斥锁sync.Mutex,和读写锁sync.RWMutex。除了锁,还有原子操作sync/atomic等。但是,这些机制关注的重点是goroutines的并发数据安全性。而本文想讨论的是goroutine的并发行为控制。
在goroutine并发行为控制中,有三种常见的方式,分别是WaitGroup、channel和Context。
以上就是go语言怎么实现并发控制的详细内容,更多请关注Work网其它相关文章!