Golang context 实现原理

本篇文章是基于小徐先生的文章的修改和个人注解，要查看原文可以点击上述的链接查看

目前我这篇文章的go语言版本是1.24.1

context上下文

context被当作第一个参数（官方建议），并且不断的传递下去，基本上一个项目代码到处都是context，但是你们真的知道他有什么作用吗？

接下来就来看看这个golang世界中的典型工具吧

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可以用来在goroutine之间传递上下文信息，相同的context可以传递给运行在不同goroutine中的函数，上下文对于多个goroutine同时使用是安全的，context包定义了上下文类型，可以使用background、TODO创建一个上下文，在函数调用链之间传播context，也可以使用WithDeadline、WithTimeout、WithCancel 或 WithValue 创建的修改副本替换它，听起来有点绕，其实总结起就是一句话：context的作用就是在不同的goroutine之间同步请求特定的数据、取消信号以及处理请求的截止日期。

目前我们常用的一些库都是支持context的，例如gin、database/sql等库都是支持context的，这样更方便我们做并发控制了，只要在服务器入口创建一个context上下文，不断透传下去即可。

二.context的使用

2.1 context.Context

他是核心数据结构，看一下它的样子吧：

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

Context 为 interface，定义了四个核心 api：

• Deadline：返回 context 的过期时间

• Done：返回 context 中的 channel

• Err：返回错误

• Value：返回 context 中的对应 key 的值

2.2 标准error

var Canceled = errors.New("context canceled")var DeadlineExceeded error = deadlineExceededError{}type deadlineExceededError struct{}func (deadlineExceededError) Error() string   { return "context deadline exceeded" }
func (deadlineExceededError) Timeout() bool   { return true }
func (deadlineExceededError) Temporary() bool { return true }

• Canceled：context 被 cancel 时会报此错误

• DeadlineExceeded：context 超时时会报此错误

三.类的实现

3.1 emptyCtx

通过看它的源码我们会发现，这个空的上下文其实就是实现了这个context这个接口，对于实现的4个方法都是返回的nil，这就是为什么说他是empty

在之前的版本中他可能是int类型，后来已经被修改了

type emptyCtx struct{}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 any) any {return nil
}

• emptyCtx 是一个空的 context

• Deadline 方法会返回一个公元元年时间以及 false 的 flag，标识当前 context 不存在过期时间；

• Done 方法返回一个 nil 值，用户无论往 nil 中写入或者读取数据，均会陷入阻塞；

• Err 方法返回的错误永远为 nil；

• Value 方法返回的 value 同样永远为 nil.

3.1.1 context.Background() & context.TODO()

context包主要提供了两种方式创建context：

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

我们在看代码的时候，经常可以看到不是Background就是todo作为上下文的起始，那他们有什么区别呢？

两者的区别

这两个函数其实只是互为别名，没有差别，官方给的定义是：

• context.Background 是上下文的默认值，所有其他的上下文都应该从它衍生（Derived）出来。
• context.TODO 应该只在不确定应该使用哪种上下文时使用；

所以在大多数情况下，我们都使用context.Background作为起始的上下文向下传递。

看一下两者的底层是什么？

两者其实都是一个对context的一个继承

type backgroundCtx struct{ emptyCtx }
type todoCtx struct{ emptyCtx }func Background() Context {return backgroundCtx{}
}func TODO() Context {return todoCtx{}
}

看到这里，你会发现上面的两种方式是创建根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的衍生方法就这些，关于这些with函数，会在后续的使用中看到

3.1.2 With类函数

1. WithCancel(parent Context)

用途：创建一个新的上下文和取消函数。当调用取消函数时，所有派生自这个上下文的操作将被通知取消。

应用场景：当一个长时间运行的操作需要能够被取消时。例如，用户在网页中点击“取消”按钮时，相关的数据库或 HTTP 请求应立即停止。

2. WithDeadline(parent Context, d time.Time)

用途：创建一个新的上下文，该上下文在指定的时间点自动取消。

应用场景：在请求处理时设置最大执行时间。例如，调用外部 API 时，如果响应时间超过预期，将自动取消请求，以避免无效的等待。

3. WithTimeout(parent Context, timeout time.Duration)

用途：创建一个新的上下文，它会在指定的持续时间内自动取消。

应用场景：适用于设置操作的超时时间，确保系统不会在某个操作上无休止地等待。常用于网络请求或长时间运行的任务。

4. WithValue(parent Context, key, val interface{})

