Путь захвата

1. CAS(state, 0, locked) - успех, единицы наносекунд, дальше ничего не происходит.
2. Спин. Занят, но normal mode, ещё какой-то P работает (там, скорее всего, и владелец), а локальная очередь нашего P пуста - крутимся до 4 раз по 30 инструкций PAUSE. Дешевле, чем парковка, если владелец вот-вот отпустит.
3. Парковка. runtime_SemacquireMutex: горутина в _Gwaiting, поток ОС свободен и берёт другую работу. Это семафор рантайма, а не futex потока.
4. Пробуждение. В normal mode разбуженная горутина конкурирует с новичками и может проиграть: новички уже на CPU. В starvation mode Unlock отдаёт лок ей напрямую.

Два режима и порог 1 мс

• Normal: максимальная пропускная способность. Лок достаётся тому, кто ближе - кэш горячий, переключений меньше. Риск: старая горутина в очереди голодает.
• Starvation: включается, когда какая-то горутина прождала больше 1 мс (starvationThresholdNs). Строгий FIFO, спиннинг выключен, новые горутины сразу в хвост. Пропускная способность падает, зато хвост латентности перестаёт расти.
• Выход обратно в normal: очередь опустела либо очередной ждущий провёл в ней меньше 1 мс.

Повторный Lock

var mu sync.Mutex
mu.Lock()
mu.Lock()      // здесь горутина уходит в _Gwaiting навсегда

У мьютекса нет поля «владелец» - он не знает, кто его взял, и не может пропустить «своего». Горутина встаёт в очередь ожидания самой себя. Если это была единственная живая горутина, рантайм напечатает fatal error: all goroutines are asleep - deadlock!; если в программе есть другая работа - просто тихо зависнет одна горутина, и это утечка.

Как устроен

Внутри - Mutex w (очередь писателей между собой), readerCount int32, readerWait int32 и два семафора. RLock: атомарный инкремент readerCount; если результат неотрицательный - сразу внутрь. Lock: берём w, потом вычитаем из readerCount константу rwmutexMaxReaders = 1<<30, делая счётчик отрицательным, и ждём, пока уже вошедшие читатели выйдут.

Когда даёт выигрыш

• Читателей на порядок больше писателей и критическая секция длинная (десятки микросекунд и больше): парсинг, обход структуры, сериализация под локом.
• Не даёт выигрыша на «прочитать одно поле»: атомарных операций у читателя столько же, сколько у Mutex (по одной на RLock и RUnlock), и обе пишут в общий readerCount. На секции в 20 нс читатели почти всё время толкаются за эту кэш-линию, и параллелизма не выходит, а без конкуренции пара RLock/RUnlock даже чуть дороже: 3,3 нс против 1,9 нс (M4 Pro, go1.27).
• Бывает и хуже при большом числе ядер: readerCount лежит в одной кэш-линии, и десятки ядер, инкрементящих её, устраивают cache line bouncing. В таких случаях выигрывает шардирование (свой мьютекс на каждый шард) или атомарный снимок через atomic.Pointer (copy-on-write).

Write starvation

Если пускать читателей всегда, пока readerCount > 0, сплошной поток чтений закроет писателю дорогу навсегда. Go решает это тем, что Lock сразу уводит readerCount в минус: все новые RLock уходят спать, писатель дожидается только тех, кто уже внутри. Голодания писателя нет. Обратная сторона: при плотном потоке писателей подтормаживают уже читатели, но это честная очередь.

// 1. Рекурсивный RLock. Если между строками встрял писатель:
mu.RLock()
mu.RLock()      // блокируется: писатель уже увёл readerCount в минус
                // а писатель ждёт нас -> deadlock

// 2. «Апгрейд» блокировки - его не существует
mu.RLock()
mu.Lock()       // Lock ждёт выхода читателей, включая нас самих
// Правильно: RUnlock -> Lock -> ПЕРЕПРОВЕРИТЬ состояние, оно могло измениться

Что именно ломается

• Копия залоченного. В state стоит бит locked, но отпускать эту копию никто не будет - оригинал разблокирует себя, а не её. Первый же Lock на копии виснет навсегда.
• Копия разлоченного. Две горутины берут разные мьютексы и спокойно лезут в одни и те же данные. Синхронизации нет, а выглядит код правильным - race detector такое поймает, а глаз обычно нет.
• Счётчик waiters тоже копируется: у копии он говорит, что кто-то ждёт, хотя на семафоре копии не спит никто. Unlock попытается разбудить несуществующего ждущего.

