Конкурентность

У процесса своё изолированное адресное пространство и набор ресурсов ядра. Внутри процесса планируются потоки: у каждого свой стек и регистры, а память общая; переключение между потоками стоит входа в ядро и порядка микросекунды. Горутину планирует сам рантайм, и ядро о ней не знает вообще.

Три источника дешевизны

1. Стек. Поток резервирует фиксированный (1–8 МБ виртуально, страницы подтягиваются по обращению). Горутина стартует с 2 КБ реальной памяти и растёт копированием. Миллион потоков занимает терабайты виртуального адресного пространства, а миллион горутин обходится несколькими гигабайтами реальной памяти.
2. Переключение. Сменить горутину значит сохранить SP, PC и указатель на g в gobuf и загрузить другие. Не нужно менять привилегии, не нужно сбрасывать TLB, кэши остаются тёплыми. ~50–200 нс против 1–2 мкс.
3. Кто планирует. Планировщик Go знает семантику: он видит, что горутина встала на канале, и переключает мгновенно, а не ждёт истечения кванта. Ядро такого не знает.

Чем горутина хуже потока

• Нет приоритетов, нет affinity к ядру, нет real-time гарантий.
• Нельзя убить извне (см. отдельный вопрос).
• Настоящий блокирующий syscall всё равно займёт целый поток ОС.
• Нет изоляции: паника в любой горутине без recover роняет весь процесс.

Механика

Компилятор вставляет в пролог почти каждой функции сравнение указателя стека с g.stackguard0. Если для кадра места не хватает, управление уходит в runtime.morestack, оттуда в newstack и copystack: выделить блок вдвое больше, скопировать байты, обойти все указатели, которые смотрели внутрь старого стека, и сдвинуть их на разницу адресов. Для этого компилятор хранит точные карты указателей на каждый safe-point: тот же механизм обслуживает и точный GC.

Обратное делает shrinkstack: во время GC, если горутина использует меньше четверти своего стека, он ужимается вдвое.

Историческая часть, которую любят спрашивать

До Go 1.3 стеки были сегментированными: новый кусок связывался со старым списком. Проблема называлась «hot split»: если граница сегмента попадала внутрь горячего цикла, каждая итерация выделяла и освобождала сегмент, и профиль проваливался на порядок. В 1.3–1.4 перешли на копирующие стеки, а начальный размер снизили с 8 КБ до 2 КБ.

// Показать рост стека можно так:
func deep(n int) {
    var pad [512]byte           // чтобы кадр был заметным
    _ = pad
    if n > 0 { deep(n - 1) }
}
// gctrace рост стека не покажет. Его видно в CPU-профиле как runtime.morestack
// и runtime.copystack: go test -run TestDeep -cpuprofile cpu.out

Конкурентная программа остаётся конкурентной на одном ядре: GOMAXPROCS=1 не мешает запустить тысячу горутин, они просто будут чередоваться. Параллелизм появляется, когда ядер больше одного и GOMAXPROCS > 1. Отсюда несимметричность: конкурентность даёт возможность параллелизма, но не наоборот.

Пример, который лучше мантры

HTTP-сервер, который на каждый запрос ходит в базу и в стороннее API. На одном ядре он всё равно обслужит тысячу одновременных соединений: пока одна горутина ждёт ответа сети, ядро свободно, и на нём работает другая. Это чистая конкурентность без параллелизма, и выигрыш тут не от ядер, а от того, что ожидание не блокирует.

Теперь обратный случай: посчитать SHA-256 от тысячи файлов. Это CPU-bound работа, и конкурентность сама по себе не ускорит ничего: на одном ядре тысяча горутин посчитает ровно столько же, сколько один цикл, только с накладными расходами на переключения. Ускорит именно параллелизм: восемь ядер дадут примерно восьмикратный выигрыш.

Зачем понадобился P

В Go 1.0 модель была GM: одна глобальная очередь под одним мьютексом. На многоядерных машинах это упиралось в contention, а ещё убивало локальность: горутина могла уехать на любой поток, и кэш процессора обнулялся. В Go 1.1 Дмитрий Вьюков добавил P: теперь у каждого P своя очередь на 256 слотов (lock-free кольцевой буфер) и свой mcache, так что обычные аллокации и планирование идут без единого атомарного конфликта.

Порядок поиска работы (findRunnable)

1. раз в 61 тик: одна горутина из глобальной очереди (чтобы та не голодала);
2. runnext: слот на одну «только что созданную/разбуженную» горутину, ради локальности кэша;
3. локальная очередь P;
4. глобальная очередь: пачкой len/GOMAXPROCS + 1;
5. неблокирующий netpoll;
6. work stealing: до 4 попыток украсть половину очереди у случайного P;
7. ничего нет, и тогда P в idle-список, M паркуется.

Где рождается горутина

go f() кладёт новую G в runnext текущего P. Если локальная очередь переполнена (256 штук), половина её вместе с новой горутиной уезжает в глобальную очередь одним батчем. Это и есть «перелив»: одному P не дают накопить всё.

Цепочка такая: G → (P) → M → поток ОС → ядро. Горутина попадает в очередь P; M, владеющий этим P, снимает её и исполняет; поток ОС планируется ядром на физическое ядро по своим правилам. Go не управляет affinity и не может «прибить» горутину к ядру: ближайшее, что есть, это runtime.LockOSThread: она прибивает горутину к конкретному потоку (нужно для OpenGL, некоторых C-библиотек и Linux namespace).

Количественно

• G: сколько запустил, столько и есть, упираешься только в память.
• P: ровно GOMAXPROCS, фиксировано на время работы (в 1.25 может меняться при смене cgroup-лимита).
• M: динамически. Рантайм создаёт новый M, когда текущий уходит в блокирующий syscall и P нужно отдать другому. Потолок 10 000.

Поэтому в проде число потоков работает как диагностика. GOMAXPROCS=8 и 12 потоков это норма. GOMAXPROCS=8 и 600 потоков значат, что где-то массово блокирующие syscall или cgo, и это стоит памяти (у каждого M ещё и свой системный стек) и переключений контекста.

// сколько потоков у процесса
// Linux:  cat /proc/<pid>/status | grep Threads
// изнутри программы:
import "runtime/pprof"
p := pprof.Lookup("threadcreate")   // сколько потоков вообще создавалось
fmt.Println(p.Count())              // 5 на пустой программе с GOMAXPROCS=14.
                                    // Число зависит от машины и от истории процесса,
                                    // а не от текущего числа живых потоков

Блокирующий syscall

1. Перед вызовом рантайм зовёт entersyscall: сохраняет контекст горутины и переводит P в состояние _Psyscall.
2. Если syscall возвращается быстро, exitsyscall подхватывает тот же P: дешёвый быстрый путь.
3. Если нет, sysmon через ~20 мкс видит зависший _Psyscall и делает handoffp: отбирает P и отдаёт другому M (взяв свободный или создав новый). Работа на этом ядре продолжается.
4. Когда syscall наконец вернётся, «осиротевший» M попробует получить любой свободный P; если не выйдет, положит горутину в глобальную очередь и припаркуется в пуле потоков.

netpoller

Всё, что открыто через пакет net (и os.Pipe, и таймеры на части платформ), рантайм переводит в O_NONBLOCK и регистрирует в поллере. Вызов conn.Read внутри выглядит так: попытка read → EAGAIN → gopark горутины со ссылкой на её g в pollDesc. Горутина снята с потока, поток пошёл выполнять следующую.

Поллер дёргают в трёх местах: в findRunnable (неблокирующий netpoll), перед парковкой последнего M (блокирующий, иначе некому будет проснуться) и в sysmon, если сеть не опрашивали больше 10 мс. Готовые горутины переводят в _Grunnable и кладут в очередь.

Кооперативное вытеснение

Планировщик записывает в g.stackguard0 специальное значение stackPreempt. Пролог следующей вызванной функции сравнивает SP с этим полем, «видит переполнение», уходит в morestack, а тот распознаёт флаг и передаёт управление планировщику. Механизм роста стека переиспользован тут красиво, но работает только там, где есть вызов функции.

// Go 1.13 и раньше: программа зависала намертво
func main() {
    runtime.GOMAXPROCS(1)
    go func() { for { } }()     // ни вызовов, ни аллокаций: вытеснить негде
    time.Sleep(time.Second)
    fmt.Println("недостижимо в 1.13")
}

// запуск на go1.27: строка печатается через секунду, асинхронное вытеснение работает.
// недостижимо в 1.13

Асинхронное вытеснение (Go 1.14)

