---
tags: [go/lang, sync-primitives, futex, double-check-locking, rwmutex-starvation]
create time: 2026-08-08 19:00
update time: 2026-08-08 19:00
---

# Sync 包核心源码

## 概述

sync 包提供了 Go 中最基础的并发原语：Mutex、RWMutex、WaitGroup、Once、Map 和 Pool。这些看似简单的组件背后隐藏着大量系统级优化——futex 机制、写饿死模式、反溢出设计、双检锁等。理解它们的源码实现，有助于在实际编码中做出正确的选择，避免不必要的性能陷阱。

> [!NOTE] 使用原则
> sync 包的每个组件都针对特定场景做了极致优化。不要自己发明新的同步原语——用现成的、经过充分测试的工具，出了问题有人背锅。

## 核心原理

### sync.Mutex — futex 机制下的互斥锁

Go 的 mutex 不是简单的自旋锁，而是结合 futex（fast userspace mutex）的自适应锁。状态由 `state` 字段三个位控制：

```
state[31]:  locked 位 (1 = 持有中)
state[30]:  waiter 位 (1 = 有等待者)
state[0-29]: 等待者数量
```

加锁流程采用两阶段策略：

```mermaid
flowchart TD
    A["atomic CAS state 0"] --> B{"成功?"}
    B -->|是| C["获得锁, return"]
    B -->|否| D["slowLock调用"]
    
    D --> E["设置 locked+waiter 位"]
    E --> F["gopark 进入睡眠"]
    F --> G["被唤醒: 解锁者调用了 unlock"]
    G --> H["重新竞争或直接获得"]
    
    style C fill:#c8e6c9
    style F fill:#fff3e0
```

**快路径**：通过 atomic CAS 尝试将 state 设为 locked。如果竞争不激烈，几乎零开销就拿到锁。

**慢路径**：当 CAS 失败时调用 `slowLock`，将自己包装成 sudog 放入等待队列并休眠。这种设计让高竞争下不会浪费 CPU 周期去自旋。

> [!TIP] 面试常考点
> Go 1.9 引入的 Mutex 实现了自适应自旋：在低竞争时会短暂地自旋（几微秒），在高竞争时立即休眠。这个阈值 runtime 自动调节。

### sync.RWMutex — 写饿死 starving 模式

RWMutex 支持多读单写，但有一个特殊模式：**写饥饿（write starvation）**。

正常模式下，新来的读者会和已持有的读者共享锁，这可能导致_writer_ 永远等不到写权限（reader  starvation）。写饿死模式解决了这个问题：

```go
// RWMutex state 布局
state[0]:      locked (mutex 是否被 writer 持有)
state[1-8]:    reader count (当前读者数)
state[9-24]:   waiter count (等待写锁的数量)
state[25]:     expired (writer semaphore 信号量标志)
state[26-30]:  reserved
state[31]:     starving mode (1 = 饥饿模式)
```

饥饿模式的触发和解除：

| 条件 | 操作 |
|------|------|
| waiter >= 1 且等待时间 > 1ms | 切换到饥饿模式 |
| 锁转让给等待队列最前面的 writer | 在饥饿模式下直接移交，不给后续读者 |
| 所有等待者一次性全部满足 | 解除饥饿模式，回到正常模式 |

```mermaid
flowchart LR
    A["普通模式"] -->|"writer等太久"| B["饥饿模式"]
    B -->|"锁移交给队首writer"| C["其他reader被挡在外面"]
    C -->|"等待者全部唤醒"| A
    
    style A fill:#e3f2fd
    style B fill:#fff3e0
    style C fill:#ffe0b2
```

> [!WARNING] 常见误区
> RWMutex 的 ReadRlock / RUnlock 不是可重入的。一个 goroutine 已经持有读锁后再次请求会死锁。这与 Java 的 ReentrantReadWriteLock 不同。

### sync.WaitGroup — 反 overflow 设计

WaitGroup 内部用 int64 的两个半段分别表示 counter 和 waiters：

```
int64:
  high 32 bits: counter (goroutine数量)
  low 32 bits:  waiters (阻塞在Wait()的数量)
```

为什么要分两段？为了防止 counter overflow。如果只用单一 int32 来表示 counter：

- 当 counter 从 1 减到 0 时调用 Wait()
- 另一个 goroutine 立刻 Add(1) 再 Done()
- counter 绕回 0，导致 Wait() 误认为计数为 0 而提前返回

分高低位后，Add 只能减少高位，Wait 只能增加低位，两者不会互相干扰。

```go
func main() {
    var wg sync.WaitGroup
    wg.Add(3)
    
    for i := 0; i < 3; i++ {
        go func() {
            doWork()
            wg.Done() // counter--, 可能产生负值? 不会!
        }()
    }
    
    wg.Wait() // 阻塞直到 counter == 0
}
```

> [!TIP] 注意事项
> WaitGroup 不可复制！Copy 后的 WaitGroup 与原 WaitGroup 共享同一个计数器副本，行为不可预测。正确做法是用指针传递或在 goroutine 创建前定义 WaitGroup。