Где копирование происходит незаметно

type S struct {
    mu sync.Mutex
    n  int
}

func (s S) Bad() {}            // 1) метод на значении копирует при каждом вызове
func f(s S) {}                 // 2) аргумент по значению
func g() S { return S{} }      // 3) возврат по значению (пустой можно, живой нельзя)
var a, b S; a = b              // 4) присваивание
m := map[string]S{}            // 5) значения мапы вообще неадресуемы
for _, s := range []S{{}, {}} {}  // 6) range копирует элемент
var i any = s                  // 7) упаковка в интерфейс копирует
go f(s)                        // 8) аргумент go-вызова копируется в момент запуска

go vet copylocks

Анализатор copylocks входит в базовый набор go vet, но в урезанный набор, который go test гоняет сам, не входит: его запускают явно, go vet ./... в CI. Он ищет копирование любого типа, реализующего sync.Locker или содержащего такой тип на любой глубине: Mutex, RWMutex, WaitGroup, Cond, Once, Pool, atomic.Int64 и остальные типы atomic из Go 1.19. Сообщение выглядит как call of f copies lock value: S contains sync.Mutex.

Как устроена

Три значения: счётчик активных задач, счётчик ждущих в Wait и семафор. Add(n) прибавляет к счётчику, Done() это Add(-1). Когда счётчик доходит до нуля, все ждущие в Wait просыпаются через runtime_Semrelease. Счётчик ушёл в минус: паника sync: negative WaitGroup counter.

Четыре классические ошибки

// 1) Add внутри горутины даёт гонку: Wait может увидеть 0 раньше старта
for _, u := range urls {
    go func() { wg.Add(1); defer wg.Done(); fetch(u) }()   // неправильно
}
wg.Wait()   // может вернуться мгновенно, ничего не дождавшись

// 2) WaitGroup скопирован: у функции своя копия счётчика
func work(wg sync.WaitGroup) { defer wg.Done() }           // неправильно
func work(wg *sync.WaitGroup) { defer wg.Done() }          // правильно

// 3) Done без defer: паника внутри горутины навсегда подвесит Wait
go func() { fetch(u); wg.Done() }()                        // неправильно

// 4) WaitGroup переиспользуют до возврата Wait
wg.Add(1); go f(); go func(){ wg.Wait() }(); wg.Add(1)     // неправильно:
// panic: WaitGroup is reused before previous Wait has returned

Правильный шаблон и Go 1.25

// До 1.25
var wg sync.WaitGroup
for _, u := range urls {
    wg.Add(1)
    go func() {
        defer wg.Done()
        fetch(u)
    }()
}
wg.Wait()

// Go 1.25: Add, go и Done в одном вызове
var wg sync.WaitGroup
for _, u := range urls {
    wg.Go(func() { fetch(u) })
}
wg.Wait()

wg.Go(f) внутри делает wg.Add(1), запускает горутину и через defer вызывает wg.Done(), когда f вернётся, - то есть ошибки 1, 3 и частично 2 становятся невозможными. Панику внутри f он не перехватывает: она по-прежнему роняет процесс. А Done при панике он с Go 1.26 намеренно не зовёт: иначе Wait проснулся бы и main мог успеть завершиться раньше, чем паника уронит процесс. Документация прямо требует, чтобы f не паниковала.

import "golang.org/x/sync/errgroup"

func fetchAll(ctx context.Context, urls []string) ([]Result, error) {
    g, ctx := errgroup.WithContext(ctx)   // ctx отменится при первой ошибке
    g.SetLimit(8)                          // максимум 8 одновременных горутин
    results := make([]Result, len(urls))   // пишем по индексу, гонки нет

    for i, u := range urls {
        g.Go(func() error {
            r, err := fetch(ctx, u)        // ctx уже отменяемый
            if err != nil {
                return fmt.Errorf("fetch %s: %w", u, err)
            }
            results[i] = r
            return nil
        })
    }
    if err := g.Wait(); err != nil {       // вернёт первую ошибку
        return nil, err
    }
    return results, nil
}

Что даёт сверх WaitGroup

• Ошибки. g.Go принимает func() error, а g.Wait() возвращает первую ненулевую (остальные отбрасываются).
• Отмена по первой ошибке. errgroup.WithContext возвращает производный контекст; как только любая функция вернула ошибку, он отменяется, и все остальные горутины должны сами это увидеть по ctx.Done().
• SetLimit(n). Встроенный семафор на канале ёмкости n. g.Go при исчерпании лимита блокируется, пока не освободится слот; g.TryGo - неблокирующая версия, возвращает false. SetLimit нужно вызывать до первого Go.
• Паника не перехватывается. recover() внутри errgroup нет, и паника в любой горутине группы роняет процесс - Wait до неё не доживёт. Перехват недолго существовал в x/sync v0.14–v0.15 и был откачен сознательно. Если фоновая работа может паниковать, recover пишут сами, внутри переданной в Go функции.

