深入浅出Context原理

1.1 背景

在 Go 服务中，每个传入的请求都在其自己的goroutine 中处理。请求处理程序通常启动额外的 goroutine 来访问其他后端，如数据库和 RPC服务。处理请求的 goroutine 通常需要访问特定于请求(request-specific context)的值，例如最终用户的身份、授权令牌和请求的截止日期(deadline)。当一个请求被取消或超时时，处理该请求的所有 goroutine 都应该快速退出(fail fast)，这样系统就可以回收它们正在使用的任何资源。

Go 1.7 引入一个 context 包，它使得跨 API 边界的请求范围元数据、取消信号和截止日期很容易传递给处理请求所涉及的所有 goroutine(显示传递)。

其他语言: Thread Local Storage(TLS)，XXXContext。

1.2 什么是context？

可以字面意思可以理解为上下文，比较熟悉的有进程/线程上线文，关于Golang中的上下文，一句话概括就是：goroutine的相关环境快照，其中包含函数调用以及涉及的相关的变量值。通过Context可以区分不同的goroutine请求，因为在Golang Severs中，每个请求都是在单个goroutine中完成的。

由于在Golang severs中，每个request都是在单个goroutine中完成，并且在单个goroutine（不妨称之为A）中也会有请求其他服务（启动另一个goroutine（称之为B）去完成）的场景，这就会涉及多个Goroutine之间的调用。如果某一时刻请求其他服务被取消或者超时，则作为深陷其中的当前goroutine B需要立即退出，然后系统才可回收B所占用的资源。
即一个request中通常包含多个goroutine，这些goroutine之间通常会有交互。

那么，如何有效管理这些goroutine成为一个问题（主要是退出通知和元数据传递问题），Google的解决方法是Context机制，相互调用的goroutine之间通过传递context变量保持关联，这样在不用暴露各goroutine内部实现细节的前提下，有效地控制各goroutine的运行。

如此一来，通过传递Context就可以追踪goroutine调用树，并在这些调用树之间传递通知和元数据。
虽然goroutine之间是平行的，没有继承关系，但是Context设计成是包含父子关系的，这样可以更好的描述goroutine调用之间的树型关系。

1.3 context结构

// A Context carries a deadline, cancelation signal, and request-scoped values
// across API boundaries. Its methods are safe for simultaneous use by multiple
// goroutines.
type Context interface {
    // Done returns a channel that is closed when this Context is canceled
    // or times out.
    Done() <-chan struct{}

    // Err indicates why this context was canceled, after the Done channel
    // is closed.
    Err() error

    // Deadline returns the time when this Context will be canceled, if any.
    Deadline() (deadline time.Time, ok bool)

    // Value returns the value associated with key or nil if none.
    Value(key interface{}) interface{}
}

👆🏻golang Context的源码，Context是一个Interface，有四个方法，Done(),Err(),Deadline,Value。

字段	含义
Deadline	返回一个time.Time，表示当前Context应该结束的时间，ok则表示有结束时间
Done	当Context被取消或者超时时候返回的一个close的channel，告诉给context相关的函数要停止当前工作然后返回了。(这个有点像全局广播)
Err	context被取消的原因
Value	context实现共享数据存储的地方，是协程安全的。

同时包中也定义了提供cancel功能需要实现的接口。

// A canceler is a context type that can be canceled directly. The
// implementations are *cancelCtx and *timerCtx.
type canceler interface {
	cancel(removeFromParent bool, err error)
	Done() <-chan struct{}
}

go的context库提供了四种实现,如下

• emptyCtx:

  type emptyCtx int
  

  完全空的Context，实现的函数也都是返回nil，仅仅只是实现了Context的接口

• cancelCtx:

  // A cancelCtx can be canceled. When canceled, it also cancels any children
  // that implement canceler.
  type cancelCtx struct {
  	Context
  
  	mu       sync.Mutex            // protects following fields
  	done     chan struct{}         // created lazily, closed by first cancel call
  	children map[canceler]struct{} // set to nil by the first cancel call
  	err      error                 // set to non-nil by the first cancel call
  }
  

  继承自Context，同时也实现了canceler接口。

• timerCtx

  // A timerCtx carries a timer and a deadline. It embeds a cancelCtx to
  // implement Done and Err. It implements cancel by stopping its timer then
  // delegating to cancelCtx.cancel.
  type timerCtx struct {
  	cancelCtx
  	timer *time.Timer // Under cancelCtx.mu.
  
  	deadline time.Time
  }
  

  继承自cancelCtx，增加了timeout机制。