Sysmon замечает горутину, работающую дольше 10 мс, и шлёт её потоку сигнал SIGURG. Обработчик проверяет, что точка «асинхронно безопасна» (регистры описаны картами указателей, мы не в критической секции рантайма, не в //go:nosplit-функции), и подменяет адрес возврата на runtime.asyncPreempt: та сохраняет весь регистровый файл и уходит в планировщик. SIGURG выбрали потому, что он реально не используется и не мешает отладчикам.

Где всё ещё можно «захватить» процессор

• Внутри cgo-вызова: сигнал не поможет, чужой код мы не контролируем.
• В функциях рантайма с //go:nosplit и с отключёнными сигналами.
• При GODEBUG=asyncpreemptoff=1: его иногда включают для отладки, потому что асинхронное вытеснение мешает воспроизводить некоторые баги.
• Логически: горутина держит мьютекс и молотит цикл. Её вытеснят, но лок она не отдаст, и все ожидающие всё равно стоят. Вытеснение спасает планировщик, а не твой дизайн.

Что именно ограничивает

Не число потоков и не число горутин, а количество контекстов P. Одновременно исполняется Go-код максимум в GOMAXPROCS горутинах. Потоков при этом может быть сколько угодно: те, что сидят в блокирующих syscall, P не держат.

Проблема контейнеров

Под с limits.cpu: "1" на 64-ядерной ноде до Go 1.25 получал GOMAXPROCS=64, потому что runtime.NumCPU() читает маску affinity, а не cgroup-квоту. Дальше включается CFS throttling: cgroup выдаёт квоту на период 100 мс, 64 потока выжирают её за первые единицы миллисекунд, и остаток периода контейнер заморожен. Симптомы: рваные p99, «непонятные» лаги, метрика container_cpu_cfs_throttled_seconds_total ползёт вверх. GC тоже страдает: он масштабируется по GOMAXPROCS и создаёт лишних воркеров.

Что делать

// До Go 1.25 стандарт де-факто:
import _ "go.uber.org/automaxprocs"    // при старте читает cgroup v1/v2 и ставит GOMAXPROCS

// В Go 1.25 (нужно go >= 1.25 в go.mod) это в рантайме:
//   default = min(runtime.NumCPU(), ceil(cgroup CPU limit)), минимум 2
//   значение обновляется само при смене лимита (опрос ~раз в секунду)
//   GOMAXPROCS(0) больше не «замораживает» значение, а просто читает
//   выключить: GODEBUG=containermaxprocs=0,updatemaxprocs=0
//   переопределить: переменная окружения GOMAXPROCS=N или runtime.GOMAXPROCS(n)

Считаем стоимость

• Стек 2 КБ минимум, но после первого же вызова с локальными массивами это 4–8 КБ. Миллион → 2–8 ГБ.
• Структура g весит сотни байт, плюс место в очередях.
• Работа GC: каждый стек это корень для сканирования. Миллион корней ощутимо удлиняет фазу сканирования и STW-моменты.
• Планировщик: миллион элементов в очередях, стилинг чаще, локальность хуже.

// Это отработает, но посмотри на RSS процесса
var wg sync.WaitGroup
for i := 0; i < 1_000_000; i++ {
    wg.Add(1)
    go func() { defer wg.Done(); time.Sleep(time.Second) }()
}
fmt.Println(runtime.NumGoroutine())   // 1000001, а не 1000000:
                                      // NumGoroutine считает и саму main-горутину
wg.Wait()

Когда ок

• Горутина «лёгкая»: держит только сокет и маленький буфер (классика: сервер на сотни тысяч WebSocket-соединений).
• Работа I/O-bound, горутины почти всегда спят в netpoller.
• Нет общего узкого места: общего мьютекса, общей мапы, одного канала-бутылочного горлышка.

Когда нет

• Каждая горутина открывает соединение к БД: пул на 20 коннектов, миллион ожидающих это очередь, а не параллелизм. Ограничивать надо на входе.
• Каждая держит буфер на 32 КБ, вот и 32 ГБ.
• CPU-bound задачи: больше GOMAXPROCS считающих горутин пользы не даёт, только оверхед на переключения.
• Горутина на каждый элемент коллекции, типичный антипаттерн: дешевле пул из GOMAXPROCS воркеров.

Почему так спроектировано

Принудительно убивать поток давно считается ошибкой дизайна (в Java Thread.stop deprecated с 1.2). Убитая горутина оставила бы за собой захваченные мьютексы, недописанные структуры данных, незакрытые файлы и невыполненные defer. Go выбрал единственный безопасный вариант: горутина сама решает, где ей корректно закончиться.

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

func worker(ctx context.Context, in <-chan Job, out chan<- Result) error {
    for {
        select {
        case <-ctx.Done():
            return ctx.Err()                 // выходим явно
        case job, ok := <-in:
            if !ok {
                return nil                   // источник закрыт, штатно завершаемся
            }
            res, err := handle(ctx, job)     // ctx прокидываем внутрь, иначе отмена не дойдёт
            if err != nil {
                return err
            }
            select {                          // отправка тоже должна отменяться
            case out <- res:
            case <-ctx.Done():
                return ctx.Err()
            }
        }
    }
}

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

• Отмену проверяем, а отправку нет. Классическая утечка: горутина увидела ctx.Done(), но зависла на out <- res, потому что читателя уже нет. Каждая блокирующая операция должна быть в select с ctx.Done().
• Долгая работа без точек проверки. Если внутри цикл на минуту, проверяй ctx.Err() внутри цикла, а не только снаружи.
• ctx не прокинут в вызываемый код. Отдавай ctx в db.QueryContext и в http.NewRequestWithContext, иначе отмена «застрянет» на первом же блокирующем вызове.

runtime.Gosched()

Вызывает mcall(gosched_m): горутину переводят из _Grunning в _Grunnable, кладут в глобальную очередь (важно: не в локальную, чтобы дать шанс другим P), и M идёт выбирать следующую. Горутина не блокируется и не спит, она просто пропускает ход.

После Go 1.14 нужда в нём почти отпала: асинхронное вытеснение справляется само. Остались редкие случаи: бенчмарки и тесты, где нужно спровоцировать переключение; очень длинные вычислительные циклы, где хочется отдать управление раньше 10 мс; спин-ожидание в низкоуровневом коде.

// Gosched не годится для синхронизации: он не барьер и не даёт happens-before
var ready bool
go func() { data = compute(); ready = true }()
for !ready { runtime.Gosched() }   // гонка: компилятор вправе вынести !ready из цикла
// правильно: канал, sync.WaitGroup или atomic.Bool

runtime.NumGoroutine()

Возвращает gcount(): число горутин в состояниях, отличных от «мертва» и «системная». Стоит это несколько атомарных чтений, так что вешать на /metrics можно спокойно, хоть каждую секунду.

// Эта метрика нужна любому Go-сервису: по ней ловят утечку горутин
goroutines := prometheus.NewGaugeFunc(
    prometheus.GaugeOpts{Name: "go_goroutines_current"},
    func() float64 { return float64(runtime.NumGoroutine()) },
)
// Растущий без насыщения график = утечка. Дальше:
//   curl localhost:6060/debug/pprof/goroutine?debug=2
// и смотрим, на какой строке они все стоят.

1. sync.WaitGroup — когда горутин много и результат не нужен

var wg sync.WaitGroup
for _, u := range urls {
    wg.Add(1)                          // Add до go, не внутри горутины
    go func() {                        // Go 1.22+: u уже своя на каждой итерации
        defer wg.Done()                // Done в defer сработает и при панике
        fetch(u)
    }()
}
wg.Wait()

// В Go 1.25 то же короче, и Add/Done уже не забудешь:
var wg sync.WaitGroup
for _, u := range urls {
    wg.Go(func() { fetch(u) })
}
wg.Wait()

2. Канал-сигнал — когда горутина одна

done := make(chan struct{})
go func() { defer close(done); work() }()
<-done                                 // ждём

// с таймаутом:
select {
case <-done:
case <-time.After(5 * time.Second):
    return errors.New("timeout")       // горутина продолжит работать, см. предупреждение ниже
}

3. errgroup — когда нужны ошибки и отмена

g, ctx := errgroup.WithContext(ctx)
g.SetLimit(8)                          // не больше 8 одновременно
for _, u := range urls {
    g.Go(func() error { return fetch(ctx, u) })
}
if err := g.Wait(); err != nil {       // вернёт первую ошибку и отменит ctx для остальных
    return err
}

4. Канал результата — когда нужно одно значение

res := make(chan Result, 1)            // буфер 1, чтобы отправитель не завис, если мы ушли
go func() { res <- compute() }()
r := <-res

Поля hchan

• В qcount и dataqsiz лежат число элементов и вместимость буфера (это и есть len/cap).
• buf указывает на массив dataqsiz * elemsize байт; у небуферизированного канала он nil.
• sendx и recvx: индексы записи и чтения в кольце.
• recvq и sendq держат двусвязные списки sudog: горутины, стоящие на приёме и на отправке.
• А в lock mutex лежит обычный runtime.mutex. Канал не lock-free.
• closed uint32, elemtype, elemsize.

Внутри sudog лежит всё про ожидание: указатель на g, указатель elem на место, откуда взять или куда положить значение, флаг success, ссылки на соседей. У одной горутины бывает несколько sudog сразу, ровно это происходит в select, где она встаёт в очереди сразу нескольких каналов. Кэшируются sudog в P и в глобальном пуле, чтобы не аллоцировать на каждой блокировке.

Главная оптимизация — прямая передача

Если при отправке в recvq кто-то есть, значение не кладётся в буфер: send вызывает sendDirect и копирует значение прямо в стек получателя, минуя буфер вообще. Это экономит одну копию и, что важнее, оставляет данные горячими в кэше. Симметрично работает приём с непустой sendq.

Тут проверяют не память, а умение разложить механизм. Отвечай по нарастающей: сначала наивная версия, потом настоящая.

Шаг 1: наивная версия

Структура: mutex, слайс-очередь, sync.Cond для отправителей и второй для получателей. Send: лок, пока очередь полна висим на cond.Wait(), кладём, condRecv.Signal(), анлок. Это рабочий канал, его правда можно написать на собесе за пять минут. Минусы: два лишних пробуждения на каждую передачу, нет прямой передачи, и select по нескольким каналам так не сделать.

Шаг 2: что добавляет рантайм

• Свои очереди вместо Cond. Нужен явный список ожидающих (sudog), чтобы будить конкретную горутину, а не всех, и чтобы соблюдать FIFO-справедливость.
• gopark/goready вместо futex. Блокировать надо горутину, а не поток: поток должен уйти выполнять другую работу. Обычной библиотеке такое недоступно, отсюда и вывод, что каналы обязаны жить в рантайме.
• Прямая передача. Если ждущий уже есть, копируем ему в стек и не трогаем буфер.
• Поддержка select. Горутина должна уметь стоять в нескольких очередях сразу, и ровно один из каналов должен её «выиграть»: это делается через g.selectDone с CAS.
• Кольцевой буфер вместо слайса: фиксированный размер, никаких реаллокаций, индексы вместо сдвигов.

Практический критерий выбора

• Буфер 0 берут, когда нужна синхронизация и обратное давление (backpressure). Продюсер физически не может обогнать консьюмера. Это дефолт, с которого стоит начинать.
• Буфер 1 работает как «почтовый ящик»: отправитель кладёт и уходит, гарантированно не зависая. Канал ответа в RPC, канал ошибки, сигнальный канал.
• Буфер N сглаживает рывки, когда средняя скорость потребителя выше средней скорости продюсера, а пики короткие. Число надо обосновать (например, «столько же, сколько воркеров»), а не «поставим 100, пусть будет».

Почему именно так — логика, а не произвол

• nil блокирует, а не паникует, чтобы в select можно было отключать ветку присваиванием ch = nil. Свойство спроектированное, а не побочный эффект.
• close паникует на nil, потому что закрывает владелец, а владелец обязан знать, что канал создан. Молчаливое «ничего не делаем» скрыло бы ошибку.
• Send в закрытый паникует, потому что закрытие означает «данных больше не будет». Тихо проглотить значение значит потерять данные, а это хуже паники.
• Recv из закрытого не паникует, потому что получателей может быть много, они узнают о конце асинхронно, и это нормальный путь завершения, а не ошибка.
• Повторный close паникует: значит, владельцев у канала несколько, то есть где-то ошибка в архитектуре.

ch := make(chan int, 3)
ch <- 1
ch <- 2
close(ch)

v, ok := <-ch   // 1, true
v, ok = <-ch    // 2, true
v, ok = <-ch    // 0, false: буфер пуст, канал закрыт
v, ok = <-ch    // 0, false, и так бесконечно

// range делает то же самое и выходит сам, но здесь канал уже вычерпан
// четырьмя строками выше, поэтому цикл ничего не напечатает и сразу завершится:
for v := range ch { fmt.Println(v) }   // ни одной строки

// А вот если бы range шёл сразу после close, не читая вручную:
ch2 := make(chan int, 3)
ch2 <- 1
ch2 <- 2
close(ch2)
for v := range ch2 { fmt.Println(v) }  // 1
                                       // 2

Механика

В chanrecv проверка выглядит так: «если канал закрыт и qcount == 0, вернуть zero и false». Оба условия вместе. Пока в кольцевом буфере что-то есть, работает обычная ветка: скопировать из buf[recvx], сдвинуть recvx, уменьшить qcount. closechan при этом трогает только флаг closed и очереди ожидающих, а буфер не очищает.

Пошагово, что делает рантайм

1. chansend берёт лок канала, видит пустую recvq и dataqsiz == 0.
2. Достаёт sudog из кэша, кладёт в него указатель на отправляемое значение (значение остаётся в стеке отправителя, копии пока нет) и ставит его в sendq.
3. Вызывает gopark: статус _Gwaiting, причина chan send, лок канала отпускается.
4. Управление уходит в schedule(). Поток M не блокируется, он подбирает следующую runnable-горутину и продолжает жечь процессор.
5. Когда придёт получатель, chanrecv найдёт наш sudog, скопирует значение напрямую из нашего стека в свой и вызовет goready.

«Блокировка по существу»

Так называют настоящую, семантическую блокировку: горутина не может продолжить, потому что логически ждёт события. Есть ещё «блокировка по реализации», это когда встал поток ОС. В Go на канале, мьютексе, WaitGroup и сетевом I/O блокируется только горутина: планировщик её снимает и переиспользует поток. А вот блокирующий syscall к диску, вызов через cgo или runtime.LockOSThread блокируют настоящий поток: P у него отберёт sysmon, но сам M будет стоять.

recvq устроен как обычный двусвязный список, а dequeue() берёт голову. Значит, при отправке одного значения его получит горутина, которая раньше всех припарковалась на этом канале. Отсюда канал и работает распределителем работы: N воркеров в for job := range jobs разберут задачи без дублей и без дополнительной синхронизации.

jobs := make(chan int)
for w := 1; w <= 3; w++ {
    go func(id int) {
        for j := range jobs {          // трое читают из одного канала
            fmt.Println("worker", id, "job", j)
        }
    }(w)
}
jobs <- 42        // ровно одну строку напечатает какой-то один worker
close(jobs)       // а вот это увидят все трое: broadcast через close

Вариант 1: close — сигнал «всем, один раз»

done := make(chan struct{})
// N горутин делают <-done и все просыпаются от одного close
close(done)

Работает мгновенно и для тех, кто ещё не успел подписаться: чтение из закрытого канала возвращается сразу. Упирается всё в одноразовость: повторно «раззакрыть» нельзя, данные передать нельзя (только факт). Именно так устроен ctx.Done(). Чтобы передать вместе с сигналом ещё и значение, используют пару: сначала записать значение в поле под мьютексом, потом закрыть канал. Читатель после пробуждения гарантированно увидит запись (close happens-before приём из закрытого канала).

Вариант 2: fan-out — по каналу на подписчика

type Broker[T any] struct {
    mu   sync.RWMutex
    subs map[chan T]struct{}
}

func (b *Broker[T]) Subscribe() (<-chan T, func()) {
    ch := make(chan T, 16)                 // буфер, чтобы медленный подписчик не тормозил всех
    b.mu.Lock()
    b.subs[ch] = struct{}{}
    b.mu.Unlock()
    return ch, func() {                    // отписка
        b.mu.Lock()
        delete(b.subs, ch)
        b.mu.Unlock()
        close(ch)
    }
}

func (b *Broker[T]) Publish(v T) {
    b.mu.RLock()
    defer b.mu.RUnlock()
    for ch := range b.subs {
        select {
        case ch <- v:                      // отправили
        default:                           // подписчик не успевает: дропаем, а не блокируем всех
        }
    }
}

select {
case ch <- v:
    // приняли
default:
    // не приняли: дропаем, считаем метрику, кладём в overflow
}

Почему select, а не len

select с default компилируется в selectnbsend → chansend(c, v, block=false): рантайм берёт лок канала и в одной критической секции и проверяет готовность, и выполняет отправку. Между «проверил» и «отправил» ничего вклиниться не может. Вариант if len(ch) < cap(ch) { ch <- v } распадается на две разные операции: между ними другая горутина заполнит буфер, и ты заблокируешься именно там, где обещал не блокироваться.

Таймаут на операцию с каналом

select {
case v := <-ch:
    return v, nil
case <-time.After(5 * time.Second):
    return zero, context.DeadlineExceeded
}

// В сервисе почти всегда лучше наследовать таймаут от вызывающего:
ctx, cancel := context.WithTimeout(parent, 5*time.Second)
defer cancel()
select {
case v := <-ch:
    return v, nil
case <-ctx.Done():
    return zero, ctx.Err()
}

Обёртка над функцией, которая не умеет отменяться

func withTimeout[T any](ctx context.Context, f func() (T, error)) (T, error) {
    type res struct {
        v   T
        err error
    }
    done := make(chan res, 1)          // буфер 1: горутина не зависнет, если мы ушли
    go func() {
        v, err := f()
        done <- res{v, err}
    }()
    select {
    case r := <-done:
        return r.v, r.err
    case <-ctx.Done():
        var zero T
        return zero, ctx.Err()         // а f() продолжает работать в фоне
    }
}

Цикл for v := range ch компилятор разворачивает ровно в for { v, ok := <-ch; if !ok { break }; ... }. Никаких других способов выйти у него нет: ни len(ch) == 0, ни таймаут его не завершат. Отсюда два практических следствия.

• Если канал не закрыть, горутина с range останется навсегда. Типовая утечка, и часто её не замечают, потому что программа продолжает работать.
• Если выходить надо ещё и по отмене контекста, range не подходит, нужен select.

// range: выход только по close
for v := range ch {
    process(v)
}
// сюда попадём, лишь когда
// кто-то сделает close(ch)

// select: выход по close или по отмене
for {
    select {
    case v, ok := <-ch:
        if !ok { return }
        process(v)
    case <-ctx.Done():
        return
    }
}

Правило закрытия и почему оно именно такое

Закрытие утверждает: «данных больше не будет». Знать это может только тот, кто данные производит. Если получатель закроет канал, любой продолжающий писать отправитель получит панику. Отсюда полный свод:

1. Писатель один: он и закрывает, обычно defer close(ch).
2. Писателей много: никто из них не закрывает, закрывает координатор после wg.Wait() в отдельной горутине.
3. Надо остановить писателя: шли отдельный канал done/ctx в обратную сторону, а не закрывай канал данных получателем.
4. Канал вообще можно не закрывать, если он больше не нужен: GC соберёт его вместе с hchan. Закрытие нужно только как сигнал.

Почему проверка не работает

// Так не работает: между проверкой и отправкой гонка.
if !isClosed(ch) {
    ch <- v      // между if и этой строкой канал могли закрыть -> panic
}

Более того, встроенного isClosed вообще нет. Узнать о закрытости можно единственным способом: попробовать прочитать, а это разрушающая операция.

Работающие подходы, по возрастанию надёжности

1. Дисциплина владения (правильный ответ). У канала один владелец: он создаёт, пишет и закрывает. Наружу отдаётся <-chan T, так что чужой код физически не может ни писать, ни закрывать. 90% проблем исчезает на этом шаге.
2. Отдельный done-канал. Сигнал остановки идёт навстречу потоку данных. Отправитель проверяет его в том же select, что и отправку:

   select {
   case ch <- v:
   case <-done:      // нам сказали остановиться: выходим, не закрывая ch
       return
   }

   Запомни: закрывается done, а не ch. Канал данных вообще может остаться незакрытым, его соберёт GC.
3. sync.Once на close. Если по архитектуре закрыть канал может несколько мест, остаётся один корректный вариант: обернуть закрытие:

   type SafeChan struct {
       ch   chan int
       once sync.Once
   }
   func (s *SafeChan) Close() { s.once.Do(func() { close(s.ch) }) }

   Это убирает панику «close of closed channel», но не убирает панику «send on closed channel»: отправитель по-прежнему может писать в уже закрытый канал.
4. Мьютекс вокруг отправки и закрытия. Полностью безопасно, но убивает саму идею канала: RWMutex, отправка под RLock, закрытие под Lock с флагом. Годится как аварийный вариант в чужом легаси.
5. recover в отправителе. Работает, но это признание в проигрыше: паника уже разрушила инварианты, значение потеряно, и такой код не проходит ревью.

Что делают len и cap

len(ch) читает поле qcount, cap(ch) читает dataqsiz, и оба без взятия c.lock. Data race по букве memory model тут нет (это выровненное чтение одного слова, и рантайм читает его напрямую), но есть race condition на уровне логики: между твоей проверкой и действием состояние канала меняют другие горутины.

// Опасно: TOCTOU, классическая race condition
if len(ch) < cap(ch) {
    ch <- v          // здесь буфер уже могли забить, заблокируемся
}

// Правильно: проверка и отправка атомарны под локом канала
select {
case ch <- v:
default:
}

// Допустимо: метрики, где неточность не критична
metrics.QueueDepth.Set(float64(len(ch)))

Как дочитать канал до конца перед завершением (drain)

// 1. Отправитель закрыл канал, лучший случай:
for v := range ch {         // сам выйдет, когда буфер опустеет
    handle(v)
}

// 2. Канал не закрыт, забираем только то, что уже лежит:
for {
    select {
    case v := <-ch:
        handle(v)
    default:
        return              // готового больше нет, уходим
    }
}

// 3. Дренаж с дедлайном: забрать хвост, но не ждать вечно
t := time.NewTimer(2 * time.Second)
defer t.Stop()
for {
    select {
    case v, ok := <-ch:
        if !ok { return }
        handle(v)
    case <-t.C:
        return              // хвост не успели: потерю принимаем осознанно
    }
}

• chan T двунаправленный, можно всё, включая close.
• chan<- T умеет отправку и close. Чтение не компилируется.
• <-chan T: только приём. Ни отправка, ни close не компилируются: invalid operation: cannot close receive-only channel.

Приведение работает только в сторону сужения и делается неявно при передаче аргумента. Обратно не выйдет даже через явный каст: chan<- int в chan int не приводится. Это и делает гарантию настоящей: получив <-chan T, вернуть себе право писать нельзя.

// Сигнатура сама документирует роль каждой стороны.
func produce(out chan<- Job)        { defer close(out); ... }  // может закрыть
func consume(in  <-chan Job)        { for j := range in { ... } }  // не может испортить
func pipe(in <-chan int) <-chan int { ... }                    // стадия конвейера

ch := make(chan Job)
go produce(ch)     // ch неявно сузился до chan<- Job
consume(ch)        // и до <-chan Job

Канал в канале

Тип chan chan T абсолютно легален, и на нём стоят два рабочих паттерна: «канал ответа внутри запроса» (см. схему выше) и «канал подтверждения остановки». Второй выглядит так:

// Просим воркер остановиться и ждём подтверждения, что он закончил.
type stopReq struct{ ack chan struct{} }

stop := make(chan stopReq)

go func() {                                  // воркер
    for {
        select {
        case r := <-stop:
            cleanup()
            close(r.ack)                     // «я всё, можешь идти дальше»
            return
        case j := <-jobs:
            handle(j)
        }
    }
}()

ack := make(chan struct{})
stop <- stopReq{ack}
<-ack                                        // синхронная остановка с подтверждением

Почему struct{}, а не bool

• unsafe.Sizeof(struct{}{}) == 0. В буферизированном канале на 1000 элементов буфер займёт 0 байт полезных данных вместо 1000; все нулевые значения указывают на runtime.zerobase, и memmove копирует 0 байт. Экономия честная, но в 99% случаев неважная.
• Важнее семантика. chan bool заставляет читателя гадать: а что значит false? «Остановись» или «не останавливайся»? С chan struct{} вопроса не возникает: значение неинформативно по типу, информативен только факт получения (или закрытия).
• Это идиома стандартной библиотеки: ctx.Done() <-chan struct{}, http.Server.Shutdown, все внутренние сигнальные каналы рантайма. map[T]struct{} как множество работает на той же идее.

Почему нельзя

makechan считает размер один раз: если elemsize == 0 или size == 0, выделяется только hchan; иначе hchan и буфер size * elemsize, часто одной аллокацией подряд в памяти. Поменять размер значило бы перевыделить буфер, переложить элементы, поправить sendx/recvx под локом и заодно испортить указатели sudog.elem. Команда Go сознательно оставила канал примитивом с фиксированной ёмкостью: неограниченная очередь прячет отсутствие backpressure, а это чаще баг, чем фича.

Если очень нужно

Два входных и выходных канала плюс горутина-диспетчер со слайсом. Весь трюк в том, чтобы выключать ветку отправки через nil-канал, когда очередь пуста (код выше, в теории главы). Свойства такой конструкции:

• in никогда не блокирует отправителя, очередь растёт в куче;
• порядок FIFO сохраняется;
• цена такая: лишняя горутина, лишняя передача через канал и неограниченный рост памяти, если потребитель медленнее продюсера.

Что важнее размера — владение

Отправляя указатель, ты отдаёшь владение объектом. Контракт должен быть явным: после ch <- p отправитель к *p не прикасается ни на чтение, ни на запись. Нарушишь, получишь гонку, которую race-детектор поймает, только если оба доступа реально совпали по времени в тестовом прогоне. То есть в проде она всплывёт через полгода. Со значением такого класса ошибок не существует физически.

// Опасно: буфер переиспользуется после отправки
buf := make([]byte, 4096)
for {
    n, _ := r.Read(buf)
    ch <- buf[:n]        // отправили заголовок слайса, массив общий
    // следующая итерация перезапишет то, что читает получатель
}

// Безопасно: копия на каждую отправку
for {
    n, _ := r.Read(buf)
    chunk := make([]byte, n)
    copy(chunk, buf[:n])
    ch <- chunk
}

// Безопасно и без аллокаций: буфер возвращается по второму каналу (пул)
free := make(chan []byte, 8)
b := <-free
n, _ := r.Read(b)
ch <- b[:n]              // получатель, закончив, вернёт b в free

type Request struct {
    Payload int
    Reply   chan<- Response          // направленный: воркер только пишет
}
type Response struct {
    Result int
    Err    error
}

type Pool struct {
    reqs chan Request
    wg   sync.WaitGroup
}

func NewPool(n int) *Pool {
    p := &Pool{reqs: make(chan Request)}
    p.wg.Add(n)
    for i := 0; i < n; i++ {
        go func() {
            defer p.wg.Done()
            for r := range p.reqs {      // выйдут все n, когда закроем reqs
                v, err := handle(r.Payload)
                r.Reply <- Response{v, err}   // не заблокируется: буфер 1
            }
        }()
    }
    return p
}

// Для вызывающего Call синхронный, внутри асинхронный.
func (p *Pool) Call(ctx context.Context, v int) (int, error) {
    reply := make(chan Response, 1)       // всё держится на буфере 1
    select {
    case p.reqs <- Request{v, reply}:
    case <-ctx.Done():
        return 0, ctx.Err()               // не смогли даже поставить задачу
    }
    select {
    case r := <-reply:
        return r.Result, r.Err
    case <-ctx.Done():
        return 0, ctx.Err()               // ушли, воркер допишет в буфер и освободится
    }
}

func (p *Pool) Close() { close(p.reqs); p.wg.Wait() }

Что здесь принципиально

• Буфер 1 у канала ответа. Без него брошенный по таймауту запрос навсегда подвешивает воркер. С ним воркер кладёт ответ в буфер, идёт за следующей задачей, а осиротевший канал забирает GC.
• Отмена на обоих select. Клиент может не успеть ни поставить задачу, ни дождаться ответа, поэтому отменяемы должны быть обе точки.
• Направленный тип chan<- Response в структуре: воркер физически не может закрыть чужой канал ответа.
• Закрытие reqs как сигнал остановки всем воркерам сразу, а wg.Wait() как гарантия, что все доработали.

// high приоритетнее low: сначала пытаемся забрать из high неблокирующе.
for {
    select {
    case v := <-high:
        handle(v)
    case v := <-low:
        // прежде чем обработать low, ещё раз проверим high
        select {
        case h := <-high:
            handle(h)
            // low-значение уже забрано из канала, «вернуть» его нельзя,
            // поэтому либо обработать позже, либо держать свою очередь
            handle(v)
        default:
            handle(v)
        }
    case <-ctx.Done():
        return
    }
}

Более чистый вариант — сначала дренаж high

for {
    // 1) выгребаем весь high, пока он не опустеет
    for {
        select {
        case v := <-high:
            handle(v)
            continue
        default:
        }
        break
    }
    // 2) high пуст, блокируемся на всём сразу
    select {
    case v := <-high:
        handle(v)
    case v := <-low:
        handle(v)
    case <-ctx.Done():
        return
    }
}

Что именно течёт

time.After(d) = NewTimer(d).C. Наружу отдают только канал, ссылки на сам *Timer у тебя нет, значит Stop() вызвать невозможно. Таймер лежит в per-P куче таймеров рантайма и удерживает канал и замыкание до истечения d. Если select ушёл в другую ветку, таймер всё равно досидит свой срок. При цикле в 10 000 итераций в секунду и time.After(time.Minute) в пике живёт до 600 000 таймеров, а это десятки мегабайт и заметный рост стоимости операций с кучей таймеров.

// Плохо
for {
    select {
    case v := <-ch:
        handle(v)
    case <-time.After(time.Minute):
        return
    }
}

// Хорошо
t := time.NewTimer(time.Minute)
defer t.Stop()
for {
    select {
    case v := <-ch:
        handle(v)
        if !t.Stop() { <-t.C }
        t.Reset(time.Minute)
    case <-t.C:
        return
    }
}

Три штатные замены

1. Один time.Timer на цикл со Stop/Reset, если таймаут отсчитывается заново после каждого события (idle timeout).
2. context.WithTimeout берут, когда дедлайн общий на всю операцию и должен пробрасываться вглубь. ctx.Done() в select, один defer cancel(), никаких лишних таймеров: cancel честно останавливает внутренний таймер.
3. time.Ticker нужен для периодического такта, а не для однократного дедлайна. Обязательно defer ticker.Stop(): неостановленный тикер будит рантайм, пока на него есть ссылка, а до Go 1.23 — вечно.

Три прохода

1. Проход 1 — пробуем без блокировки. Каналы залочены в lockorder (сортировка по адресу), обход идёт в pollorder (случайная перестановка). Готовый case — это непустая противоположная очередь ожидающих, либо место/данные в буфере, либо закрытый канал на приёме. Нашли: обмен, разлочить всё, вернуть индекс.
2. Проход 2 — встаём в очереди. Если готовых нет и default нет, на каждый case заводится свой sudog и встаёт в sendq или recvq нужного канала. Потом gopark: горутина уходит в _Gwaiting, все локи отпускаются, поток ОС продолжает работать с другими горутинами.
3. Проход 3 — уборка. Кто-то пришёл на один из каналов, выиграл гонку через CAS на g.selectDone, передал значение и вызвал goready. Проснувшись, selectgo снова берёт все локи и снимает свои sudog со всех очередей, возвращая их в кэш.

Две неочевидные детали

• Зачем сортировка по адресу. Два select в разных горутинах могут пересекаться по каналам. Если бы один брал локи в порядке A, B, а другой в порядке B, A, вышел бы классический дедлок на внутренних локах рантайма. Глобальный порядок «по возрастанию адреса» это исключает.
• Зачем CAS на selectDone. Горутина стоит в нескольких очередях, и два разных канала могут одновременно решить, что партнёр именно она. CAS 0→1 определяет единственного победителя; проигравший видит, что горутина уже занята, и идёт искать следующего в очереди.

Что было бы при проверке сверху вниз

for {
    select {
    case <-ticker.C:      // если бы порядок задавал приоритет,
        report()          // тикер раз в 10 мс всегда был бы готов,
    case j := <-jobs:     // и вот эта ветка не выполнилась бы никогда
        handle(j)
    }
}

Со случайным выбором обе ветки в среднем берут по половине готовых итераций, и порядок, в котором разработчик написал case, ни на что не влияет.

Три эффекта, ради которых это сделано

• Нет голодания. Ни одну ветку не заглушит соседняя, какой бы «горячей» она ни была.
• Перестановка веток не меняет поведение. Значит, рефакторинг безопасен, а ревьюер не должен держать в голове приоритеты.
• Расфазировка одинаковых воркеров. Пять горутин с одинаковым select не выстраиваются в одну и ту же последовательность решений.

Как именно реализована случайность

В selectgo массив индексов перемешивает алгоритм Фишера-Йетса, а случайные числа даёт быстрый потоковый генератор рантайма (cheaprandn, состояние живёт в m, без блокировок и без обращения к math/rand). Перемешивается только pollorder, порядок опроса; локи (lockorder) берутся строго по возрастанию адреса.

// Неблокирующий приём
select {
case v := <-ch: use(v)
default:        // канал пуст
}

// Неблокирующая отправка
select {
case ch <- v:
default:        // буфер полон / получателя нет
}

// Неблокирующая проверка отмены
select {
case <-ctx.Done(): return ctx.Err()
default:        // не отменён, считаем дальше
}

Ключевое свойство: атомарность

Проверка «готов ли канал» и сама операция идут внутри одной критической секции под локом канала. Поэтому select/default нельзя заменить на if len(ch) > 0 { v := <-ch }: между if и чтением значение успеет забрать другая горутина, и ты заблокируешься.

Где применяют по делу

• Телеметрия и логи: лучше потерять сэмпл метрики, чем притормозить обработку запроса.
• Сигнальные каналы с буфером 1: «есть новая работа», и если сигнал уже лежит, второй не нужен.
• Дренаж: забрать всё, что уже накопилось, и уйти.
• Периодическая проверка отмены внутри долгого вычисления.

Такая горутина не потребляет CPU и не занимает поток ОС, она просто выпадает из планировщика насовсем. Разбудить её нечем: у неё нет ни одного sudog ни в одной очереди.

Единственное осмысленное применение

func main() {
    go worker()
    go metricsServer()
    select {}     // «главная горутина, повиси, пока работают фоновые»
}

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

В selectgo case с nil-каналом просто пропускается при опросе и не получает sudog. Поэтому он не мешает остальным, не тратит ресурсов и никогда не выигрывает. Если все каналы nil и default нет, горутина заблокируется навсегда, ровно как на select {}.

Паттерн 1: отправлять, только когда есть что

var out chan Result          // nil, пока результата нет
var pending Result
for {
    select {
    case v := <-in:
        pending = compute(v)
        out = results        // включаем ветку отправки
    case out <- pending:
        out = nil            // выключаем: отправлять больше нечего
    case <-ctx.Done():
        return
    }
}

Без этого приёма пришлось бы либо крутить default-цикл, либо отправлять нулевые значения, либо разводить два разных select и дублировать в каждом логику отмены.

Паттерн 2: аккуратное завершение при закрытии одного из источников

// merge двух каналов: закрывшийся источник обнуляем, чтобы не крутиться на нём вечно
for a != nil || b != nil {
    select {
    case v, ok := <-a:
        if !ok { a = nil; continue }   // закрытый канал всегда готов, поэтому обнуляем
        out <- v
    case v, ok := <-b:
        if !ok { b = nil; continue }
        out <- v
    }
}
close(out)

Таймаут

// Разово можно и time.After
select {
case v := <-ch:
    return v, nil
case <-time.After(5 * time.Second):
    return zero, errTimeout
}

// В цикле только переиспользуемый таймер
t := time.NewTimer(5 * time.Second)
defer t.Stop()

Отмена по контексту

select {
case v := <-ch:
    use(v)
case <-ctx.Done():
    return ctx.Err()      // context.Canceled или context.DeadlineExceeded
}

Так лучше, чем time.After: дедлайн приходит сверху, его наследуют все вложенные вызовы, снимает его явный cancel(), и лишних таймеров не плодится.

Graceful-цикл воркера

func worker(ctx context.Context, jobs <-chan Job, out chan<- Result) error {
    tick := time.NewTicker(time.Minute)
    defer tick.Stop()
    for {
        select {
        case j, ok := <-jobs:
            if !ok {
                return nil                  // 1) продюсер закрыл вход, выходим штатно
            }
            r, err := handle(ctx, j)
            if err != nil {
                return err
            }
            select {                         // 2) отправка результата тоже отменяема
            case out <- r:
            case <-ctx.Done():
                return ctx.Err()
            }
        case <-tick.C:
            heartbeat()
        case <-ctx.Done():
            return ctx.Err()                 // 3) внешняя отмена
        }
    }
}

Путь захвата

1. CAS(state, 0, locked) — успех, ~15–25 нс, дальше ничего не происходит.
2. Спин. Занят, но normal mode и есть свободные ядра — крутимся до 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, делая счётчик отрицательным, и ждём, пока уже вошедшие читатели выйдут.

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

• Читателей на порядок больше писателей и критическая секция длинная (десятки микросекунд и больше): парсинг, обход структуры, сериализация под локом.
• Не даёт выигрыша на «прочитать одно поле»: у RWMutex вдвое больше атомарных операций, чем у Mutex, и на секции в 20 нс накладные расходы съедают весь параллелизм.
• Бывает и хуже при большом числе ядер: 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), запускает горутину и гарантирует wg.Done() через defer — то есть ошибки 1, 3 и частично 2 становятся невозможными. Панику внутри 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.Uint32
    m    Mutex
}

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

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

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

