golang從context原始碼領悟介面的設計

peng發表於2019-07-26

注:寫帖子時go的版本是1.12.7
go語言中實現一個interface不用像其他語言一樣需要顯示的宣告實現介面。go語言只要實現了某interface的方法就可以做型別轉換。go語言沒有繼承的概念,只有Embedding的概念。想深入學習這些用法,閱讀原始碼是最好的方式.Context的原始碼非常推薦閱讀,從中可以領悟出go語言介面設計的精髓。

對外暴露Context介面

Context原始碼中只對外顯露出一個Context介面

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

對於Context的實現原始碼裡有一個最基本的實現,就是私有的emptyCtx,他也就是我們經常使用的context.Background()底層的實現,他是一個int型別,實現了Context介面的所有方法,但都是沒有做任何處理,都是返回的預設空值。只有String()方法,裡有幾行程式碼,去判斷emptyCtx的型別來進行相應的字串輸出,String()方法其實是實現了介面StringeremptyCtx是整個Context靈魂,為什麼這麼說,因為你對context的所有的操作都是基於他去做的再次封裝。
注意一下Value(key interface{}) interface{} ,因為還沒有泛型,所以能用的做法就是傳遞或者返回interface{}。不知道Go2會不會加入泛型,說是會加入,但是還沒有出最終版,一切都是未知的,因為前一段時間還說會加入try,後來又宣佈放棄。

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

在使用Context時我們能直接得到就是backgroundtodo

func Background() Context {
    return background
}
func TODO() Context {
    return todo
}

其他所有對外公開的方法都必須傳入一個Context做為parent,這裡設計的很巧妙,為什麼要有parent後面我會詳細說。

可以cancel掉的Context

可以cancel掉的context有三個公開的方法,也就是,是否帶過期時間的Context

func WithCancel(parent Context) (ctx Context, cancel CancelFunc)
func WithDeadline(parent Context, d time.Time) (Context, CancelFunc)
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc)

Context只用關心自己是否Done(),具體這個是怎麼完成的他並不關心,是否可以cancel掉也不是他的業務,所以原始碼中把這部分功能分開來。
Context最常用的功能就是去監控他的Done()是否已完成,然後判斷完成的原因,根據自己的業務展開相應的操作。要提一下Context是執行緒安全的,他在必要的地方都加了鎖處理。Done()的原理:其實是close掉了channel所以所有監控Done()方法都能知道這個Context執行完了。

ctx, cancel := context.WithTimeout(ctx, 100*time.Millisecond)
defer cancel()
v, err := DoSomething(ctx)
if err != nil {
    return err
}
select {
case <-ctx.Done():
    return ctx.Err()
case out <- v:
}

我這裡不綴述Context是如何使用的。這篇帖子主要分析的是原始碼。
Context可以被cancel掉需要考慮幾個問題:

  • 如何處理父或子Contextcancel
  • cancelContext是否也應該刪除掉。

我們從原始碼中來找到答案。
看一下canceler的介面,這是一個獨立的私有介面,和Context介面獨立開來,Context只做自己的事,並不用關心自己有啥附加的功能,比如現在說的cancel功能,這也是一個很好的例子,如果有需要對Context進行擴充套件,可以參考他們的程式碼。

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

和兩個錯誤

var Canceled = errors.New("context canceled")
var DeadlineExceeded error = deadlineExceededError{}

是個是被主動Cancel的錯誤和一個超時的錯誤,這兩個錯誤是對外顯露的,我們也是根據這兩個Error判斷Done()是如何完成的。
實現canceler介面的是結構體cancelCtx

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

注意:cancelCtxContext介面Embedding進去了,也就是說cancelCtx多重實現介面,不但是個canceler型別也是一個Context型別。
原始碼中cancelCtx並沒有實現Context介面中的所有的方法,這就是Embedding的強大之處,Context介面的具體實現都是外部傳進來的具體Context實現型別來實現的eg: cancelCtx{Context: xxxx}
還要注意一點就是這兩個介面都有各自的Done()方法,cancelCtx有實現自己的Done()方法,也就是說無論轉換成canceler介面型別還是Context型別呼叫Done()方法時,都是他自己的實現

cancelCtx 為基礎還有一個是帶過期時間的實現timerCtx

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

    deadline time.Time
}

timerCtxWithDeadlineWithTimeout方法的基礎。

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

WithCancel 需要呼叫者主動去呼叫cancel,其他的兩個,就是有過期時間,如果不主動去呼叫cancel到了過期時間系統會自動呼叫。

上面我有說過context包中Background()TODO()方法,是其他所有公開方法的基礎,因為其他所有的公開方法都需要傳遞進來一個Context介面做為parent。這樣我們所有建立的新的Context都是以parent為基礎來進行封裝和操作

看一下cancelCtx的是如何初始化的

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

propagateCancel回答了我們第一個問題

如何處理父或子Contextcancel

func propagateCancel(parent Context, child canceler) {
    if parent.Done() == nil {
        return // parent is never canceled
    }
    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{})
            }
            p.children[child] = struct{}{}
        }
        p.mu.Unlock()
    } else {
        go func() {
            select {
            case <-parent.Done():
                child.cancel(false, parent.Err())
            case <-child.Done():
            }
        }()
    }
}

propagateCancel做了以下幾件事

  1. 檢查parent是否可以cancel
  2. 檢查parent是否是cancelCtx型別
    2.1. 如果是,再檢查是否已經cancel掉,是則cancel掉child,否則加入child
    2.2. 如果不是,則監控parentchild 的Done()

我們看一下timerCtx的具體實現

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 {
        c.done = closedchan
    } else {
        close(c.done)
    }
    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)
    }
}

我們去檢視所有對cancel的呼叫會發現

func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
    c := newCancelCtx(parent)
    propagateCancel(parent, &c)
    return &c, func() { c.cancel(true, Canceled) }
}
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,
    }
    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) }
}

返回的cancel方法都是func() { c.cancel(true, Canceled) }

回答了我們的第二個問題

cancelContext是否也應該刪除掉。
所有建立的可以cancel掉的方法都會被從parent上刪除掉

儲存key/value資訊的Context

Context還有一個功能就是儲存key/value的資訊,從原始碼中我們可以看出一個Context只能儲存一對,但是我們可以呼叫多次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} }
在查詢key的時候,是一個向上遞迴的過程:
func (c *valueCtx) Value(key interface{}) interface{} { if c.key == key { return c.val } return c.Context.Value(key) }
總結一下

  • 介面要有邊界,要簡潔。
  • 對外公開的部分要簡單明瞭。
  • 提煉邊界方法和輔助實現部分,隱藏細節。

相關文章