[[432383]]

前言

哈嘍，大家好，我是asong。今天想與大家分享context包，經過一年的沉淀，重新出發，基于Go1.17.1從源碼角度再次分析，不過這次不同的是，我打算先從入門開始，因為大多數初學的讀者都想先知道怎么用，然后才會關心源碼是如何實現的。

相信大家在日常工作開發中一定會看到這樣的代碼：

func a1(ctx context ...){ 
  b1(ctx) 
} 
func b1(ctx context ...){ 
  c1(ctx) 
} 
func c1(ctx context ...) 

context被當作第一個參數(官方建議)，并且不斷透傳下去，基本一個項目代碼中到處都是context，但是你們真的知道它有何作用嗎以及它是如何起作用的嗎?我記得我第一次接觸context時，同事都說這個用來做并發控制的，可以設置超時時間，超時就會取消往下執行，快速返回，我就單純的認為只要函數中帶著context參數往下傳遞就可以做到超時取消，快速返回。相信大多數初學者也都是和我一個想法，其實這是一個錯誤的思想，其取消機制采用的也是通知機制，單純的透傳并不會起作用，比如你這樣寫代碼：

func main()  { 
 ctx,cancel := context.WithTimeout(context.Background(),10 * time.Second) 
 defer cancel() 
 go Monitor(ctx) 
 
 time.Sleep(20 * time.Second) 
} 
 
func Monitor(ctx context.Context)  { 
 for { 
  fmt.Print("monitor") 
 } 
} 

即使context透傳下去了，沒有監聽取消信號也是不起任何作用的。所以了解context的使用還是很有必要的，本文就先從使用開始，逐步解析Go語言的context包，下面我們就開始嘍!!!

context包的起源與作用

看官方博客我們可以知道context包是在go1.7版本中引入到標準庫中的：

context可以用來在goroutine之間傳遞上下文信息，相同的context可以傳遞給運行在不同goroutine中的函數，上下文對于多個goroutine同時使用是安全的，context包定義了上下文類型，可以使用background、TODO創建一個上下文，在函數調用鏈之間傳播context，也可以使用WithDeadline、WithTimeout、WithCancel 或 WithValue 創建的修改副本替換它，聽起來有點繞，其實總結起就是一句話：context的作用就是在不同的goroutine之間同步請求特定的數據、取消信號以及處理請求的截止日期。

目前我們常用的一些庫都是支持context的，例如gin、database/sql等庫都是支持context的，這樣更方便我們做并發控制了，只要在服務器入口創建一個context上下文，不斷透傳下去即可。

context的使用

創建context

context包主要提供了兩種方式創建context:

• context.Backgroud()
• context.TODO()

這兩個函數其實只是互為別名，沒有差別，官方給的定義是：

• context.Background 是上下文的默認值，所有其他的上下文都應該從它衍生(Derived)出來。
• context.TODO 應該只在不確定應該使用哪種上下文時使用;

所以在大多數情況下，我們都使用context.Background作為起始的上下文向下傳遞。

上面的兩種方式是創建根context，不具備任何功能，具體實踐還是要依靠context包提供的With系列函數來進行派生：

func WithCancel(parent Context) (ctx Context, cancel CancelFunc) 
func WithDeadline(parent Context, deadline time.Time) (Context, CancelFunc) 
func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) 
func WithValue(parent Context, key, val interface{}) Context 

這四個函數都要基于父Context衍生，通過這些函數，就創建了一顆Context樹，樹的每個節點都可以有任意多個子節點，節點層級可以有任意多個，畫個圖表示一下：

基于一個父Context可以隨意衍生，其實這就是一個Context樹，樹的每個節點都可以有任意多個子節點，節點層級可以有任意多個，每個子節點都依賴于其父節點，例如上圖，我們可以基于Context.Background衍生出四個子context：ctx1.0-cancel、ctx2.0-deadline、ctx3.0-timeout、ctx4.0-withvalue，這四個子context還可以作為父context繼續向下衍生，即使其中ctx1.0-cancel 節點取消了，也不影響其他三個父節點分支。

創建context方法和context的衍生方法就這些，下面我們就一個一個來看一下他們如何被使用。

WithValue攜帶數據

