golang從context源碼領悟接口的設計

時間  2019-11-06
標籤 golang context 源碼 領悟 接口 設計 欄目 Go 简体版
原文   原文鏈接

注：寫帖子時go的版本是1.12.7 Context的github地址
go語言中實現一個interface不用像其餘語言同樣須要顯示的聲明實現接口。go語言只要實現了某interface的方法就能夠作類型轉換。go語言沒有繼承的概念，只有Embedding的概念。想深刻學習這些用法，閱讀源碼是最好的方式.Context的源碼很是推薦閱讀，從中能夠領悟出go語言接口設計的精髓。git

對外暴露Context接口

Context源碼中只對外顯露出一個Context接口github

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()方法實際上是實現了接口Stringer。emptyCtx是整個Context的靈魂，爲何這麼說，由於你對context的全部的操做都是基於他去作的再次封裝。
注意一下Value(key interface{}) interface{} ,由於尚未泛型，因此能用的作法就是傳遞或者返回interface{}。不知道Go2會不會加入泛型，說是會加入，可是尚未出最終版，一切都是未知的，由於前一段時間還說會加入try,後來又宣佈放棄。golang

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時咱們能直接獲得就是background和todo安全

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

其餘全部對外公開的方法都必須傳入一個Context作爲parent,這裏設計的很巧妙，爲何要有parent後面我會詳細說。學習

能夠cancel掉的Context

能夠cancel掉的context有三個公開的方法，也就是，是否帶過時時間的Contextui

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掉須要考慮幾個問題：設計

  • 如何處理父或子Context的cancel。
  • cancel後Context是否也應該刪除掉。

咱們從源碼中來找到答案。
看一下canceler的接口,這是一個獨立的私有接口，和Context接口獨立開來，Context只作本身的事，並不用關心本身有啥附加的功能，好比如今說的cancel功能，這也是一個很好的例子，若是有須要對Context進行擴展，能夠參考他們的代碼。code

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
}

注意：cancelCtx把Context接口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
}

timerCtx是WithDeadline和WithTimeout方法的基礎。

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回答了咱們第一個問題

如何處理父或子Context的cancel。

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. 若是不是，則監控parent和child 的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) }

回答了咱們的第二個問題

cancel後Context是否也應該刪除掉。
全部建立的能夠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) }
總結一下

  • 接口要有邊界，要簡潔。
  • 對外公開的部分要簡單明瞭。
  • 提煉邊界方法和輔助實現部分，隱藏細節。
相關文章
相關標籤/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公眾號
   歡迎關注本站公眾號,獲取更多信息
聯繫我們 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程