最近在公司分析gRPC源码，proto文件生成的代码，接口函数第一个参数统一是ctx context.Context接口，公司很多同事都不了解这样设计的出发点是什么，其实我也不了解其背后的原理。今天趁着妮妲台风妹子正面登录深圳，全市停工、停课、停业，在家休息找了一些资料研究把玩一把。golang
Context一般被译做上下文，它是一个比较抽象的概念。在公司技术讨论时也常常会提到上下文。通常理解为程序单元的一个运行状态、现场、快照，而翻译中上下又很好地诠释了其本质，上下上下则是存在上下层的传递，上会把内容传递给下。在Go语言中，程序单元也就指的是Goroutine。编程
每一个Goroutine在执行以前，都要先知道程序当前的执行状态，一般将这些执行状态封装在一个Context变量中，传递给要执行的Goroutine中。上下文则几乎已经成为传递与请求同生存周期变量的标准方法。在网络编程下，当接收到一个网络请求Request，处理Request时，咱们可能须要开启不一样的Goroutine来获取数据与逻辑处理，即一个请求Request，会在多个Goroutine中处理。而这些Goroutine可能须要共享Request的一些信息；同时当Request被取消或者超时的时候，全部从这个Request建立的全部Goroutine也应该被结束。安全
Go的设计者早考虑多个Goroutine共享数据，以及多Goroutine管理机制。Context介绍请参考Go Concurrency Patterns: Context，golang.org/x/net/context包就是这种机制的实现。网络
context包不只实现了在程序单元之间共享状态变量的方法，同时能经过简单的方法，使咱们在被调用程序单元的外部，经过设置ctx变量值，将过时或撤销这些信号传递给被调用的程序单元。在网络编程中，若存在A调用B的API, B再调用C的API，若A调用B取消，那也要取消B调用C，经过在A,B,C的API调用之间传递Context，以及判断其状态，就能解决此问题，这是为何gRPC的接口中带上ctx context.Context参数的缘由之一。ide
Go1.7(当前是RC2版本)已将原来的golang.org/x/net/context包挪入了标准库中，放在$GOROOT/src/context下面。标准库中net、net/http、os/exec都用到了context。同时为了考虑兼容，在原golang.org/x/net/context包下存在两个文件，go17.go是调用标准库的context包，而pre_go17.go则是以前的默认实现，其介绍请参考go程序包源码解读。函数
context包的核心就是Context接口，其定义以下：翻译
type Context interface {
Deadline() (deadline time.Time, ok bool)
Done() <-chan struct{}
Err() error
Value(key interface{}) interface{}
}
Deadline会返回一个超时时间，Goroutine得到了超时时间后，例如能够对某些io操做设定超时时间。设计
Done方法返回一个信道（channel），当Context被撤销或过时时，该信道是关闭的，即它是一个表示Context是否已关闭的信号。code
当Done信道关闭后，Err方法代表Context被撤的缘由。协程
Value可让Goroutine共享一些数据，固然得到数据是协程安全的。但使用这些数据的时候要注意同步，好比返回了一个map，而这个map的读写则要加锁。
Context接口没有提供方法来设置其值和过时时间，也没有提供方法直接将其自身撤销。也就是说，Context不能改变和撤销其自身。那么该怎么经过Context传递改变后的状态呢？
不管是Goroutine，他们的建立和调用关系老是像层层调用进行的，就像人的辈分同样，而更靠顶部的Goroutine应有办法主动关闭其下属的Goroutine的执行（否则程序可能就失控了）。为了实现这种关系，Context结构也应该像一棵树，叶子节点须老是由根节点衍生出来的。
要建立Context树，第一步就是要获得根节点，context.Background函数的返回值就是根节点：
func Background() Context
该函数返回空的Context，该Context通常由接收请求的第一个Goroutine建立，是与进入请求对应的Context根节点，它不能被取消、没有值、也没有过时时间。它经常做为处理Request的顶层context存在。
有了根节点，又该怎么建立其它的子节点，孙节点呢？context包为咱们提供了多个函数来建立他们：
func WithCancel(parent Context) (ctx Context, cancel CancelFunc)
func WithDeadline(parent Context, deadline time.Time) (Context, CancelFunc)
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)
func WithValue(parent Context, key interface{}, val interface{}) Context
函数都接收一个Context类型的参数parent，并返回一个Context类型的值，这样就层层建立出不一样的节点。子节点是从复制父节点获得的，而且根据接收参数设定子节点的一些状态值，接着就能够将子节点传递给下层的Goroutine了。
再回到以前的问题：该怎么经过Context传递改变后的状态呢？使用Context的Goroutine没法取消某个操做，其实这也是符合常理的，由于这些Goroutine是被某个父Goroutine建立的，而理应只有父Goroutine能够取消操做。在父Goroutine中能够经过WithCancel方法得到一个cancel方法，从而得到cancel的权利。
第一个WithCancel函数，它是将父节点复制到子节点，而且还返回一个额外的CancelFunc函数类型变量，该函数类型的定义为：
type CancelFunc func()
调用CancelFunc对象将撤销对应的Context对象，这就是主动撤销Context的方法。在父节点的Context所对应的环境中，经过WithCancel函数不只可建立子节点的Context，同时也得到了该节点Context的控制权，一旦执行该函数，则该节点Context就结束了，则子节点须要相似以下代码来判断是否已结束，并退出该Goroutine：
select {
case <-cxt.Done():
// do some clean...
}
WithDeadline函数的做用也差很少，它返回的Context类型值一样是parent的副本，但其过时时间由deadline和parent的过时时间共同决定。当parent的过时时间早于传入的deadline时间时，返回的过时时间应与parent相同。父节点过时时，其全部的子孙节点必须同时关闭；反之，返回的父节点的过时时间则为deadline。
WithTimeout函数与WithDeadline相似，只不过它传入的是从如今开始Context剩余的生命时长。他们都一样也都返回了所建立的子Context的控制权，一个CancelFunc类型的函数变量。
当顶层的Request请求函数结束后，咱们就能够cancel掉某个context，从而层层Goroutine根据判断cxt.Done()来结束。
WithValue函数，它返回parent的一个副本，调用该副本的Value(key)方法将获得val。这样咱们不光将根节点原有的值保留了，还在子孙节点中加入了新的值，注意若存在Key相同，则会被覆盖。
context包经过构建树型关系的Context，来达到上一层Goroutine能对传递给下一层Goroutine的控制。对于处理一个Request请求操做，须要采用context来层层控制Goroutine，以及传递一些变量来共享。
Context对象的生存周期通常仅为一个请求的处理周期。即针对一个请求建立一个Context变量（它为Context树结构的根）；在请求处理结束后，撤销此ctx变量，释放资源。
每次建立一个Goroutine，要么将原有的Context传递给Goroutine，要么建立一个子Context并传递给Goroutine。
Context能灵活地存储不一样类型、不一样数目的值，而且使多个Goroutine安全地读写其中的值。
当经过父Context对象建立子Context对象时，可同时得到子Context的一个撤销函数，这样父Context对象的建立环境就得到了对子Context将要被传递到的Goroutine的撤销权。
Programs that use Contexts should follow these rules to keep interfaces consistent across packages and enable static analysis tools to check context propagation:
使用Context的程序包须要遵循以下的原则来知足接口的一致性以及便于静态分析。
Do not store Contexts inside a struct type; instead, pass a Context explicitly to each function that needs it. The Context should be the first parameter, typically named ctx；不要把Context存在一个结构体当中，显式地传入函数。Context变量须要做为第一个参数使用，通常命名为ctx；
Do not pass a nil Context, even if a function permits it. Pass context.TODO if you are unsure about which Context to use；即便方法容许，也不要传入一个nil的Context，若是你不肯定你要用什么Context的时候传一个context.TODO；
Use context Values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions；使用context的Value相关方法只应该用于在程序和接口中传递的和请求相关的元数据，不要用它来传递一些可选的参数；
The same Context may be passed to functions running in different goroutines; Contexts are safe for simultaneous use by multiple goroutines；一样的Context能够用来传递到不一样的goroutine中，Context在多个goroutine中是安全的；
在子Context被传递到的goroutine中，应该对该子Context的Done信道（channel）进行监控，一旦该信道被关闭（即上层运行环境撤销了本goroutine的执行），应主动终止对当前请求信息的处理，释放资源并返回。