我們日常在業務開發中都希望能有一個trace_id能串聯所有的日志，這就需要我們打印日志時能夠獲取到這個trace_id，在python中我們可以用gevent.local來傳遞，在java中我們可以用ThreadLocal來傳遞，在Go語言中我們就可以使用Context來傳遞，通過使用WithValue來創建一個攜帶trace_id的context，然后不斷透傳下去，打印日志時輸出即可，來看使用例子：

const ( 
 KEY = "trace_id" 
) 
 
func NewRequestID() string { 
 return strings.Replace(uuid.New().String(), "-", "", -1) 
} 
 
func NewContextWithTraceID() context.Context { 
 ctx := context.WithValue(context.Background(), KEY,NewRequestID()) 
 return ctx 
} 
 
func PrintLog(ctx context.Context, message string)  { 
 fmt.Printf("%s|info|trace_id=%s|%s",time.Now().Format("2006-01-02 15:04:05") , GetContextValue(ctx, KEY), message) 
} 
 
func GetContextValue(ctx context.Context,k string)  string{ 
 v, ok := ctx.Value(k).(string) 
 if !ok{ 
  return "" 
 } 
 return v 
} 
 
func ProcessEnter(ctx context.Context) { 
 PrintLog(ctx, "Golang夢工廠") 
} 
 
 
func main()  { 
 ProcessEnter(NewContextWithTraceID()) 
} 

輸出結果：

2021-10-31 15:13:25|info|trace_id=7572e295351e478e91b1ba0fc37886c0|Golang夢工廠 
Process finished with the exit code 0 

我們基于context.Background創建一個攜帶trace_id的ctx，然后通過context樹一起傳遞，從中派生的任何context都會獲取此值，我們最后打印日志的時候就可以從ctx中取值輸出到日志中。目前一些RPC框架都是支持了Context，所以trace_id的向下傳遞就更方便了。

在使用withVaule時要注意四個事項：

• 不建議使用context值傳遞關鍵參數，關鍵參數應該顯示的聲明出來，不應該隱式處理，context中最好是攜帶簽名、trace_id這類值。
• 因為攜帶value也是key、value的形式，為了避免context因多個包同時使用context而帶來沖突，key建議采用內置類型。
• 上面的例子我們獲取trace_id是直接從當前ctx獲取的，實際我們也可以獲取父context中的value，在獲取鍵值對是，我們先從當前context中查找，沒有找到會在從父context中查找該鍵對應的值直到在某個父context中返回 nil 或者查找到對應的值。
• context傳遞的數據中key、value都是interface類型，這種類型編譯期無法確定類型，所以不是很安全，所以在類型斷言時別忘了保證程序的健壯性。

超時控制

通常健壯的程序都是要設置超時時間的，避免因為服務端長時間響應消耗資源，所以一些web框架或rpc框架都會采用withTimeout或者withDeadline來做超時控制，當一次請求到達我們設置的超時時間，就會及時取消，不在往下執行。withTimeout和withDeadline作用是一樣的，就是傳遞的時間參數不同而已，他們都會通過傳入的時間來自動取消Context，這里要注意的是他們都會返回一個cancelFunc方法，通過調用這個方法可以達到提前進行取消，不過在使用的過程還是建議在自動取消后也調用cancelFunc去停止定時減少不必要的資源浪費。

withTimeout、WithDeadline不同在于WithTimeout將持續時間作為參數輸入而不是時間對象，這兩個方法使用哪個都是一樣的，看業務場景和個人習慣了，因為本質withTimout內部也是調用的WithDeadline。

現在我們就舉個例子來試用一下超時控制，現在我們就模擬一個請求寫兩個例子：

• 達到超時時間終止接下來的執行

func main()  { 
 HttpHandler() 
} 
 
func NewContextWithTimeout() (context.Context,context.CancelFunc) { 
 return context.WithTimeout(context.Background(), 3 * time.Second) 
} 
 
func HttpHandler()  { 
 ctx, cancel := NewContextWithTimeout() 
 defer cancel() 
 deal(ctx) 
} 
 
func deal(ctx context.Context)  { 
 for i:=0; i< 10; i++ { 
  time.Sleep(1*time.Second) 
  select { 
  case <- ctx.Done(): 
   fmt.Println(ctx.Err()) 
   return 
  default: 
   fmt.Printf("deal time is %d\n", i) 
  } 
 } 
} 

輸出結果：

deal time is 0 
deal time is 1 
context deadline exceeded 