• Почему done ставится после f? Если бы до, вторая горутина увидела бы done == 1 и пошла работать с наполовину проинициализированным объектом. Сейчас она блокируется на мьютексе и выходит из 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 как expunged, физическая уборка происходит при очередном пересоздании dirty.
• Обновление существующего ключа идёт через 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]/Value закрывают сразу три дыры: нельзя обратиться к полю напрямую, гарантировано 8-байтное выравнивание (на 32-битных платформах старый API требовал ручной заботы, иначе паника), и go vet ловит копирование через встроенный noCopy.

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 и в комментариях к sync прямо написано: используйте мьютекс там, где он естественнее. Стандартная библиотека полна мьютексов (net/http, database/sql, runtime).

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

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

// Счётчик «по-гошному» через канал: в разы медленнее и в разы сложнее
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

Задача, которую он решает

Один входящий запрос порождает десятки горутин: сервисный слой, три параллельных запроса к БД, вызов внешнего API, запись в кэш. Клиент отвалился через 200 мс, и вся эта работа стала бессмысленной, но продолжает жечь CPU, держать соединения из пула и место в памяти. Без общего механизма каждый слой пришлось бы связывать своим done-каналом и передавать его руками через все сигнатуры.

Context даёт ровно такой done-канал, только со стандартным интерфейсом из четырёх методов, который понимают database/sql, net/http, gRPC, драйверы Kafka и вообще вся экосистема. Ценна тут именно стандартизация: любая библиотека умеет отменяться одинаково.

