共计 14620 个字符，预计需要花费 37 分钟才能阅读完成。
这篇文章是答复交换时一个老哥的问题，跟 go 的 context 相干内容，上一篇（https://www.cnblogs.com/dojo-…）讲了一些基础知识，这一篇持续在并发解决上进行钻研。次要是 Go Context 的应用、原理。因为工夫和精力有限，所以文章中大量援用相干材料中的内容以及图片，再此致敬。
Go Context
React 中 Context 次要用来跨组件传递一些数据，Go 中 Context 其中一个作用也跟传递数据无关，不过是在 goroutine 中互相传递数据；Context 的另一个作用在于能够便捷敞开被创立进去的 goroutine。
在理论中当服务器端收到一个申请时，很可能须要发送几个申请去申请其余服务的数据，因为 Go 语法上的同步阻塞写法，咱们个别会创立几个 goroutine 并发去做一些事件；那么这时候很可能几个 goroutine 之间须要共享数据，还有当 request 被勾销时，创立的几个 goroutine 也应该被勾销掉。那么这就是 Go Context 的用武之地。
对于协程泄露：
个别 main 函数是主协程，主协程执行结束后子协程也会被销毁；然而对于服务来说，主协程不会执行结束就退出。
所以如果每个申请都本人创立协程，而协程有没有受到结束信息完结信息，可能处于阻塞状态，这种状况下才会产生协程泄露
context 包中外围是 Context 接口：
type Context interface {Deadline() (deadline time.Time, ok bool)
Done() <-chan struct{}
Err() error
Value(key interface{}) interface{}}- Deadline 办法返回以后 Context 被勾销的工夫，也就是实现工作的截止工夫 (deadline)；
- Done 办法须要返回一个 channel，这个 Channel 会在当前工作实现或者上下文被勾销之后敞开，能够在子 goroutine 中利用 select 进行监控，来回收子 goroutine；屡次调用 Done 办法会返回同一个 Channel；
// Done is provided for use in select statements:
// // Stream generates values with DoSomething and sends them to out
// // until DoSomething returns an error or ctx.Done is closed.
// func Stream(ctx context.Context, out chan<- Value) error {
// for {// v, err := DoSomething(ctx)
// if err != nil {
// return err
// }
// select {// case <-ctx.Done():
// return ctx.Err()
// case out <- v:
// }
// }
// }
// See https://blog.golang.org/pipelines for more examples of how to use
// a Done channel for cancellation.- Err 办法会返回以后 Context 完结的起因，它只会在 Done 返回的 Channel 被敞开时才会返回空值：
- 如果以后 Context 被勾销就会返回 Canceled 谬误；
- 如果以后 Context 超时就会返回 DeadlineExceeded 谬误；
- Value 办法会从 Context 中返回键对应的值，对于同一个上下文来说，屡次调用 Value 并传入雷同的 Key 会返回雷同的后果，该办法仅用于传递跨 API 和过程间跟申请域的数据。
// // Package user defines a User type that's stored in Contexts.
// package user
// import "context"
// // User is the type of value stored in the Contexts.
// type User struct {...}
//
// // key is an unexported type for keys defined in this package.
// // This prevents collisions with keys defined in other packages.
// type key int
// // userKey is the key for user.User values in Contexts. It is
// // unexported; clients use user.NewContext and user.FromContext
// // instead of using this key directly.
// var userKey key
// // NewContext returns a new Context that carries value u.
// func NewContext(ctx context.Context, u *User) context.Context {// return context.WithValue(ctx, userKey, u)
// }
// // FromContext returns the User value stored in ctx, if any.
// func FromContext(ctx context.Context) (*User, bool) {// u, ok := ctx.Value(userKey).(*User)
// return u, ok
// }ctx.Value(userKey).(*User) 这里是 Go 语言中的类型断言（http://c.biancheng.net/view/4…）
value, ok := x.(T)
x 示意一个接口的类型，T 示意一个具体的类型（也可为接口类型）该断言表达式会返回 x 的值（也就是 value）和一个布尔值（也就是 ok），可依据该布尔值判断 x 是否为 T 类型：如果 T 是具体某个类型，类型断言会查看 x 的动静类型是否等于具体类型 T。如果查看胜利，类型断言返回的后果是 x 的动静值，其类型是 T。如果 T 是接口类型，类型断言会查看 x 的动静类型是否满足 T。如果查看胜利，x 的动静值不会被提取，返回值是一个类型为 T 的接口值。无论 T 是什么类型，如果 x 是 nil 接口值，类型断言都会失败。在 context 包中 Context 一个接口有四个具体实现和六个函数：
emptyCtx
emptyCtx 实质是一个整型类型，他对 Context 接口的实现，非常简单，其实是什么也没做，都是一堆空办法：
// An emptyCtx is never canceled, has no values, and has no deadline. It is not
// struct{}, since vars of this type must have distinct addresses.
type emptyCtx int
func (*emptyCtx) Deadline() (deadline time.Time, ok bool) {return}
func (*emptyCtx) Done() <-chan struct{} {return nil}
func (*emptyCtx) Err() error {return nil}
func (*emptyCtx) Value(key any) any {return nil}
func (e *emptyCtx) String() string {
switch e {
case background:
return "context.Background"
case todo:
return "context.TODO"
}
return "unknown empty Context"
}
var (background = new(emptyCtx)
todo = new(emptyCtx)
)这里的 String 办法挺有意思，因为上面中能够看到 background 和 todo 都是一个 emptyContext 所以，这里间接 case 进行比照 background 和 todo；
Background 和 TODO 这两个公共办法是返回 background 和 todo；官网倡议 Background 用做顶层的 context，todo 看起来用来占位应用，不过实现来说两个没区别
// 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}
// TODO returns a non-nil, empty Context. Code should use context.TODO when
// it's unclear which Context to use or it is not yet available (because the
// surrounding function has not yet been extended to accept a Context
// parameter).
func TODO() Context {return todo}cancelCtx
通过 WithCancel 来创立的就是 cancelCtx，WithCancel 返回一个 ctx 和 cancel 办法，通过调用 cancel 办法，能够将 Context 勾销，来管制协程，具体看上面例子：
在这个例子中，通过 defer 调用 cancel，在 FixLeakingByContext 函数完结时去掉 context，在 CancelByContext 中配合 select 和 context 的 done 形式来应用，能够防止协程资源没有被回收引起的内存泄露。
func FixLeakingByContex() {
// 创立上下文用于治理子协程
ctx, cancel := context.WithCancel(context.Background())
// 完结前清理未完结协程
defer cancel()
ch := make(chan int)
go CancelByContext(ctx, ch)
go CancelByContext(ctx, ch)
go CancelByContext(ctx, ch)
// 随机触发某个子协程退出
ch <- 1
}
func CancelByContext(ctx context.Context, ch chan (int)) int {
select {case <-ctx.Done():
//fmt.Println("cancel by ctx.")
return 0
case n := <-ch :
return n
}
}看下 WithCancel 的源码：
func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
if parent == nil {panic("cannot create context from nil parent")
}
// WithCancel 通过一个父级 Context 来创立出一个 cancelCtx
c := newCancelCtx(parent)
// 调用 propagateCancel 依据父级 context 的状态来关联 cancelCtx 的 cancel 行为
propagateCancel(parent, &c)
// 返回 c 和一个办法，办法中调用 c.cancel 并传递 Canceled 变量
return &c, func() { c.cancel(true, Canceled) }
}
func newCancelCtx(parent Context) cancelCtx {return cancelCtx{Context: parent}
}
var Canceled = errors.New("context canceled")WithCancel 通过一个父级 Context 来创立出一个 cancelCtx，而后调用 propagateCancel 依据父级 context 的状态来关联 cancelCtx 的 cancel 行为（感觉这里不应该叫 propagate，冒泡个别了解是自下向上，这个函数显著是自下向上，应该叫 cascade 更为正当一些）。随后返回 c 和一个办法，办法中调用 c.cancel 并传递 Canceled 变量（其实是一个 error 实例）；
cancelCtx 是 WidthDeadline 和 WidthTimeout 的基石，所以 cancelCtx 的实现绝对简单，咱们重点解说。
newCancelCtx 办法能够看到是创立了一个 cancelCtx 实例
func newCancelCtx(parent Context) cancelCtx {return cancelCtx{Context: parent}
}咱们也看下 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 atomic.Value // of 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
}cancelCtx 有一个内嵌的 Context 类型，理论存储的都是父级上下文对象，还有四个独立的字段：
- mu：一个互斥量，用来加锁保障某些操作的线程安全性
- done：atomic.Value 一个能够对任意类型进行原子型操作的构造；提供 Load 和 Store 办法；看 Go 源码这里存的是一个 struct{} 类型的 channel
- children：一个 key 为 canceler 值为 struct{} 的 map 类型；
- err：寄存 error 的字段
这里的 cancelder 是一个接口，代表能够间接被 cancel 的 Context 类型，根本指的是 cancelCtx 和 timerCtx 两种 context，也被他俩实现
// 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{}
}上面看下 propagateCancel，据父级 context 的状态来关联 cancelCtx 的 cancel 行为
// propagateCancel arranges for child to be canceled when parent is.
func propagateCancel(parent Context, child canceler) {
// 如果父元素的 Done 办法返回为空，也就是说父 context 是 emptyCtx
// 间接返回，因为父上下文不会做任何解决
done := parent.Done()
if done == nil {return // parent is never canceled}
// 如果父上下文不是 emptyCtx 类型，应用 select 来判断一下父上下文的 done channel 是不是曾经被敞开掉了
// 敞开则调用 child 的 cancel 办法
// select 其实会阻塞，但这里给了一个 default 办法，所以如果父上下文的 done channel 没有被敞开则持续之心后续代码
// 这里相当于利用了 select 的阻塞性来做 if-else 判断
select {
case <-done:
// parent is already canceled
child.cancel(false, parent.Err())
return
default:
}
// parentCancelCtx 目标在于寻找父上下文中最底层的 cancelCtx，因为像 timerCtx 等会内嵌 cancelCtx
if p, ok := parentCancelCtx(parent); ok {
// 如果找的到，就把最内层的 cancelCtx 跟 child 的设置好关联关系
// 这里要思考到多线程环境，所以是加锁解决
p.mu.Lock()
if p.err != nil {
// 如果先人 cancelCtx 曾经被勾销了，那么也调用 child 的 cancel 办法
// parent has already been canceled
child.cancel(false, p.err)
} else {
// 这里设置内层 cancelCtx 与 child 的父子层级关系
if p.children == nil {p.children = make(map[canceler]struct{})
}
p.children[child] = struct{}{}
}
p.mu.Unlock()} else {
// 这里代表没有找到先人 cancelCtx，单启了一个协程来进行监听（因为 select 是阻塞的），如果父上下文的 done 敞开了，则子上下文勾销
// goroutines 在别的中央代码中没有应用，不晓得为什么要做减少操作，看源码英文解释也是为了测试应用
// 独自的协程会在阻塞结束后被 GC 回收，不会有泄露危险
atomic.AddInt32(&goroutines, +1)
go func() {
select {case <-parent.Done():
child.cancel(false, parent.Err())
case <-child.Done():}
}()}
}外面调用了一个 parentCancelCtx 函数，这个函数比拟艰涩，市面上材料也还没有人去认真钻研，这里我来解说一下；
这个函数中最重要的就是 12 行，通过 cancelCtxKey 获取最近的内嵌 cancelCtx；而后让在 propagateCancel 中设置内嵌 cancelCtx 与 child 的关联关系；
同时这个函数也思考了几种状况，如果 parent 的 done 曾经是 closedchan 或者是 nil 那么没必要去拿内层的 cancelCtx 来建设层级关系，间接用 parent 自身与 child 做好关联 cancel 即可。这是 9 -11 行代码干的事。
16 行 -19 行，看源码解释是如果这个内嵌 cancelCtx 可能加了一些自定义办法，比方复写了 Done 或者 cancel，那么它就不是这里的 timerCtx、cancelCtx 或者 valueCtx，这种状况下用户本人负责解决；放到 propagateCancel 这个函数中就是把 parent 和 child 间接关联起来，不建设层级关系。及时子 child 本人 cancel 也不去跟 parent 的 children 有什么关联。
// parentCancelCtx returns the underlying *cancelCtx for parent.
// It does this by looking up parent.Value(&cancelCtxKey) to find
// the innermost enclosing *cancelCtx and then checking whether
// parent.Done() matches that *cancelCtx. (If not, the *cancelCtx
// has been wrapped in a custom implementation providing a
// different done channel, in which case we should not bypass it.)
func parentCancelCtx(parent Context) (*cancelCtx, bool) {done := parent.Done()
if done == closedchan || done == nil {return nil, false}
p, ok := parent.Value(&cancelCtxKey).(*cancelCtx)
if !ok {return nil, false}
pdone, _ := p.done.Load().(chan struct{})
if pdone != done {return nil, false}
return p, true
}那么这里就有了一个问题，propagateCancel 函数中肯定建设 parent 和 child 的 children 关系么？我了解是不必的，因为这个 else 局部代码我了解齐全能够实现父级上下文完结后，child 也进行勾销；我猜这里尽量建设 children 的 map 关系，是如果不这么做就要起一个 goroutine 来解决，相当于一个监护线程，goroutine 资源的耗费以及调度老本，比单纯的 children 层级关系更大，所以这里尽力应用 map 构造来建设层级关系。这也能够看到作者在写代码时候还是很花心思去考量各种状况的。
} else {
// 这里代表没有找到先人 cancelCtx，单启了一个协程来进行监听（因为 select 是阻塞的），如果父上下文的 done 敞开了，则子上下文勾销
// goroutines 在别的中央代码中没有应用，不晓得为什么要做减少操作，看源码英文解释也是为了测试应用
// 独自的协程会在阻塞结束后被 GC 回收，不会有泄露危险
atomic.AddInt32(&goroutines, +1)
go func() {
select {case <-parent.Done():
child.cancel(false, parent.Err())
case <-child.Done():}
}()}接下来看下 cancelCtx 中 Value、Done、Err 以及公有办法 cancel 的实现；
Value 办法
源码如下
func (c *cancelCtx) Value(key any) any {
if key == &cancelCtxKey {return c}
return value(c.Context, key)
}首先要介绍下 cancelCtxKey，这是一个 context 包中的公有变量，当对 cancelCtx 调用 Value 办法并用这个 key 作为参数时，返回 cancelCtx 自身；
如果没有找到则是调用的 context 包中的公有办法 value，来在父级上下文中 key 对应的值；
这个办法首先进行类型断言，判断 Context 是否是 valueCtx、cancelCtx、timerCtx 以及 emptyCtx 等；依据不同的类型做不同解决，比方 cancelCtx 和 timerCtx 先进行 cancelCtxKey 判断，emptyCtx 间接返回 nil，valueCtx 则判断是否是本人实例化时候传入的 key，否则就去本人的内层 context 也就是 parent 层级上冒泡获取对应的值。
func value(c Context, key any) any {
for {switch ctx := c.(type) {
case *valueCtx:
if key == ctx.key {return ctx.val}
c = ctx.Context
case *cancelCtx:
if key == &cancelCtxKey {return c}
c = ctx.Context
case *timerCtx:
if key == &cancelCtxKey {return &ctx.cancelCtx}
c = ctx.Context
case *emptyCtx:
return nil
default:
return c.Value(key)
}
}
}Done 办法
func (c *cancelCtx) Done() <-chan struct{} {
// 返回 atomic.Value 中存储的值
d := c.done.Load()
if d != nil {
// atomic.Value 类型的 Load 办法返回的是 ifaceWords 类型，所以这里是利用了类型断言
// 把 ifaceWords 类型转换为 struct 类型的 chan
return d.(chan struct{})
}
// 这里是并发场景要思考的问题，因为会存在多个线程并发进行的过程，所以不肯定哪个 goroutine 就对 c.done 进行了批改
// 所以这里不能间接像单线程一样，if d！=nil else。。。；首先得抢锁。c.mu.Lock()
defer c.mu.Unlock()
d = c.done.Load()
// 下面抢锁的过程可能抢到了，也可能没抢到，所以到这里是抢到了锁，然而 c.done 未必还是 nil；// 所以这里要再次做判断
if d == nil {d = make(chan struct{})
c.done.Store(d)
}
return d.(chan struct{})
}看到下面锁的过程，发现并发状况的解决要比 js 这种单线程思考的多得多。并发对一个变量的解决不能简略的 if-else；要联合锁、CAS、原子操作一起思考（对于 atomic.Value 中的 ifaceWords 的局部能够看这篇文章：https://www.cnblogs.com/dojo-… 中原子操作局部）。
Err 办法
func (c *cancelCtx) Err() error {c.mu.Lock()
err := c.err
c.mu.Unlock()
return err
}这个办法比较简单只是获取了 cancelCtx 的 err 属性，这个属性在 cancel 中会会被设置。
cancel 办法
func (c *cancelCtx) cancel(removeFromParent bool, err error) {
if err == nil {panic("context: internal error: missing cancel error")
}
// 因为前面要对 c.err 和 c.done 进行更新，所以这里要抢锁
c.mu.Lock()
if c.err != nil {
// if 这部分放到锁的内部是否能够？看起来是能够的，然而如果放到里面，if 判断不通过此时 c.err 为 nil
// 接着进行抢锁，那么在抢到锁之后依然要对 c.err 判断是否还是 nil，能力进行更新
// 因为在抢锁过程中，可能 c.err 曾经被某个协程批改了
// 所以把这部分放到锁之后是正当的。c.mu.Unlock()
return // already canceled
}
c.err = err // 赋值
d, _ := c.done.Load().(chan struct{})
// 读取 done 的值
if d == nil {
// 如果 done 为 nil，就把一个外部的 closedchan 存入 c.done 中；// closedchan 是一个 channel 类型，在 context 包的 init 函数中就会把它 close 掉
c.done.Store(closedchan)
} else {close(d)
}
// 遍历 c 的 children 调用他们的 cancel；for child := range c.children {
// NOTE: acquiring the child's lock while holding parent's lock.
child.cancel(false, err)
}
c.children = nil
c.mu.Unlock()
// 这部分没有在锁的代码中，是因为函数中会本人加锁？if removeFromParent {removeChild(c.Context, c)
}
}代码最初调用 removeChild 办法，这部分为什么没在 c.mu 锁中，我猜是因为这个函数的代码本人会进行锁的解决。
// removeChild removes a context from its parent.
func removeChild(parent Context, child canceler) {p, ok := parentCancelCtx(parent)
if !ok {return}
p.mu.Lock()
if p.children != nil {delete(p.children, child)
}
p.mu.Unlock()}能够看到代码中的锁局部，是在第 7 行开始的，那么为什么 parentCancelCtx 没有被蕴含在锁中，这里猜想下，因为 parentCancelCtx 的次要目标是为了获取父级上下文内层的 cancelCtx，而这个值是在实例化时候就曾经确定的，这里只是读取所以能够不必放在互斥锁的临界区代码中，防止性能节约。
接下来就是 p.mu 来抢锁，实现对层级构造的接触。
timerCtx
WithTimeout 和 WithDeadline 创立的都是 timerCtx，timerCtx 外部内嵌了 cancelCtx；
type timerCtx struct {
cancelCtx
timer *time.Timer // Under cancelCtx.mu.
deadline time.Time
}因为内嵌了 cancelCtx，而 cancelCtx 实现了 Done、Value、Err 以及 cancel（公有）办法，所以 timerCtx 上也能够间接调用这几个办法（http://c.biancheng.net/view/7…）；cancelCtx 并未实现 Deadline 办法，然而 emptyCtx 实现了，如果他的父级上下文是 emptyCtx 那么 cancelCtx 也能够调用 Deadline 办法。
看完 cancelCtx 的办法之后，比照起来 timerCtx 的办法都比较简单，不做过多解释
func (c *timerCtx) Deadline() (deadline time.Time, ok bool) {return c.deadline, true}
func (c *timerCtx) String() string {return contextName(c.cancelCtx.Context) + ".WithDeadline(" +
c.deadline.String() + "[" +
time.Until(c.deadline).String() + "])"
}
func (c *timerCtx) cancel(removeFromParent bool, err error) {c.cancelCtx.cancel(false, err)
if removeFromParent {
// Remove this timerCtx from its parent cancelCtx's children.
removeChild(c.cancelCtx.Context, c)
}
c.mu.Lock()
if c.timer != nil {c.timer.Stop()
c.timer = nil
}
c.mu.Unlock()}能够看到 cancel 办法中先调用了内嵌的 cancelCtx 的 cancel 办法；而后利用 cancelCtx 的互斥锁抢锁来对 c.timer 进行操作批改；cancel 办法第 13-16 行须要留神，因为 withDeadline 在创立时把 parent 和 timerCtx 建设了层级关系，所以这里依据条件进行移除操作。
上面来看下 withDeadline 函数：
func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) {
if parent == nil {panic("cannot create context from nil parent")
}
// 如果 parent 的 deadline 小于以后工夫，间接创立 cancelCtx，外面会调用 propagateCancel 办法
// 来依据父上下文状态进行解决
if cur, ok := parent.Deadline(); ok && cur.Before(d) {
// The current deadline is already sooner than the new one.
return WithCancel(parent)
}
// 创立 timerCtx，这里能够看到 cancelCtx 是公有变量，而 cancelCtx 中的 Context 字段是私有变量
c := &timerCtx{cancelCtx: newCancelCtx(parent),
deadline: d,
}
// 设置层级勾销关联
propagateCancel(parent, c)
dur := time.Until(d)
// 如果曾经超时间接勾销
if dur <= 0 {c.cancel(true, DeadlineExceeded) // deadline has already passed
return c, func() { c.cancel(false, Canceled) }
}
c.mu.Lock()
defer c.mu.Unlock()
// 如果没有超时并且没有被调用过 cancel，那么设置 timer，超时则调用 cancel 办法；if c.err == nil {c.timer = time.AfterFunc(dur, func() {c.cancel(true, DeadlineExceeded)
})
}
return c, func() { c.cancel(true, Canceled) }
}理解下面内容之后，WithTimeout 就很简略了，只是调用了 WidthDeadline 办法
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {return WithDeadline(parent, time.Now().Add(timeout))
}valeCtx
这个构造体绝对简略，有一个 Context 公共变量，一个任意类型的 key 和任意类型的 any：
type valueCtx struct {
Context
key, val any
}withValue 办法也比较简单，这里就不做过多介绍
func WithValue(parent Context, key, val any) 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}
}还有一个 Value 办法：
如果 key 与 WithValue 调用时雷同，则返回对应的 val，否则进入 value 办法，在内嵌的 Context 中查找 key 对应的值，这个办法下面介绍过，依据 Context 类型先做一些类型判断，来判断一些要害的 key 如 cancelCtxKey，不然持续在内嵌 Context 中查找。
func (c *valueCtx) Value(key any) any {
if c.key == key {return c.val}
return value(c.Context, key)
}参考资料
本文大量援用了相干参考资料的图片和语言，尤其是 CPU 硬件局部图片大部分来自于小林 coding（https://xiaolincoding.com/os/…）的图片。版权问题请与我分割，侵删。
深刻了解 Go Context：https://article.itxueyuan.com…
context 源码：https://github.com/golang/go/…
聊一聊 Go 的 Context 上下文：https://studygolang.com/artic…
go context 详解：https://www.cnblogs.com/juanm…
Go 语言 Context（上下文）：http://c.biancheng.net/view/5…
atomic 原理以及实现：https://blog.csdn.net/u010853…
atomic 前世今生：https://blog.betacat.io/post/…