type Once struct {
        done atomic.Bool               // с Go 1.25; раньше atomic.Uint32
    m    Mutex
}

func (o *Once) Do(f func()) {
    if !o.done.Load() {            // fast path: ~1 нс, без лока
        o.doSlow(f)
    }
}

func (o *Once) doSlow(f func()) {
    o.m.Lock()
    defer o.m.Unlock()
    if !o.done.Load() {            // double-check уже под локом
        defer o.done.Store(true)   // после f, а не до
        f()
    }
}

Три вопроса, которые задают следом

• Почему done ставится после f? Если бы до, вторая горутина увидела бы done == true и пошла работать с наполовину проинициализированным объектом. Сейчас она блокируется на мьютексе и выходит из Do только когда f реально закончила. Это и есть гарантия «после возврата из Do инициализация завершена».
• Что если f запаникует? done всё равно выставится (это defer), и повторный Do ничего не сделает. Логика «повторить при ошибке» через Once не выражается - нужен singleflight или собственный флаг.
• Почему нельзя просто if !inited { init(); inited = true }? Это data race: два потока увидят false и вызовут init дважды, а без синхронизации ещё и не увидят чужой записи вообще.

Обёртки Go 1.21

// OnceFunc: просто «выполнить один раз»
initLog := sync.OnceFunc(func() { setupLogging() })

// OnceValue: ленивое значение
config := sync.OnceValue(func() *Config { return mustLoadConfig() })
cfg := config()                        // первый вызов грузит, остальные возвращают готовое

// OnceValues: значение и ошибка
loadDB := sync.OnceValues(func() (*sql.DB, error) { return sql.Open(...) })
db, err := loadDB()

Как устроен

У каждого P - свой poolLocal с приватным слотом (доступ вообще без синхронизации) и локальной очередью, из которой другие P могут воровать. Поэтому Get/Put почти бесплатны и хорошо масштабируются по ядрам. Если ничего не нашлось - вызывается New.

Связь с GC - самое важное

1. При старте цикла GC хук poolCleanup проходит по всем пулам.
2. Текущие локальные наборы переезжают в victim-кэш, а старые victim выбрасываются насовсем.
3. Get сначала смотрит в свой primary, потом ворует у соседей, потом лезет в victim, и только потом зовёт New.

Итог: объект живёт в пуле максимум два цикла GC. Victim-кэш появился в Go 1.13 именно чтобы убрать провал производительности сразу после сборки, когда пул опустошался целиком и все шли в New.

var bufPool = sync.Pool{New: func() any { return new(bytes.Buffer) }}

func render(w io.Writer, data any) error {
    buf := bufPool.Get().(*bytes.Buffer)
    buf.Reset()                       // обязательно: в пуле лежит грязный объект
    defer bufPool.Put(buf)
    if err := tmpl.Execute(buf, data); err != nil {
        return err
    }
    _, err := w.Write(buf.Bytes())
    return err
}

// Для слайсов кладут указатель, иначе каждый Put аллоцирует
var slicePool = sync.Pool{New: func() any { s := make([]byte, 0, 4096); return &s }}

Механика

• read - структура readOnly{m map[K]*entry, amended bool}, заменяемая целиком одним atomic.Store. Чтение существующего ключа - атомарная загрузка указателя и обычный доступ к мапе. Лока нет вообще.
• amended = «в dirty есть ключи, которых нет в read». Если false и ключ не найден в read - можно сразу возвращать «нет», не трогая мьютекс.
• dirty - обычная мапа под мьютексом. Содержит все актуальные ключи. Все новые ключи попадают только сюда.
• misses - счётчик промахов мимо read. Когда misses >= len(dirty), происходит промоушен: dirty становится новой read, dirty = nil, misses = 0.
• Следующая запись нового ключа заново копирует всю read в dirty - операция O(n) под мьютексом.
• Delete не удаляет сразу: ставит в entry nil. При очередном пересоздании dirty такие записи помечаются expunged и в неё не копируются, а физически исчезают, когда эта dirty станет новой read.
• Обновление существующего ключа идёт через CAS прямо в *entry, то есть тоже без лока - read и dirty ссылаются на один и тот же entry.