• 沒有達到超時時間終止接下來的執行

func main()  { 
 HttpHandler1() 
} 
 
func NewContextWithTimeout1() (context.Context,context.CancelFunc) { 
 return context.WithTimeout(context.Background(), 3 * time.Second) 
} 
 
func HttpHandler1()  { 
 ctx, cancel := NewContextWithTimeout1() 
 defer cancel() 
 deal1(ctx, cancel) 
} 
 
func deal1(ctx context.Context, cancel context.CancelFunc)  { 
 for i:=0; i< 10; i++ { 
  time.Sleep(1*time.Second) 
  select { 
  case <- ctx.Done(): 
   fmt.Println(ctx.Err()) 
   return 
  default: 
   fmt.Printf("deal time is %d\n", i) 
   cancel() 
  } 
 } 
} 

輸出結果：

deal time is 0 
context canceled 

使用起來還是比較容易的，既可以超時自動取消，又可以手動控制取消。這里大家要記的一個坑，就是我們往從請求入口透傳的調用鏈路中的context是攜帶超時時間的，如果我們想在其中單獨開一個goroutine去處理其他的事情并且不會隨著請求結束后而被取消的話，那么傳遞的context要基于context.Background或者context.TODO重新衍生一個傳遞，否決就會和預期不符合了，可以看一下我之前的一篇踩坑文章：context使用不當引發的一個bug。

withCancel取消控制

日常業務開發中我們往往為了完成一個復雜的需求會開多個gouroutine去做一些事情，這就導致我們會在一次請求中開了多個goroutine確無法控制他們，這時我們就可以使用withCancel來衍生一個context傳遞到不同的goroutine中，當我想讓這些goroutine停止運行，就可以調用cancel來進行取消。

來看一個例子：

func main()  { 
 ctx,cancel := context.WithCancel(context.Background()) 
 go Speak(ctx) 
 time.Sleep(10*time.Second) 
 cancel() 
 time.Sleep(1*time.Second) 
} 
 
func Speak(ctx context.Context)  { 
 for range time.Tick(time.Second){ 
  select { 
  case <- ctx.Done(): 
   fmt.Println("我要閉嘴了") 
   return 
  default: 
   fmt.Println("balabalabalabala") 
  } 
 } 
} 

運行結果：

balabalabalabala 
....省略 
balabalabalabala 
我要閉嘴了 

我們使用withCancel創建一個基于Background的ctx，然后啟動一個講話程序，每隔1s說一話，main函數在10s后執行cancel，那么speak檢測到取消信號就會退出。

自定義Context

因為Context本質是一個接口，所以我們可以通過實現Context達到自定義Context的目的，一般在實現Web框架或RPC框架往往采用這種形式，比如gin框架的Context就是自己有封裝了一層，具體代碼和實現就貼在這里，有興趣可以看一下gin.Context是如何實現的。

源碼賞析

Context其實就是一個接口，定義了四個方法：

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

• Deadlne方法：當Context自動取消或者到了取消時間被取消后返回
• Done方法：當Context被取消或者到了deadline返回一個被關閉的channel
• Err方法：當Context被取消或者關閉后，返回context取消的原因
• Value方法：獲取設置的key對應的值

這個接口主要被三個類繼承實現，分別是emptyCtx、ValueCtx、cancelCtx，采用匿名接口的寫法，這樣可以對任意實現了該接口的類型進行重寫。

下面我們就從創建到使用來層層分析。

創建根Context

其在我們調用context.Background、context.TODO時創建的對象就是empty：

var ( 
 background = new(emptyCtx) 
 todo       = new(emptyCtx) 
) 
 
func Background() Context { 
 return background 
} 
 
func TODO() Context { 
 return todo 
} 

Background和TODO還是一模一樣的，官方說：background它通常由主函數、初始化和測試使用，并作為傳入請求的頂級上下文;TODO是當不清楚要使用哪個 Context 或尚不可用時，代碼應使用 context.TODO，后續在在進行替換掉，歸根結底就是語義不同而已。

emptyCtx類

emptyCtx主要是給我們創建根Context時使用的，其實現方法也是一個空結構，實際源代碼長這樣：

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

WithValue的實現

withValue內部主要就是調用valueCtx類：

