简介
context是一个在go中时常用到的程序包,google官方开发。特别常见的一个应用场景是由一个请求衍生出的各个goroutine之间需要满足一定的约束关系,以实现一些诸如有效期,中止routine树,传递请求全局变量之类的功能。使用context实现上下文功能约定需要在你的方法的传入参数的第一个传入一个context.Context类型的变量。
比如:
- 上层需要指定超时的情况: ctx, cancel := context.WithTimeout(ctx, 100*time.Millisecond)
- 上层需要主动取消的情况:ctx, cancel := context.WithCancel(ctx);需要的地方调用cancel()
问题
对于context包中提供的WithTimeout(本质上调用的是WithDeadline) 方法;官方有这样的说明
// Canceling this context releases resources associated with it, so code should
// call cancel as soon as the operations running in this Context complete:
//
// func slowOperationWithTimeout(ctx context.Context) (Result, error) {
// ctx, cancel := context.WithTimeout(ctx, 100*time.Millisecond)
// defer cancel() // releases resources if slowOperation completes before timeout elapses
// return slowOperation(ctx)
// }
文中说到要尽快调用cancel()用来释放关联的资源,那到底这个cancel做了什么,如果不调用呢?
解释
通过阅读代码可以发现,主要做了四件事)
close(c.done)
这里c.done,即使没有close,也不会影响GC;猜测是为了防止slowOperation里面又创建的goroutine里面等待c.done,这样可能会阻塞,防止goroutine泄露
所有的child 调用cancel
这个就是递归了
delete(p.children, child) 删除自己在上层context的记录
这个有利于GC,如果不删除掉,这个无用的context对象会一直留着,直到上层对象被GC了
c.timer.Stop() 关闭定时器
如果在超时发生前,slowOperation结束了,这个时候提前 关闭
但是对于WithTimeout(或者WithDeadline) 有两种情况
1. 一种是发生超时了,这个时候cancel 会自动调用,资源被释放
2. 另一种没有发生超时,也就是slowOperation结束的时候,这个时候需要咱们主动调用cancel;但是即使没有调用,在过期时间到了的时候还是会调用cancel,释放资源
所以:cancel 即使不主动调用,也不影响资源的最终释放,但是提前主动调用,可以尽快的释放,避免等待过期时间之间的浪费;
建议还是按照官方的说明使用,养成良好的习惯,在调用WithTimeout之后defer cancel()
注: 最近在看grpc的源码的时候,就发现了一处没有主动调用cancel的情况;并且给原作者提了一个issue,不过这是因为原作者有特殊用意故意为之的
地址:why not call cancel() after context.WithTimeout, is it a bug or have something another?