Дерево

• Корнем служит context.Background(), он никогда не отменяется и не имеет дедлайна. Это emptyCtx, буквально пустая структура.
• Каждый WithCancel/WithTimeout/WithValue создаёт новый контекст-потомок, ссылающийся на родителя. Родитель о потомке знает через карту children (только отменяемые потомки в ней есть).
• Отмена родителя рекурсивно отменяет всех потомков. Отмена потомка на родителя не влияет: сигнал ходит только вниз.
• Дедлайн наследуется по минимуму: потомок не может жить дольше родителя. WithTimeout(ctx, time.Hour) внутри запроса с бюджетом 200 мс не даст ничего.

Механика отмены

Done() возвращает <-chan struct{}, который при отмене закрывается. Закрытие канала будит сразу всех, кто на нём ждёт, и повторное чтение из закрытого канала возвращает нулевое значение мгновенно. Поэтому один и тот же контекст можно проверять из любого числа горутин без всяких блокировок. Сам канал создаётся лениво: если Done() никто не звал, канала в структуре нет.

Разбор по одному

• WithCancel(parent) отменяется только по явному вызову cancel(). Для фоновых воркеров, конвейеров, «останови всё, если один упал». Возвращает cancelCtx.
• WithTimeout(parent, d) — отмена через интервал. 95% случаев в продовом коде: «запрос к платёжке не дольше 800 мс». Внутри лежит timerCtx, то есть cancelCtx + time.Timer, который при срабатывании зовёт ту же cancel с DeadlineExceeded.
• WithDeadline(parent, t) отменяет в абсолютный момент. Нужен, когда бюджет делится между последовательными шагами: три вызова по WithTimeout(ctx, 1s) дадут суммарно 3 секунды, а один WithDeadline сверху честно ограничит весь запрос секундой. Так обычно и делают «сквозной дедлайн», передавая его в заголовке между сервисами.
• WithValue(parent, k, v) стоит особняком: это valueCtx, у него нет ни отмены, ни таймера, ни карты детей. Одно значение на узел; поиск Value(k) идёт линейно вверх по цепочке до корня. Отсюда правило: не наворачивать десятки значений, каждое это лишний узел и лишний шаг поиска.

