关于golang:golang-context源码学习

golang context源码学习

应用实例

context设置超时的例子

func main() {
    ctx, cancel := context.WithTimeout(context.Background(), 1*time.Second)
    defer cancel()

    go handle(ctx, 1500*time.Millisecond)
    select {
    case <-ctx.Done():
        fmt.Println("main", ctx.Err())
    }

    time.Sleep(3 * time.Second)
}

func handle(ctx context.Context, duration time.Duration) {
    select {
    case <-ctx.Done():
        fmt.Println("handle", ctx.Err())
    case <-time.After(duration):
        fmt.Println("process request with", duration)
    }
}

输入:

main context deadline exceeded
handle context deadline exceeded

Context设置的超时工夫是1s,然而解决工夫是1.5s,最初必定会触发超时,在handle协程里,time.After会在程序启动1.5s之后返回音讯,而ctx.Done()会在1s当前返回音讯,time.After没有机会被捕捉到,handle协程就退出了;而主协程同样也能捕捉到ctx.Done里的音讯。

context的应用办法和设计原理多个 Goroutine 同时订阅 ctx.Done() 管道中的音讯,一旦接管到勾销信号就立即进行以后正在执行的工作。

源码解析

context.Context接口

type Context interface{
    Deadline() (deadline time.Time, ok bool)
    Done() <-chan struct{}
    Err() error
    Value(key interface{}) interface{} 
}

Context接口定了四个办法:

  • Deadline()会返回这个context终止时的工夫以及是否被设置了超时。
  • Done()会返回一个只读管道,通常须要内部有select语句来监听这个管道,若是context被cancel掉,那么通过该接口可能获取到音讯,没被cancel时,会始终阻塞在context.Done()的读取上。这里的cancel指WithCancel,WithDeadline,WithTimeout触发的cancel。
  • 若ctx没被cancel掉,Err()只会返回nil,若被cancel掉则会返回为何被cancel,例如deadline。
  • Value()接口是用来存值的,在后续的context中能够将其取出。

context.Background(),context.TODO()

context.Background()和context.TODO()会返回一个雷同的构造体,即emptyCtx。

var (
    background = new(emptyCtx)
    todo       = new(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 interface{}) interface{} {
    return nil
}

即它没有对Context进行任何的实现。

  • Background()返回的context通常作为整个context调用链的根context。
  • TODO()返回的context通常是在重构或编码过程中应用,不确定会如何应用

Context参数,但用其作为占位符,TODO的标识便于后续代码实现时能疾速查看到这个未实现的占位符,以便将其实现。

context.WithCancel()

func WithCancel(parent Context) (ctx Context, cancel CancelFunc)

从函数签名能够看出,WithCancel会返回一个设置了cancel的context和一个勾销函数,这个返回的context的Done管道会被敞开,当父context的Done管道被敞开时或者勾销函数被调用时。

创立一个cancelCtx

c := newCancelCtx(parent)
// newCancelCtx returns an initialized 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     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勾销时,会将后辈节点中所有的cancelCtx都勾销,propagateCancel即用来建设以后节点与先人节点这个勾销关联逻辑。

propagateCancel(parent, &c)

为啥须要建设与先人的关联逻辑呢?后续会提到。

留神,propagateCancel的第二个参数是一个canceler接口,由定义可知:

// 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{}
}

这个接口由两种带有勾销性质的ctx实现(cancelCtx和timerCtx)

  • 第一个办法是cancel,由参数能够知它会将本身勾销掉,若第一个参数为true,则会从父ctx中删除掉本人
  • 第二个办法会间接返回一个Done管道
