深刻理解Golang之context

前言

這篇文章將介紹Golang併發編程中經常使用到一種編程模式:context。本文將從爲何須要context出發,深刻了解context的實現原理,以及瞭解如何使用contextgolang

爲何須要context

在併發程序中,因爲超時、取消操做或者一些異常狀況,每每須要進行搶佔操做或者中斷後續操做。熟悉channel的朋友應該都見過使用done channel來處理此類問題。好比如下這個例子:web

func main() {
    messages := make(chan int10)
    done := make(chan bool)

    defer close(messages)
    // consumer
    go func() {
        ticker := time.NewTicker(1 * time.Second)
        for _ = range ticker.C {
            select {
            case <-done:
                fmt.Println("child process interrupt...")
                return
            default:
                fmt.Printf("send message: %d\n", <-messages)
            }
        }
    }()

    // producer
    for i := 0; i < 10; i++ {
        messages <- i
    }
    time.Sleep(5 * time.Second)
    close(done)
    time.Sleep(1 * time.Second)
    fmt.Println("main process exit!")
}
複製代碼

上述例子中定義了一個buffer爲0的channel done, 子協程運行着定時任務。若是主協程須要在某個時刻發送消息通知子協程中斷任務退出,那麼就可讓子協程監聽這個done channel,一旦主協程關閉done channel,那麼子協程就能夠推出了,這樣就實現了主協程通知子協程的需求。這很好,可是這也是有限的。編程

若是咱們能夠在簡單的通知上附加傳遞額外的信息來控制取消:爲何取消,或者有一個它必需要完成的最終期限,更或者有多個取消選項,咱們須要根據額外的信息來判斷選擇執行哪一個取消選項。安全

考慮下面這種狀況:假如主協程中有多個任務1, 2, …m,主協程對這些任務有超時控制;而其中任務1又有多個子任務1, 2, …n,任務1對這些子任務也有本身的超時控制,那麼這些子任務既要感知主協程的取消信號,也須要感知任務1的取消信號。網絡

若是仍是使用done channel的用法,咱們須要定義兩個done channel,子任務們須要同時監聽這兩個done channel。嗯,這樣其實好像也還行哈。可是若是層級更深,若是這些子任務還有子任務,那麼使用done channel的方式將會變得很是繁瑣且混亂。併發

咱們須要一種優雅的方案來實現這樣一種機制:app

  • 上層任務取消後,全部的下層任務都會被取消;
  • 中間某一層的任務取消後,只會將當前任務的下層任務取消,而不會影響上層的任務以及同級任務。

這個時候context就派上用場了。咱們首先看看context的結構設計和實現原理。函數

context是什麼

context接口

先看Context接口結構,看起來很是簡單。post

type Context interface {

    Deadline() (deadline time.Time, ok bool)

    Done() <-chan struct{}

    Err() error

    Value(key interface{}) interface{}
}
複製代碼

Context接口包含四個方法:測試

  • Deadline返回綁定當前context的任務被取消的截止時間;若是沒有設按期限,將返回ok == false
  • Done 當綁定當前context的任務被取消時,將返回一個關閉的channel;若是當前context不會被取消,將返回nil
  • Err 若是Done返回的channel沒有關閉,將返回nil;若是Done返回的channel已經關閉,將返回非空的值表示任務結束的緣由。若是是context被取消,Err將返回Canceled;若是是context超時,Err將返回DeadlineExceeded
  • Value 返回context存儲的鍵值對中當前key對應的值,若是沒有對應的key,則返回nil

能夠看到Done方法返回的channel正是用來傳遞結束信號以搶佔並中斷當前任務;Deadline方法指示一段時間後當前goroutine是否會被取消;以及一個Err方法,來解釋goroutine被取消的緣由;而Value則用於獲取特定於當前任務樹的額外信息。而context所包含的額外信息鍵值對是如何存儲的呢?其實能夠想象一顆樹,樹的每一個節點可能攜帶一組鍵值對,若是當前節點上沒法找到key所對應的值,就會向上去父節點裏找,直到根節點,具體後面會說到。

再來看看context包中的其餘關鍵內容。

emptyCtx

emptyCtx是一個int類型的變量,但實現了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 interface{}) interface{} {
    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)
)

func Background() Context {
    return background
}