Стоимость

WithValue стоит одну маленькую аллокацию, поиск идёт за O(глубины). WithCancel добавляет к аллокации запись в карту children родителя под мьютексом. WithTimeout делает то же самое плюс таймер в куче таймеров рантайма. На горячем пути с миллионом RPS это заметно, а в обычном сервисе это шум рядом с сетевым вызовом.

Что ловят

Почему это понадобилось

До Go 1.20 весь мир видел в логах ровно две строки: context canceled и context deadline exceeded. Кто отменил, на каком уровне и из-за чего, оставалось загадкой. В сервисе с errgroup и десятью параллельными вызовами это означало, что при падении одного из них девять остальных писали в лог бесполезное context canceled, а настоящая ошибка терялась.

var errTooManyRetries = errors.New("исчерпаны ретраи")

ctx, cancel := context.WithCancelCause(parent)
defer cancel(nil)                       // nil = штатное завершение

go func() {
    if err := doRetries(ctx); err != nil {
        cancel(fmt.Errorf("%w: %v", errTooManyRetries, err))
    }
}()

<-ctx.Done()
ctx.Err()                               // context.Canceled, всегда
context.Cause(ctx)                      // "исчерпаны ретраи: dial tcp: i/o timeout"
errors.Is(context.Cause(ctx), errTooManyRetries)  // true: причину можно матчить

Детали, которые отличают знающего

• Cause наследуется вниз. Причина хранится в узле, где произошла отмена; потомки, отменённые каскадом, отдают ту же причину. Поэтому её видно из самой глубины стека.
• На неотменённом контексте Cause возвращает nil, ровно как и Err().
• Если причину не задали (обычный WithCancel), Cause вернёт то же, что Err(). То есть звать Cause вместо Err() в логах безопасно всегда.
• Go 1.21 добавил WithTimeoutCause и WithDeadlineCause: при истечении Err() будет DeadlineExceeded, а Cause отдаст твою ошибку вроде errBillingSlow. Удобно, когда в цепочке несколько таймаутов и надо понять, чей сработал.
• errgroup с 1.20 внутри использует WithCancelCause, так что причиной отмены группы становится ошибка первой упавшей горутины.

Почему первым аргументом и с именем ctx

Это конвенция всей стандартной библиотеки: func (db *DB) QueryContext(ctx context.Context, query string, args ...any). Единообразие даёт дешёвый греп (grep -rn "ctx context.Context" находит все отменяемые точки), позволяет линтерам вроде contextcheck и containedctx работать, и делает обёртки-мидлвари механическими. Исключение только одно: контекст не передают в конструкторы объектов, живущих дольше вызова.

Почему не хранить в полях структуры

// Антипаттерн
type Service struct {
    ctx context.Context      // чей это контекст? какого запроса?
    db  *sql.DB
}
func (s *Service) Get(id int) (*User, error) {
    return s.db.QueryRowContext(s.ctx, ...)   // отменится, когда отменится... что-то
}

Сервис живёт весь аптайм, он синглтон. Контекст запроса живёт 200 мс. Положишь один в другой, и получишь либо вечный контекст (тогда отмена не работает вовсе), либо контекст первого запроса, отмена которого убьёт все последующие. Плюс гонка: поле пишется и читается из разных горутин. Линтер containedctx в golangci-lint ловит это правилом. Легальное исключение признано самим стандартом: http.Request, где контекст неотделим от объекта запроса и меняется через r.WithContext(ctx), создающий копию.

Почему WithValue — не для зависимостей

• Нет типобезопасности. ctx.Value(k).(*sql.DB) приводит тип в рантайме. Убрали значение из мидлвари, и узнаешь об этом паникой в проде, а не ошибкой компиляции.
• Нет видимости зависимостей. Сигнатура func Handle(ctx context.Context) ничего не говорит о том, что функции нужны БД, логгер и кэш. Явные параметры или поля структуры документируют себя сами.
• Ключ обязан быть своим неэкспортируемым типом. Строковый ключ "user" может совпасть с чужим из библиотеки и молча перетереться. Потому go vet и ругается на базовые типы в ключах.
• Что класть можно: request id, trace id / span, user id и роли после аутентификации, локаль, флаги A/B-теста, дедлайн-подсказки. То есть всё, что относится к конкретному запросу и нужно на всех уровнях, но бизнес-параметром функции не считается.

Механика

На каждое принятое соединение сервер запускает conn.serve. Внутри, пока выполняется хендлер, работает фоновое чтение (startBackgroundRead): оно ждёт данных, чтобы поймать либо новый пайплайненный запрос, либо закрытие. Если чтение вернуло EOF или ECONNRESET, вызывается cancelCtx, и контекст запроса отменяется с context.Canceled. В HTTP/2 то же самое делает RST_STREAM или закрытие стрима.

func handler(w http.ResponseWriter, r *http.Request) {
    ctx := r.Context()
    select {
    case res := <-doWork(ctx):
        json.NewEncoder(w).Encode(res)
    case <-ctx.Done():
        // клиент ушёл, сработал WriteTimeout или идёт Shutdown
        log.Info("отменено", "err", ctx.Err(), "cause", context.Cause(ctx))
        return          // писать в w бессмысленно, но безопасно
    }
}

Четыре причины отмены r.Context()

