2.6Проблемы: гонки, дедлоки, утечки

Отделим data race от логической ошибки порядка и разберём, что способен обнаружить race detector.

Как назвать поломку и чем её ловить

Сломаться конкурентная программа может тремя способами, а названий у поломок шесть, и половина на слух похожа: гонка данных и состояние гонки, дедлок, livelock, голодание, утечка горутин. Путать их дорого, потому что каждую ловят своим инструментом. Data race ловит -race, дедлок - дамп горутин, livelock - профиль CPU, starvation - хвост латентности, утечку - счётчик горутин и профиль goroutineleak. Перепутал диагноз, будешь смотреть не туда и ничего не найдёшь.

Race condition и data race - это разные вещи

Вопрос «в чём разница» задают почти всегда, и почти всегда слышат в ответ, что это синонимы. Никакие не синонимы: Go memory model формально определяет только data race, а race condition - это уже про логику программы.

Проще всего почувствовать разницу на бумажной ведомости с остатком 100 ₽ и двух кассирах. Первый случай: оба одновременно пишут карандашом в одну и ту же клетку - грифель ложится поверх грифеля, и в клетке получается нечитаемая клякса. Испорчена сама запись, и уже неважно, что каждый по отдельности считал правильно. Это data race. Второй случай: кассиры вежливо ждут друг друга и пишут по очереди, разборчиво. Но каждый сначала посмотрел остаток, увидел 100, и только потом списал 100. Ведомость идеально читаемая, все записи целы, а со счёта ушло 200 ₽ при остатке 100. Это race condition: испорчена не запись, а решение, принятое по устаревшим данным.

Отсюда два вывода, ради которых различие и нужно. Первый: инструмент, который смотрит на клетки памяти, второй случай не поймает никогда, там нет ни одного некорректного обращения. Второй: чинятся они по-разному. От кляксы спасает любая синхронизация вокруг записи; от списанных 200 ₽ спасает одно - сделать «посмотреть и списать» одной неделимой операцией, а не двумя аккуратными.

Каждая data race - это race condition, но не наоборот. Можно написать код, где вся память под мьютексом, детектор молчит, а логика всё равно неверна:

// Data race нет: каждое обращение под мьютексом. А race condition есть.
func (a *Account) Withdraw(sum int) error {
    a.mu.Lock()
    bal := a.balance          // проверка
    a.mu.Unlock()

    if bal < sum {            // между Unlock и Lock влезла другая горутина
        return errNotEnough
    }

    a.mu.Lock()
    a.balance -= sum          // списание по устаревшему решению
    a.mu.Unlock()
    return nil
}

// Правильно: решение и действие в одной атомарной операции
func (a *Account) Withdraw(sum int) error {
    a.mu.Lock()
    defer a.mu.Unlock()
    if a.balance < sum {
        return errNotEnough
    }
    a.balance -= sum
    return nil
}

counter++ из N горутин: почему ломается

counter++ выглядит одной операцией, но по сути это три шага: прочитать значение из памяти, прибавить единицу, записать обратно. Между любыми двумя из них планировщик может увести поток на другую горутину, а на многоядерной машине горутины и вовсе выполняются физически одновременно на разных ядрах.

// go build -gcflags=-S на arm64: counter++ это три инструкции
//   MOVD main.counter(SB), R1
//   ADD  $1, R1, R1
//   MOVD R1, main.counter(SB)
// на amd64 одна INCQ main.counter(SB), но без LOCK и она не атомарна
var counter int

func main() {
    var wg sync.WaitGroup
    for i := 0; i < 1000; i++ {
        wg.Go(func() {            // Go 1.25: wg.Add(1) + go func + wg.Done() в одном вызове
            for j := 0; j < 1000; j++ {
                counter++          // гонка
            }
        })
    }
    wg.Wait()
    fmt.Println(counter)           // ожидали 1000000, а выйдет что угодно.
                                   // Пять запусков подряд на go1.27 дали:
                                   //   236884  224124  239573  224828  231667
}

