Go标准库为何用互斥锁读取Context的error字段？

开发者阿泽

2026-8-25

Go标准库中cancelCtx为何使用互斥锁而非读写锁？

Go标准库的Context接口有多种底层实现：比如Background和TODO上下文基于未暴露的emptyCtx类型，本质是一个带有若干存根方法的int类型；而每次调用context.WithCancel()返回的实例则是cancelCtx类型，这是一个由互斥锁保护多个属性的结构体：

// A cancelCtx can be canceled. When canceled, it also cancels any children
// that implement 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
}

这里有个疑问：cancelCtx为何选择sync.Mutex而非sync.RWMutex？比如它的Err()方法明明可以用读锁（RLock），却用了完整的互斥锁：

func (c *cancelCtx) Err() error {
    c.mu.Lock()
    err := c.err
    c.mu.Unlock()
    return err
}

原因主要有以下几点：

锁的开销与场景适配：读写锁（RWMutex）的实现比普通互斥锁更复杂，需要维护读锁计数、处理读写互斥逻辑，内存和执行开销都更高。对于cancelCtx来说，核心操作是取消（写操作），读操作（比如调用Err()、Done()）的频率并没有高到足以抵消RWMutex的额外开销。而且一旦触发取消操作，所有持有读锁的goroutine都要等待，这种场景下RWMutex的优势并不明显。
逻辑简化与避免错误：cancelCtx的很多操作并非单一的读或写，比如取消操作需要同时修改children、err并处理done字段；Done()方法的懒加载逻辑（初始化chan）本质也是写操作。如果用RWMutex，需要区分读写锁场景，还要处理读锁升级写锁的安全问题（Go中不允许直接升级，必须先解锁读锁再加写锁），会让代码逻辑变得复杂，增加出错概率。用普通Mutex可以统一所有操作的锁逻辑，代码更简洁可靠。
维护成本优先：err字段一旦被设置（取消时）就不会再修改，理论上读操作可以不加锁，但单独为这类特殊场景做优化会增加代码复杂度。用统一的互斥锁能确保所有操作的线程安全，后续维护成本更低。

内容的提问来源于stack exchange，提问作者Ivan Velichko