1. Клиент разорвал соединение или отменил стрим.
2. Истёк Server.WriteTimeout / сработал http.TimeoutHandler.
3. Идёт Server.Shutdown и вышел его дедлайн, либо вызван Server.Close.
4. ServeHTTP просто вернул управление: контекст отменяется всегда, даже при успешном ответе.

БД

// Правильно
rows, err := db.QueryContext(ctx, "select id, name from users where org = $1", orgID)
tx, err := db.BeginTx(ctx, &sql.TxOptions{Isolation: sql.LevelReadCommitted})
_, err = tx.ExecContext(ctx, "update balances set amount = amount - $1 where id = $2", sum, id)

// Неправильно: эти формы отмену вообще не видят
rows, err := db.Query(...)   // внутри это QueryContext(context.Background(), ...)

Контекст в database/sql работает на трёх уровнях. Во-первых, ожидание свободного соединения из пула прерывается по ctx.Done(): при исчерпанном пуле запрос падает с context deadline exceeded вместо бесконечного ожидания. Во-вторых, драйвер, реализующий QueryerContext, отправляет серверу отмену (в pgx/lib pq это CancelRequest, отдельное соединение с сообщением отмены, в MySQL это KILL QUERY). В-третьих, при отмене посреди чтения rows соединение возвращается в пул корректно, а не рвётся.

HTTP-клиент

req, _ := http.NewRequestWithContext(ctx, http.MethodPost, url, body)
resp, err := client.Do(req)

При отмене Transport закрывает соединение (в HTTP/2 шлёт RST_STREAM), а Do возвращает ошибку, обёрнутую *url.Error. Проверять надо через errors.Is(err, context.DeadlineExceeded), а не сравнением строк. И отдельно: resp.Body закрывай всегда, иначе соединение не вернётся в пул и никакая отмена не поможет.

Иерархия таймаутов

• Общий бюджет запроса ставит WithDeadline в мидлвари, например 3 с.
• Пер-вызов: WithTimeout на каждый внешний вызов, меньше бюджета. БД 500 мс, биллинг 800 мс. Дедлайн наследуется, так что суммарно всё равно не выйдет за 3 с.
• client.Timeout — грубая страховка на весь запрос, включая чтение тела; контекст точнее, и ставить его надо в дополнение, а не вместо.
• Ретраи считают оставшийся бюджет: d, ok := ctx.Deadline(), и если до дедлайна меньше, чем средняя длительность вызова, ретрай не начинают.

Канонический код

ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
defer stop()

errCh := make(chan error, 1)
go func() { errCh <- srv.ListenAndServe() }()

select {
case err := <-errCh:
    if !errors.Is(err, http.ErrServerClosed) {
        log.Fatal(err)                  // порт занят и подобное
    }
case <-ctx.Done():
    log.Info("получен сигнал, останавливаемся")
}
stop()                                  // вернуть дефолтный обработчик: второй Ctrl+C убьёт сразу

shutCtx, cancel := context.WithTimeout(context.Background(), 25*time.Second)
defer cancel()
if err := srv.Shutdown(shutCtx); err != nil {
    log.Warn("таймаут graceful, рвём соединения")
    _ = srv.Close()
}

Что делает Shutdown по шагам

1. Помечает сервер как закрывающийся и закрывает слушающие сокеты: новых соединений ОС уже не принимает (клиенты получат connection refused, поэтому балансировщик надо вывести из ротации ЗАРАНЕЕ).
2. Закрывает все idle keep-alive соединения.
3. В цикле с растущим интервалом (от 1 мс до 500 мс) проверяет, остались ли активные запросы, и ждёт, пока их не станет ноль либо не истечёт переданный контекст.
4. Вызывает зарегистрированные RegisterOnShutdown хуки: там обычно закрывают WebSocket-соединения, которые Shutdown не видит.

Порядок в реальном сервисе

Сначала readiness-проба возвращает 503 (или сервис снимают из балансировщика), потом несколько секунд ждут, чтобы трафик перестал приходить. Потом srv.Shutdown с дедлайном чуть меньше, чем terminationGracePeriodSeconds в Kubernetes (иначе прилетит SIGKILL посреди уборки). Потом останавливают консьюмеры и воркеры, потом закрывают пулы БД и Redis, последним идёт flush метрик и трейсов. Подробный разбор с кодом лежит в главе 2.7.

Шаг 1: сигнал

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

Шаг 2: иерархия

type myCtx struct {
    mu       sync.Mutex
    done     chan struct{}
    err      error
    children map[*myCtx]struct{}
    deadline time.Time
    timer    *time.Timer
}

func WithCancel(p *myCtx) (*myCtx, func()) {
    c := &myCtx{done: make(chan struct{}), children: map[*myCtx]struct{}{}}
    p.mu.Lock()
    if p.err != nil {                 // родитель уже мёртв, и ребёнок рождается мёртвым
        p.mu.Unlock()
        c.cancel(p.err)
        return c, func() {}
    }
    p.children[c] = struct{}{}
    p.mu.Unlock()
    return c, func() { c.cancel(errCanceled); p.remove(c) }
}

func (c *myCtx) cancel(err error) {
    c.mu.Lock()
    if c.err != nil {                 // идемпотентность
        c.mu.Unlock()
        return
    }
    c.err = err
    close(c.done)                     // будим всех своих слушателей
    kids := c.children
    c.children = nil
    if c.timer != nil {
        c.timer.Stop()
    }
    c.mu.Unlock()

    for k := range kids {             // каскад вниз, вне лока, иначе дедлок на детях
        k.cancel(err)
    }
}

Шаг 3: дедлайн и значения

Таймаут собирается из time.AfterFunc(d, func(){ c.cancel(errDeadline) }) плюс наследование: если у родителя дедлайн раньше, свой таймер не нужен вовсе. Значения живут в отдельном типе-обёртке с одной парой ключ/значение и рекурсивным поиском вверх; он неотменяемый и потому не участвует в дереве отмены.

Грабли, о которые спотыкаются на доске

Типовой пример

// Плохо: получили ctx и не используем его
func fetch(ctx context.Context, urls []string) []Result {
    ch := make(chan Result)              // небуферизованный
    for _, u := range urls {
        go func(u string) {
            ch <- get(u)                 // встанет навсегда, если читатель ушёл
        }(u)
    }
    var out []Result
    for range urls {
        select {
        case r := <-ch:
            out = append(out, r)
        case <-ctx.Done():
            return out                   // вышли, а N горутин навсегда заперты на ch
        }
    }
    return out
}

Утечка здесь ровно в том, что отправители не знают об отмене. Чинится двумя независимыми способами: сделать канал буферизованным на len(urls), чтобы отправка никогда не блокировала, либо научить отправителя смотреть на контекст.

// Хорошо, вариант 1: буфер под все результаты, отправка никогда не блокирует
ch := make(chan Result, len(urls))

// Хорошо, вариант 2: отправитель уважает отмену
go func(u string) {
    select {
    case ch <- get(u):
    case <-ctx.Done():                   // читателя больше нет, уходим
    }
}(u)

Другие сценарии

• Долгий цикл без проверки. В for _, row := range millionRows { heavy(row) } отмену не смотрят ни разу. Лечится select { case <-ctx.Done(): return ctx.Err(); default: } в начале итерации (это неблокирующая проверка, стоит единицы наносекунд).
• time.Sleep вместо таймера. Спящая горутина не отменяема. Меняй на select { case <-time.After(d): case <-ctx.Done(): } или timer := time.NewTimer(d); defer timer.Stop().
• Вызов без Context-варианта. db.Query, http.Get, conn.Read без дедлайна: контекст есть, а отменять нечего. Для голых сокетов помогает conn.SetReadDeadline плюс context.AfterFunc(ctx, func(){ conn.Close() }).
• Фон, переживший запрос. С go audit(r.Context(), ev) проблема обратная: не утечка, а мгновенная смерть задачи. Нужен context.WithoutCancel.

Как ловить

• Метрика runtime.NumGoroutine() в мониторинге: монотонный рост под ровной нагрузкой почти всегда означает утечку.
• go tool pprof http://host/debug/pprof/goroutine: в профиле видно, на какой строке заблокированы тысячи одинаковых горутин.
• go.uber.org/goleak в TestMain уронит тест, если после него остались лишние горутины. Дешевле всего ловить именно тут.

Как отвечать по шагам

1. Назвать проблему точно. «counter++ не атомарен: по сути это чтение из памяти, инкремент и запись обратно (на arm64 три инструкции, на amd64 одна INCQ, но без префикса LOCK и она не атомарна). Две горутины читают одно и то же значение, обе прибавляют единицу, обе записывают — одно обновление потеряно. Это lost update.»
2. Показать масштаб. «На 1000 горутин по 1000 инкрементов вместо миллиона получится случайное число, и чем больше ядер, тем оно меньше: на двух ядрах около 64% от ожидаемого, на 14 ядрах около 22%. И оно разное от запуска к запуску.»
3. Доказать инструментом. go run -race main.go и показать WARNING: DATA RACE с двумя стеками.
4. Починить и объяснить выбор. Три варианта из теории выше, и главное тут критерий выбора, а не список из трёх пунктов.

Компактный сравнительный бенчмарк

// 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.

Формальное определение из Go Memory Model

«Программа с гонкой данных — это программа, в которой есть обращение на запись к переменной памяти, конкурентное с другим обращением к той же переменной, и хотя бы одно из них не является атомарным.» Конкурентные — значит не упорядоченные отношением happens-before. С 1.19 модель Go явно ограничивает и поведение при гонке: чтение значения размером в машинное слово вернёт одно из значений, записанных предшествующей или конкурентной записью, а не что-то «из воздуха». Для значений больше слова (интерфейс, строка, слайс) такой гарантии нет, и гонка на них может закончиться порчей памяти. Но это всё равно не C++, где UB тотальный.

Что говорить, если просят «в общих чертах»

«Каждая горутина носит вектор часов — по счётчику на каждую известную горутину. Синхронизация (Unlock/Lock, отправка/приём в канале, atomic) передаёт эти часы от одной горутины к другой через максимум. Каждые 8 байт памяти сопровождаются несколькими теневыми ячейками, где записано "горутина G, эпоха E, чтение/запись, размер". При новом доступе детектор сверяет эпоху из тени со своим знанием о той горутине: если моя копия часов уже "видит" ту эпоху — доступы упорядочены, всё в порядке. Если нет — это гонка, и в отчёт печатаются оба стека.»

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

• Гонке не нужно проявиться. Достаточно, чтобы обе операции выполнились хоть раз, пусть даже с разрывом в минуты. Поэтому -race находит то, что в проде падает раз в квартал.
• Ложных срабатываний практически не бывает. Отчёт детектора — это доказательство, а не подозрение. Если он что-то напечатал, это надо чинить, а не «перепроверять».
• Он проверяет и стандартную библиотеку. Гонки внутри неё (неправильное использование http.Request, запись в http.ResponseWriter из горутины после выхода из хендлера) находятся тем же способом.

Где искать, что -race не найдёт

Ключ к «гарантированно»

Формулировка вопроса не случайна: без принудительного окна код с двумя мьютексами дедлочится вероятностно и на маленьком примере может отработать сто раз подряд. Правильный ответ содержит time.Sleep (или runtime.Gosched(), или синхронизацию на канале) между первым и вторым Lock — это делает совпадение окон детерминированным. Проговорить это вслух — половина оценки за вопрос.

