[关于Context]

前言：

首先context是什么？——context是goalng中的经典工具

应用场景：1.并发的协调 2.作为存储介质

本文根据自身学习到的知识并结合相关文章对context进行解析，主要还是用于博主自己的知识梳理，如果有错误的地方，欢迎批评指正

Context的数据结构：

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

.以上四个函数是作为Context必须具备的四个api

Deadline()	这个函数返回的是Context的一个过期时间
Done()	返回的是context中的channel，用于监听是否关闭context，这个channel是正常情况下不允许往里面传送值的，因为Context会读取这个channel，如果读到值则会cancel这个context
Err()	返回context的一个error信息
Value()	这边传入key，返回context存储对应key 的值

.Context中的错误信息

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

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

emptyCtx：

emptyCtx作为一个最基本的context类，实现了Context接口，如其名，这是一个空白的Context，后续谈到的其他Context大多以这个为鼻祖类

.类实现

type emptyCtx int //本质是个整型

func (*emptyCtx) Deadline() (deadline time.Time, ok bool) {
    return//返回一个公元元年时间和false值，代表当前context不存在过期时间
}

func (*emptyCtx) Done() <-chan struct{} {
    return nil
}

func (*emptyCtx) Err() error {
    return nil
}

func (*emptyCtx) Value(key any) any {
    return 
}

实现的四个api都是返回的空值，这边的emptyCtx是无法被取消的，为什么？因为Done函数返回的是一个空channnel，无法从中读取，会一直阻塞在那里。

.Backgroud()&TODO()

这两个函数大家都不陌生应该，因为经常会遇到你需要一个context，但是不知道传什么类型context的时候就传这两个，返回值都是context，下面我们看看它们的实现

var (
    background = new(emptyCtx)//从中可以看出本质都是返回一个emptyCtx实例
    todo       = new(emptyCtx)
)

func Background() Context {//backgroud倾向作为一个形参
    return background
}

func TODO() Context {//todo更倾向于你要用这个context做某些功能
    return todo
}

cancleCtx：

.model

type cancelCtx struct {
    Context //继承了Context，代表cancel只能作为某ctx的子ctx
   
    mu       sync.Mutex            // 读写互斥锁
    done     atomic.Value          // 内置了一个done管道，功能和Done()返回的chan一样
    children map[canceler]struct{} // 存储子context
    err      error                 // set to non-nil by the first cancel call
}

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

cancelCtx主要功能是为了实现父子ctx之间的控制关系，从而达到控制协程或者线程的效果，所以是为了提高并发的安全性，cancelCtx着重实现了cancel方法，当父ctx发出取消信号时候，子ctx也跟着取消，映射到协程中，父协程的关闭也应该带着子协程的关闭，因此cancelCtx有助于防止协程泄露。

协程之间的关系和ctx之间的关系类似树状结构

.deadline

cancelCtx并没有实现这个方法，只是继承了Context的，如果直接调用会报错

.done

func (c *cancelCtx) Done() <-chan struct{} {
    d := c.done.Load()//获取内置的channel
    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{})//如果done属性空，make一个返回
        c.done.Store(d)
    }
    return d.(chan struct{})//断言
}

-这边check了两次channel，一次加锁，一次没加锁

-这边运用到懒加载机制，初始化chan存储在aotmic.Value中，然后返回(用到的时候如果不存在才初始化chan)

.err

func (c *cancelCtx) Err() error {
    c.mu.Lock()//加锁返回err
    err := c.err
    c.mu.Unlock()
    return err
}

.value

func (c *cancelCtx) Value(key any) any {
    if key == &cancelCtxKey {
        return c
    }
    return value(c.Context, key)
}

-这边的cancelCtxKey是一个鉴别自身身份的全局私有变量，只有当你是cancelCtx的时候传入这个key可以鉴别是不是cancelCtxKey,这边下面会讲到

-value方法和valueCtx类似，具体valueCtx实现

.context.WithCancel()

context有四个with方法下面一次会讲到

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

-校验父context是否为空

-注入父亲context得到新的cancelCtx，context的性能实现是子继承父，子在继承父亲的所有功能的基础上，实现自己新的功能

-propagateCancel启动一个守护协程进行保证父context取消时，当前的cancelContext被取消

-返回cancelCtx和一个闭包函数，这个闭包函数返回后单独调用可以直接取消cancelCtx，其内部就是一个cancel方法

.newCancelCtx

func newCancelCtx(parent Context) cancelCtx {
    return cancelCtx{Context: parent}//看到这边就知道了cancelCtx中Context字段的作用
}

.propagateCancel

func propagateCancel(parent Context, child canceler) {
    done := parent.Done()//获取父context的done
    if done == nil {
        return // parent is never canceled
    }

    select {
    case <-done://如果done有信号
        // parent is already canceled
        child.cancel(false, parent.Err())
        return
    default:
    }

    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 {
        atomic.AddInt32(&goroutines, +1)
        go func() {
            select {
            case <-parent.Done():
                child.cancel(false, parent.Err())
            case <-child.Done():
            }
        }()
    }
}

• 倘若 parent 是不会被 cancel 的类型（如 emptyCtx），则直接返回；

• 倘若 parent 已经被 cancel，则直接终止子 context，并以 parent 的 err 作为子 context 的 err；

• 假如 parent 是 cancelCtx 的类型，则加锁，并将子 context 添加到 parent 的 children map 当中；

• 假如 parent 不是 cancelCtx 类型，但又存在 cancel 的能力（比如用户自定义实现的 context），则启动一个协程，通过多路复用的方式监控 parent 状态，倘若其终止，则同时终止子 context，并透传 parent 的 err.

.parentCancelCtx

