一、Context包到底是干嘛用的
我们会在用到很多东西的时候都看到context的影子,比如gin框架,比如grpc,这东西到底是做啥的?
大家都在用,没几个知道这是干嘛的,知其然而不知其所以然,
谁都在CRUD,谁都觉得if else就完了,有代码能copy我也行,原理啥啥不懂不重要,反正就是一把梭
原理说白了就是:
- 当前协程取消了,可以通知所有由它创建的子协程退出
- 当前协程取消了,不会影响到创建它的父级协程的状态
- 扩展了额外的功能:超时取消、定时取消、可以给子协程共享数据
二、主协程退出通知子协程示例演示
主协程通知子协程退出
如下代码展示了,通过一个叫done的channel通道达到了这样的效果
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
34
35
36
37
38
39
40
41
|
package main import ( "fmt" "time" ) func main() { done := make(chan string) //缓冲通道预先放置10个消息 messages := make(chan int , 10 ) defer close(messages) for i := 0 ; i < 10 ; i++ { messages <- i } //启动3个子协程消费messages消息 for i := 1 ; i <= 3 ; i++ { go child(i, done, messages) } time.Sleep( 3 * time.Second) //等待子协程接收一半的消息 close(done) //结束前通知子协程 time.Sleep( 2 * time.Second) //等待所有的子协程输出 fmt.Println( "主协程结束" ) } //从messages通道获取信息,当收到结束信号的时候不再接收 func child(i int , done <-chan string, messages <-chan int ) { Consume: for { time.Sleep( 1 * time.Second) select { case <-done: fmt.Printf( "[%d]被主协程通知结束...\n" , i) break Consume default : fmt.Printf( "[%d]接收消息: %d\n" , i, <-messages) } } } |
运行结束如下
这里,我们用一个channel的关闭做到了通知所有的消费到一半的子协程退出。
问题来了,如果子协程又要启动它的子协程,这可咋整?
主协程通知有子协程,子协程又有多个子协程
这是可哲学问题,我们还是得建立一个叫done的channel来监测
下面演示一下这种操作,再在每个child方法里启动多个job,如下
全量代码贴出来
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
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
package main import ( "fmt" "time" ) func main() { done := make(chan string) //缓冲通道预先放置10个消息 messages := make(chan int , 10 ) defer close(messages) for i := 0 ; i < 10 ; i++ { messages <- i } //启动3个子协程消费messages消息 for i := 1 ; i <= 3 ; i++ { go child(i, done, messages) } time.Sleep( 3 * time.Second) //等待子协程接收一半的消息 close(done) //结束前通知子协程 time.Sleep( 2 * time.Second) //等待所有的子协程输出 fmt.Println( "主协程结束" ) } //从messages通道获取信息,当收到结束信号的时候不再接收 func child(i int , done <-chan string, messages <-chan int ) { newDone := make(chan string) defer close(newDone) go childJob(i, "a" , newDone) go childJob(i, "b" , newDone) Consume: for { time.Sleep( 1 * time.Second) select { case <-done: fmt.Printf( "[%d]被主协程通知结束...\n" , i) break Consume default : fmt.Printf( "[%d]接收消息: %d\n" , i, <-messages) } } } //任务 func childJob(parent int , name string, done <-chan string) { for { time.Sleep( 1 * time.Second) select { case <-done: fmt.Printf( "[%d-%v]被结束...\n" , parent, name) return default : fmt.Printf( "[%d-%v]执行\n" , parent, name) } } } |
运行结果如下
问题来了,如果job里再启动自己的goroutine,这样没完没了的建立done的通道有点恶心,这时候context包就来了!
我们先把上面的代码改成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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
|
package main import ( "context" "fmt" "time" ) func main() { ctx, cancel := context.WithCancel(context.Background()) //缓冲通道预先放置10个消息 messages := make(chan int , 10 ) defer close(messages) for i := 0 ; i < 10 ; i++ { messages <- i } //启动3个子协程消费messages消息 for i := 1 ; i <= 3 ; i++ { go child(i, ctx, messages) } time.Sleep( 3 * time.Second) //等待子协程接收一半的消息 cancel() //结束前通知子协程 time.Sleep( 2 * time.Second) //等待所有的子协程输出 fmt.Println( "主协程结束" ) } //从messages通道获取信息,当收到结束信号的时候不再接收 func child(i int , ctx context.Context, messages <-chan int ) { //基于父级的context建立context newCtx, _ := context.WithCancel(ctx) go childJob(i, "a" , newCtx) go childJob(i, "b" , newCtx) Consume: for { time.Sleep( 1 * time.Second) select { case <-ctx.Done(): fmt.Printf( "[%d]被主协程通知结束...\n" , i) break Consume default : fmt.Printf( "[%d]接收消息: %d\n" , i, <-messages) } } } //任务 func childJob(parent int , name string, ctx context.Context) { for { time.Sleep( 1 * time.Second) select { case <-ctx.Done(): fmt.Printf( "[%d-%v]被结束...\n" , parent, name) return default : fmt.Printf( "[%d-%v]执行\n" , parent, name) } } } |
运行结果如下
可以看到,改成context包还是顺利的通过子协程退出了
主要修改了几个地方,再ctx向下传递
基于上层context再构建当前层级的context
监听context的退出信号,
这就是context包的核心原理,链式传递context,基于context构造新的context
三、Context包的核心接口和方法
更多资料可以查看:Go 语言设计与实现
context接口
context是一个接口,主要包含以下4个方法
- Deadline
返回当前context任务被取消的时间,没有设定返回ok返回false
- Done
当绑定当前的context任务被取消时,将返回一个关闭的channel
- Err
Done返回的channel没有关闭,返回nil;
Done返回的channel已经关闭,返回非空值表示任务结束的原因;
context被取消,返回Canceled。
context超时,DeadlineExceeded
- Value
返回context
存储的键
emptyCtx结构体
实现了context接口,emptyCtx没有超时时间,不能取消,也不能存储额外信息,所以emptyCtx用来做根节点,一般用Background和TODO来初始化emptyCtx
Backgroud
通常用于主函数,初始化以及测试,作为顶层的context
TODO
不确定使用什么用context的时候才会使用
valueCtx结构体
1
|
type valueCtx struct{ Context key, val interface {} } |
valueCtx利用Context的变量来表示父节点context,所以当前context继承了父context的所有信息
valueCtx还可以存储键值。
Value
1
2
3
4
5
6
|
func (c *valueCtx) Value(key interface {}) interface {} { if c.key == key { return c.val } return c.Context.Value(key) } |
可以用来获取当前context和所有的父节点存储的key
如果当前的context不存在需要的key,会沿着context链向上寻找key对应的值,直到根节点
WithValue
可以向context添加键值
1
2
3
4
5
6
7
8
9
|
func WithValue(parent Context, key, val interface {}) Context { if key == nil { panic( "nil key" ) } if !reflect.TypeOf(key).Comparable() { panic( "key is not comparable" ) } return &valueCtx{parent, key, val} } |
添加键值会返回创建一个新的valueCtx子节点
cancelCtx结构体
1
2
3
4
5
6
7
8
9
10
11
|
type cancelCtx struct { Context mu sync.Mutex done chan struct{} children map[canceler]struct{} err error } type canceler interface { cancel(removeFromParent bool, err error) Done() <-chan struct{} } |
和valueCtx类似,有一个context做为父节点,
变量done表示一个channel,用来表示传递关闭;
children表示一个map,存储了当前context节点为下的子节点
err用来存储错误信息表示任务结束的原因
WithCancel
用来创建一个可取消的context,返回一个context和一个CancelFunc,调用CancelFunc可以触发cancel操作。
timerCtx结构体
timerCtx是基于cancelCtx的context精英,是一种可以定时取消的context,过期时间的deadline不晚于所设置的时间d
WithDeadline
返回一个基于parent的可取消的context,并且过期时间deadline不晚于所设置时间d
WithTimeout
创建一个定时取消context,和WithDeadline差不多,WithTimeout是相对时间
四、总结核心原理
- Done方法返回一个channel
- 外部通过调用<-channel监听cancel方法
- cancel方法会调用close(channel)
当调用close方法的时间,所有的channel再次从通道获取内容,会返回零值和false
1
|
res,ok := <-done: |
- 过期自动取消,使用了time.AfterFunc方法,到时调用cancel方法
1
2
3
|
c.timer = time.AfterFunc(dur, func() { c.cancel( true , DeadlineExceeded) }) |
授人以渔不如授人以渔,知其然也知其所以然,让我们共同构建美丽新世界,让人与自然更加和谐,就是这样,giao~
到此这篇关于Go语言的context包从放弃到入门的文章就介绍到这了,更多相关Go语言context包入门内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家!
原文链接:https://www.cnblogs.com/chenqionghe/p/14107790.html