func WithValue(parent Context, key, val interface{}) Context { 
 if parent == nil { 
  panic("cannot create context from nil parent") 
 } 
 if key == nil { 
  panic("nil key") 
 } 
 if !reflectlite.TypeOf(key).Comparable() { 
  panic("key is not comparable") 
 } 
 return &valueCtx{parent, key, val} 
} 

valueCtx類

valueCtx目的就是為Context攜帶鍵值對，因為它采用匿名接口的繼承實現方式，他會繼承父Context，也就相當于嵌入Context當中了

type valueCtx struct { 
 Context 
 key, val interface{} 
} 

實現了String方法輸出Context和攜帶的鍵值對信息：

func (c *valueCtx) String() string { 
 return contextName(c.Context) + ".WithValue(type " + 
  reflectlite.TypeOf(c.key).String() + 
  ", val " + stringify(c.val) + ")" 
} 

實現Value方法來存儲鍵值對：

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

看圖來理解一下：

所以我們在調用Context中的Value方法時會層層向上調用直到最終的根節點，中間要是找到了key就會返回，否會就會找到最終的emptyCtx返回nil。

WithCancel的實現

我們來看一下WithCancel的入口函數源代碼：

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

這個函數執行步驟如下：

• 創建一個cancelCtx對象，作為子context
• 然后調用propagateCancel構建父子context之間的關聯關系，這樣當父context被取消時，子context也會被取消。
• 返回子context對象和子樹取消函數

我們先分析一下cancelCtx這個類。

cancelCtx類

cancelCtx繼承了Context，也實現了接口canceler:

type cancelCtx struct { 
 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 
} 

字短解釋：

• mu：就是一個互斥鎖，保證并發安全的，所以context是并發安全的
• done：用來做context的取消通知信號，之前的版本使用的是chan struct{}類型，現在用atomic.Value做鎖優化
• children：key是接口類型canceler，目的就是存儲實現當前canceler接口的子節點，當根節點發生取消時，遍歷子節點發送取消信號
• error：當context取消時存儲取消信息

這里實現了Done方法，返回的是一個只讀的channel，目的就是我們在外部可以通過這個阻塞的channel等待通知信號。

具體代碼就不貼了。我們先返回去看propagateCancel是如何做構建父子Context之間的關聯。

propagateCancel方法

代碼有點長，解釋有點麻煩，我把注釋添加到代碼中看起來比較直觀：

func propagateCancel(parent Context, child canceler) { 
  // 如果返回nil，說明當前父`context`從來不會被取消，是一個空節點，直接返回即可。 
 done := parent.Done() 
 if done == nil { 
  return // parent is never canceled 
 } 
 
  // 提前判斷一個父context是否被取消，如果取消了也不需要構建關聯了， 
  // 把當前子節點取消掉并返回 
 select { 
 case <-done: 
  // parent is already canceled 
  child.cancel(false, parent.Err()) 
  return 
 default: 
 } 
 
  // 這里目的就是找到可以“掛”、“取消”的context 
 if p, ok := parentCancelCtx(parent); ok { 
  p.mu.Lock() 
    // 找到了可以“掛”、“取消”的context，但是已經被取消了，那么這個子節點也不需要 
    // 繼續掛靠了，取消即可 
  if p.err != nil { 
   child.cancel(false, p.err) 
  } else { 
      // 將當前節點掛到父節點的childrn map中，外面調用cancel時可以層層取消 
   if p.children == nil { 
        // 這里因為childer節點也會變成父節點，所以需要初始化map結構 
    p.children = make(map[canceler]struct{}) 
   } 
   p.children[child] = struct{}{} 
  } 
  p.mu.Unlock() 
 } else { 
    // 沒有找到可“掛”，“取消”的父節點掛載，那么就開一個goroutine 
  atomic.AddInt32(&goroutines, +1) 
  go func() { 
   select { 
   case <-parent.Done(): 
    child.cancel(false, parent.Err()) 
   case <-child.Done(): 
   } 
  }() 
 } 
} 

這段代碼真正產生疑惑的是這個if、else分支。不看代碼了，直接說為什么吧。因為我們可以自己定制context，把context塞進一個結構時，就會導致找不到可取消的父節點，只能重新起一個協程做監聽。