Три способа починить

// 1. Мьютекс: универсально
type Counter struct {
    mu sync.Mutex
    n  int
}

func (c *Counter) Inc() {
    c.mu.Lock()
    c.n++
    c.mu.Unlock()
}

func (c *Counter) Value() int {
    c.mu.Lock()
    defer c.mu.Unlock()
    return c.n            // читать тоже под локом
}

// 2. Atomic: быстро для одного слова
type Counter struct {
    n atomic.Int64        // Go 1.19: типизированный
}

func (c *Counter) Inc() {
    c.n.Add(1)            // одна инструкция LOCK XADDQ
}

func (c *Counter) Value() int64 {
    return c.n.Load()
}
// Не годится, когда надо менять
// два поля согласованно.

// 3. Канал: состоянием владеет одна горутина, остальные шлют ей сообщения
type Counter struct {
    inc  chan struct{}
    read chan chan int
    done chan struct{}
}

func NewCounter() *Counter {
    c := &Counter{
        inc:  make(chan struct{}, 256),   // буфер гасит всплески, но Value может
                                          // не увидеть Inc, которые ещё лежат в буфере
        read: make(chan chan int),
        done: make(chan struct{}),
    }
    go func() {
        n := 0                            // состояние живёт только здесь
        for {
            select {
            case <-c.inc:
                n++
            case reply := <-c.read:
                reply <- n
            case <-c.done:
                return
            }
        }
    }()
    return c
}

func (c *Counter) Inc()       { c.inc <- struct{}{} }
func (c *Counter) Value() int { r := make(chan int); c.read <- r; return <-r }
func (c *Counter) Close()     { close(c.done) }

Race detector: что происходит под капотом

-race - это не статический анализ и не эвристика «два потока трогают переменную». Это динамический детектор на базе ThreadSanitizer, который прямо на ходу строит отношение happens-before и проверяет каждый доступ к памяти на упорядоченность.

Три составные части

• Инструментация. С флагом -race компилятор вставляет перед каждым чтением и записью памяти (кроме локальных переменных на своём стеке) вызов raceread/racewrite, для структур и массивов - их range-варианты. Плюс рантайм сам сообщает детектору обо всех точках синхронизации: Lock/Unlock, отправка и приём в канале, WaitGroup.Wait, atomic-операции, запуск и завершение горутины.
• Векторные часы. Способ ответить на вопрос «что горутина A знает о том, как далеко продвинулась горутина B» - без всяких настоящих часов и без сравнения моментов времени. Единица измерения тут - эпоха: просто счётчик шагов, который горутина увеличивает на каждой своей точке синхронизации. У каждой горутины - вектор из таких счётчиков, по одному на каждую известную горутину. Собственная компонента растёт после каждой такой точки. При синхронизации часы передаются: Unlock сохраняет вектор в мьютексе, Lock берёт поэлементный максимум со своим. Так формально фиксируется «всё, что было до Unlock, произошло раньше всего, что после Lock».
• Теневая память. Отдельная служебная область, в которой детектор ведёт досье на память самой программы: не значения, а «кто и на каком своём шаге к этому месту прикасался». На каждые 8 байт памяти программы заводится несколько теневых ячеек, в каждой - id горутины, её эпоха на момент доступа, размер обращения и флаг чтение/запись. Новый доступ сравнивается с тем, что лежит в теневых ячейках: если эпоха предыдущего писателя больше, чем то, что мой вектор знает про эту горутину, значит порядок между нами не установлен - гонка.

Почему ловит не всё