func TODO() Context {
    return todo
}
複製代碼

但咱們通常不會直接使用emptyCtx,而是使用由emptyCtx實例化的兩個變量,分別能夠經過調用BackgroundTODO方法獲得,但這兩個context在實現上是同樣的。那麼BackgroundTODO方法獲得的context有什麼區別呢?能夠看一下官方的解釋:

// 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.

// 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).
複製代碼

BackgroundTODO只是用於不一樣場景下:
Background一般被用於主函數、初始化以及測試中,做爲一個頂層的context,也就是說通常咱們建立的context都是基於Background;而TODO是在不肯定使用什麼context的時候纔會使用。

下面將介紹兩種不一樣功能的基礎context類型:valueCtxcancelCtx

valueCtx

valueCtx結構體
type valueCtx struct {
    Context
    key, val interface{}
}

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

valueCtx利用一個Context類型的變量來表示父節點context,因此當前context繼承了父context的全部信息;valueCtx類型還攜帶一組鍵值對,也就是說這種context能夠攜帶額外的信息。valueCtx實現了Value方法,用以在context鏈路上獲取key對應的值,若是當前context上不存在須要的key,會沿着context鏈向上尋找key對應的值,直到根節點。

WithValue

WithValue用以向context添加鍵值對:

func WithValue(parent Context, key, val interface{}) Context {
    if key == nil {
        panic("nil key")
    }
    if !reflect.TypeOf(key).Comparable() {
        panic("key is not comparable")
    }
    return &valueCtx{parent, key, val}
}
複製代碼

這裏添加鍵值對不是在原context結構體上直接添加,而是以此context做爲父節點,從新建立一個新的valueCtx子節點,將鍵值對添加在子節點上,由此造成一條context鏈。獲取value的過程就是在這條context鏈上由尾部上前搜尋:

cancelCtx

cancelCtx結構體
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
}

type canceler interface {
    cancel(removeFromParent bool, err error)
    Done() <-chan struct{}
}
複製代碼

valueCtx相似,cancelCtx中也有一個context變量做爲父節點;變量done表示一個channel,用來表示傳遞關閉信號;children表示一個map,存儲了當前context節點下的子節點;err用於存儲錯誤信息表示任務結束的緣由。

再來看一下cancelCtx實現的方法:

func (c *cancelCtx) Done() <-chan struct{} {
    c.mu.Lock()
    if c.done == nil {
        c.done = make(chan struct{})
    }
    d := c.done
    c.mu.Unlock()
    return d
}

func (c *cancelCtx) Err() error {
    c.mu.Lock()
    err := c.err
    c.mu.Unlock()
    return err
}

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
    設置一個關閉的channel或者將done channel關閉,用以發送關閉信號
    if c.done == nil {
        c.done = closedchan
    } else {
        close(c.done)
    }
    // 將子節點context依次取消
    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 {
        // 將當前context節點從父節點上移除
        removeChild(c.Context, c)
    }
}
複製代碼

能夠發現cancelCtx類型變量其實也是canceler類型,由於cancelCtx實現了canceler接口。
Done方法和Err方法不必說了,cancelCtx類型的context在調用cancel方法時會設置取消緣由,將done channel設置爲一個關閉channel或者關閉channel,而後將子節點context依次取消,若是有須要還會將當前節點從父節點上移除。

WithCancel

WithCancel函數用來建立一個可取消的context,即cancelCtx類型的contextWithCancel返回一個context和一個CancelFunc,調用CancelFunc便可觸發cancel操做。直接看源碼:

type CancelFunc func()

func WithCancel(parent Context) (ctx Context, cancel CancelFunc)
 {
    c := newCancelCtx(parent)
    propagateCancel(parent, &c)
    return &c, func() { c.cancel(true, Canceled) }
}

// newCancelCtx returns an initialized cancelCtx.
func newCancelCtx(parent Context) cancelCtx {
    // 將parent做爲父節點context生成一個新的子節點
    return cancelCtx{Context: parent}
}