對這塊有迷惑的推薦閱讀饒大大文章：[深度解密Go語言之context](https://www.cnblogs.com/qcrao-2018/p/11007503.html)，定能為你排憂解惑。

cancel方法

最后我們再來看一下返回的cancel方法是如何實現，這個方法會關閉上下文中的 Channel 并向所有的子上下文同步取消信號：

func (c *cancelCtx) cancel(removeFromParent bool, err error) { 
  // 取消時傳入的error信息不能為nil, context定義了默認error:var Canceled = errors.New("context canceled") 
 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，通知其他協程 
 d, _ := c.done.Load().(chan struct{}) 
 if d == nil { 
  c.done.Store(closedchan) 
 } else { 
  close(d) 
 } 
  // 當前節點向下取消，遍歷它的所有子節點，然后取消 
 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 
  // 其他都是傳false，內部調用都會因為c.children = nil被剔除出去 
 if removeFromParent { 
  removeChild(c.Context, c) 
 } 
} 

到這里整個WithCancel方法源碼就分析好了，通過源碼我們可以知道cancel方法可以被重復調用，是冪等的。

withDeadline、WithTimeout的實現

先看WithTimeout方法，它內部就是調用的WithDeadline方法：

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

所以我們重點來看withDeadline是如何實現的：

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) { 
  // 不能為空`context`創建衍生context 
 if parent == nil { 
  panic("cannot create context from nil parent") 
 } 
   
  // 當父context的結束時間早于要設置的時間，則不需要再去單獨處理子節點的定時器了 
 if cur, ok := parent.Deadline(); ok && cur.Before(d) { 
  // The current deadline is already sooner than the new one. 
  return WithCancel(parent) 
 } 
  // 創建一個timerCtx對象 
 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) } 
} 

withDeadline相較于withCancel方法也就多了一個定時器去定時調用cancel方法，這個cancel方法在timerCtx類中進行了重寫，我們先來看一下timerCtx類，他是基于cancelCtx的，多了兩個字段：

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

timerCtx實現的cancel方法，內部也是調用了cancelCtx的cancel方法取消：

func (c *timerCtx) cancel(removeFromParent bool, err error) { 
  // 調用cancelCtx的cancel方法取消掉子節點context 
 c.cancelCtx.cancel(false, err) 
  // 從父context移除放到了這里來做 
 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() 
} 

終于源碼部分我們就看完了，現在你何感想?

context的優缺點

context包被設計出來就是做并發控制的，這個包有利有弊，個人總結了幾個優缺點，歡迎評論區補充。

缺點

• 影響代碼美觀，現在基本所有web框架、RPC框架都是實現了context，這就導致我們的代碼中每一個函數的一個參數都是context，即使不用也要帶著這個參數透傳下去，個人覺得有點丑陋。
• context可以攜帶值，但是沒有任何限制，類型和大小都沒有限制，也就是沒有任何約束，這樣很容易導致濫用，程序的健壯很難保證;還有一個問題就是通過context攜帶值不如顯式傳值舒服，可讀性變差了。
• 可以自定義context，這樣風險不可控，更加會導致濫用。
• context取消和自動取消的錯誤返回不夠友好，無法自定義錯誤，出現難以排查的問題時不好排查。
• 創建衍生節點實際是創建一個個鏈表節點，其時間復雜度為O(n)，節點多了會掉支效率變低。

優點

使用context可以更好的做并發控制，能更好的管理goroutine濫用。

context的攜帶者功能沒有任何限制，這樣我我們傳遞任何的數據，可以說這是一把雙刃劍

網上都說context包解決了goroutine的cancelation問題，你覺得呢?

參考文章

https://pkg.go.dev/context@go1.7beta1#Background https://studygolang.com/articles/21531 https://draveness.me/golang/docs/part3-runtime/ch06-concurrency/golang-context/ https://www.cnblogs.com/qcrao-2018/p/11007503.html https://segmentfault.com/a/1190000039294140 https://www.flysnow.org/2017/05/12/go-in-action-go-context.html

總結

context雖然在使用上丑陋了一點，但是他卻能解決很多問題，日常業務開發中離不開context的使用，不過也別使用錯了context，其取消也采用的channel通知，所以代碼中還有要有監聽代碼來監聽取消信號，這點也是經常被廣大初學者容易忽視的一個點。

文中示例已上傳github：https://github.com/asong2020/Golang_Dream/tree/master/code_demo/context_example

 

好啦，本文到這里就結束了，我是asong，我們下期見。