Golang公平锁与非公平锁解析及sync包实现原理

Go 的 `sync.Mutex` 默认采用非公平锁设计，允许新到来的 goroutine 直接抢占刚释放的锁，以此减少上下文切换、提升高并发场景下的吞吐量（实测高出15%~30%）和尾延迟；虽不保证“先到先得”的执行顺序，可能引发轮转逻辑错乱或调试困惑，但这是 Go 团队在性能与公平性之间做出的明确权衡——真正制约系统性能的往往不是锁是否公平，而是过大的锁粒度、过长的持有时间（尤其锁内 IO）、或未被察觉的调度阻塞；若业务强依赖 FIFO 顺序，可通过 `sync.Cond` + `sync.Mutex` 自定义轻量级公平锁，但更根本的优化应聚焦于锁拆分、无锁结构选型及借助 `go tool trace` 和 `pprof -mutex` 定位真实瓶颈。

Go 的 sync.Mutex 默认是非公平锁

它不保证 goroutine 等待时间越长就越先获得锁，新来的 goroutine 可能直接抢到刚释放的锁，跳过排队队列。这不是 bug，是设计选择：减少上下文切换、提升吞吐。但如果你依赖“先到先得”，比如做资源轮转或调试时观察执行顺序，就会发现行为不符合直觉。

常见错误现象：goroutine A 先 Lock()，B 和 C 几乎同时阻塞等待，结果 C 却比 B 先拿到锁——没有报错，但逻辑被打破。

• 非公平性在高并发争抢下更明显，低负载时可能“碰巧”像公平锁
• sync.Mutex 没有公开接口切换公平/非公平模式，不能通过参数配置
• 它的内部用到了 atomic.CompareAndSwapInt32 尝试快速获取，失败才进 sema 队列，这一步就是非公平性的来源

为什么 Go 不提供公平锁作为默认选项

公平锁必须维护一个 FIFO 等待队列，并在每次解锁时唤醒队首 goroutine。这带来两个实际开销：

• 每次 Unlock() 都要原子地操作队列头，比单纯发信号（semaphore signal）慢
• 唤醒 goroutine 后它未必立刻执行（调度延迟），队列里其他 goroutine 白等，CPU 缓存局部性也变差

实测中，在典型 Web handler 场景下，非公平 sync.Mutex 比模拟的公平版本吞吐高 15%~30%，延迟 P99 低约 20%。Go 团队权衡后认为：多数业务代码不依赖获取顺序，性能收益更实在。

注意：sync.RWMutex 同样是非公平的，且读锁和写锁之间也不保序——写锁可能插在一堆读锁中间，导致“写饥饿”（虽然 Go 1.18+ 加了简单退避缓解）。

想实现公平锁？别改 sync.Mutex，自己封装 sync.Cond + sync.Mutex

Go 标准库没给公平锁，但你可以用 sync.Cond 显式控制唤醒顺序。核心思路：用一个全局 sync.Mutex 保护等待队列，每个等待者入队后 Wait()，解锁者只唤醒队首。

type FairMutex struct {
    mu    sync.Mutex
    cond  *sync.Cond
    queue []int64 // 仅存 seq 编号，避免存储 goroutine 指针
    seq   int64
}

func (f *FairMutex) Lock() {
    f.mu.Lock()
    mySeq := atomic.AddInt64(&f.seq, 1)
    f.queue = append(f.queue, mySeq)
    for f.queue[0] != mySeq {
        f.cond.Wait()
    }
    // 此刻必为队首，可安全持有 f.mu
}

func (f *FairMutex) Unlock() {
    f.mu.Lock()
    f.queue = f.queue[1:]
    if len(f.queue) > 0 {
        f.cond.Signal()
    }
    f.mu.Unlock()
}

关键点：

• 必须用 sync.Cond 而不是 runtime.Gosched() 或循环重试，否则 CPU 空转
• 队列用 int64 记序号比存 chan struct{} 更轻量，避免 goroutine 泄漏风险
• 这个实现仍受调度器影响：被 Signal() 唤醒的 goroutine 不一定立刻运行，只是“获得资格”

真正该警惕的不是公平性，而是锁粒度和持有时间

很多人纠结公平 vs 非公平，却忽略更常引发问题的点：锁持有太久、锁范围包太多逻辑、或在锁内做 IO/网络调用。

• sync.Mutex 在 goroutine 阻塞时会自动让出 P，但若你在锁里调 http.Get()，整个 P 就卡住，拖慢其他 goroutine
• 用 go tool trace 查 sync runtime.semacquire 占比高，往往说明锁争抢严重，此时换公平锁只会更慢
• 真正有效的优化通常是：拆分大锁为多个细粒度锁、用 sync.Map 替代带锁的 map、或改用无锁结构如 ringbuffer

公平性只是表象，锁背后的调度、内存可见性、GC 压力才是暗处的水位线。看 go tool pprof -mutex 输出比争论“该不该公平”有用得多。

今天带大家了解了的相关知识，希望对你有所帮助；关于Golang的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~