func propagateCancel(parent Context, child canceler) {
    if parent.Done() == nil {
        // parent.Done()返回nil代表父節點以上的路徑上沒有可取消的context
        return // parent is never canceled
    }
    // 獲取最近的類型爲cancelCtx的祖先節點
    if p, ok := parentCancelCtx(parent); ok {
        p.mu.Lock()
        if p.err != nil {
            // parent has already been canceled
            child.cancel(false, p.err)
        } else {
            if p.children == nil {
                p.children = make(map[canceler]struct{})
            }
            // 將當前子節點加入最近cancelCtx祖先節點的children中
            p.children[child] = struct{}{}
        }
        p.mu.Unlock()
    } else {
        go func() {
            select {
            case <-parent.Done():
                child.cancel(false, parent.Err())
            case <-child.Done():
            }
        }()
    }
}

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 nilfalse
        }
    }
}
複製代碼

以前說到cancelCtx取消時,會將後代節點中全部的cancelCtx都取消,propagateCancel即用來創建當前節點與祖先節點這個取消關聯邏輯。

  1. 若是parent.Done()返回nil,代表父節點以上的路徑上沒有可取消的context,不須要處理;
  2. 若是在context鏈上找到到cancelCtx類型的祖先節點,則判斷這個祖先節點是否已經取消,若是已經取消就取消當前節點;不然將當前節點加入到祖先節點的children列表。
  3. 不然開啓一個協程,監聽parent.Done()child.Done(),一旦parent.Done()返回的channel關閉,即context鏈中某個祖先節點context被取消,則將當前context也取消。

這裏或許有個疑問,爲何是祖先節點而不是父節點?這是由於當前context鏈多是這樣的:

當前cancelCtx的父節點context並非一個可取消的context,也就無法記錄children

timerCtx

timerCtx是一種基於cancelCtxcontext類型,從字面上就能看出,這是一種能夠定時取消的context

type timerCtx struct {
    cancelCtx
    timer *time.Timer // Under cancelCtx.mu.

    deadline time.Time
}

func (c *timerCtx) Deadline() (deadline time.Time, ok bool) {
    return c.deadline, true
}

func (c *timerCtx) cancel(removeFromParent bool, err error) {
    將內部的cancelCtx取消
    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()
}
複製代碼

timerCtx內部使用cancelCtx實現取消,另外使用定時器timer和過時時間deadline實現定時取消的功能。timerCtx在調用cancel方法,會先將內部的cancelCtx取消,若是須要則將本身從cancelCtx祖先節點上移除,最後取消計時器。

WithDeadline

WithDeadline返回一個基於parent的可取消的context,而且其過時時間deadline不晚於所設置時間d

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) {
    if cur, ok := parent.Deadline(); ok && cur.Before(d) {
        // The current deadline is already sooner than the new one.
        return WithCancel(parent)
    }
    c := &timerCtx{
        cancelCtx: newCancelCtx(parent),
        deadline:  d,
    }
    // 創建新建context與可取消context祖先節點的取消關聯關係
    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()
    if c.err == nil {
        c.timer = time.AfterFunc(dur, func() {
            c.cancel(true, DeadlineExceeded)
        })
    }
    return c, func() { c.cancel(true, Canceled) }
}
複製代碼
  1. 若是父節點parent有過時時間而且過時時間早於給定時間d,那麼新建的子節點context無需設置過時時間,使用WithCancel建立一個可取消的context便可;
  2. 不然,就要利用parent和過時時間d建立一個定時取消的timerCtx,並創建新建context與可取消context祖先節點的取消關聯關係,接下來判斷當前時間距離過時時間d的時長dur
  • 若是dur小於0,即當前已通過了過時時間,則直接取消新建的timerCtx,緣由爲DeadlineExceeded
  • 不然,爲新建的timerCtx設置定時器,一旦到達過時時間即取消當前timerCtx
WithTimeout

WithDeadline相似,WithTimeout也是建立一個定時取消的context,只不過WithDeadline是接收一個過時時間點,而WithTimeout接收一個相對當前時間的過時時長timeout:

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

context的使用

首先使用context實現文章開頭done channel的例子來示範一下如何更優雅實現協程間取消信號的同步:

func main() {
    messages := make(chan int10)

    // producer
    for i := 0; i < 10; i++ {
        messages <- i
    }

    ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)

    // consumer
    go func(ctx context.Context) {
        ticker := time.NewTicker(1 * time.Second)
        for _ = range ticker.C {
            select {
            case <-ctx.Done():
                fmt.Println("child process interrupt...")
                return
            default:
                fmt.Printf("send message: %d\n", <-messages)
            }
        }
    }(ctx)

    defer close(messages)
    defer cancel()

    select {
    case <-ctx.Done():
        time.Sleep(1 * time.Second)
        fmt.Println("main process exit!")
    }
}
複製代碼

