需求背景:

项目中需要定期执行任务A来做一些辅助的工作,A的执行需要在超时时间内完成,如果本次执行超时了,那就不对本次的执行结果进行处理(即放弃这次执行)。同时A又依赖B,C两个子任务的执行结果。B, C之间相互独立,可以并行的执行。但无论B,C哪一个执行失败或超时都会导致本次任务执行失败。

Groutine的并发控制:

go中对于groutine的并发控制有三种解决方案:

  1. 通过channel控制。
    1. 父groutine中声明无buffer的chan切片,向要开启的子groutine中传入切片中的一个chan
    2. 子groutine执行完成后向这个chan中写入数据(可以是和父groutine通信的也可以不是)
    3. 父groutine遍历所有chan并执行 <-chan 操作, 利用无buffer的channel只有读写同时准备好才能执行的特性进行控
  2. WaitGroup控制。
    1. 通过sync.Waitgroup, 每开启一个子groutine就执行 wg.Add(1), 子groutine内部执行wg.Done(), 父groutine通过wg.Wait()等待所有子协程
  3. Context控制。
    1. waitGroup和Context应该是Go中较为常用的两种并发控制。相较而言,context对于派生groutine有更强大的控制力,可以控制多级树状分布的groutine。
    2. 当然waitGroup的子groutine也可以再开启新的waitGroup并且等待多个孙groutine, 但是不如context的控制更加方便.

Context:

context包提供了四个方法创建不同类型的context

  1. WitchCancel()
  2. WithDeadline()
  3. WithTimeout()
  4. WithValue()

WithValue()主要用于通过context传递一些上下文消息,不在本次讨论中。WithTimeout和WithDeadLine几乎是一致的。但无论哪种,控制groutine都需要使用ctx.Done()方法. Done() 方法返回一个 "只读"的chan   <-chan struct{}, 需要编写代码监听这个chan,一旦收到它的消息就说明这个context应当结束了,无论是到达了超时时间还是在某个地方主动cancel()了方法。

看看代码:

var ch1 chan int
var ch2 chan int

// 任务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)
// 任务A的逻辑部分,开启子任务B, C。
// B,C通过ch1,ch2和A通信。
// 同时监听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)
// 任务A监控ctx是否到达timeOUT,timeout就终止本次执行
select {
case <- ctx.Done():
fmt.Println("父级1超时退出,当前count值为", count, "当前时间:", time.Now())
}
time.Sleep(time.Second * 3)
}
}

// 改进后的任务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
}
}

// 改进前的任务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, 使得它超时
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控制的更多相关文章

  1. openstack controller ha测试环境搭建记录(十三)——配置cinder(控制节点)

    在任一控制节点创建用户:mysql -u root -pCREATE DATABASE cinder;GRANT ALL PRIVILEGES ON cinder.* TO 'cinder'@'loc ...

  2. openstack controller ha测试环境搭建记录(十)——配置neutron(控制节点)

    创建neutron用户:mysql -u root -p CREATE DATABASE neutron;GRANT ALL PRIVILEGES ON neutron.* TO 'neutron'@ ...

  3. openstack controller ha测试环境搭建记录(八)——配置nova(控制节点)

    在任一节点创建nova用户:mysql -u root -p CREATE DATABASE nova;GRANT ALL PRIVILEGES ON nova.* TO 'nova'@'localh ...

  4. 记一次.net core 异步线程设置超时时间

    前言: 刷帖子看到一篇 Go 记录一次groutine通信与context控制 看了一下需求背景,挺有意思的,琢磨了下.net core下的实现 需求背景: 项目中需要定期执行任务A来做一些辅助的工作 ...

  5. 权限管理系统系列之WCF通信

    目录 权限管理系统系列之序言  首先说下题外话,有些园友看了前一篇[权限管理系统系列之序言]博客加了QQ群(186841119),看了我写的权限管理系统的相关文档(主要是介绍已经开发的功能),给出了一 ...

  6. Android USB转串口通信开发基本流程

    好久没有写文章了,年前公司新开了一个项目,是和usb转串口通信相关的,需求是用安卓平板通过usb转接后与好几个外设进行通信.一直忙到近期,才慢慢闲下来,趁着这个周末不忙.记录下usb转串口通信开发的基 ...

  7. 【MPI学习7】MPI并行程序设计模式:MPI的进程组和通信域

    基于都志辉老师MPI编程书中的第15章内容. 通信域是MPI的重要概念:MPI的通信在通信域的控制和维护下进行 → 所有MPI通信任务都直接或间接用到通信域这一参数 → 对通信域的重组和划分可以方便实 ...

  8. 【MPI学习5】MPI并行程序设计模式:组通信MPI程序设计

    相关章节:第13章组通信MPI程序设计. MPI组通信与点到点通信的一个重要区别就是:组通信需要特定组内所有成员参与,而点对点通信只涉及到发送方和接收方. 由于需要组内所有成员参与,因此也是一种比较复 ...

  9. SSL、TLS协议格式、HTTPS通信过程、RDP SSL通信过程

    相关学习资料 http://www.360doc.com/content/10/0602/08/1466362_30787868.shtml http://www.gxu.edu.cn/college ...