用途：创建一个新的上下文，并将键值对存储在该上下文中。

应用场景：在处理请求时，将特定的数据（如用户身份信息、RequestID）在处理链中传递，而不需要在每个函数参数中显式传递。

3.2 cancelCtx

接下来看一下第二个实现的类吧，看名字就能看出来他是一个带有取消功能的上下文。

type cancelCtx struct {Contextmu       sync.Mutex            done     atomic.Value          children map[canceler]struct{} // 这里是一个set{}err      error                 cause    error                
}type canceler interface {cancel(removeFromParent bool, err, cause error)Done() <-chan struct{}
}// 这里体现了goland的一个编程哲学
// 作为一个父context，它只需要关注子类的这两个方法即可，
// 它的子类可能更有能力，但是与父亲无关，只需要知道他是否还存在即可
// 会通过就近生成interface的方式，把无关的信息都屏蔽掉。
// 也就是谁使用谁声明谁管理

• 继承了一个 context 作为其父 context. 可见，cancelCtx 必然为某个 context 的子 context；

• 内置了一把锁，用以协调并发场景下的资源获取；

• done：实际类型为 chan struct{}，即用以反映 cancelCtx 生命周期的通道；

• children：一个 set，指向 cancelCtx 的所有子 context；

• err：记录了当前 cancelCtx 的错误. 必然为某个 context 的子 context；

• cause：是在go1.20之后加入的字段，主要作用适用于记录导致context被取消的具体原因

在这里，要加入一些其他的内容----同步调用和异步调用

同步调用，其实就是一种串行的方式，也就是我们平时写的程序，他是一步一步进行下去，类似一条链的形式。

而异步调用则是开辟协程，并且不会阻塞主线程，并且主线程对子协程的感知能力很弱，开辟了多个子协程，就会形成类似树的形式

就会导致，主线程对子协程的管理能力下降，从而致使协程无法回收，最后导致协程泄露的一个问题。

在创建协程方面，我们要知道一点，如果不知道你创建的协程什么时候结束，你就不应该去创建，不应该滥用并发。

如何解决这个协程的控制呢？

那么今天的主角就是cancelCtx了

先说cancelCtx继承了Context，对其方法进行了一个重写，但是并没有对Deadline方法重写，而是直接继承的父类的。Deadline不进行重写是因为他没有过期取消的能力。

func (c *cancelCtx) Value(key any) any {// 这里为什么要加入这个判断，在后续会介绍，主要就是用于判断// 其自身是否是一个cancelCtx类型，这个cancelCtxKey是一个定值if key == &cancelCtxKey {return c}return value(c.Context, key)
}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{})
}func (c *cancelCtx) Err() error {c.mu.Lock()err := c.errc.mu.Unlock()return err
}

3.2.1 WithCancel取消控制

既然想实现这种父子联动的行为，就轮到了With下的一个函数WithCancel函数，通过这个函数从而得到一个cancelCtx对象，从而实现一个对子协程的一个控制

func main()  {ctx,cancel := context.WithCancel(context.Background())// 以context.Background()为父，创建得到一个子context和cancelgo 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("我要闭嘴了")returndefault:fmt.Println("balabalabalabala")}}
}

来对这个例子做出一个解释：

select就相当于是一个多路复用，进行一个监听的操作，通过这个WithCancel获取上下文和取消函数

当调用这个cancel函数的时候，就会直接通过这个ctx.Done发送这个取消机制，从而实现一个控制的效果

这里的操作也就是我们常说的超时控制了，当然cancel并没有涉及到超时，他是通过调用cancel()才可以实现一个关闭。

这个结构体就是cancel取消函数的结构体，他返回的是一个函数类型，所以调用的时候需要加上()

来看下这个函数的具体流程这里先提前告知一点，如果停止一个cancelCtx，则这个它下面所有的子上下文都将被杀死，具体的操作看propagateCancel函数