// propagateCancel arranges for child to be canceled when parent is.
func propagateCancel(parent Context, child canceler) {
    if parent.Done() == nil {
        return // parent is never canceled
    } //如果parent的Done管道是空,阐明该父context永远不会被勾销,通常是emptyCtx,那么不必建设该ctx与先人ctx的关系

    if p, ok := parentCancelCtx(parent); ok {//当其父context为cancel性质的context(timerCtx或cancelCtx)会返回true和这个cancelCtx,若为valueCtx则会由context向上查找直到找到一个cancel性质的ctx;否则返回false

        //父ctx为cancel性质的ctx

          //加锁
        p.mu.Lock()
        if p.err != nil {
            // parent has already been canceled
              //父ctx曾经被cancel掉了,所以该子ctx将会间接调用cancel办法cancel掉本人。
            //这样,尽管之后给内部调用返回了一个cancel函数,然而因为在child.cancel中曾经设置了c.err,所以之后内部再调用cancel,cancelCtx的cancel办法也不会再做别的操作了,发现c.err不为nil,间接return,代表曾经被cancel掉了
            child.cancel(false, p.err)
        } else {
              //否则把本人退出到先人cancelCtx的children中
            if p.children == nil {
                p.children = make(map[canceler]struct{})
            }
            p.children[child] = struct{}{}
        }
        p.mu.Unlock()
    } else {
        //父context不为cancelCtx,则起一个后盾协程,监听父ctx和以后ctx的Done管道,直到有ctx的Done管道被敞开(ctx被勾销)
          //TODO,为何parent不为cancelCtx,还能有done信号被捕捉到???
        go func() {
            select {
            case <-parent.Done():
                   //这种状况何时会呈现?
                child.cancel(false, parent.Err())
            case <-child.Done():
            }
        }()
    }
}
  1. 如果parent.Done()返回nil,表明父节点以上的门路上没有可勾销的context,不须要解决;
  2. 如果在context链上找到到cancelCtx类型的先人节点,则判断这个先人节点是否曾经勾销,如果曾经勾销就勾销以后节点;否则将以后节点退出到先人节点的children列表。

否则开启一个协程,监听parent.Done()和child.Done(),一旦parent.Done()返回的channel敞开,即context链中某个先人节点context被勾销,则将以后context也勾销。
这里或者有个疑难,为什么是先人节点而不是父节点?这是因为以后context链可能是这样的:

以后cancelCtx的父节点context并不是一个可勾销的context,也就没法记录children。这也是为什么须要在这个函数中建设以后节点与先人cancelCtx节点的cancel关系

问题:
为什么会有

go func() {
            select {
            case <-parent.Done():
                   //这种状况何时会呈现?
                child.cancel(false, parent.Err())
            case <-child.Done():
            }
        }()

因为else中,曾经阐明了先人ctx不为可勾销的ctx,那为啥还可能捕捉到第一个case的Done管道的信号呢?

这里须要引入parentCancelCtx的代码

func parentCancelCtx(parent Context) (*cancelCtx, bool) {
    for {
        switch c := parent.(type) {
        case *cancelCtx:
            return c, true
        case *timerCtx:
            return &c.cancelCtx, true
        case *valueCtx:
            parent = c.Context
        default:
            return nil, false
        }
    }
}

这里只能判断出cancelCtx,timeCtx,valueCtx三种类型,而若是将ctx内嵌到一个自定义的构造体a中,并且之后调用了WithCancel构建了子节点b。将这个子节点再调用WithCancel构建孙节点c,此时parentCancelCtx办法是辨认不出这个b为cancelCtx的,因而须要应用else下的第一个case来捕捉b节点的Done音讯。

再来说一下,select 语句里的两个 case 其实都不能删。

select {
    case <-parent.Done():
        child.cancel(false, parent.Err())
    case <-child.Done():
}
  • 第一个 case 阐明当父节点勾销,则勾销子节点。如果去掉这个 case,那么父节点勾销的信号就不能传递到子节点。
  • 第二个 case 是说如果子节点本人勾销了,那就退出这个 select,父节点的勾销信号就不必管了。如果去掉这个 case,那么很可能父节点始终不勾销,这个 goroutine 就透露了。当然,如果父节点勾销了,就会反复让子节点勾销,不过,这也没什么影响嘛。

返回一个cancelCtx与一个cancel函数

return &c, func() { c.cancel(true, Canceled) }

这个cancel函数被内部调用时,会将本身从父节点中删除掉。并且cancel掉该节点的所有子节点:

// cancel closes c.done, cancels each of c's children, and, if
// removeFromParent is true, removes c from its parent's children.
func (c *cancelCtx) cancel(removeFromParent bool, err error) {
    if err == nil {
        panic("context: internal error: missing cancel error")
    }
    c.mu.Lock()
    if c.err != nil {
        c.mu.Unlock()
        return // already canceled
    }
    c.err = err
    if c.done == nil {
          //惰性创立,初始化时不会赋值。须要勾销时间接给一个敞开的channel
          //很有意思的是这个channel是在init里被敞开的
        c.done = closedchan
    } else {
        close(c.done)
    }

    //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()

      //何时该参数应该为true?
      //当内部调用cancel时,该参数为true
    if removeFromParent {
        removeChild(c.Context, c)
    }
}

两个问题须要答复:

  1. 什么时候会传 true?
  2. 为什么有时传 true,有时传 false?

答1:
内部调用cancel时传true,外部调用cancel时传false。
调用 WithCancel() 办法的时候,也就是新创建一个可勾销的 context 节点时,返回的 cancelFunc 函数会传入 true。这样做的后果是:当调用返回的 cancelFunc 时,会将这个 context 从它的父节点里“除名”,因为父节点可能有很多子节点,你本人勾销了,所以我要和你断绝关系,对其他人没影响

答2:
外部调用cancel时不必从父节点删除掉本身。外部调用的机会是:

1. 在建设先人与以后ctx的cancel关系时,若发现先人曾经被cancel了,这时会外部调用cancel:这种状况下,先人通常是曾经被内部调用了cancel,它曾经将其chidren置为了nil,这时就不必要再删除了;
2. 监听到先人的Done管道敞开,即先人曾经被cancel掉,这种状况和第一种状况相似,children曾经被置为了nil,不必要再删除。

context.WithTimeout()

func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) {
    return WithDeadline(parent, time.Now().Add(timeout))
}

context.WithTimeout办法底层其实是调用的WithDeadline,返回了一个带有 超时信息的context和一个勾销函数,规范用法如下:

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)
}

看一下WithDeadline的实现形式

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc)

由函数签名能够看出会返回一个带超时的context和一个勾销函数,若WithDeadline返回的context在d工夫点未被勾销,那么它的Done管道将被强制敞开。

具体实现代码:

判断父context是否曾经超时了:

if cur, ok := parent.Deadline(); ok && cur.Before(d) {
        // The current deadline is already sooner than the new one.
        return WithCancel(parent)
    }

若是父context被设置了超时,且截止工夫点要短于以后冀望设置的超时工夫的截止工夫点,那么间接基于父ctx构建一个可勾销的ctx。
起因是一旦父节点超时,主动调用 cancel 函数,子节点也会随之勾销。因而构建一个相对工夫晚于父节点的子ctx是没有意义的。

构建timerCtx

首先须要理解一下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
}

能够看到timerCtx内嵌了cancelCtx,同时它还有本人的timer和deadline。
Timer是一个定时器,当达到设定的工夫后,会向timer的管道中发一个事件。
会在 deadline 到来时,会监听到事件,这时主动勾销 context,这是在ctx的WithDeadline中做的。

看下timerCtx的cancel办法

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()
}
  1. 首先会将本人和所有子节点cancel掉;
  2. 会将本身的timer的Stop掉,避免deadline到来时再次被勾销。

构建以后ctx与先人ctx的cancel关系

propagateCancel(parent, c)

这个与之前的cancel是一样的,不再赘述。

计算以后工夫与deadline的时间差

dur := time.Until(d)
    if dur <= 0 {
        c.cancel(true, DeadlineExceeded) // deadline has already passed
        return c, func() { c.cancel(false, Canceled) }
    }

如果以后工夫曾经达到了deadline的工夫点,那么间接将其勾销,并返回。

设置timer到期的回调函数

c.mu.Lock()
    defer c.mu.Unlock()
    if c.err == nil {
        c.timer = time.AfterFunc(dur, func() {
            c.cancel(true, DeadlineExceeded)
        })
    }
    return c, func() { c.cancel(true, Canceled) }

如果timer到期后timerCtx会调用cancel勾销本人。

参考文章

https://www.zhihu.com/search?…

评论

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

这个站点使用 Akismet 来减少垃圾评论。了解你的评论数据如何被处理