随机推荐

  1. HDU 6608:Fansblog(威尔逊定理)

    Fansblog Time Limit: 2000/2000 MS (Java/Others) Memory Limit: 65536/65536 K (Java/Others) Total Subm ...

  2. 「算法笔记」数位 DP

    一.关于数位 dp 有时候我们会遇到某类问题,它所统计的对象具有某些性质,答案在限制/贡献上与统计对象的数位之间有着密切的关系,有可能是数位之间联系的形式,也有可能是数位之间相互独立的形式.(如求满足 ...

  3. Layui的本地存储方法-Layui.data的基本使用

    本地存储是对 localStorage 和 sessionStorage 的友好封装,可更方便地管理本地数据. localStorage 持久化存储:layui.data(table, setting ...

  4. Zookeeper基础教程(三):Zookeeper连接使用—zkCli

    上一篇介绍Zookeeper的安装,并介绍了使用ZooInspector连接Zookeeper,这里主要介绍以命令行的形式介绍Zookeeper 假如我们已经安装了Zookeeper集群,集群中的安装 ...

  5. IIS部署php项目——discuz论坛

    1.安装CgiModule模块 首先,IIS要部署php项目,需要CgiModule模块的支持,所以首先我们要确认这个模块是否存在 打开IIS管理器: 我这里是存在的: 如果不存在,可以自行在控制面板 ...

  6. Go项目开源规范

    我们为什么一定要知道开源规范呢? 一是,开源项目在代码质量.代码规范.文档等方面,要比非开源项目要求更高,在项目开发中按照开源项目的要求来规范自己的项目,可以更好地驱动项目质量的提高: 二是,一些大公 ...

  7. Chrome升级到91版本以上后Cookies SameSite问题,IdentityServer4登录不上问题?

    还原下问题: 跨站Cookie安全级别限制,如过是https不用担心这个问题,但是IP访问,本地测试等就会出现登录不上 针对这个问题,记得早在之前80版本的chrome就会存在的问题,可能大家会用:c ...

  8. unittest_TestSuite测试套件(2)

    在前面一章中演示了unittest如何执行一个简单的测试,但有两个问题: 我们知道测试用例的执行顺序是根据测试用例名称顺序执行的,在不改变用例名称的情况下,我们怎么来控制用例执行的顺序呢? 一个测试文 ...

  9. spring security 登出操作 详细说明

    1.前言 这里专门 做 spring security 登出操作 的  详细记录 2.操作 (1)目录结构 (2)在security 拦截规则配置文件添加退出登录支持 源码 package com.e ...

  10. 日志收集系统系列(五)之LogTransfer

    从kafka里面把日志取出来,写入ES,使用Kibana做可视化展示 1. ElasticSearch 1.1 介绍 Elasticsearch(ES)是一个基于Lucene构建的开源.分布式.RES ...