你什么时候使用 sync 包而不是 channels？

Question

Accepted Answer

Go 提供两种并发安全方法：**channels**（"通过通信共享内存"）和 **`sync` 包**（用互斥锁/锁直接保护共享内存）。尽管 Go 推崇 channel-first 的理念，但 sync 原语通常是保护共享状态更简单、更高效的选择。

## sync.Mutex — 用锁保护共享状态

```go
type Counter struct {
    mu    sync.Mutex
    count int
}

func (c *Counter) Increment() {
    c.mu.Lock()           // acquire the lock — only one goroutine at a time past here
    defer c.mu.Unlock()    // release on return (defer ensures it always happens)
    c.count++              // safe — protected critical section
}
```

`Mutex` 确保一次只有一个 goroutine 能访问受保护的数据，防止数据竞争。`Lock()`/`defer Unlock()` 模式是惯用法。

## sync.RWMutex — 多个读者或一个写者

```go
type Cache struct {
    mu   sync.RWMutex
    data map[string]string
}
func (c *Cache) Get(key string) string {
    c.mu.RLock()           // READ lock — multiple readers allowed concurrently
    defer c.mu.RUnlock()
    return c.data[key]
}
func (c *Cache) Set(key, value string) {
    c.mu.Lock()            // WRITE lock — exclusive
    defer c.mu.Unlock()
    c.data[key] = value
}
```

`RWMutex` 允许并发读取但独占写入——非常适合像缓存这样的读密集数据。

## 其他 sync 原语

```go
sync.WaitGroup           // wait for a group of goroutines to finish (Add/Done/Wait)
sync.Once                // run something EXACTLY once (lazy init, singletons)
  var once sync.Once
  once.Do(initialize)    // initialize runs only on the first call, ever
sync.Map                 // a concurrent map (specialized cases)
atomic.AddInt64(&n, 1)   // lock-free atomic operations for simple counters
```

## 何时使用 sync 与 channels

```text
Use sync (Mutex/RWMutex/atomic) when:
  ✓ Protecting simple shared STATE (a counter, a cache, a map)
  ✓ The logic is "guard this data" — locking is simpler and faster than channels here
  ✓ Read-heavy data (RWMutex), one-time init (Once), simple counters (atomic)

Use channels when:
  ✓ COMMUNICATING/passing data between goroutines, signaling, coordinating
  ✓ Pipelines, worker distribution, ownership transfer
```

实用规则：**"不要通过共享内存来通信"是一条指导方针，而非教条。** 对于简单的共享状态保护，互斥锁比为了使用 channels 而扭曲逻辑更清晰、更高效。

## 为什么这很重要

知道何时使用 `sync` 包而不是 channels 是 Go 并发成熟度的关键标志。

虽然 Go 推广 channels（"通过通信共享内存"），但这只是一条指导方针——常见的错误是在应该使用简单 **互斥锁** 的地方强行使用 channels，而互斥锁会更清晰且更快。

`sync` 包是保护共享状态（计数器、缓存、map）的正确、惯用工具：`Mutex` 用于独占访问，`RWMutex` 用于读密集数据，`WaitGroup` 用于等待 goroutine，`Once` 用于一次性初始化，`atomic`/`sync.Map` 用于特殊场景。

理解 channels 擅长于**通信和协调**，而 sync 原语擅长于**保护共享内存**——并选择合适的工具而不是教条般地使用 channels——会导致更简洁、更高效、更正确的并发代码。

这种判断力正是区分有经验的 Go 开发者的特征，也是频繁出现的高级面试话题。