Модуль 5 ⏱ ~24 мин чтения 📐 3 Mermaid диаграмм

40. sync.WaitGroup, Mutex, RWMutex

«Управление сложностью — вот суть программирования».
— Брайан Керниган

В предыдущих статьях мы возносили дифирамбы каналам и парадигме CSP. Из-за этого у начинающих разработчиков иногда складывается ложное впечатление, будто в идиоматичном Go нет места классическим примитивам синхронизации и мьютексам. Это опасное заблуждение.

Создатели языка, и в частности Роб Пайк, всегда подчеркивали: «Используйте то, что проще и выразительнее».

Каналы идеально подходят для передачи владения данными, конвейерной обработки (pipelines) и оркестрации жизненного цикла. Но если вам нужно просто защитить in-memory кэш (например, map) от одновременной записи или подождать завершения пула воркеров, использование каналов сделает код переусложненным, медленным и многословным. В таких сценариях на сцену выходит пакет sync.

1. sync.WaitGroup: Оркестрация горутин

Когда вы запускаете фоновые горутины, функция main (или родительская горутина) не будет их ждать. Если main завершится, рантайм Go жестко убьет все фоновые процессы процесса ОС. sync.WaitGroup — это потокобезопасный счетчик, который решает проблему барьерной синхронизации.

Основных методов у него три:

Add(int) — увеличивает счетчик (сколько горутин мы ждем).
Done() — уменьшает счетчик на 1 (вызывается внутри горутины при завершении).
Wait() — блокирует текущую горутину, пока счетчик не станет равен 0.

А с Go 1.25 есть ещё Go(f func()): он сам делает Add(1), запускает f в новой горутине и вызывает Done() по её завершении — так ошибиться с порядком Add (см. ловушку ниже) уже нельзя.

Под капотом: Атомики и Семафоры

Под капотом: Устройство WaitGroup

Начиная с Go 1.20, структура WaitGroup была упрощена и выглядит так (сам тип atomic.Uint64 появился в Go 1.19):

type WaitGroup struct {
    noCopy noCopy        // Маркер для go vet, запрещающий копирование
    state  atomic.Uint64 // 64-битное состояние (счетчик + ждущие)
    sema   uint32        // Семафор для парковки горутин
}

Гениальность заключается в поле state. Это одно 64-битное число, которое логически разделено на две части:

Верхние 32 бита: Счетчик самих горутин (изменяется через Add и Done).
Нижние 32 бита: Счетчик ожидающих (waiters), то есть количество горутин, вызвавших Wait(). (С Go 1.25 под счётчик ожидающих отведены младшие 31 бит, а бит 31 занят флагом пакета testing/synctest.)

Когда вызывается Done(), рантайм делает атомарное вычитание из верхних 32 бит. Если счетчик становится равен нулю, рантайм смотрит на нижние 32 бита и вызывает runtime_Semrelease ровно столько раз, сколько горутин ждут на семафоре, мгновенно их пробуждая.

flowchart LR
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    subgraph State64["Поле state (atomic.Uint64)"]
        High["Верхние 32 бита:<br>Счетчик горутин (Add/Done)"]
        Low["Нижние 32 бита:<br>Счетчик ждущих waiters (Wait)"]
    end
    High -->|"При равенстве 0"| Sema["Семафор sema:<br>runtime_Semrelease"]

Ловушка / Gotcha: Race Condition с Add()

Абсолютная классика собеседований и багов в продакшене:

var wg sync.WaitGroup
for i := 0; i < 10; i++ {
    go func() {
        wg.Add(1) // ОШИБКА: Add вызывается внутри горутины!
        defer wg.Done()
        // ...работа...
    }()
}
wg.Wait()

Почему это сломается? Планировщик Go не гарантирует мгновенный запуск горутины. Главный поток может дойти до wg.Wait(), увидеть, что счетчик равен 0 (потому что ни одна горутина еще не успела проснуться и сделать Add(1)), и мгновенно завершить работу программы.
Правильно: wg.Add(1) всегда должен вызываться до ключевого слова go.

2. sync.Mutex: Эксклюзивная блокировка

