Select и таймауты

В прошлом уроке канал умел ждать ровно одну трубу: приём <-ch блокировал горутину, пока по ней не приедет значение. Жизнь быстро ломает такую простоту: сервер одновременно читает запросы из сети и сигналы остановки, воркер — задачи из очереди и команду «хватит», телеметрия смешивает логи, метрики и ошибки из трёх разных труб. Писать по приёму на каждый канал — значит расставить горутину в очередь ожиданий, где, пока вы стоите во второй строке, первая молчит зря.

select в Go — это диспетчер, который висит сразу на нескольких каналах и просыпается на первом готовом. По запросу select go вы найдёте ровно этот механизм: одна конструкция, несколько канальных веток, выполняется та, чья операция сейчас возможна. Это то самое мультиплексирование, о котором мы обещали в конце урока про каналы, — и оно же превратит ни в чём не повинную утечку горутины из урока про горутины в решаемую задачу.

Синтаксически select — близнец switch, а по роли в арсенале — центральная техника продвинутого раздела курса: ветки выбираются не по значению выражения, а по готовности операций с каналами. Дальше — все правила этого выбора: от случайного жребия до таймаутов.

Выглядит select так: ключевое слово, фигурные скобки, внутри — ветки case, а каждая ветка — операция с каналом. Приём: case v := <-ch1:. Отправка: case ch2 <- x:. Ничего канального в ветке стоять не может — ни сравнение, ни вызов функции; компилятор отвергнет программу сразу. Есть и особая ветка default, которая срабатывает, когда не готов ни один канал, — о ней отдельный раздел ниже.

Три правила поведения. Первое: select вычисляет все свои канальные операции ровно один раз при входе и блокируется, если ни одна не готова. Второе: как только хотя бы одна операция становится возможной, select выполняет её ветку и выходит — в отличие от switch, прохода по всем веткам не бывает, и fallthrough здесь запрещён. Третье: приёмы case v := <-ch и двухзначный case v, ok := <-ch живут здесь так же, как в обычном коде, — флаг ok по-прежнему различает настоящий ноль от «канала больше нет».

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

Логика выбора трёхступенчатая. Если готова ровно одна ветка — выполняется она, и это самый частый и самый детерминированный случай. Если не готова ни одна — select блокируется и ждёт, пока что-нибудь созреет; в этом он ничем не отличается от одиночного приёма <-ch, только ждёт сразу несколько вещей. А вот третья ступень — фирменная: если готовых веток несколько, select бросает жребий и выполняет равновероятно одну из них.

Зачем придумана случайность? Чтобы ни один канал не мог раз и навсегда зажать себе все внимание. Представьте ситчаут, где два канала стабильно готовы: при выборе «первого по порядку» второй ветке доставались бы крохи, а жребий держит шансы честными — 50 на 50 при двух готовых, одна третья при трёх. Это встроенная защита от голодания, и она достаётся вам бесплатно.

Из жребия следует практический вывод: программу, где две ветки готовятся одновременно, нельзя писать «под конкретный порядок» — вывод может отличаться от запуска к запуску. Все демо этого урока поэтому построены так, чтобы готовой была ровно одна ветка: рандеву с одной стороны, задержки с запасом в десять раз — с другой. Детерминизм в конкурентном коде делается дизайном, а не молитвой о планировщике.

select умеет и обратное — не ждать ни секунды. Если среди веток есть default, блокировка отменяется: select мгновенно проверяет каналы, выполняет готовую ветку, а когда готовых нет — выполняет default. Так из блокирующих операций получаются неблокирующие: попробовать прочитать и уйти, попробовать записать и не застрять.

Классические сценарии три. Try-receive: заглянуть в канал «а нет ли уже работы» и, если пусто, заняться чем-то полезным. Try-send: положить значение, если есть место, а если буфер полон — не стоять в очереди, а, скажем, посчитать отказ. Try-both: проверить сразу несколько направлений и сделать что-нибудь по умолчанию, когда всё молчит. Ветка default — это и есть место для «а что, если никого нет».

Но у неблокирующего режима есть тёмная сторона, о которой стоит сказать жёстко: select с default внутри `for` — сжигатель процессора. Цикл «проверь канал — нет — проверь — нет — проверь» крутится тысячи раз в секунду и греет ядро впустую; это называется занятым ожиданием. Если вам нужен периодический опрос, вставляйте в цикл паузу или таймер — о способе через time.After скажем ниже, — а лучше вовсе уберите default и дайте select честно поспать.

Поодиночке select выполняется один раз — а сила приходит в связке с циклом. Скелет for { select { ... } } — это стандартный воркер Go: бесконечный цикл, который в каждом обороте ждет два события — «прилетела задача» и «прилетела команда остановиться». Задачи едут по рабочему каналу, команда — по каналу done; каждая ветка case обрабатывает своё.

