关于go:Go-Context原理详解

这篇文章是答复交换时一个老哥的问题，跟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 intfunc (*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/...