• Только выполненные пути. Не покрытая тестом ветка инструментирована, но ни разу не выполнилась, и её гонки невидимы. Значит, ценность -race прямо пропорциональна покрытию и разнообразию нагрузки.
• Только реально запущенные горутины. Если в тесте всего один воркер, а в проде их сто, конкуренции не возникнет и сравнивать будет нечего. Поэтому конкурентные тесты пишут с -race и -count=10, с реальным числом горутин, иногда с GOMAXPROCS>1 явно.
• Ёмкость теней и истории. Теневых ячеек на слово всего четыре, старые вытесняются. Стек прошлого доступа детектор восстанавливает из истории горутины: если между двумя доступами она успела сделать десятки тысяч других обращений к памяти, гонка молча не попадёт в отчёт, пока не поднимешь history_size. А лимита в 8128 живых горутин из старых статей с Go 1.19 (ThreadSanitizer v3) больше нет.
• Гонки вне Go. Cgo-код, ассемблер без инструментации, память, которую трогает сторонняя C-библиотека, детектору не видны.
• Race condition он не ловит принципиально - только data race.

Цена

# стандартный набор в CI
go test -race ./...                       # обязательная ступень пайплайна
go test -race -count=5 ./internal/worker  # многократный прогон конкурентных тестов
go build -race -o app-race ./cmd/app      # бинарь для стенда, не для прода

# настройка детектора
GORACE="halt_on_error=1 history_size=4 log_path=/tmp/race" go test -race ./...
#   halt_on_error=1: падать на первой гонке (в CI удобно)
#   history_size:    сколько прошлых доступов помнит горутина, больше = меньше пропусков, дороже

# так выглядит отчёт: два стека доступа и где запущена каждая из двух горутин
==================
WARNING: DATA RACE
Write at 0x00c000012188 by goroutine 9:
  main.(*Counter).Inc()
      /app/counter.go:14 +0x88
  main.main.func2()
      /app/main.go:22 +0x68

Previous read at 0x00c000012188 by goroutine 7:
  main.(*Counter).Value()
      /app/counter.go:19 +0x74
  main.main.func1()
      /app/main.go:16 +0x80

Goroutine 9 (running) created at:
  main.main()
      /app/main.go:19 +0x1a4

Goroutine 7 (finished) created at:
  main.main()
      /app/main.go:14 +0x100
==================

Дедлок: определение и четыре условия

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

Классические условия Коффмана - четыре одновременно необходимых признака. Ломать дедлок можно, убрав любое из них, и в Go на практике ломают в основном четвёртое.

Код, который дедлочится гарантированно

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

func main() {
    var muA, muB sync.Mutex
    var wg sync.WaitGroup

    wg.Add(2)
    go func() {                              // G1: порядок A -> B
        defer wg.Done()
        muA.Lock()
        time.Sleep(50 * time.Millisecond)    // окно: даём G2 взять muB
        muB.Lock()                           // ждёт вечно: muB у G2
        muB.Unlock()
        muA.Unlock()
    }()
    go func() {                              // G2: порядок B -> A  <-- зеркальный
        defer wg.Done()
        muB.Lock()
        time.Sleep(50 * time.Millisecond)
        muA.Lock()                           // ждёт вечно: muA у G1
        muA.Unlock()
        muB.Unlock()
    }()
    wg.Wait()
}

// Реальный вывод go1.27 (в stderr, сокращённый; exit status 2):
//
// fatal error: all goroutines are asleep - deadlock!
//
// goroutine 1 [sync.WaitGroup.Wait]:
// sync.runtime_SemacquireWaitGroup(...)
// sync.(*WaitGroup).Wait(0x...)
// main.main()
//
// goroutine 6 [sync.Mutex.Lock]:
// internal/sync.runtime_SemacquireMutex(...)
// internal/sync.(*Mutex).lockSlow(0x...)
// main.main.func1()
//         created by main.main in goroutine 1
//
// goroutine 7 [sync.Mutex.Lock]:
// main.main.func2()
//         created by main.main in goroutine 1
//
// Читать надо состояние в квадратных скобках: у main это ожидание WaitGroup
// (до Go 1.24 та же строка выглядела как [semacquire]), а у двух рабочих Mutex.Lock.
// Номера горутин не 2 и 3, потому что рантайм заводит служебные горутины раньше.

Минимальные однострочники, которые тоже валят рантайм и которые любят просить написать «за десять секунд»:

// 1. отправка в небуферизованный канал,
//    читателя нет
func main() {
    ch := make(chan int)
    ch <- 1
}

// 2. рекурсивный Lock: у Mutex
//    нет владельца и нет реентрантности
func main() {
    var mu sync.Mutex
    mu.Lock()
    mu.Lock()
}

// 3. Add без Done
func main() {
    var wg sync.WaitGroup
    wg.Add(1)
    wg.Wait()
}

// 4. пустой select: вечный сон
//    без единого готового кейса
func main() {
    select {}
}

Как рантайм детектит дедлок и когда не детектит

Знаменитое fatal error: all goroutines are asleep - deadlock! печатает функция checkdead() в планировщике. И это не детектор дедлоков. Рантайм не строит граф ожидания и не разбирает, кто кого ждёт. Он проверяет одно глобальное условие: «во всей программе не осталось ни одного потока, который мог бы когда-нибудь получить работу».

checkdead вызывается, когда последний рабочий поток M собирается уйти в сон, и считает три числа: сколько есть runnable-горутин, сколько M сидит в системных вызовах и есть ли активные таймеры. Если работы нет нигде, а живые горутины при этом заблокированы (_Gwaiting) - значит, разбудить их некому, и рантайм честно падает, печатая стеки.

Диагностика зависания в проде

# 1. дамп без остановки сервиса, с него и начинают
curl -s 'http://127.0.0.1:6060/debug/pprof/goroutine?debug=2' > /tmp/g.txt

# 2. кто где стоит: топ состояний
grep -oP '^goroutine \d+ \[\K[^\]]+' /tmp/g.txt | sort | uniq -c | sort -rn
#   7412 chan receive, 43 minutes     <-- утечка или зависший конвейер
#     12 sync.Mutex.Lock, 43 minutes  <-- вот он, дедлок
#      3 IO wait

# 3. SIGQUIT, когда pprof не подключён (стеки в stderr, процесс умирает)
kill -QUIT $(pgrep app)        # все горутины, включая служебные; GOTRACEBACK=all для этого не нужен

Стратегии предотвращения

• Глобальный порядок захвата. Все локи в системе нумеруются (например, по адресу, по имени, по слою), и захватывать их можно только по возрастанию. Циклическое ожидание становится невозможным. Это гарантия, а не снижение вероятности, и она работает даже там, где без нескольких локов сразу не обойтись.
• Не звать чужой код под локом. Колбэк, метод интерфейса, обращение в другой сервис под мьютексом - источник дедлоков, потому что вы не знаете, какие локи возьмут внутри. Правило: под локом только работа со своими полями.
• Один лок вместо двух. Часто два мьютекса заводят «для гранулярности», а в профиле никакого контеншена на них нет. Один более крупный лок проще и безопаснее.
• Копировать данные наружу. Взять лок, скопировать нужное в локальную переменную, отпустить, дальше работать без лока. Критическая секция в две строки почти не может участвовать в дедлоке.
• Таймауты вместо вечного ожидания. На каналах - select с ctx.Done(); на семафоре - semaphore.Weighted.Acquire(ctx, n); в БД - lock_timeout и statement_timeout. Дедлок превращается в ошибку, которую видно в логах и метриках.
• TryLock (Go 1.18+) - взять лок, если свободен, иначе сразу вернуться. Позволяет откатиться и повторить. В документации стоит прямое предупреждение: правильное применение редко, и часто это признак проблемы в дизайне. Без рандомизированного бэкоффа легко получить livelock вместо дедлока.

// Порядок захвата по адресу: перевод между счетами, оба под локом.
// Без сортировки Transfer(a,b) и Transfer(b,a) дедлочатся на первой же коллизии.
func Transfer(from, to *Account, sum int) error {
    if from == to {
        return nil                           // иначе второй Lock того же мьютекса - дедлок
    }
    first, second := from, to
    if uintptr(unsafe.Pointer(first)) > uintptr(unsafe.Pointer(second)) {
        first, second = second, first        // всегда меньший адрес первым
    }
    first.mu.Lock()
    defer first.mu.Unlock()
    second.mu.Lock()
    defer second.mu.Unlock()

    if from.balance < sum {
        return errNotEnough
    }
    from.balance -= sum
    to.balance += sum
    return nil
}