Два сценария, где она оправдана

1. Ключ записывается один раз, читается много раз - кэш, который только растёт: скомпилированные шаблоны, метаданные типов, справочники.
2. Разные горутины работают с непересекающимися наборами ключей - тогда промахи редки, а read у каждой своя по факту доступа.

Почему обычно хуже mutex+map

Что есть в пакете

Типы Go 1.19 вместо функций

// Старый API: легко случайно обратиться неатомарно
var n int64
atomic.AddInt64(&n, 1)
fmt.Println(n)                 // 1, но это гонка: обычное чтение переменной,
                               // которую пишут атомарно. -race поймает

// Новый API: неатомарного доступа просто нет
var n atomic.Int64
n.Add(1)
fmt.Println(n.Load())          // 1, и прочитать можно только так

Типы atomic.Int32/Int64/Uint32/Uint64/Bool/Pointer[T] закрывают сразу три дыры: нельзя обратиться к полю напрямую, у Int64/Uint64 гарантировано 8-байтное выравнивание (на 32-битных платформах старый API требовал ручной заботы, иначе паника), и go vet ловит копирование через встроенный noCopy. Старый atomic.Value (Go 1.4) закрывает только первую: поля noCopy в нём нет, и его копирование vet пропустит.

atomic.Value: горячая перезагрузка конфига

var cfg atomic.Pointer[Config]

func reload() {                     // писатель: раз в минуту
    c := loadFromFile()
    cfg.Store(c)                    // подменяем указатель целиком
}

func handle(r *http.Request) {      // читатели: тысячи в секунду
    c := cfg.Load()                 // ~1 нс, ноль контенции
    use(c.Timeout)
}

Это copy-on-write: конфиг не мутируют на месте, а собирают новый объект и атомарно подменяют указатель. Читатели вообще не синхронизируются между собой, старый объект живёт, пока на него ссылается хоть один обработчик, и потом его забирает GC. Для read-heavy данных это быстрее любого RWMutex.

// 1) Проверка и действие - две операции. Между ними всё может измениться.
if counter.Load() < limit {
    counter.Add(1)                 // лимит будет превышен под нагрузкой
}
// Правильно: цикл CAS
for {
    old := counter.Load()
    if old >= limit { return errLimit }
    if counter.CompareAndSwap(old, old+1) { return nil }
}

// 2) Два атомарных поля - не атомарная пара
balance.Store(newBalance)
version.Store(newVersion)          // между строками кто-то прочитает несогласованное состояние
// Правильно: один atomic.Pointer на неизменяемую структуру со ВСЕМИ полями

// 3) atomic.Value с разными типами
var v atomic.Value
v.Store(&ConfigA{})
v.Store(&ConfigB{})                // panic: sync/atomic: store of inconsistently typed value
// И Store(nil) тоже паникует - в отличие от atomic.Pointer[T]

Семафор на канале

sem := make(chan struct{}, 10)          // не больше 10 одновременно

for _, task := range tasks {
    sem <- struct{}{}                   // Acquire: блокируется, если 10 уже работают
    go func() {
        defer func() { <-sem }()        // Release только через defer
        process(task)
    }()
}
// дождаться остатка: заполнить семафор целиком
for i := 0; i < cap(sem); i++ { sem <- struct{}{} }

Ёмкость канала и есть лимит. Плюсы: ноль зависимостей, работает в select, значит легко добавить таймаут и отмену:

select {
case sem <- struct{}{}:                 // получили слот
    defer func() { <-sem }()
case <-ctx.Done():
    return ctx.Err()                    // не дождались слота, уходим
}

Важная деталь: где ставить Acquire

// Плохо: горутина создаётся сразу, лимит ограничивает только «работающих»
for _, t := range tasks {
    go func() {
        sem <- struct{}{}               // миллион горутин уже создан и спит здесь
        defer func() { <-sem }()
        process(t)
    }()
}

// Хорошо: Acquire до go, горутину не создаём, пока нет слота
for _, t := range tasks {
    sem <- struct{}{}
    go func() { defer func() { <-sem }(); process(t) }()
}

semaphore.Weighted

import "golang.org/x/sync/semaphore"

sem := semaphore.NewWeighted(100)       // 100 условных единиц ресурса

func handle(ctx context.Context, req Request) error {
    w := int64(req.SizeMB)              // тяжёлый запрос занимает больше
    if err := sem.Acquire(ctx, w); err != nil {
        return err                      // контекст отменён или истёк
    }
    defer sem.Release(w)
    return process(req)
}