Канал done — это почтовый ящик для стоп-сигнала. В уроке про горутины горутины запускались и умирали сами по себе; здесь у вас появляется рычаг: main отправляет в done — воркер просыпается в ветке case <-done:, делает уборку и выходит через return. Обратите внимание на нюанс, который стоит прочувствовать: после выхода воркера main не знает, что тот закончил, — в демо ниже мы завели третий канал finished, через который воркер отчитывается, а main терпеливо принимает отчёт. Без такого рандеву main мог бы закончить работу раньше воркера и оборвать его финальную строку.

А как остановить сразу пятерых воркеров? Слать каждому по сигналу — развлечение на минуту. Каноничнее закрыть канал done: ветка приёма из закрытого канала готова всегда, поэтому close(done) срабатывает как широковещательный стоп для любого числа слушателей. Это уже мостик к разделу о закрытых каналах в select — и он подкреплён таблицей ниже. Ожидание целой бригады воркеров аккуратнее делать через WaitGroup — это тема ближайшего урока про синхронизацию, там же соберём полноценный пул workers.

Если вы искали по запросу «таймауты golang», то почти каждый найденный рецепт — одна и та же строка внутри select: case <-time.After(d):. Функция time.After из пакета time возвращает канал <-chan time.Time и обещает: через длительность d в этот канал приедет одно значение, «будильник прозвенит». В ветке select этот канал работает как соперник: либо основная операция успеет, либо прозвенит таймер — и вы уйдёте по ветке таймаута.

Важное отличие от time.Sleep: sleep блокирует горутину целиком — время ползёт, ничего не происходит. А таймер time.After строится и начинает идти параллельно с остальными ветками select: вы всё ещё ждёте данные, просто теперь у ожидания есть предел. Это и есть канонический таймаут на операцию с каналом — две-три строки вместо целого сторожевого механизма.

У медали есть оборот. Кто не победил в select — тот продолжил жить: неуспешный поставщик так и стоит в своей отправке, а таймер доживает до звонка и мусорится только потом. Один зависший поставщик — мелочь; сотня забытых — утечка горутин, которая съест память. Честное решение этой проблемы — контекст отмены: в курсе ему посвящён отдельный урок про context, а пока запомните правило — select с таймаутом спасает ждущего, но не отправляющего. И ещё: таймер нельзя перезапустить — для переиспользуемых будильников есть time.NewTimer с методом Stop, но в этом уроке нам хватит и одноразового.

В прошлом уроке мы выучили: читать закрытый канал можно — сначала вычитывается остаток буфера, потом приём мгновенно возвращает нулевое значение и ok = false. Перенесите это знание в select, и получится жёсткое правило: ветка чтения из закрытого канала готова всегда. Для select «готово» означает «операция может выполниться не блокируясь» — а приём из закрытого канала выполняется мгновенно по определению.

Отсюда две противоположные практики. Злодейская: select в бесконечном for, где одна из веток читает канал, который кто-то закрыл, — ветка становится вечно готовой, цикл превращается в карусель нулевых значений, крутящуюся до лимита времени, а default при этом никогда не дождётся своей очереди. Диагностика простая: программа жрёт процессор и печатает нули — ищите близкий close.

Добрая практика из того же правила — широковещательная остановка. Пять воркеров слушают один канал done в ветках case <-done:; main делает close(done) — и все пять веток становятся готовыми одновременно, все воркеры выходят в одном мгновении, без пяти отдельных сигналов и без подсчёта «кому уже отправил, кому нет». Канал закрывает та сторона, которая им владеет, — правило из прошлого урока здесь работает без исключений.

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

Паттерн: приёмник владеет переменной канала и в любой момент присваивает ей nil — secondary = nil — и ветка case v := <-secondary: мгновенно замолкает, хотя сам select не переписан ни на строку. Присвоили другой канал — ветка ожила и слушает уже нового поставщика. Так мультиплексор собирают по частям: источник потерял доверие — выключили его ветку, вместо него подключили другой канал, а когда придёт quit — ушли совсем. Ничего похожего switch вам не предложит: там ветки задаются при компиляции, здесь — в рантайме значением переменной.

Один предостерегающий аккорд. Выключатель работает, пока жива хоть одна другая ветка: select, у которого все канальные ветки nil-каналы и нет default, блокируется навсегда — в настоящем Go это fatal error deadlock, в песочнице сработает лимит времени. И не забудьте про origin: нулевое значение канала — nil, забытый make выключает канал целиком, как говорилось в прошлый раз.