关于golang的context.WithTimeout的cancel的说明

简介

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做了什么，如果不调用呢？

解释

通过阅读代码可以发现，主要做了四件事）

1. close(c.done)

   这里c.done,即使没有close，也不会影响GC；猜测是为了防止slowOperation里面又创建的goroutine里面等待c.done，这样可能会阻塞，防止goroutine泄露

2. 所有的child 调用cancel

   这个就是递归了

3. delete(p.children, child) 删除自己在上层context的记录

   这个有利于GC，如果不删除掉，这个无用的context对象会一直留着，直到上层对象被GC了

4. 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?