Mutex (Mutual Exclusion) гарантирует, что только одна горутина может находиться в критической секции (например, при записи в map, которая в Go не является потокобезопасной).

Mechanical Sympathy: Fast Path против Slow Path

Системные вызовы для блокировки потоков ОС (futex в Linux) — это очень дорого. Поэтому sync.Mutex в Go использует гибридный подход.

У мьютекса есть два пути захвата:

Fast Path (Быстрый путь): Горутина пытается атомарно (с помощью процессорной инструкции Compare-And-Swap, CAS) изменить состояние мьютекса в User Space. Если мьютекс был свободен, операция занимает около 20 тактов CPU. Никаких обращений к ОС не происходит.
Slow Path (Медленный путь): Если мьютекс занят, горутина не засыпает сразу. Она делает Spinning (Активное ожидание) — несколько раз крутит пустой цикл процессора (инструкция PAUSE), надеясь, что мьютекс вот-вот освободится. И только если спиннинг не помог, горутина заносится в очередь ожидания семафора и паркуется (runtime.gopark), освобождая системный тред (M) для других горутин.

flowchart TD
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    A["Захват Mutex"]:::warning --> B{"Свободен? CAS-операция"}
    B -->|"Да"| C["Fast Path<br>Захват за 20 тактов CPU"]
    B -->|"Нет"| D["Slow Path<br>Spinning - активное ожидание"]
    D --> E{"Удалось захватить?"}
    E -->|"Да"| C
    E -->|"Нет"| F["Парковка горутины<br>Очередь семафора"]

Starvation Mode (Режим голодания)

Собеседование

Вопрос: Что такое режим голодания (Starvation) в sync.Mutex и зачем он нужен?
Ответ: До Go 1.9 новые горутины, приходящие за мьютексом, имели преимущество перед теми, кто уже давно ждал в очереди семафора, потому что новые горутины уже находились на процессоре (крутили Спиннинг) и быстрее перехватывали освобожденный мьютекс через CAS. Это приводило к Tail Latency — старые горутины могли ждать блокировки секундами.

В Go 1.9 добавили Starvation Mode. Если горутина ждет мьютекс дольше 1 миллисекунды, мьютекс переходит в режим голодания. В этом режиме:

Новые горутины вообще не пытаются захватить мьютекс (Спиннинг отключается).
При освобождении мьютекса (Unlock), блокировка передается строго напрямую первой горутине в очереди ожидания.
Режим отключается, когда очередь пустеет или горутина ждала меньше 1 мс.

Ловушка / Gotcha: Копирование Mutex

Мьютекс — это структура со счетчиками. Если вы передадите её по значению (by value), вы скопируете текущее состояние блокировки, создав совершенно новый, независимый мьютекс.

type Cache struct {
    mu   sync.Mutex
    data map[string]string
}

// ОШИБКА: метод с Value Receiver копирует структуру и мьютекс!
func (c Cache) Set(k, v string) { ... }

Всегда используйте указатели (Pointer Receiver) для структур, содержащих примитивы синхронизации. Компилятор такой код пропустит, но go vet (анализатор copylocks) находит эту ошибку, выдавая passes lock by value.

Ограничения Mutex и RWMutex

Мьютексы в Go нереентерабельны: повторный Lock() в той же горутине, уже держащей мьютекс, — гарантированный deadlock.
RLock() нельзя брать рекурсивно: если между двумя RLock() одной горутины писатель вызовет Lock(), он заблокирует новых читателей — и второй RLock() повиснет навсегда.
«Повысить» RLock() до Lock() нельзя: сначала RUnlock(), затем Lock() (и заново проверить состояние).
Unlock() незахваченного мьютекса — неперехватываемая fatal error: sync: unlock of unlocked mutex.
Методы TryLock() (Go 1.18) существуют, но нужны редко; частое их использование обычно говорит о проблеме в дизайне.

3. sync.RWMutex: Разделение чтения и записи

Если ваши данные обновляются редко (например, конфиги или In-Memory словарь), но читаются тысячами горутин одновременно, использование обычного Mutex убьет пропускную способность: читатели будут выстраиваться в очередь друг за другом.

Для этого существует sync.RWMutex (Read-Write Mutex):