// Вариант с каналом вместо 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()
}

Дедлоки, которые встречаются в реальном коде

• Реентрантный вызов. Метод берёт лок и зовёт другой публичный метод того же типа, который берёт тот же лок. sync.Mutex не реентрантный — мгновенный самодедлок. Лечение: приватные методы xxxLocked(), которые лок не берут, и соглашение о суффиксе.
• Колбэк под локом. Под мьютексом вызывается пользовательская функция, которая сама берёт этот же лок (например, обращается к тому же объекту).
• RLock внутри RLock. Выглядит безобидно (читатели же не мешают друг другу), но если между ними встал писатель — дедлок, потому что RWMutex блокирует новых читателей ради писателя.
• WaitGroup.Wait() раньше чтения. Воркеры пишут в небуферизованный results, main сначала wg.Wait(), потом читает — воркеры стоят на отправке, main стоит на Wait. Классика конвейеров.
• Один канал на запрос и на ответ. Обе стороны шлют, обе ждут.

Механика

Планировщик вызывает checkdead в момент, когда последний «рабочий» M собирается уснуть (в stopm, при mput). Сначала он считает неспящие потоки: все M минус простаивающие, минус простаивающие, но привязанные к горутине через LockOSThread, минус служебные вроде sysmon. Поток в системном вызове не простаивает, и на нём проверка заканчивается. Если неспящих M нет, он обходит все горутины и смотрит таймеры в кучах P. Таймеров нет, а живые горутины есть и все ждут — значит, ждут события, которое некому произвести. Рантайм печатает fatal error: all goroutines are asleep - deadlock!, дампит стеки и завершает процесс с кодом 2.

Дополнительно в дампе у частных случаев уточнённое состояние: отправка в nil-канал и приём из него дают [chan send (nil chan)] и [chan receive (nil chan)], select без единого кейса — [select (no cases)]. Это лишь подсказка, а не отдельный алгоритм.

Пять ситуаций, когда детектор молчит

// Один и тот же дедлок: с падением и без.
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!  (строки «поймали:» нет,
// рантайм не разматывает стек и вообще не запускает отложенные функции)

Порядок действий по инциденту

1. Посмотреть метрики. go_goroutines — полка или рост? CPU — ноль (дедлок) или сотка (livelock)? RPS упал в ноль или частично?
2. Снять дамп, не убивая под. curl host:6060/debug/pprof/goroutine?debug=2 > dump.txt. Если pprof не подключён — снимать через kill -QUIT на поде, который не жалко, предварительно выведя его из балансировки.
3. Сгруппировать. Состояние указано в заголовке каждой горутины, а у стоящих дольше минуты — и время: goroutine 42 [sync.Mutex.Lock, 17 minutes].
4. Найти пару. Для дедлока на локах характерны две-три группы, чьи стеки берут одни и те же мьютексы в разном порядке. Для утечки — одна разросшаяся группа с одинаковым стеком.
5. Проверить внешние ресурсы. Если все висят в IO wait / select вокруг database/sql — это не дедлок Go, а исчерпанный пул соединений или дедлок в самой БД.

# Минимальный набор для прода: 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 { ... }

Внешние ресурсы

• База данных. Две транзакции берут строки в разном порядке — классический дедлок. Postgres обнаруживает его сам (по умолчанию через deadlock_timeout, 1 с) и убивает одну транзакцию с SQLSTATE 40P01; MySQL/InnoDB — с ошибкой 1213. Задача приложения — распознать код и повторить транзакцию. Профилактика та же: единый порядок обновления строк, короткие транзакции, SELECT ... FOR UPDATE в детерминированном порядке (например, ORDER BY id).
• Пул соединений. Отдельный, очень частый случай: хендлер держит соединение и внутри просит второе из того же пула (например, вложенный запрос под транзакцией). При SetMaxOpenConns(N) и N параллельных запросах пул исчерпан, и все ждут друг друга. Симптом — все горутины в database/sql.(*DB).conn. Лечение: не брать второе соединение под первым, передавать *sql.Tx вниз явно.
• Распределённые локи. Redis/etcd/Zookeeper: дедлок возможен, детектора нет ни у кого. Спасает только TTL на локе и единый порядок захвата.
• Файлы и ОС. flock, именованные семафоры, полный pipe, который никто не читает.

Livelock: как получается

// Две горутины «вежливо уступают» друг другу и обе не двигаются.
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)

Другие источники livelock в реальных системах: цикл ретраев без джиттера (все клиенты бьют в один и тот же момент — «громовое стадо») и взаимные откаты транзакций, которые тут же перезапускаются. Общий признак — высокий CPU при нулевом прогрессе, что легко отличить от дедлока по графику загрузки.

Starvation в Go: где встроена защита

Три вопроса к каждому go func

1. Что её завершит? Ровно три допустимых ответа: закроется входной канал, сработает ctx.Done(), закончится конечная работа.
2. Кто её дождётся? WaitGroup, errgroup или канал завершения. Горутина, которую никто не ждёт, при shutdown будет убита посреди работы.
3. Что она удерживает? Замыкание держит все захваченные переменные. Горутина, которая «просто ждёт», может удерживать в живых мегабайтный буфер запроса и сетевое соединение.

Сценарии, помимо перечисленных в теории

• Отправка в канал результата после отмены. Даже с select на ctx.Done() в цикле, финальная отправка out <- res в конце функции — незащищённая точка утечки. Отправлять тоже надо через select.
• time.After в цикле select. Каждая итерация создаёт новый таймер, который до Go 1.23 удерживался рантаймом до срабатывания. В горячем цикле это была утечка памяти (не горутин, но эффект тот же). Так было до 1.23; стало — недостижимый таймер собирается GC, и утечки в прежнем виде больше нет. В Go 1.27 переключатель GODEBUG=asynctimerchan, которым можно было вернуть старое поведение, удалён совсем: каналы таймеров теперь всегда небуферизованные, независимо от версии в go.mod. С тикерами то же: Ticker без Stop() соберут, когда пропадут ссылки, а тикер, из которого никто не читает, рантайм не нагружает. Утечкой остаётся горутина, которая читает из тикера в цикле без выхода, — и тикер вместе с ней.
• Горутина, ждущая на sync.Cond.Wait(). Если никто не позовёт Broadcast, разбудить её нечем: у Cond нет отмены по контексту вообще. Одна из причин, по которой Cond редко берут.
• Незакрытый http.Response.Body. Если тело не дочитано, держит соединение и две горутины транспорта (чтения и записи), сборщик их не освободит. С лимитом соединений на хост новые запросы встают, без лимита копятся соединения и дескрипторы.
• Подписка на события без отписки — брокер, watch в etcd, обработчик сигналов.

Инструменты обнаружения

// Ручная проверка в тесте, если тянуть 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])
}

Как писать это на доске, чтобы не запутаться

Не начинайте с кода. Начните с четырёх вопросов вслух. Интервьюер оценивает именно это, а код потом ложится сам:

1. Сколько каналов и кто их владелец? Два: jobs (владеет продюсер) и results (владеют воркеры, коллективно).
2. Кто и когда их закрывает? jobs закрывает продюсер после последней задачи. results закрывает отдельная горутина go func(){ wg.Wait(); close(results) }(): ни один воркер не знает, закончили ли остальные.
3. Что произойдёт при отмене посередине? Продюсер перестаёт раздавать, воркеры доделывают текущее, коллектор дочитывает то, что успели положить.
4. Что если получателя результатов не станет? Либо буфер на все результаты, либо select с ctx.Done() на отправке. Иначе утечёт ровно N горутин.

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

jobs := make(chan Job)
res  := make(chan Result, len(input))
var wg sync.WaitGroup

for i := 0; i < n; i++ {
    wg.Go(func() {                       // Go 1.25; до неё: wg.Add(1) + go func + defer wg.Done()
        for j := range jobs {
            out, err := handle(ctx, j)
            res <- Result{j.ID, out, err}
        }
    })
}
go func() { defer close(jobs); for _, j := range input { jobs <- j } }()
go func() { wg.Wait(); close(res) }()

for r := range res { collect(r) }

Почему именно так

• Отправка в закрытый канал роняет панику, и проверкой её не предотвратить: между «проверил, что не закрыт» и «отправил» есть окно. Значит, безопасный протокол один: закрывать со стороны отправителя, когда он точно знает, что больше не пошлёт.
• Повторный close тоже паника. Отсюда либо один владелец, либо sync.Once, либо флаг под мьютексом.
• Приём из закрытого канала безопасен и мгновенен: возвращает нулевое значение и ok == false. Поэтому close и работает как широковещательный сигнал для любого числа получателей: именно на этом построен context.Done().

Три конфигурации и решение для каждой

// Если без закрытия извне никак, вот безопасный враппер.
type SafeChan[T any] struct {
    mu     sync.RWMutex
    closed bool
    ch     chan T
}

func (s *SafeChan[T]) Send(v T) error {
    s.mu.RLock()                         // читатели-отправители не мешают друг другу
    defer s.mu.RUnlock()
    if s.closed {
        return ErrClosed
    }
    s.ch <- v                            // под RLock: Close не сможет вклиниться
    return nil
}

func (s *SafeChan[T]) Close() {
    s.mu.Lock()                          // ждёт, пока все Send завершатся
    defer s.mu.Unlock()
    if !s.closed {
        s.closed = true
        close(s.ch)
    }
}
// Цена: RLock на каждую отправку и риск задержки Close, если канал полон,
// а читателя нет. Поэтому это запасной вариант, а не основной подход.

Два механизма остановки и почему нужны оба

• Каскад закрытий работает только при нормальном исчерпании источника. Стадия дочитала вход, вышла из range, сработал defer close(out), следующая стадия увидела закрытие. Так конвейер сворачивается сам, без единой строчки управляющего кода.
• Общая отмена нужна для всего остального: потребитель ушёл по таймауту, сделал break, случилась ошибка. Без неё стадия, застрявшая на отправке в канал, который никто не читает, никогда не дойдёт до своего close, и каскад не запустится. Отсюда правило: отправка внутри стадии всегда через select с ctx.Done().

Куда девать ошибки

// Практичный вариант: ошибка едет по конвейеру вместе с данными.
type Item[T any] struct {
    Val T
    Err error
}

func stage[T, R any](ctx context.Context, in <-chan Item[T],
    f func(context.Context, T) (R, error)) <-chan Item[R] {

    out := make(chan Item[R])
    go func() {
        defer close(out)
        for it := range in {
            var res Item[R]
            if it.Err != nil {
                res = Item[R]{Err: it.Err}     // ошибку пропускаем дальше как есть
            } else {
                v, err := f(ctx, it.Val)
                res = Item[R]{Val: v, Err: err}
            }
            select {
            case out <- res:
            case <-ctx.Done():
                return
            }
        }
    }()
    return out
}
// Плюс: один канал, одна точка закрытия, ошибки не теряются и видно, на каком
// элементе сломалось. Минус: каждая стадия обязана проверять it.Err первой строкой.

Вариант без WaitGroup — на select с обнулением каналов

Просят как «а можете иначе?» или когда каналов ровно два. Идиома основана на том, что операция с nil-каналом блокируется навсегда, а значит, ветку select с nil-каналом никогда не выберут. Так ветку и «выключают».