------这边是我们收伏笔的地方，前面聊到cancelCtx可以通过一个私有全局判断自身是否是cancelCtx类型

func parentCancelCtx(parent Context) (*cancelCtx, bool) {
    done := parent.Done()
    if done == closedchan || done == nil {//如果chan已经关闭或者是不会被cancel的类型，这个前面聊过，就直接返回，肯定算不了cancelCtx
        return nil, false
    }
    p, ok := parent.Value(&cancelCtxKey).(*cancelCtx)//就是这个地方判断，可以跳转到上面的value方法查看实现
    if !ok {
        return nil, false
    }
    pdone, _ := p.done.Load().(chan struct{})//判断两个chan是否是同一个
    if pdone != done {
        return nil, false
    }
    return p, true
}

.cancelCtx.cancel

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

    if removeFromParent {
        removeChild(c.Context, c)
    }
}

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

• 进入方法主体，首先校验传入的 err 是否为空，若为空则 panic；

• 加锁；

• 校验 cancelCtx 自带的 err 是否已经非空，若非空说明已被 cancel，则解锁返回；

• 将传入的 err 赋给 cancelCtx.err；

• 处理 cancelCtx 的 channel，若 channel 此前未初始化，则直接注入一个 closedChan，否则关闭该 channel；

• 遍历当前 cancelCtx 的 children set，依次将 children context 都进行 cancel；

• 解锁.

• 根据传入的 removeFromParent flag 判断是否需要手动把 cancelCtx 从 parent 的 children set 中移除.

.removechild

func removeChild(parent Context, child canceler) {
    p, ok := parentCancelCtx(parent)
    if !ok {
        return
    }
    p.mu.Lock()
    if p.children != nil {
        delete(p.children, child)
    }
    p.mu.Unlock()
}

• 如果 parent 不是 cancelCtx，直接返回（因为只有 cancelCtx 才有 children set）

• 加锁；

• 从 parent 的 children set 中删除对应 child

• 解锁返回.

timerCtx:

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

    deadline time.Time
}

在cancelCtx的基础上进行封装，这边多了timer属性和deadline属性，timer字段类似闹钟，定时设定了context的终止时间。deadline则还是过期时间

.deadline

func (c *timerCtx) Deadline() (deadline time.Time, ok bool) {
    return c.deadline, true
}

在说的这些Context中，deadline只在timerCtx中有效，用于展示过期时间，毕竟只有这个context设置了终止时间

.cancel

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

• 复用继承的 cancelCtx 的 cancel 能力，进行 cancel 处理；

• 判断是否需要手动从 parent 的 children set 中移除，若是则进行处理

• 加锁；

• 停止 time.Timer

• 解锁返回.

.WithTimeout&WithDeadline

withtimeout内部调用withdeadline，二者几乎相同

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

context.WithTimeout 方法用于构造一个 timerCtx，本质上会调用 context.WithDeadline 方法：

func WithDeadline(parent Context, d time.Time) (Context, CancelFunc) {
    if parent == nil {
        panic("cannot create context from nil parent")
    }
    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) }
}

• 校验 parent context 非空；

• 校验 parent 的过期时间是否早于自己，若是，则构造一个 cancelCtx 返回即可；

• 构造出一个新的 timerCtx；

• 启动守护方法，同步 parent 的 cancel 事件到子 context；

• 判断过期时间是否已到，若是，直接 cancel timerCtx，并返回 DeadlineExceeded 的错误；

• 加锁；

• 启动 time.Timer，设定一个延时时间，即达到过期时间后会终止该 timerCtx，并返回 DeadlineExceeded 的错误；

• 解锁；

• 返回 timerCtx，已经一个封装了 cancel 逻辑的闭包 cancel 函数.

valueCtx：

type valueCtx struct {
    Context
    key, val any
}

• valueCtx 同样继承了一个 parent context；

• 一个 valueCtx 中仅有一组 kv 对.

.value

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

• 假如当前 valueCtx 的 key 等于用户传入的 key，则直接返回其 value；

• 假如不等，则从 parent context 中依次向上寻找.

func value(c Context, key any) any {
    for {
        switch ctx := c.(type) {
        case *valueCtx:
            if key == ctx.key {
                return ctx.val
            }
            c = ctx.Context
        case *cancelCtx:
            if key == &cancelCtxKey {
                return c
            }
            c = ctx.Context
        case *timerCtx:
            if key == &cancelCtxKey {
                return &ctx.cancelCtx
            }
            c = ctx.Context
        case *emptyCtx:
            return nil
        default:
            return c.Value(key)
        }
    }
}

• 启动一个 for 循环，由下而上，由子及父，依次对 key 进行匹配；

• 其中 cancelCtx、timerCtx、emptyCtx 类型会有特殊的处理方式；不同类型不同处理

• 找到匹配的 key，则将该组 value 进行返回.

5.3 valueCtx 用法小结

valueCtx 不适合视为存储介质，存放大量的 kv 数据，原因有三：

• 一个 valueCtx 实例只能存一个 kv 对，因此 n 个 kv 对会嵌套 n 个 valueCtx，造成空间浪费；

• 基于 k 寻找 v 的过程是线性的，时间复杂度 O(N)；//由下往上

• 不支持基于 k 的去重，相同 k 可能重复存在，并基于起点的不同，返回不同的 v. 由此得知，valueContext 的定位类似于请求头，只适合存放少量作用域较大的全局 meta 数据.

5.4 context.WithValue()

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

• 倘若 parent context 为空，panic；

• 倘若 key 为空 panic；

• 倘若 key 的类型不可比较，panic；

• 包括 parent context 以及 kv对，返回一个新的 valueCtx.

本文参考了b站小徐先生的视频讲解结合自身的理解，大家可以取看看原视频也许有更深的理解