// Вариант с откатом: держим первый лок, второй пробуем; не вышло, отпускаем всё.
func TransferTry(from, to *Account, sum int) error {
    for attempt := 0; attempt < 100; attempt++ {
        from.mu.Lock()
        if to.mu.TryLock() {
            defer from.mu.Unlock()
            defer to.mu.Unlock()
            return apply(from, to, sum)
        }
        from.mu.Unlock()                     // перед повтором обязательно отпускаем
        // рандом здесь не для красоты: без него две горутины входят в livelock
        time.Sleep(time.Duration(rand.Intn(1<<min(attempt, 10))) * time.Microsecond) // потолок ~1 мс
    }
    return errBusy
}

Livelock и starvation

Оба слова описывают состояние «прогресса нет», но ни одно из них не равно дедлоку, и между собой они тоже разные. Livelock (дословно «живая блокировка») - горутины вовсе не спят: они замечают конфликт, вежливо откатываются, пробуют снова и попадают в тот же конфликт, потому что делают это синхронно, в такт друг с другом. Работа кипит, процессор загружен на сто процентов, полезного результата ноль. Бытовая аналогия - двое в узком коридоре, которые одновременно шагают в одну и ту же сторону, чтобы разойтись, и снова оказываются нос к носу. Аналогия честная ровно до одного места: люди через пару раз сообразят и один остановится, а код без рандомизации задержки будет повторять это до конца процесса.

Starvation (голодание) - случай мягче: система в целом отлично прогрессирует, метрики зелёные, но конкретная горутина раз за разом проигрывает конкуренцию за ресурс и не продвигается. От дедлока отличается тем, что горутина могла бы работать в любой момент - ей просто не дают; от livelock - тем, что страдает не вся система, а невезучий участник, и видно это не по CPU, а по хвосту латентности.

В самом Go со starvation борется sync.Mutex: если горутина не может получить лок дольше 1 мс, мьютекс переключается в starvation mode и начинает передавать владение строго по очереди FIFO, отключив спиннинг новых претендентов. Это лечит худший случай ценой пропускной способности. У sync.RWMutex защита другая: как только писатель встал в очередь, новые RLock() блокируются - иначе бесконечный поток читателей никогда не пустил бы писателя. Побочный эффект известен: рекурсивный RLock в этот момент дедлочится.

Утечки горутин

Горутина - это объект в куче: от 2 КБ стека на старте (растёт по мере надобности), запись в allgs, работа для GC при каждом цикле. Горутина, которая никогда не завершится, - это утечка памяти, а вместе с ней обычно утекает и то, что она держит: соединение, буфер, замыкание с большим объектом. Сотня таких в секунду - и через сутки процесс уходит в OOM.

// Классическая утечка: таймаут у вызывающего, вечная блокировка у воркера
func leaky(ctx context.Context) (int, error) {
    ch := make(chan int)                 // небуферизованный
    go func() {
        ch <- slowWork()                 // если ctx истёк, получателя нет и горутина стоит вечно
    }()
    select {
    case v := <-ch:
        return v, nil
    case <-ctx.Done():
        return 0, ctx.Err()              // ушли, горутина осталась. И так на каждый таймаут.
    }
}

// Починка 1 (самая простая): буфер 1, отправка всегда проходит, горутина завершится
func fixedBuffer(ctx context.Context) (int, error) {
    ch := make(chan int, 1)
    go func() { ch <- slowWork() }()
    select {
    case v := <-ch:
        return v, nil
    case <-ctx.Done():
        return 0, ctx.Err()
    }
}