func merge2[T any](ctx context.Context, a, b <-chan T) <-chan T {
    out := make(chan T)
    go func() {
        defer close(out)
        for a != nil || b != nil {           // пока жив хоть один источник
            select {
            case v, ok := <-a:
                if !ok {
                    a = nil                  // выключаем ветку навсегда
                    continue
                }
                select {
                case out <- v:
                case <-ctx.Done():
                    return
                }
            case v, ok := <-b:
                if !ok {
                    b = nil
                    continue
                }
                select {
                case out <- v:
                case <-ctx.Done():
                    return
                }
            case <-ctx.Done():
                return
            }
        }
    }()
    return out
}
// Почти все забывают обнулить закрытый канал.
// Закрытый канал всегда готов к приёму, select начнёт выбирать его
// в бесконечном цикле: busy-loop на 100% CPU вместо аккуратного слияния.

Способ 1: слайс по индексу (когда вход — слайс)

// Самый простой и самый недооценённый вариант: канал результатов не нужен вообще.
// Каждая горутина пишет в свою ячейку, гонки нет, синхронизация не нужна.
func mapParallel[T, R any](ctx context.Context, in []T, limit int,
    f func(context.Context, T) (R, error)) ([]R, error) {

    out := make([]R, len(in))
    g, ctx := errgroup.WithContext(ctx)
    g.SetLimit(limit)

    for i, v := range in {
        g.Go(func() error {
            r, err := f(ctx, v)
            if err != nil {
                return fmt.Errorf("элемент %d: %w", i, err)
            }
            out[i] = r                       // своя ячейка, без синхронизации
            return nil
        })
    }
    if err := g.Wait(); err != nil {         // Wait как барьер: после него слайс виден целиком
        return nil, err
    }
    return out, nil
}
// Почему запись в разные элементы слайса безопасна: это разные адреса памяти.
// Слайс не перевыделяется (длина фиксирована), заголовок никто не меняет.
// А g.Wait() создаёт happens-before между записями и последующим чтением.

Способ 2: переупорядочивание потока

// Когда на входе бесконечный поток и слайс не построить.
type Seq[T any] struct {
    Idx int
    Val T
}

func reorder[T any](ctx context.Context, in <-chan Seq[T]) <-chan T {
    out := make(chan T)
    go func() {
        defer close(out)
        buf  := make(map[int]T)
        next := 0
        for it := range in {
            buf[it.Idx] = it.Val
            for {                            // отдаём всё, что стало непрерывным
                v, ok := buf[next]
                if !ok {
                    break
                }
                select {
                case out <- v:
                case <-ctx.Done():
                    return
                }
                delete(buf, next)
                next++
            }
        }
    }()
    return out
}
// Цена честного порядка: один застрявший элемент держит в памяти всё,
// что обогнало его. Обязательно ограничивать размер buf и падать/тормозить
// при переполнении, иначе медленный элемент превращается в OOM.

Реализация целиком — четыре метода

type Semaphore chan struct{}

func NewSemaphore(n int) Semaphore { return make(Semaphore, n) }

func (s Semaphore) Acquire(ctx context.Context) error {
    select {
    case s <- struct{}{}:
        return nil
    case <-ctx.Done():
        return ctx.Err()
    }
}
func (s Semaphore) TryAcquire() bool {
    select {
    case s <- struct{}{}:
        return true
    default:
        return false
    }
}
func (s Semaphore) Release() { <-s }
func (s Semaphore) InUse() int { return len(s) }   // готовая метрика насыщения

На что обратить внимание в ответе

• Отправка и есть захват. Слоты складываются в буфер; полный буфер значит «все заняты». Направление контринтуитивно, поэтому его проговаривают явно.
• defer Release() сразу после успешного Acquire, и никогда до проверки ошибки: Release без Acquire читает из пустого канала и блокируется навсегда.
• Ожидающие стоят в FIFO-очереди канала, голодания нет by design.
• len(s) даёт бесплатную метрику: экспортируйте её, и насыщение лимита будет видно на графике раньше, чем начнутся таймауты.
• Стоимость ожидания выше, чем у пула. В пуле ждёт задача (несколько байт в буфере), в семафоре целая горутина со стеком и всем контекстом запроса. Поэтому у семафора почти всегда нужен либо таймаут, либо TryAcquire с честным отказом.

Сравнение

// Лимитер на клиента: то, что нужно в 90% случаев.
type PerKey struct {
    mu   sync.Mutex
    lim  map[string]*entry
    r    rate.Limit
    b    int
}
type entry struct {
    l    *rate.Limiter
    seen time.Time
}

func (p *PerKey) Allow(key string) bool {
    p.mu.Lock()
    e, ok := p.lim[key]
    if !ok {
        e = &entry{l: rate.NewLimiter(p.r, p.b)}
        p.lim[key] = e
    }
    e.seen = time.Now()
    p.mu.Unlock()
    return e.l.Allow()
}

// Без вытеснения карта растёт вечно: это утечка памяти, а не «мелочь».
func (p *PerKey) gc(ctx context.Context, ttl time.Duration) {
    t := time.NewTicker(ttl)
    defer t.Stop()
    for {
        select {
        case <-t.C:
            p.mu.Lock()
            for k, e := range p.lim {
                if time.Since(e.seen) > ttl {
                    delete(p.lim, k)
                }
            }
            p.mu.Unlock()
        case <-ctx.Done():
            return
        }
    }
}

Зачем нужен or-done — главный смысл

Когда вы читаете канал, который вернула чужая библиотека, у вас нет гарантии, что его когда-нибудь закроют. Обычный for v := range foreign в этом случае даёт потенциально вечную горутину. Писать вместо него select с ctx.Done() в каждом месте использования утомительно, да и забывается легко. orDone прячет эту защиту внутрь один раз:

// Было: в каждом потребителе шум, который легко забыть.
loop:
for {
    select {
    case v, ok := <-foreign:
        if !ok {
            break loop
        }
        use(v)
    case <-ctx.Done():
        break loop
    }
}

// Стало: защита один раз, потребители тривиальны.
for v := range orDone(ctx, foreign) {
    use(v)
}

Ключевая идиома внутри tee

Обнуление локальной копии канала внутри select: после отправки в o1 присваиваем o1 = nil, и эта ветка перестаёт выбираться, потому что операция с nil-каналом блокируется навсегда. Так элемент уходит сначала тому получателю, кто освободился первым. Ту же идиому применяют в merge2, при переключении между источниками и при временной приостановке чтения.

Что внутри — по сути весь пакет

type Group struct {
    cancel  func(error)
    wg      sync.WaitGroup
    sem     chan token      // появляется после SetLimit
    errOnce sync.Once       // «первая ошибка» фиксируется ровно один раз
    err     error
}

func (g *Group) Go(f func() error) {
    if g.sem != nil {
        g.sem <- token{}    // SetLimit сводится к семафору на канале
    }
    g.wg.Add(1)
    go func() {
        defer g.done()
        if err := f(); err != nil {
            g.errOnce.Do(func() {
                g.err = err
                if g.cancel != nil {
                    g.cancel(g.err)   // отменяем производный ctx, остальные сворачиваются
                }
            })
        }
    }()
}

Сравнение трёх инструментов

g, _ := errgroup.WithContext(ctx)   // ПОТЕРЯЛИ производный ctx
g.Go(func() error { return fetch(ctx, a) })   // получает ИСХОДНЫЙ ctx
// Ошибка вернётся, но остальные горутины доработают до конца:
// отменять-то нечего, производный контекст выброшен.

g, ctx := errgroup.WithContext(ctx)  // ПРАВИЛЬНО: затеняем ctx
g.Go(func() error { return fetch(ctx, a) })

Восемь вещей, которые проверяют этим вопросом

1. NewTicker, а не time.Tick: у последнего нет Stop(), и тикер живёт до конца процесса.
2. defer t.Stop() сразу после создания.
3. Ветка ctx.Done(): без неё горутина вечная.
4. Первый прогон до цикла, если работа нужна сразу: Ticker выдаёт первый тик только через период.
5. Свой дедлайн на итерацию. Зависшая итерация останавливает расписание навсегда и в дампе выглядит как одна невинная горутина.
6. recover внутри итерации. Паника в фоновой задаче не должна ронять сервис.
7. Ошибка итерации логируется, но не выходит из цикла. Одна сетевая ошибка не должна убивать расписание до рестарта.
8. Джиттер. Десять реплик с периодом в минуту создают синхронный всплеск; случайная задержка старта размазывает нагрузку.

Когда Ticker не подходит

// Ticker меряет период между тиками. Если нужен фиксированный интервал
// между окончанием и началом (работа длится непредсказуемо долго), берут Timer.
func runFixedGap(ctx context.Context, gap time.Duration, f func(context.Context)) {
    for {
        f(ctx)
        select {
        case <-time.After(gap):     // с Go 1.23 таймер соберётся GC, утечки нет
        case <-ctx.Done():
            return
        }
    }
}

// Ticker отбрасывает пропущенные тики, а не копит их.
// Это защита от лавины: если итерация длилась 10 периодов, то после неё
// придёт один тик, а не 10 подряд. Но и фактическая частота упадёт:
// иногда это ровно то, что нужно, иногда это скрытая деградация.

Почему порядок именно такой

Правило одно: компонент можно останавливать только после того, как остановлены все, кто им пользуется. HTTP-сервер пользуется воркерами и БД, воркеры пользуются БД, значит порядок жёстко задан: сервер → воркеры → БД. Закроете БД первой, получите шквал ошибок в последних, самых важных запросах, тех самых, которые как раз пытались доработать.

Три вещи, которые различают уровни кандидата

• Пауза на readiness. В Kubernetes SIGTERM и удаление эндпоинта происходят параллельно: часть трафика ещё летит на под. Без паузы в 5–15 секунд каждый деплой даёт всплеск 502. Про это помнят те, кто реально катал сервисы.
• shutCtx от context.Background(), а не от корневого. Корневой уже отменён сигналом; если взять его, все шаги остановки завершатся мгновенно с ошибкой.
• Бюджет меньше grace period оркестратора. 25 секунд при terminationGracePeriodSeconds: 30, иначе SIGKILL оборвёт всё на середине, и аккуратный код не поможет.

Три стратегии и когда какая

// Drop-oldest: в очереди всегда самое свежее.
func (q *Queue) PushLatest(v Item) {
    for {
        select {
        case q.ch <- v:
            return
        default:
            select {
            case <-q.ch:            // выбросили самый старый
                q.dropped.Add(1)    // метрика обязательна: без неё потери невидимы
            default:                // кто-то успел забрать, пробуем снова
            }
        }
    }
}

Как выбирать размер буфера

• 0 (небуферизованный): жёсткая синхронизация, продюсер идёт в темпе консьюмера. Самая честная и самая наблюдаемая схема.
• Маленький (1..2×N воркеров) сглаживает микровсплески и джиттер планировщика, не искажая картину. Разумный дефолт.
• Большой (тысячи) почти всегда ошибка: он маскирует нехватку мощности, добавляет минуты к латентности хвоста и превращает падение процесса в потерю всей очереди. Очередь должна переживать рестарт, значит это уже не канал, а брокер или БД.