• valueCtx

// A valueCtx carries a key-value pair. It implements Value for that key and
// delegates all other calls to the embedded Context.
type valueCtx struct {
	Context
	key, val interface{}
}

存储键值对的数据。

1.4 context的创建

为了更方便的创建Context，包里头定义了Background来作为所有Context的根，它是一个emptyCtx的实例。

var (
	background = new(emptyCtx)
	todo       = new(emptyCtx)
)

// Background returns a non-nil, empty Context. It is never canceled, has no
// values, and has no deadline. It is typically used by the main function,
// initialization, and tests, and as the top-level Context for incoming
// requests.
func Background() Context {
	return background
}

你可以认为所有的Context是树的结构，Background是树的根，当任一Context被取消的时候，那么继承它的Context 都将被回收。

1.5 如何将 context 集成到 API 中？

在将 context 集成到 API 中时，要记住的最重要的一点是，它的作用域是请求级别 的。例如，沿单个数据库查询存在是有意义的，但沿数据库对象存在则没有意义。
目前有两种方法可以将 context 对象集成到 API 中：

• The first parameter of a function call

  首参数传递 context 对象，比如，参考 net 包 Dialer.DialContext。此函数执行正常的 Dial 操作，但可以通过 context 对象取消函数调用。

  func (d *Dialer) DialContext(ctx context.Context, network, address string) (Conn, error) {}
  

• Optional config on a request structure

  在第一个 request 对象中携带一个可选的 context 对象。例如 net/http 库的 Request.WithContext，通过携带给定的 context 对象，返回一个新的 Request 对象。

  func (d *Request) WithContext(ctx context.Context) *Request
  

1.6 Do not store Contexts inside a struct type

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:

func DoSth(ctx context.Context, arg Arg) error {
	// ... use ctx ...
}

Incoming requests to a server should create a Context.

使用 context 的一个很好的心智模型是它应该在程序中流动，应该贯穿你的代码。这通常意味着您不希望将其存储在结构体之中。它从一个函数传递到另一个函数，并根据需要进行扩展。理想情况下，每个请求都会创建一个 context 对象，并在请求结束时过期。
不存储上下文的一个例外是，当您需要将它放入一个结构中时，该结构纯粹用作通过通道传递的消息。如下例所示。

// A message processes parameter and returns the result on responseChan.
// ctx is place in a struct, but this is ok to do.
type message struct {
	response  chan<- int
	parameter string
	ctx       context.Context
}

1.7 context.WithValue

在1.3小结有描述valueCtx的结构。

为了实现不断的 WithValue，构建新的 context，内部在查找 key 时候，使用递归方式不断从当前，从父节点寻找匹配的 key(链表的方式去寻找，a能找a.Value，b能找b.Value与a.Value…)，直到 root context（Backgrond 和 TODO Value 函数会返回 )。其实现了隔离性，但是性能会损耗更多，所以其不适合大量的去调用。

func (c *valueCtx) Value(key interface{}) interface{} {
	if c.key == key {
		return c.val
	}
	return c.Context.Value(key)
}

比如我们新建了一个基于 context.Background() 的 ctx1，携带了一个 map 的数据，map 中包含了 “k1”: “v1” 的一个键值对，ctx1 被两个 goroutine 同时使用作为函数签名传入，如果我们修改了 这个map，会导致另外进行读 context.Value 的 goroutine 和修改 map 的 goroutine，在 map 对象上产生 data race。因此我们要使用 copy-on-write 的思路，解决跨多个 goroutine 使用数据、修改数据的场景。

Replace a Context using WithCancel, WithDeadline, WithTimeout, or WithValue.

1.7.1 The chain of function calls between them must propagate the Context

COW: 从 ctx1 中获取 map1（可以理解为 v1 版本的 map 数据）。构建一个新的 map 对象 map2，复制所有 map1 数据，同时追加新的数据 “k2”: “v2” 键值对，使用 context.WithValue 创建新的 ctx2，ctx2 会传递到其他的 goroutine 中。这样各自读取的副本都是自己的数据，写行为追加的数据，在 ctx2 中也能完整读取到，同时也不会污染 ctx1 中的数据。

1.8 When a Context is canceled, all Contexts derived from it are also canceled

当一个 context 被取消时，从它派生的所有 context 也将被取消。WithCancel(ctx) 参数 ctx 认为是 parent ctx，在内部会进行一个传播关系链的关联。Done() 返回 一个 chan，当我们取消某个parent context, 实际上上会递归层层 cancel 掉自己的 child context 的 done chan 从而让整个调用链中所有监听 cancel 的 goroutine 退出。