// Починка 2 лучше: работа сама отменяется и не жжёт CPU впустую
func fixedCancellable(ctx context.Context) (int, error) {
    ch := make(chan int, 1)
    go func() { ch <- slowWorkCtx(ctx) }()   // slowWorkCtx уважает ctx.Done()
    select {
    case v := <-ch:
        return v, nil
    case <-ctx.Done():
        return 0, ctx.Err()
    }
}

// В тестах: goleak падает, если после теста остались лишние горутины
func TestMain(m *testing.M) {
    goleak.VerifyTestMain(m,
        // известные вечные горутины библиотек заглушают явно, поимённо
        goleak.IgnoreTopFunction("go.opencensus.io/stats/view.(*worker).start"),
    )
}

func TestWorker(t *testing.T) {
    defer goleak.VerifyNone(t)           // проверка на уровне одного теста
    ...
}

// В проде: метрика + алерт на монотонный рост
prometheus.MustRegister(prometheus.NewGaugeFunc(
    prometheus.GaugeOpts{Name: "go_goroutines_custom"},
    func() float64 { return float64(runtime.NumGoroutine()) },
))

// В коде как любой другой профиль
pprof.Lookup("goroutineleak").WriteTo(os.Stdout, 1)
// goroutineleak profile: total 2
// 1 @ 0x... 0x... 0x...
// #	0x...	main.leakChan+0x2f	/app/main.go:11

// По HTTP, если импортирован net/http/pprof:
// curl 'http://127.0.0.1:6060/debug/pprof/goroutineleak?debug=1'

// go test -bench=. -cpu=1,8 -benchmem     (M4 Pro, go1.27; канал - горутина-владелец)
// BenchmarkMutex       1.898 ns/op       BenchmarkMutex-8     122.9 ns/op
// BenchmarkAtomic      1.697 ns/op       BenchmarkAtomic-8    31.58 ns/op
// BenchmarkChannel     51.03 ns/op       BenchmarkChannel-8   163.5 ns/op
// (при -cpu=1 суффикса -1 у имени нет; 0 B/op и 0 allocs/op опущены)
//
// Порядок цифр важнее самих цифр: без конкуренции мьютекс почти не дороже atomic
// (быстрый путь Lock и Unlock - пара атомарных операций), а канал дороже на порядок.
// Под конкуренцией всё дорожает: atomic вчетверо дешевле мьютекса, канал ненамного
// дороже него. Atomic упирается в кеш-когерентность (одна кеш-линия на все ядра),
// а мьютекс в парковку/пробуждение горутин.

// A. Data race без очевидной race condition в бизнес-смысле:
//    флаг, который просто «когда-нибудь» станет true.
var done bool                        // без sync
go func() { done = true }()
for !done { }                        // может крутиться вечно

// Почему вечно: компилятор имеет право поднять чтение done из цикла в регистр,
// потому что в отсутствие синхронизации он вправе считать, что никто извне
// переменную не меняет. Go 1.27 так не делает и перечитывает done на каждом витке,
// но модель памяти Go прямо пишет, что такой цикл не обязан завершиться.
// Правильно: atomic.Bool, канал или sync.Once.

// B. Race condition без data race: вся память под мьютексом, логика всё равно неверна.
if !cache.Has(key) {                 // Has() внутри под RLock, data race нет
    v := expensiveLoad(key)          // между Has и Set влезли ещё 50 горутин
    cache.Set(key, v)                // и все 50 сделали expensiveLoad
}
// Это TOCTOU (time-of-check to time-of-use). Чинится не мьютексом,
// а объединением проверки и действия: singleflight или LoadOrStore.

// Вариант с каналом вместо Sleep: строгая гарантия, без гонки по времени.
func main() {
    var muA, muB sync.Mutex
    ready := make(chan struct{})          // «я взял свой первый лок»
    var wg sync.WaitGroup
    wg.Add(2)

    go func() {
        defer wg.Done()
        muA.Lock()
        ready <- struct{}{}               // сообщил
        <-ready                           // дождался встречного
        muB.Lock()                        // оба лока заняты крест-накрест
        muB.Unlock(); muA.Unlock()
    }()
    go func() {
        defer wg.Done()
        muB.Lock()
        <-ready                           // дождался G1 и только потом ответил:
        ready <- struct{}{}               // шли бы обе первыми - встали бы на канале
        muA.Lock()
        muA.Unlock(); muB.Unlock()
    }()
    wg.Wait()
}