type CancelFunc func()func WithCancel(parent Context) (ctx Context, cancel CancelFunc) {c := withCancel(parent)//Canceled是一个error，自定义的错误信息return c, func() { c.cancel(true, Canceled, nil) }
}func withCancel(parent Context) *cancelCtx {if parent == nil {panic("cannot create context from nil parent")}c := &cancelCtx{}c.propagateCancel(parent, c)return c
}func (c *cancelCtx) propagateCancel(parent Context, child canceler) {c.Context = parent// 这一步就是说父亲是emptyCtx，他就没有必要取消// 所以没有必要大费周折的取消它，直接就返回就行done := parent.Done()if done == nil {return // parent is never canceled}// 如果父亲被取消了，那儿子也应该直接取消，记录一下取消的错误和原因select {case <-done:// parent is already canceledchild.cancel(false, parent.Err(), Cause(parent))returndefault:}// 如果我的父也是cancelCtx，则我需要将孩子加入map里面if p, ok := parentCancelCtx(parent); ok {// parent is a *cancelCtx, or derives from one.p.mu.Lock()if p.err != nil {// parent has already been canceledchild.cancel(false, p.err, p.cause)} else {if p.children == nil {p.children = make(map[canceler]struct{})}p.children[child] = struct{}{}}p.mu.Unlock()return}//检查父Context是否支持AfterFunc，也就是一个回调机制// if a, ok := parent.(afterFuncer); ok {// parent implements an AfterFunc method.c.mu.Lock()stop := a.AfterFunc(func() {child.cancel(false, parent.Err(), Cause(parent))})c.Context = stopCtx{Context: parent,stop:    stop,}c.mu.Unlock()return}// 开启一个守护协程，时刻监听，第一个判断父亲是不是被终止了// 如果父亲被终止了，就应该给孩子也砍一刀，让他们也都终止// 如果孩子被终止了，那就被终止了，什么也不需要处理，传播具有单向性goroutines.Add(1)go func() {select {case <-parent.Done():child.cancel(false, parent.Err(), Cause(parent))case <-child.Done():}}()
}

parentCancelCtx用于判断是不是cancelCtx类型

func (c *cancelCtx) Value(key any) any {// 这里为什么要加入这个判断，在后续会介绍，主要就是用于判断// 其自身是否是一个cancelCtx类型，这个cancelCtxKey是一个定值if key == &cancelCtxKey {return c}return value(c.Context, key)
}func parentCancelCtx(parent Context) (*cancelCtx, bool) {done := parent.Done()if done == closedchan || done == nil {return nil, false}p, ok := parent.Value(&cancelCtxKey).(*cancelCtx)if !ok {return nil, false}pdone, _ := p.done.Load().(chan struct{})if pdone != done {return nil, false}return p, true
}

再看一下返回的闭包函数吧

cancelCtx.cancel 方法有三个入参，第一个 removeFromParent 是一个 bool 值，表示当前 context 是否需要从父 context 的 children set 中删除；第二个 err 则是 cancel 后需要展示的错误，第三个则表示导致错误原因。

func (c *cancelCtx) cancel(removeFromParent bool, err, cause error) {if err == nil {panic("context: internal error: missing cancel error")}if cause == nil {cause = err}c.mu.Lock()if c.err != nil {c.mu.Unlock()return // already canceled}c.err = errc.cause = caused, _ := c.done.Load().(chan struct{})if d == nil {// closedchan 这里是一个全局chan// 关闭，从而取消监听，Store就是为了确保原子性和可见性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, cause)}c.children = nilc.mu.Unlock()if removeFromParent {removeChild(c.Context, c)}
}// removeChild removes a context from its parent.
func removeChild(parent Context, child canceler) {if s, ok := parent.(stopCtx); ok {s.stop()return}p, ok := parentCancelCtx(parent)if !ok {return}p.mu.Lock()if p.children != nil {delete(p.children, child)}p.mu.Unlock()
}

3.3 timerCtx

接下来看第三个实现的类

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

timerCtx 在 cancelCtx 基础上又做了一层封装，除了继承 cancelCtx 的能力之外，新增了一个 time.Timer 用于定时终止 context；另外新增了一个 deadline 字段用于字段 timerCtx 的过期时间.

这样就有了实现时停的操作，它对Dealine进行了一个重写，其他都是继承的cancelCtx的

Deadline返回的是 deadline time.Time

3.3.1WithTimeout和WithDeadline

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

这两个函数他们的参数就可以看出区别，context.WithTimeout是指经过的时间段，而WithDeadline则是指时间点。

这里属于是超时取消。

3.4 valueCtx

type valueCtx struct {Contextkey, val any
}

说一下这个valueCtx吧，在不同位置设置的value其实在查找方面是有问题的，比如你在最下面那一层去存放，也就是B下面的子节点存放value，只有A和B才可以访问这个value，C和D是无法访问到的。

3.4.1WithValue

func WithValue(parent Context, key, val any) 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}
}

通过这个函数来设置value值。