select в Go

Случайный выбор - это гарантия, а не деталь

Когда готова одна ветка, select выполняет её. Когда готовы несколько - выбирает псевдослучайно, и это документированное поведение, а не побочный эффект реализации.

Проверим на тысяче итераций с двумя всегда готовыми каналами: получилось 496 срабатываний первой ветки и 504 второй. Практически ровно пополам, и порядок написания веток на это никак не влияет.

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

// Отсюда следствие для кода: нельзя закладывать приоритет через порядок case. Нужен приоритет - делают вложенный select: сначала неблокирующая проверка важного канала с default, и только потом общее ожидание.

default: ожидание превращается в проверку

Ветка default выполняется, когда ни один канал не готов прямо сейчас. Это меняет саму природу конструкции: select с default никогда не блокируется, он делает мгновенный опрос и идёт дальше. Проверено на пустом канале: default срабатывает немедленно.

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

Опасность у default ровно одна, зато серьёзная: select с default внутри цикла без паузы превращается в активное ожидание. Ядро загружено на сто процентов, работа не делается, метрики выглядят как «сервис под нагрузкой».

// Если тебе нужно именно ждать, default не нужен вовсе. Пустой select{} без веток блокируется навсегда - иногда это осознанно пишут в конце main, чтобы процесс не завершился, пока работают фоновые горутины.

select {
case v := <-ch:
    handle(v)
default:
    // ничего не готово прямо сейчас - идём дальше, не блокируясь
}

select {
case queue <- job:
default:
    metrics.Dropped.Inc()   // очередь полна, событие выбрасываем осознанно
}

Таймауты и отмена

Таймаут делается веткой с time.After: канал, в который значение придёт через заданное время. Проверено - срабатывает ровно по сроку. Одноразовый запрос с ограничением по времени пишется в четыре строки.

У time.After есть нюанс, о котором спрашивают: таймер живёт до срабатывания и держит память. В цикле на миллион итераций это миллион таймеров, поэтому там берут time.NewTimer с явным Stop либо контекст.

Отмена сверху приходит через контекст: ветка case <-ctx.Done() разблокируется, когда вызвали cancel или истёк дедлайн. Без этой ветки горутина остаётся висеть навсегда - про такие утечки отдельная подтема.

// Хороший обработчик обычно имеет три ветки: полезная работа, отмена по контексту и, если нужно, собственный таймаут. Ветка с ctx.Done() в долгоживущих горутинах - не необязательное украшение, а условие того, что сервис умеет останавливаться.

time.After

канал, в который придёт значение через заданное время; таймер живёт до срабатывания

nil-канал: выключатель ветки

Операции с nil-каналом блокируются навсегда - и приём, и отправка. Звучит как чистая ошибка, но внутри select это превращается в полезный инструмент: ветка с nil-каналом просто никогда не сработает, то есть выключена.

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

Вне select nil-канал - беда. Одинокий приём из него в единственной горутине даёт fatal error: all goroutines are asleep - deadlock, и рантайм честно пишет состояние горутины: chan receive (nil chan).

// Заметь разницу: тут рантайм смог заметить проблему, потому что спали вообще все горутины. Если хотя бы одна работает - например, обслуживает HTTP, - никакого сообщения не будет, и заблокированная горутина просто тихо останется висеть навсегда.

for a != nil || b != nil {
    select {
    case v, ok := <-a:
        if !ok { a = nil; continue }   // выключили ветку
        use(v)
    case v, ok := <-b:
        if !ok { b = nil; continue }
        use(v)
    }
}

Как отвечать: «Что выполнится, если в select готовы сразу две ветки?»

Одна из них, выбранная псевдослучайно. Это документированная гарантия, а не деталь реализации: я проверял на тысяче итераций с двумя всегда готовыми каналами, вышло примерно поровну, 496 против 504. Сделано так, чтобы не было голодания: если бы select всегда брал верхнюю ветку, плотный поток в первом канале навсегда заслонил бы редкие события во втором. Из этого следует, что приоритет через порядок case задать нельзя. Если приоритет реально нужен, делают вложенный select: сначала неблокирующая проверка важного канала с веткой default, и только если там пусто - общее ожидание. Ещё пара смежных вещей, которые обычно спрашивают следом: default выполняется, когда не готов никто, и превращает select в мгновенный опрос - удобно для неблокирующей отправки, но в цикле без паузы это активное ожидание и сожжённое ядро. А ветка с nil-каналом не срабатывает никогда, и этим пользуются, чтобы выключать источники по мере их закрытия.

Названа гарантия с проверенными числами, объяснена причина через голодание, дан рабочий способ сделать приоритет и добавлены два смежных механизма.

На чём валят

• −Закладывают приоритет через порядок веток - выбор случайный.
• −Ставят default в цикл без паузы и получают активное ожидание на сто процентов ядра.
• −Не обнуляют закрытый канал в конвейере: закрытая ветка готова всегда и крутит цикл вхолостую.
• −Плодят time.After в горячем цикле и копят таймеры вместо time.NewTimer со Stop.
• −Забывают ветку ctx.Done() в долгоживущей горутине, и сервис не умеет останавливаться.
• −Считают, что рантайм заметит любую вечную блокировку: он видит только случай, когда спят все горутины.