该问题来源于自己在读fabric源码时，看到的一个测试代码，在一个函数中启用协程，然后该函数退出了，由于平常没有这样处理过，以及受原有c++函数域的影响，认为函数退出，子协程应该也退出了呀。
这其实是自己对go协程的理解不到位引起的，go的协程作用域不是在某个函数中的，当然，如果那个函数是main函数，就符合要求了。
该代码为solo算法的测试代码：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
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: }} |
遇到该问题后，我写了几个测试：
单纯的函数退出，是不会影响协程的
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
package mainimport "fmt"var ch chan intfunc 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退出会结束主协程，之后会强制结束子协程，一般不会遇到上述在普通函数退出的问题，也没仔细思考，所以分析源码时有点困惑。
子协程启动子协程,父协程的退出，并没有影响到子协程
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
liudeMacBook-Pro:~ liu$ cat tmp.go package mainimport ( "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 dadexit kid |
补充：golang中父子协程生命周期问题，以及通过context优雅关闭子协程
背景
上次基于mysql实现分布式锁，今天经过测试发现问题，主要是协程不断获取锁的逻辑存在问题，因为获取锁的协程挂掉之后，但其新生成的用来不断更新锁的协程并不会退出，导致锁一直不能被释放，究其原因如下
原因
通过下面代码即可说明
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
|
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解决方式如下：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
|
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 函数 退出
以上为个人经验，希望能给大家一个参考，也希望大家多多支持服务器之家。如有错误或未考虑完全的地方，望不吝赐教。
原文链接：https://longtails.blog.csdn.net/article/details/89303653