RLock() / RUnlock() — захват для чтения. Множество горутин могут владеть им одновременно.
Lock() / Unlock() — эксклюзивный захват для записи. Блокирует и новых читателей, и новых писателей.

Механика работы под капотом

Как Lock() предотвращает появление новых читателей, пока ждет завершения старых?
В RWMutex есть счетчик readerCount (атомарный int32).
Когда приходит писатель, он делает хитрый трюк: вычитает из readerCount константу rwmutexMaxReaders (равную $2^{30}$).
Счетчик становится отрицательным!
Новые читатели видят отрицательное число и сразу уходят в очередь ожидания. При этом писатель точно знает количество старых читателей (прибавив константу обратно) и ждет, пока они не вызовут RUnlock().

flowchart TD
    classDef process  fill:#1e293b,stroke:#38bdf8,stroke-width:1px,color:#f8fafc
    classDef success  fill:#064e3b,stroke:#34d399,stroke-width:1px,color:#f8fafc
    classDef error    fill:#7f1d1d,stroke:#f87171,stroke-width:1px,color:#f8fafc
    classDef warning  fill:#78350f,stroke:#fbbf24,stroke-width:1px,color:#f8fafc
    classDef entry    fill:#1e3a5f,stroke:#38bdf8,stroke-width:2px,color:#f8fafc
    classDef aux      fill:#334155,stroke:#64748b,stroke-width:1px,color:#f8fafc
    classDef system   fill:#312e81,stroke:#a78bfa,stroke-width:1px,color:#f8fafc
    classDef data     fill:#132d29,stroke:#2dd4bf,stroke-width:1px,color:#f8fafc
    classDef network  fill:#881337,stroke:#fb7185,stroke-width:1px,color:#f8fafc
    classDef accent   fill:#1e1b4b,stroke:#818cf8,stroke-width:1px,color:#f8fafc
    subgraph RWMutexState["Состояние RWMutex"]
        W["Писатель вызывает Lock()"]:::process --> Sub["readerCount -= rwmutexMaxReaders (2^30)"]
        Sub --> Neg{"readerCount < 0"}
        Neg -->|"Новые читатели"| WaitQueue["Уходят в очередь ожидания"]
        Neg -->|"Старые читатели"| Finish["Завершают работу через RUnlock()"]
        Finish --> UnlockWriter["Писатель получает эксклюзивный доступ"]
    end

Ловушка / Gotcha: RWMutex медленнее Mutex?

Существует инженерный миф, что RWMutex всегда лучше Mutex, если чтений больше. Это не так.
При каждом вызове RLock(), рантайм делает атомарный инкремент счетчика readerCount. Если у вас 64 физических ядра, и все они одновременно делают RLock(), кэш-линия процессора (L1 Cache Line), содержащая этот счетчик, будет постоянно инвалидироваться и пересылаться между ядрами (Cache Coherence Protocol, механизм MESI).
Из-за этого "прыгания" кэш-линии RWMutex может оказаться медленнее обычного Mutex, если критическая секция чтения очень короткая (например, просто чтение одного int из мапы).
RWMutex эффективен только тогда, когда чтение занимает существенное время (микросекунды). Всегда профилируйте код бенчмарками!

Итог

WaitGroup: Используйте для ожидания завершения пула фоновых задач. Вызывайте Add строго до старта горутины.
Mutex: Защищает критические секции. Использует гибридный подход (Спиннинг + Парковка). Имеет режим защиты от голодания (Starvation Mode).
RWMutex: Оптимизирует Read-Heavy нагрузки. Но берегитесь аппаратного ограничения — инвалидации кэш-линий при огромном количестве одновременных RLock().
Не копируйте блокировки: Примитивы из пакета sync всегда должны передаваться и использоваться по указателю.

Базовые примитивы покрывают 90% задач синхронизации. Но пакет sync таит в себе еще несколько продвинутых инструментов для хардкорной оптимизации и работы с памятью, которые отличают Senior разработчика от Middle. В следующей статье мы разберем паттерны синглтона, широковещательных сигналов, переиспользования аллокаций и работу без мьютексов вообще: 41. sync.Once, Cond, Pool и atomic.