// Один и тот же дедлок: с падением и без.
func main() {
    ch := make(chan int)
    <-ch                       // fatal error: all goroutines are asleep
}
// stderr, go1.27:
//   fatal error: all goroutines are asleep - deadlock!
//
//   goroutine 1 [chan receive]:
//   main.main()
//           /tmp/x/main.go:6 +0x30
//   exit status 2
// (вариант с отправкой в такой же канал отличается одним словом: [chan send])

func main() {
    go func() {                // «heartbeat», который живёт всегда
        for range time.Tick(time.Second) {
        }
    }()
    ch := make(chan int)
    <-ch                       // зависнет молча: таймер = потенциальный прогресс.
}                              // Так ведёт себя любой реальный сервис.
// вывода нет вообще, ни в stdout, ни в stderr: процесс висит, пока его не убьют

// Это fatal error, а не паника, поэтому defer с recover не поможет.
func main() {
    defer func() {
        if r := recover(); r != nil { fmt.Println("поймали:", r) }  // не выполнится никогда
    }()
    ch := make(chan int)
    <-ch
}
// stderr: fatal error: all goroutines are asleep - deadlock!  (строки «поймали:» нет,
// рантайм не разматывает стек и вообще не запускает отложенные функции)

# Минимальный набор для прода: pprof на отдельном порту, не наружу
go func() { log.Println(http.ListenAndServe("127.0.0.1:6060", nil)) }()
# import _ "net/http/pprof"

# Снять и разобрать
curl -s '127.0.0.1:6060/debug/pprof/goroutine?debug=2' > dump.txt
curl -s '127.0.0.1:6060/debug/pprof/goroutine?debug=1' | head -40   # агрегат по стекам

# Топ состояний с временем ожидания
grep -o '\[[a-z A-Z.,0-9]*\]' dump.txt | sort | uniq -c | sort -rn | head
#    5120 [chan receive, 6 minutes]
#      25 [IO wait, 6 minutes]
#       2 [sync.Mutex.Lock, 6 minutes]
#       2 [IO wait]
#       1 [sleep, 6 minutes]
#       1 [running]

# Интерактивно, с деревом вызовов
go tool pprof -http=:8080 http://127.0.0.1:6060/debug/pprof/goroutine

# Контеншен и блокировки (включать точечно, они не бесплатны)
runtime.SetMutexProfileFraction(5)     # /debug/pprof/mutex
runtime.SetBlockProfileRate(1_000_000) # /debug/pprof/block, 1 сэмпл на 1мс блокировки

// Порядок захвата в пакете storage (нарушение = дедлок):
//   1. Registry.mu      (глобальный реестр)
//   2. Shard.mu         (шард)
//   3. Entry.mu         (запись)
// Захватывать только сверху вниз. Никогда не брать Registry.mu, держа Shard.mu.

type Shard struct {
    mu sync.Mutex
    m  map[string]*Entry
}

// Публичный метод берёт лок и делегирует в *Locked-версию.
func (s *Shard) Get(k string) (*Entry, bool) {
    s.mu.Lock()
    defer s.mu.Unlock()
    return s.getLocked(k)
}

// Соглашение: суффикс Locked = «лок уже держит вызывающий, сам не бери».
func (s *Shard) getLocked(k string) (*Entry, bool) {
    e, ok := s.m[k]
    return e, ok
}

// У sync.Mutex нет LockContext. Если нужен лок с таймаутом,
// берут семафор на единицу или канал-мьютекс.
import "golang.org/x/sync/semaphore"

sem := semaphore.NewWeighted(1)

if err := sem.Acquire(ctx, 1); err != nil {
    return fmt.Errorf("не дождались лока: %w", err)   // ctx.Err(), а не вечный сон
}
defer sem.Release(1)