func main() {
	gen := func(ctx context.Context) <-chan int {
		dst := make(chan int)
		n := 1
		go func() {
			for {
				select {
				case <-ctx.Done():
					return // return not to leak the goroutine
				case dst <- n:
					n++
				}
			}
		}()
		return dst
	}

	ctx, cancel := context.WithCancel(context.Background())
	defer cancel() // cancel when we are finished consuming integers

	for n := range gen(ctx) {
		fmt.Println(n)
		if n == 5 {
			break
		}
	}
}

1.9 Debugging or tracing data is safe to pass in a Context

context.WithValue 方法允许上下文携带请求范围的数据。这些数据必须是安全的，以便多个 goroutine 同时使用。这里的数据，更多是面向请求的元数据，不应该作为函数的可选参数来使用(比如 context 里面挂了一个sql.Tx 对象，传递到 Dao 层使用)，因为元数据相对函数参数更加是隐含的，面向请求的。而参数是更加显示的。

func WithValue(parent Context, key, val interface{}) Context {
	if parent == nil {
		panic("cannot create context from nil parent")
	}
	if key == nil {
		panic("nil key")
	}
	if !reflectlite.TypeOf(key).Comparable() {
		panic("key is not comparable")
	}
	return &valueCtx{parent, key, val}
}

同一个 context 对象可以传递给在不同 goroutine 中运行的函数使用；上下文对于多个 goroutine 同时使用是安全的（就是说放进去的值是不能被篡改的）。如果有的的确确需要修改的值，就需要使用COW思想，新建一个值将原来的deep copy，然后将里面的值修改再挂一个新的值就搞定了（即生成一个新的值往下传，这样才是无污染的）。对于值类型最容易犯错的地方，在于 context value 应该是 immutable 的，每次重新赋值应该是新的 context，即: context.WithValue(ctx, oldvalue)
https://pkg.go.dev/google.golang.org/grpc/metadata
Context.Value should inform, not control

Use context values only for request-scoped data that transits processes and APIs, not for passing optional parameters to functions.
比如 染色，API 重要性，Trace
https://github.com/go-kratos/kratos/blob/master/pkg/net/metadata/key.go

1.10 All blocking/long operations should be cancelable

如果要实现一个超时控制，通过上面的 context 的 parent/child 机制，其实我们只需要启动一个定时器，然后在超时的时候，直接将当前的 context 给 cancel 掉，就可以实现监听在当前和下层的额 context.Done() 的 goroutine 的退出。

package main

import (
	"context"
	"fmt"
	"time"
)

const shortDuration = 1 * time.Millisecond

func main() {
	d := time.Now().Add(shortDuration)
	ctx, cancel := context.WithDeadline(context.Background(), d)

	defer cancel()	// 避免泄漏
	select {
	case <-time.After(1 * time.Second):
		fmt.Println("overslept")
	case <-ctx.Done():
		fmt.Println(ctx.Err())
	}
}

2. 总结

通过引入Context包，一个request范围内所有goroutine运行时的取消可以得到有效的控制。但是这种解决方式却不够优雅。一旦代码中某处用到了Context，传递Context变量（通常作为函数的第一个参数）会像病毒一样蔓延在各处调用它的地方。比如在一个request中实现数据库事务或者分布式日志记录，创建的context，会作为参数传递到任何有数据库操作或日志记录需求的函数代码处。即每一个相关函数都必须增加一个context.Context类型的参数，且作为第一个参数，这对无关代码完全是侵入式的。

更多详细内容可参见：Michal Strba 的context-should-go-away-go2文章

Context机制最核心的功能是在goroutine之间传递cancel信号，但是它的实现是不完全的。

Cancel可以细分为主动与被动两种，通过传递context参数，让调用goroutine可以主动cancel被调用goroutine。但是如何得知被调用goroutine什么时候执行完毕，这部分Context机制是没有实现的。而现实中的确又有一些这样的场景，比如一个组装数据的goroutine必须等待其他goroutine完成才可开始执行，这是context明显不够用了，必须借助sync.WaitGroup。

func serve(l net.Listener) error {
        var wg sync.WaitGroup
        var conn net.Conn
        var err error
        for {
                conn, err = l.Accept()
                if err != nil {
                        break
                }
                wg.Add(1)
                go func(c net.Conn) {
                        defer wg.Done()
                        handle(c)
                }(conn)
        }
        wg.Wait()
        return err
}