解决go在函数退出后子协程的退出问题
程序员文章站
2022-04-12 23:02:23
该问题来源于自己在读fabric源码时,看到的一个测试代码,在一个函数中启用协程,然后该函数退出了,由于平常没有这样处理过,以及受原有c++函数域的影响,认为函数退出,子协程应该也退出了呀。这其实是自...
该问题来源于自己在读fabric源码时,看到的一个测试代码,在一个函数中启用协程,然后该函数退出了,由于平常没有这样处理过,以及受原有c++函数域的影响,认为函数退出,子协程应该也退出了呀。
这其实是自己对go协程的理解不到位引起的,go的协程作用域不是在某个函数中的,当然,如果那个函数是main函数,就符合要求了。
该代码为solo算法的测试代码:
func gowithwait(target func()) *waitablego { wg := &waitablego{ done: make(chan struct{}), } go func() { target()//该协程会阻塞在这 close(wg.done)//用来对外通知 }() //外边结束,里边还不结束吗? return wg } // this test checks that if consenter is halted before a timer fires, nothing is actually written. func testhaltbeforetimeout(t *testing.t) { batchtimeout, _ := time.parseduration("1ms") //support的构造还不清楚 support := &mockmultichannel.consentersupport{ blocks: make(chan *cb.block), blockcutterval: mockblockcutter.newreceiver(), sharedconfigval: &mockconfig.orderer{batchtimeoutval: batchtimeout}, } defer close(support.blockcutterval.block) bs := newchain(support) //bs.main是solo算法的启动函数,是个死循环,处理函数 wg := gowithwait(bs.main) defer bs.halt()//中止 syncqueuemessage(testmessage, bs, support.blockcutterval) bs.halt() select { case <-support.blocks: t.fatalf("expected no invocations of append") case <-wg.done: } }
遇到该问题后,我写了几个测试:
单纯的函数退出,是不会影响协程的
package main import "fmt" var ch chan int func test() int { ch = make(chan int) go func() { for { fmt.println(<-ch) fmt.println("hello") } fmt.println("aaaa") }() //不阻塞,那go func()不会异常退出吗? //协程并不是函数,不会因为这个函数的退出而退出 //test()启动一个deadloop子协程,这个会在主协程main结束后被强制退出 return 0 } func main() { c := test() ch <- 10 fmt.println("c", c) }
我经常在main里边直接写协程的测试demo,main退出会结束主协程,之后会强制结束子协程,一般不会遇到上述在普通函数退出的问题,也没仔细思考,所以分析源码时有点困惑。
子协程启动子协程,父协程的退出,并没有影响到子协程
liudemacbook-pro:~ liu$ cat tmp.go package main import ( "fmt" "time" ) func test() { go func() { //父协程 defer func() { fmt.println("exit dad") }() go func() { //子协程 defer func() { fmt.println("exit kid") }() }() }() } func main() { test() time.sleep(time.second) } liudemacbook-pro:~ liu$ go run tmp.go exit dad exit kid
补充:golang中父子协程生命周期问题,以及通过context优雅关闭子协程
背景
上次基于mysql实现分布式锁,今天经过测试发现问题,主要是协程不断获取锁的逻辑存在问题,因为获取锁的协程挂掉之后,但其新生成的用来不断更新锁的协程并不会退出,导致锁一直不能被释放,究其原因如下
原因
通过下面代码即可说明
fmt.println("main 函数 开始...") go func() { fmt.println("父 协程 开始...") go func() { for { fmt.println("子 协程 执行中...") timer := time.newtimer(time.second * 2) <-timer.c } }() time.sleep(time.second*5) fmt.println("父 协程 退出...") }() time.sleep(time.second*10) fmt.println("main 函数 退出")
main 函数 开始...
父 协程 开始...
子 协程 执行中...
子 协程 执行中...
子 协程 执行中...
父 协程 退出...
子 协程 执行中...
子 协程 执行中...
main 函数 退出
由此可以看出:
main 函数退出,所有协程退出
协程无父子关系,即在父协程开启新的协程,若父协程退出,不影响子协程
解决方式
通过context上下文来解决,当然也可以通过channel管道来解决,context解决方式如下:
fmt.println("main 函数 开始...") go func() { ctx, cancel := context.withcancel(context.background()) defer cancel() fmt.println("父 协程 开始...") go func(ctx context.context) { for { for { select { case <-ctx.done(): fmt.println("子 协程 接受停止信号...") return default: fmt.println("子 协程 执行中...") timer := time.newtimer(time.second * 2) <-timer.c } } } }(ctx) time.sleep(time.second*5) fmt.println("父 协程 退出...") }() time.sleep(time.second*10) fmt.println("main 函数 退出")
main 函数 开始...
父 协程 开始...
子 协程 执行中...
子 协程 执行中...
子 协程 执行中...
父 协程 退出...
子 协程 接受停止信号...
main 函数 退出
以上为个人经验,希望能给大家一个参考,也希望大家多多支持。如有错误或未考虑完全的地方,望不吝赐教。