目录
- 需求背景:
- groutine的并发控制：
- context:
- 看看代码:
- 总结
需求背景:
项目中需要定期执行任务a来做一些辅助的工作，a的执行需要在超时时间内完成，如果本次执行超时了，那就不对本次的执行结果进行处理（即放弃这次执行）。同时a又依赖b，c两个子任务的执行结果。b, c之间相互独立，可以并行的执行。但无论b,c哪一个执行失败或超时都会导致本次任务执行失败。
groutine的并发控制：
go中对于groutine的并发控制有三种解决方案：
- 通过channel控制。
父groutine中声明无buffer的chan切片，向要开启的子groutine中传入切片中的一个chan
子groutine执行完成后向这个chan中写入数据(可以是和父groutine通信的也可以不是)
父groutine遍历所有chan并执行 <-chan 操作, 利用无buffer的channel只有读写同时准备好才能执行的特性进行控
- waitgroup控制。
通过sync.waitgroup, 每开启一个子groutine就执行 wg.add(1), 子groutine内部执行wg.done(), 父groutine通过wg.wait()等待所有子协程
- context控制。
waitgroup和context应该是go中较为常用的两种并发控制。相较而言，context对于派生groutine有更强大的控制力，可以控制多级树状分布的groutine。
当然waitgroup的子groutine也可以再开启新的waitgroup并且等待多个孙groutine, 但是不如context的控制更加方便.
context:
context包提供了四个方法创建不同类型的context
- witchcancel()
- withdeadline()
- withtimeout()
- withvalue()
withvalue()主要用于通过context传递一些上下文消息，不在本次讨论中。withtimeout和withdeadline几乎是一致的。但无论哪种，控制groutine都需要使用ctx.done()方法. done() 方法返回一个 "只读"的chan <-chan struct{}, 需要编写代码监听这个chan，一旦收到它的消息就说明这个context应当结束了，无论是到达了超时时间还是在某个地方主动cancel()了方法。
看看代码:
var ch1 chan int var ch2 chan int <br>// 任务a， 通过最外层的for来控制定期执行 func testme(t *testing.t) { ch1 = make(chan int, 0) ch2 = make(chan int, 0) count := 0 for { count ++ ctx, cancel := context.withtimeout(context.background(), time.second * 2)<br> // 任务a的逻辑部分，开启子任务b, c。<br> // b,c通过ch1，ch2和a通信。<br> // 同时监听ctx.done，如果超时了立即结束本次任务不继续执行 go func(ctx context.context) { go g1(ctx, count) go g2(ctx, count) v1, v2 := -1, -1 for v1 == -1 || v2 == -1 { select { case <- ctx.done(): cancel() fmt.println("父级2超时退出，当前count值为", count, "当前时间：", time.now()) return case v1 = <- ch1: case v2 = <- ch2: } } fmt.println("正常执行完成退出, 开启下次循环，当前count值为：", count, "当前 v1: ", v1, "当前 v2: ", v2) }(ctx)<br> // 任务a监控ctx是否到达timeout，timeout就终止本次执行 select { case <- ctx.done(): fmt.println("父级1超时退出，当前count值为", count, "当前时间：", time.now()) } time.sleep(time.second * 3) } } <br>// 改进后的任务b，即使计算出了结果，也不会再向ch1写数据了，不会造成脏数据 func g1 (ctx context.context, num int) { fmt.println("g1 num", num, "time", time.now()) select { case <-ctx.done(): fmt.println("子级 g1关闭, 不向channel中写数据") return default: ch1 <- num } } <br>// 改进前的任务c func g2 (ctx context.context, num int) { fmt.println("g2 num", num, "time", time.now()) ch2 <- num
基于上述代码，子任务b, c的处理其实有一次较大的变动。一开始b,c都是类似于子任务c，即g2的这种写法。
这种写法在执行完成后就把自身的结果交给channel， 父groutine通过channel来读取数据，正常情况下也能工作。但异常情况下，如子任务b执行完成，子任务c(即g2)因为网络通信等原因执行了5s(超过context的最大时长), 就会出现比较严重的问题。到达超时时间后，a检测到了超时就自动结束了本次任务，但g2还在执行过程中。g2执行完成后向ch2写数据阻塞了(因为a已关闭，没有读取ch2的groutine)。下一个循环中a再次开启读取ch1与ch2, 实际上读取ch1是当次的结果，ch2是上次任务中g2返回的结果，导致两处依赖的数据源不一致。
模拟上述情况，将g2做了一些改动如下:
// 在第3次任务重等待3s, 使得它超时<br>func g2 (ctx context.context, num int) { if num == 3 { time.sleep(time.second * 3) } fmt.println("g2 num", num, "time", time.now()) ch2 <- num }
实际上，如果想要通过context控制groutine, 一定要监控done()方法。如g1所示。相同情况下a超时退出，c仍在执行。c执行完成后先检测context是否已退出，如果已退出就不再向ch2中写入本次的数据了。(抛砖引玉了，也可能有更好的写法，希望大佬不吝赐教)
将g2改成和g1类似的写法后测试结果如下：
func g2 (ctx context.context, num int) { if num == 3 { time.sleep(time.second * 10) fmt.println("这次g2 超时，应当g1, g2都不返回") } fmt.println("g2 num", num, "time", time.now()) select { case <-ctx.done(): fmt.println("子级 g2关闭, 不向channel中写数据") return default: ch2 <- num } }
总结
到此这篇关于go中groutine通信与context控制的文章就介绍到这了,更多相关go groutine通信与context控制内容请搜索<计算机技术网(www.ctvol.com)!!>以前的文章或继续浏览下面的相关文章希望大家以后多多支持<计算机技术网(www.ctvol.com)!!>！
需要了解更多python教程分享Go中groutine通信与context控制实例详解，都可以关注python教程分享栏目—计算机技术网(www.ctvol.com)!
本文来自网络收集，不代表计算机技术网立场，如涉及侵权请联系管理员删除。
ctvol管理联系方式QQ:251552304
本文章地址：https://www.ctvol.com/pythontutorial/1047518.html