// Дешёвая альтернатива без зависимостей: буферизованный канал ёмкости 1.
type ChanMutex chan struct{}

func NewChanMutex() ChanMutex { return make(ChanMutex, 1) }

func (m ChanMutex) Lock(ctx context.Context) error {
    select {
    case m <- struct{}{}:
        return nil
    case <-ctx.Done():
        return ctx.Err()
    }
}
func (m ChanMutex) Unlock() { <-m }
// Цена: без конкуренции на порядок дороже sync.Mutex (на M4 Pro 23 нс против 2).
// Берут только там, где отменяемость важнее наносекунд.

// 1. Отправка без читателя (небуферизованный канал)
ch := make(chan int)
ch <- 1                              // навсегда

// 2. Приём из канала, в который никто не пошлёт и который не закроют
<-make(chan int)

// 3. Полный буфер + потребитель, который ждёт продюсера
in := make(chan int, 2)
in <- 1; in <- 2
in <- 3                              // буфер полон, потребитель ещё не стартовал

// 4. nil-канал: операция блокируется навсегда, а не паникует
var nilCh chan int
nilCh <- 1                           // [chan send (nil chan)]

// 5. select без кейсов (на одних nil-каналах встанет так же, но в дампе [select])
select {}                            // [select (no cases)]

// 6. Взаимный обмен: обе горутины сначала шлют
go func() { a <- 1; <-b }()
go func() { b <- 1; <-a }()          // оба стоят на отправке

// 7. WaitGroup.Wait() до чтения результатов
results := make(chan int)            // небуферизованный
for i := 0; i < 3; i++ {
    wg.Go(func() { results <- work() })
}
wg.Wait()                            // воркеры встали на отправке: дедлок
for r := range results { ... }
// Чинится закрытием канала в отдельной горутине:
//   go func() { wg.Wait(); close(results) }()
//   for r := range results { ... }

// Две горутины «вежливо уступают» друг другу и обе не двигаются.
func transfer(from, to *Account) {
    for {
        from.mu.Lock()
        if to.mu.TryLock() {
            defer from.mu.Unlock()
            defer to.mu.Unlock()
            return                     // успех
        }
        from.mu.Unlock()               // уступил и сразу пробует снова, вот и livelock:
    }                                  // без паузы горутины легко входят в такт
}                                      // и повторяют один и тот же конфликт

// Лечится рандомизированным экспоненциальным бэкоффом. Фиксированная пауза
// спасает лишь случайно: горутины разводит разброс пробуждений таймеров.
backoff := time.Duration(rand.Int63n(int64(base))) * (1 << attempt)

// Ручная проверка в тесте, если тянуть goleak не хочется
func TestNoLeak(t *testing.T) {
    before := runtime.NumGoroutine()

    srv := New()
    srv.Start()
    doWork(srv)
    srv.Stop()

    // Горутины завершаются не мгновенно: нужен опрос с дедлайном,
    // а не единичная проверка сразу после Stop.
    deadline := time.Now().Add(2 * time.Second)
    for time.Now().Before(deadline) {
        if runtime.NumGoroutine() <= before {
            return
        }
        time.Sleep(10 * time.Millisecond)
    }
    buf := make([]byte, 1<<20)
    n := runtime.Stack(buf, true)           // all=true: стеки всех горутин
    t.Fatalf("утечка: было %d, стало %d\n%s", before, runtime.NumGoroutine(), buf[:n])
}

Что стоит запомнить

• Data race требует конкурентного доступа с записью без синхронизации.
• Логическая race condition может существовать без data race.
• Race detector проверяет только исполненные пути.

Частые ошибки

• Sleep не задаёт happens-before.
• Успешный прогон -race не доказывает отсутствие гонок.

var n int
for i := 0; i < 2; i++ { go func() { n++ }() }
time.Sleep(time.Millisecond); fmt.Println(n)

var n int
go func(){ n++ }()
fmt.Println(n)