Критерии

Что говорит официальный Go

Слоган Роба Пайка «Do not communicate by sharing memory; instead, share memory by communicating» - про то, что владение данными в каждый момент должно принадлежать одной горутине, а передавать его надо явной операцией. Но в Go Wiki (страница MutexOrChannel) прямо написано: берите то, что выразительнее и проще, а для кэшей и состояния - мьютекс. Комментарий к пакету sync при этом строже: его примитивы, кроме Once и WaitGroup, он отводит низкоуровневым библиотекам, а синхронизацию верхнего уровня советует делать каналами. Стандартная библиотека полна мьютексов (net/http, database/sql, runtime).

Что типично в реальных проектах

• Мьютекс/atomic - внутри типов: кэши, пулы, метрики, реестры, состояние соединения. Их больше по количеству.
• Канал - на границах между компонентами: очередь задач воркерам, конвейер обработки, сигналы завершения, события.
• Гибрид - норма. Worker pool: задачи через канал, счётчики результатов через atomic, общая мапа результатов под мьютексом.
• Цена. Канал ~25–80 нс на операцию, мьютекс и атомик без конкуренции - единицы наносекунд (около 2 нс на M4 Pro, go1.27), а под конкуренцией атомик в разы дешевле мьютекса. Разница важна только в горячих путях, но там она решает.

// Счётчик «по-гошному» через канал: в разы медленнее и в разы сложнее
type Counter struct {
    ops chan func(*int)
}
func (c *Counter) Inc() { c.ops <- func(n *int) { *n++ } }

// То же самое, как надо
type Counter struct {
    n atomic.Int64
}
func (c *Counter) Inc() { c.n.Add(1) }

API и обязательный шаблон

c := sync.NewCond(&mu)

// Ждущая сторона проверяет в цикле, не через if
mu.Lock()
for !condition() {          // проверять условие в цикле обязательно
    c.Wait()                // атомарно отпускает mu и засыпает; проснувшись, снова берёт mu
}
useState()
mu.Unlock()

// Сигналящая сторона
mu.Lock()
changeState()
mu.Unlock()
c.Signal()                  // будит одного; Broadcast будит всех

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

Где Cond всё-таки уместен

• Ограниченная очередь с двумя разными условиями («не пуста» для читателей, «не полна» для писателей) и множеством ждущих на каждом - каналами это выражается хуже.
• Пул ресурсов: ждём освобождения любого из N объектов. Именно так Cond используется внутри некоторых драйверов БД.
• Broadcast по изменению состояния, когда состояние сложное и его нельзя «передать» значением, - например, «конфигурация перезагружена».

Что такое happens-before

Это частичный порядок между событиями программы. Если запись W happens-before чтение R и между ними нет других записей в ту же переменную, то R гарантированно видит W. Если такого ребра нет - R может увидеть что угодно: старое значение, новое, а на некоторых архитектурах и разорванное.

Откуда берутся рёбра

• Внутри одной горутины - порядок исходного кода.
• go f(): всё, что было до запуска, видно внутри новой горутины.
• Отправка в канал happens-before завершения соответствующего приёма.
• close(ch) happens-before приёма нулевого значения из-за закрытия.
• n-й Unlock happens-before (n+1)-го Lock.
• Once.Do(f): завершение f happens-before возврата из любого другого Do.
• WaitGroup: все Done happens-before возврата Wait.
• С Go 1.19 операции sync/atomic явно объявлены sequentially consistent - раньше их семантика была описана только «по факту реализации».

Почему bool-флаг не работает

var data int
var ready bool

// горутина A
data = 42
ready = true          // компилятор вправе поменять эти строки местами:
                      // зависимости по данным между ними нет

// горутина B
for !ready {}         // может крутиться вечно: компилятор имеет право
                      // прочитать ready один раз и закешировать в регистре
use(data)             // даже увидев ready==true, может прочитать data == 0

Ломается в трёх независимых местах: компилятор переставляет и кеширует чтения, процессор выполняет записи не в порядке программы и держит их в store buffer, и кэши ядер не обязаны синхронизироваться немедленно. Ни одна из них не «баг» - все они законны для программы без гонок, а программа с гонкой по определению находится вне контракта.

// Правильно: канал
data = 42
close(ready)      // ребро happens-before

<-ready
use(data)         // гарантированно 42

// Правильно: atomic
data = 42
flag.Store(true)

for !flag.Load() {}
use(data)         // гарантированно 42