Когда вы используете пакет sync вместо channels?

Question

Accepted Answer

Go предлагает два подхода к безопасности параллелизма: **channels** («делиться памятью путём общения») и пакет **`sync`** (мьютексы/блокировки для прямой защиты общей памяти). Несмотря на философию Go, ориентированную на channels, примитивы 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` гарантирует, что только одна горутина одновременно получает доступ к защищённым данным, предотвращая гонки данных. Паттерн `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` — правильный, идиоматичный инструмент для **защиты общего состояния** (счётчики, кэши, отображения): мьютексы для исключительного доступа, `RWMutex` для данных с интенсивным чтением, `WaitGroup` для ожидания горутин, `Once` для инициализации один раз, и `atomic`/`sync.Map` для специальных случаев.

Понимание того, что channels отлично подходят для *общения и координации*, а примитивы sync отлично подходят для *защиты общей памяти* — и выбор подходящего инструмента вместо догматического использования channels — приводит к более простому, эффективному и правильному параллельному коду.

Это суждение — именно то, что отличает опытных разработчиков Go, и является частой темой продвинутого интервью.