這個例子中,只要讓子線程監聽主線程傳入的ctx,一旦ctx.Done()返回空channel,子線程便可取消執行任務。但這個例子還沒法展示context的傳遞取消信息的強大優點。

閱讀過net/http包源碼的朋友可能注意到在實現http server時就用到了context, 下面簡單分析一下。

一、首先Server在開啓服務時會建立一個valueCtx,存儲了server的相關信息,以後每創建一條鏈接就會開啓一個協程,並攜帶此valueCtx

func (srv *Server) Serve(l net.Listener) error {

    ...

    var tempDelay time.Duration     // how long to sleep on accept failure
    baseCtx := context.Background() // base is always background, per Issue 16220
    ctx := context.WithValue(baseCtx, ServerContextKey, srv)
    for {
        rw, e := l.Accept()

        ...

        tempDelay = 0
        c := srv.newConn(rw)
        c.setState(c.rwc, StateNew) // before Serve can return
        go c.serve(ctx)
    }
}
複製代碼

二、創建鏈接以後會基於傳入的context建立一個valueCtx用於存儲本地地址信息,以後在此基礎上又建立了一個cancelCtx,而後開始從當前鏈接中讀取網絡請求,每當讀取到一個請求則會將該cancelCtx傳入,用以傳遞取消信號。一旦鏈接斷開,便可發送取消信號,取消全部進行中的網絡請求。

func (c *conn) serve(ctx context.Context) {
    c.remoteAddr = c.rwc.RemoteAddr().String()
    ctx = context.WithValue(ctx, LocalAddrContextKey, c.rwc.LocalAddr())
    ...

    ctx, cancelCtx := context.WithCancel(ctx)
    c.cancelCtx = cancelCtx
    defer cancelCtx()

    ...

    for {
        w, err := c.readRequest(ctx)

        ...

        serverHandler{c.server}.ServeHTTP(w, w.req)

        ...
    }
}
複製代碼

三、讀取到請求以後,會再次基於傳入的context建立新的cancelCtx,並設置到當前請求對象req上,同時生成的response對象中cancelCtx保存了當前context取消方法。

func (c *conn) readRequest(ctx context.Context) (w *response, err error) {

    ...

    req, err := readRequest(c.bufr, keepHostHeader)

    ...

    ctx, cancelCtx := context.WithCancel(ctx)
    req.ctx = ctx

    ...

    w = &response{
        conn:          c,
        cancelCtx:     cancelCtx,
        req:           req,
        reqBody:       req.Body,
        handlerHeader: make(Header),
        contentLength: -1,
        closeNotifyCh: make(chan bool1),

        // We populate these ahead of time so we're not
        // reading from req.Header after their Handler starts
        // and maybe mutates it (Issue 14940)
        wants10KeepAlive: req.wantsHttp10KeepAlive(),
        wantsClose:       req.wantsClose(),
    }

    ...
    return w, nil
}
複製代碼

這樣處理的目的主要有如下幾點:

  • 一旦請求超時,便可中斷當前請求;

  • 在處理構建response過程當中若是發生錯誤,可直接調用response對象的cancelCtx方法結束當前請求;

  • 在處理構建response完成以後,調用response對象的cancelCtx方法結束當前請求。

在整個server處理流程中,使用了一條context鏈貫穿ServerConnectionRequest,不只將上游的信息共享給下游任務,同時實現了上游可發送取消信號取消全部下游任務,而下游任務自行取消不會影響上游任務。

總結

context主要用於父子任務之間的同步取消信號,本質上是一種協程調度的方式。另外在使用context時有兩點值得注意:上游任務僅僅使用context通知下游任務再也不須要,但不會直接干涉和中斷下游任務的執行,由下游任務自行決定後續的處理操做,也就是說context的取消操做是無侵入的;context是線程安全的,由於context自己是不可變的(immutable),所以能夠放心地在多個協程中傳遞使用。

參考資料

一、Package context

二、Go Concurrency Patterns: Context

三、Understanding the context package in golang

相關文章
相關標籤/搜索