Go語言上下文context底層原理
1. context 介紹
很多時候,我們會遇到這樣的情況,上層與下層的goroutine需要同時取消,這樣就涉及到了goroutine間的通信。在Go中,推薦我們以通信的方式共享內存,而不是以共享內存的方式通信。所以,就需要用到channl,但是,在上述場景中,如果需要自己去處理channl的業(yè)務邏輯,就會有很多費時費力的重復工作,因此,context出現(xiàn)了。
context是Go中用來進程通信的一種方式,其底層是借助channl與snyc.Mutex實現(xiàn)的。
2. 基本介紹
context的底層設計,我們可以概括為1個接口,4種實現(xiàn)與6個方法。
1 個接口
- Context 規(guī)定了
context的四個基本方法
4 種實現(xiàn)
- emptyCtx 實現(xiàn)了一個空的
context,可以用作根節(jié)點 - cancelCtx 實現(xiàn)一個帶
cancel功能的context,可以主動取消 - timerCtx 實現(xiàn)一個通過定時器
timer和截止時間deadline定時取消的context - valueCtx 實現(xiàn)一個可以通過
key、val兩個字段來存數據的context
6 個方法:
- Background 返回一個
emptyCtx作為根節(jié)點 - TODO 返回一個
emptyCtx作為未知節(jié)點 - WithCancel 返回一個
cancelCtx - WithDeadline 返回一個
timerCtx - WithTimeout 返回一個
timerCtx - WithValue 返回一個
valueCtx
3. 源碼分析
3.1 Context 接口
type Context interface {
Deadline() (deadline time.Time, ok bool)
Done() <-chan struct{}
Err() error
Value(key interface{}) interface{}
}- Deadline() :返回一個time.Time,表示當前Context應該結束的時間,ok則表示有結束時間
- Done():返回一個只讀chan,如果可以從該 chan 中讀取到數據,則說明 ctx 被取消了
- Err():返回 Context 被取消的原因
- Value(key):返回key對應的value,是協(xié)程安全的
3.2 emptyCtx
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
}emptyCtx實現(xiàn)了空的Context接口,其主要作用是為Background和TODO這兩個方法都會返回預先初始化好的私有變量 background 和 todo,它們會在同一個 Go 程序中被復用:
var (
background = new(emptyCtx)
todo = new(emptyCtx)
)
func Background() Context {
return background
}
func TODO() Context {
return todo
}Background和TODO在實現(xiàn)上沒有區(qū)別,只是在使用語義上有所差異:
Background是上下文的根節(jié)點;TODO應該僅在不確定應該使用哪種上下文時使用;
3.3 cancelCtx
cancelCtx實現(xiàn)了canceler接口與Context接口:
type canceler interface {
cancel(removeFromParent bool, err error)
Done() <-chan struct{}
}其結構體如下:
type cancelCtx struct {
// 直接嵌入了一個 Context,那么可以把 cancelCtx 看做是一個 Context
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
}我們可以使用WithCancel的方法來創(chuàng)建一個cancelCtx:
func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {
if parent == nil {
panic("cannot create context from nil parent")
}
c := newCancelCtx(parent)
propagateCancel(parent, &c)
return &c, func() { c.cancel(true, Canceled) }
}
func newCancelCtx(parent Context) cancelCtx {
return cancelCtx{Context: parent}
}上面的方法,我們傳入一個父 Context(這通常是一個 background,作為根節(jié)點),返回新建的 context,并通過閉包的形式,返回了一個 cancel 方法。
newCancelCtx將傳入的上下文包裝成私有結構體context.cancelCtx。
propagateCancel則會構建父子上下文之間的關聯(lián),形成樹結構,當父上下文被取消時,子上下文也會被取消:
func propagateCancel(parent Context, child canceler) {
// 1.如果 parent ctx 是不可取消的 ctx,則直接返回 不進行關聯(lián)
done := parent.Done()
if done == nil {
return // parent is never canceled
}
// 2.接著判斷一下 父ctx 是否已經被取消
select {
case <-done:
// 2.1 如果 父ctx 已經被取消了,那就沒必要關聯(lián)了
// 然后這里也要順便把子ctx給取消了,因為父ctx取消了 子ctx就應該被取消
// 這里是因為還沒有關聯(lián)上,所以需要手動觸發(fā)取消
// parent is already canceled
child.cancel(false, parent.Err())
return
default:
}
// 3. 從父 ctx 中提取出 cancelCtx 并將子ctx加入到父ctx 的 children 里面
if p, ok := parentCancelCtx(parent); ok {
p.mu.Lock()
// double check 一下,確認父 ctx 是否被取消
if p.err != nil {
// 取消了就直接把當前這個子ctx給取消了
// parent has already been canceled
child.cancel(false, p.err)
} else {
// 否則就添加到 children 里面
if p.children == nil {
p.children = make(map[canceler]struct{})
}
p.children[child] = struct{}{}
}
p.mu.Unlock()
} else {
// 如果沒有找到可取消的父 context。新啟動一個協(xié)程監(jiān)控父節(jié)點或子節(jié)點取消信號
atomic.AddInt32(&goroutines, +1)
go func() {
select {
case <-parent.Done():
child.cancel(false, parent.Err())
case <-child.Done():
}
}()
}
}上面的方法可能遇到以下幾種情況:
- 當
parent.Done() == nil,也就是parent不會觸發(fā)取消事件時,當前函數會直接返回; - 當
child的繼承鏈包含可以取消的上下文時,會判斷parent是否已經觸發(fā)了取消信號;- 如果已經被取消,
child會立刻被取消; - 如果沒有被取消,
child會被加入parent的children列表中,等待parent釋放取消信號;
- 如果已經被取消,
- 當父上下文是開發(fā)者自定義的類型、實現(xiàn)了 context.Context 接口并在
Done()方法中返回了非空的管道時;- 運行一個新的 Goroutine 同時監(jiān)聽
parent.Done()和child.Done()兩個 Channel; - 在
parent.Done()關閉時調用child.cancel取消子上下文;
- 運行一個新的 Goroutine 同時監(jiān)聽
propagateCancel 的作用是在 parent 和 child 之間同步取消和結束的信號,保證在 parent 被取消時,child 也會收到對應的信號,不會出現(xiàn)狀態(tài)不一致的情況。
func parentCancelCtx(parent Context) (*cancelCtx, bool) {
done := parent.Done()
// 如果 done 為 nil 說明這個ctx是不可取消的
// 如果 done == closedchan 說明這個ctx不是標準的 cancelCtx,可能是自定義的
if done == closedchan || done == nil {
return nil, false
}
// 然后調用 value 方法從ctx中提取出 cancelCtx
p, ok := parent.Value(&cancelCtxKey).(*cancelCtx)
if !ok {
return nil, false
}
// 最后再判斷一下cancelCtx 里存的 done 和 父ctx里的done是否一致
// 如果不一致說明parent不是一個 cancelCtx
pdone, _ := p.done.Load().(chan struct{})
if pdone != done {
return nil, false
}
return p, true
}ancelCtx 的 done 方法會返回一個 chan struct{}:
func (c *cancelCtx) Done() <-chan struct{} {
d := c.done.Load()
if d != nil {
return d.(chan struct{})
}
c.mu.Lock()
defer c.mu.Unlock()
d = c.done.Load()
if d == nil {
d = make(chan struct{})
c.done.Store(d)
}
return d.(chan struct{})
}
var closedchan = make(chan struct{})parentCancelCtx 其實就是判斷 parent context 里面有沒有一個 cancelCtx,有就返回,讓子context可以“掛靠”到parent context 上,如果不是就返回false,不進行掛靠,自己新開一個 goroutine 來監(jiān)聽。
3.4 timerCtx
timerCtx 內部不僅通過嵌入 cancelCtx 的方式承了相關的變量和方法,還通過持有的定時器 timer 和截止時間 deadline 實現(xiàn)了定時取消的功能:
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) {
c.cancelCtx.cancel(false, err)
if removeFromParent {
removeChild(c.cancelCtx.Context, c)
}
c.mu.Lock()
if c.timer != nil {
c.timer.Stop()
c.timer = nil
}
c.mu.Unlock()
}3.5 valueCtx
valueCtx 是多了 key、val 兩個字段來存數據:
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)
}如果 key 和當前 ctx 中存的 value 一致就直接返回,沒有就去 parent 中找。最終找到根節(jié)點(一般是 emptyCtx),直接返回一個 nil。所以用 Value 方法的時候要判斷結果是否為 nil,類似于一個鏈表,效率是很低的,不建議用來傳參數。
4. 使用建議
在官方博客里,對于使用 context 提出了幾點建議:
- 不要將 Context 塞到結構體里。直接將 Context 類型作為函數的第一參數,而且一般都命名為 ctx。
- 不要向函數傳入一個 nil 的 context,如果你實在不知道傳什么,標準庫給你準備好了一個 context:todo。
- 不要把本應該作為函數參數的類型塞到 context 中,context 存儲的應該是一些共同的數據。例如:登陸的 session、cookie 等。
- 同一個 context 可能會被傳遞到多個 goroutine,別擔心,context 是并發(fā)安全的。
到此這篇關于Go語言上下文context底層原理的文章就介紹到這了,更多相關Go context 內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!
相關文章
詳解prometheus監(jiān)控golang服務實踐記錄
這篇文章主要介紹了詳解prometheus監(jiān)控golang服務實踐記錄,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-11-11
基于gin的golang web開發(fā)之認證利器jwt
這篇文章主要介紹了基于gin的golang web開發(fā)之認證利器jwt,本文給大家介紹的非常詳細,對大家的學習或工作具有一定的參考借鑒價值,需要的朋友可以參考下2020-12-12