### sync.Once — 双检锁（Double-Check Locking）

Do 方法确保传入的函数只执行一次：

```go
func (o *Once) Do(f func()) {
    if atomic.LoadUint32(&o.done) == 0 {
        o.doSlow(f)
    }
}

func (o *Once) doSlow(f func()) {
    o.m.Lock()
    defer o.m.Unlock()
    if o.done == 0 { // 二次检查
        defer atomic.StoreUint32(&o.done, 1)
        f()
    }
}
```

两层检查的精妙之处：
1. **第一层无锁快速路径**：大部分情况下 done 已经是 1，直接 return，零锁开销
2. **第二层防重复**：即使多个 goroutine 同时通过了第一层检查，只有第一个能进入 f()

> [!NOTE] panic 的处理
> 如果 f() panic，Once 认为执行已完成（done=1），不会再重试。这意味着 panic 是一次性的，后续调用直接跳过 f()。如果需要重试语义，应自行包装。

### sync.Map — 读写分离架构

sync.Map 的内部结构体现了典型的"读多用 map、写多用 dirty map"分离思想：

```
sync.Map 包含:
├── readOnly:  {elem: map[K]V, amended: bool}  ← 读专用，线程安全只读
├── dirty:    {elem: map[K]V, missed: int}      ← 写专用，需要互斥锁保护
└── deleted:  sentinel value in readOnly         ← 标记已删除
```

amended flag 的作用是关键：
- `amended=false` 时，读取只查 readOnly（无锁快速路径）
- `amended=true` 时，读取先查 readOnly，miss 再去 dirty 查找，并把 missing key 预热到 readOnly
- 当 `dirty == nil` 或 `missed >= 2^th` 时，将 dirty 提升为 readOnly

```mermaid
flowchart TD
    A["Load key"] --> B{"key in readOnly?"}
    B -->|是| C["命中! return val"]
    B -->|否| D{"amended == true?"}
    D -->|否| E["未找到, 返回 not-found"]
    D -->|是| F["查 dirty map"]
    F --> G{"key in dirty?"}
    G -->|是| H["预热到readOnly<br/>return val"]
    G -->|否| E
    
    style C fill:#c8e6c9
    style H fill:#e3f2fd
    style E fill:#ffcdd2
```

这种设计使得高频读取的场景下完全不需要持锁，性能远超 map + RWMutex。

## 代码示例

### Once 的安全延迟初始化

```go
var once sync.Once
var db *sql.DB

func GetDB() *sql.DB {
    once.Do(func() {
        db, _ = sql.Open("postgres", dsn)
        db.SetMaxOpenConns(25)
    })
    return db
}
```

Once 保证初始化代码在多 goroutine 环境下只执行一次，且后续调用零锁开销。

### WaitGroup + Channel 协作模式

```go
func fetchAll(urls []string) <-chan Result {
    out := make(chan Result, len(urls))
    var wg sync.WaitGroup
    
    for _, u := range urls {
        wg.Add(1)
        go func(url string) {
            defer wg.Done()
            out <- fetch(url)
        }(u)
    }
    
    go func() {
        wg.Wait()   // 等待所有请求完成
        close(out)  // 关闭 channel，通知接收方
    }()
    
    return out
}
```

这是一个经典的并发模式：WaitGroup 统计工作完成情况，Channel 收集结果。二者缺一不可。

## 实践场景

### 面试高频问题

**Q: Mutex 和 RWMutex 怎么选？**
- 读多写少 → RWMutex
- 读写比例接近 → Mutex
- 临界区代码极短 → Mutex（省了 RWMutex 额外的位运算开销）
- 不确定 → Mutex（更安全的选择）

**Q: WaitGroup 的 Add 可以在 Wait 之后调用吗？**
可以，但不推荐。这会导致 Wait 直接返回（counter=0），而后续的 Add 会引发 panic。正确模式是在启动 goroutine 前调用 Add。

**Q: sync.Once 能保证 f() 的执行顺序吗？**
不能保证哪个 goroutine 执行的 f()，只保证只有一个。在极少数高竞争场景下，可能多个 goroutine 同时进入 doSlow，但只有第一个真正执行 f()。

### 实战建议

- **优先用 select + ctx.Done() 代替 sync 原语**：现代 Go 编程中，context 驱动的取消模式通常比 manual waitgroup 更优雅
- **Pool 适合高频分配释放的场景**：如 HTTP request/response 复用
- **不要用 WaitGroup 做信号量**：那是 semaphore pattern，应该用 channel buffered size=1

## 扩展阅读

- [[Goroutine 调度模型]] — sync 原语的底层阻塞由 GMP 调度器驱动
- [[Select 多路复用机制]] — select-case 可与 WaitGroup 配合实现复杂的并发协调
- [[Context 包详解]] — context 与 sync 原语组合使用是标准的并发模式