Канал в Go: значение мимо буфера, select без приоритетов и цена, которую платят парковкой

Что здесь на самом деле спрашивают

Лестница почти всегда такая:

1. «Что такое канал?» — проверяют, скажете ли вы «указатель на структуру с мьютексом» или ограничитесь словом «труба».
2. «Чем отличается буферизованный от небуферизованного?» — проверяют, понимаете ли вы, что дело в парковке, а не в скорости.
3. «Что будет, если писать в закрытый канал? А читать? А из nil?» — та самая таблица из двенадцати клеток.
4. «Как select выбирает ветку?» — вопрос-ловушка: не сверху вниз.
5. «Где здесь утечка?» (с кодом) — проверяют, знаете ли вы, что горутина на заблокированном канале живёт вечно.

Дальше урок идёт по этой лестнице.

База: одна горутина отправила, другая получила

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

Есть две горутины. Одна доходит до строки ch <- v и отправляет значение. Другая доходит до <-ch и получает его. Значение переходит от первой ко второй, и обе идут дальше своими делами.

ch := make(chan int)
 
go func() { ch <- 42 }()   // одна отправила
v := <-ch                  // другая получила

Канал здесь — не переменная, которую читают и пишут, а место встречи: пока никто не пришёл с другой стороны, значение через него не проходит.

И вот главный вопрос урока: что происходит, когда отправка и приём не совпали во времени? Горутины идут своим ходом, и до своих строк они доходят когда придётся: отправитель может оказаться у ch <- v за секунду до того, как получатель дойдёт до <-ch, — или на минуту позже.

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

На этом «ждёт» и держится всё остальное в теме. Буфер — способ отложить ожидание отправителя. select — способ ждать сразу нескольких каналов. Закрытие — способ сказать всем ждущим, что ждать больше нечего.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования «что такое канал». Дальше — про то, как канал ведёт себя в остальных своих состояниях (буфер полон, канал закрыт, канала нет вовсе), почему у select нет порядка, чего стоит ожидание и где на нём утекают горутины.

Механизм 1: таблица поведения — вся тема на одном экране

Канал стоит разбирать не с устройства, а с того, что он делает в каждом из своих состояний. Это буквально вопрос собеседования, и списком он не запоминается — зато запоминается таблицей, потому что клетки в ней связаны.

Вот та же пара действий из «Базы», разложенная по состояниям канала:

Читается она по строкам, и каждая строка — отдельный вопрос собеседования. Третья операция, close, добавляет к этому ещё одно измерение; полная таблица из двенадцати клеток разобрана на картинке. Нажимайте клетки — разбор под таблицей объясняет, почему именно так:

Из двенадцати клеток стоит выучить не двенадцать фактов, а два правила:

1. Паникуют только запись и закрытие, и только там, где канала нет или он уже закрыт. Три паники: send on closed, close of closed, close of nil.
2. Чтение не паникует никогда. Ровно поэтому закрытие годится как широковещательный сигнал: все ждущие читатели просыпаются разом.

И одна клетка, которую забывают чаще всех: закрытие не выбрасывает то, что уже лежит в буфере. Спецификация говорит это дословно — приём из закрытого канала выдаёт нулевое значение after any previously sent values have been received (после того, как получены все ранее отправленные значения). Сначала дочитываются положенные значения с ok == true, и только потом начинается нулевое с false. На этом построена задача в конце урока.

nil-канал — не ошибка, а инструмент. Раз ветка select с nil-каналом никогда не выбирается, обнуление канала — штатный способ выключить ветку:

for {
    select {
    case v, ok := <-in:
        if !ok {
            in = nil        // ветка выключена, select живёт дальше
            continue
        }
        // …
    case <-ctx.Done():
        return
    }
}

Без этого приёма закрытый канал крутил бы select вхолостую: чтение из него готово всегда.

Механизм 2: небуферизованный канал — это рандеву

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

Отсюда практическое, ради чего небуферизованный канал и берут: он даёт не передачу данных, а согласование момента. Отправитель, вернувшийся из ch <- v, знает, что получатель уже здесь.

И отсюда же то, что удивляет при разборе устройства.

Канал почти всегда рисуют трубой: отправитель кладёт в буфер, получатель забирает из буфера. В самом частом случае это неверно.

Если получатель уже ждёт, значение идёт мимо буфера — копируется прямо из стека отправителя в стек получателя. Буфер не участвует вовсе.

Это не абстракция про реализацию: она наблюдаема из программы. Если бы значение легло в буфер, len(ch) стал бы единицей. Он остаётся нулём.

Механизм 3: буферизованный канал — ограниченная очередь

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

Отсюда правильный ответ на вопрос «зачем тогда буфер». Буфер нужен не для скорости передачи, а чтобы отправителю не приходилось ждать получателя. Он не убирает блокировку — он её отсрочивает ровно на свою вместимость.

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

Механизм 4: select не смотрит ветки сверху вниз

Самая частая правка на код-ревью: «поставь case <-ctx.Done() первым, чтобы отмена срабатывала раньше». Она не делает ничего.

Спецификация: если готовы несколько операций, a single one that can proceed is chosen via a uniform pseudo-random selection (одна из готовых выбирается равномерным псевдослучайным образом). Порядок веток в исходнике не значит ничего.

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

select {
case <-ctx.Done():
    return ctx.Err()
default:
}

Ещё две вещи про select, которые спрашивают следом:

• default превращает select в неблокирующий. Без него select без готовых веток ждёт; с ним — уходит сразу.
• select {} без веток блокируется навсегда. Это не ошибка компиляции, а идиома «занять текущую горутину навсегда».

Механизм 5: где утекают горутины

Классический вопрос «найдите утечку», и код обычно такой:

func find(ctx context.Context) int {
    ch := make(chan int)          // без буфера
    go func() { ch <- search() }()
    select {
    case v := <-ch:
        return v
    case <-ctx.Done():
        return -1                 // ушли, а горутина осталась
    }
}

По таймауту функция возвращается — а горутина внутри навсегда застревает на ch <- search(): получателя больше нет, буфера нет.

И такая горутина не собирается сборщиком мусора. Это ключевой факт: она жива, её стек жив, и всё, на что она ссылается, тоже. Сборщик мусора не умеет собирать заблокированные горутины — он не может знать, что разбудить их некому.

Лечится это буфером на одно значение: отправитель положит результат и уйдёт, даже если читать уже некому.

ch := make(chan int, 1)

И отдельно про то, чем такое ловится. go test -race эту утечку не находит — гонки здесь нет, всё корректно синхронизировано. Ловится она счётом: runtime.NumGoroutine() до и после, либо профиль goroutine из runtime/pprof, либо goleak в тестах. Ответ «поймаем детектором гонок» — неверный, и это ровно та разница, которую вопрос проверяет.

Механизм 6: что канал гарантирует про память

Про эту сторону забывают, а спрашивают её на позициях повыше. Канал — не только транспорт, но и точка синхронизации.

• Отправка синхронизирована до завершения приёма: всё, что отправитель записал в память до ch <- v, получатель после <-ch увидит.
• Закрытие синхронизировано до приёма, вернувшего нулевое значение. Поэтому close(done) — законный способ опубликовать данные, записанные до закрытия.
• У небуферизованного канала есть и обратная гарантия: приём синхронизирован до завершения отправки. Отсюда его вторая роль — рандеву: отправитель знает, что получатель дошёл до места.

Практический вывод: close(done) как сигнал готовности не требует ни мьютекса, ни атомиков вокруг данных, которые он публикует.

Глубже: что под этим в рантайме

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

chan T — это указатель на структуру рантайма. Внутри неё: кольцевой буфер (если он заказан), мьютекс и две очереди ожидающих горутин — те, кто ждёт отправки, и те, кто ждёт приёма.

Из этого следует сразу несколько ответов:

• Канал, переданный в функцию, — тот же канал. Копируется указатель, а структура за ним одна. Никаких *chan T не нужно.
• Канал внутри защищён мьютексом. «Канал — это lock-free» неверно: каждая операция берёт мьютекс структуры. Быстро он не поэтому.
• nil-канал — это указатель в никуда. Ни буфера, ни очередей: положить значение некуда, разбудить некого. Отсюда всё его поведение.

Стоит сказать вслух и то, чем канал не является. Канал — не очередь сообщений и не средство ускорить передачу данных: две горутины через канал всегда медленнее, чем одна без него. Канал покупает синхронизацию, и модель памяти формулирует это прямо: A send on a channel is synchronized before the completion of the corresponding receive from that channel (Отправка в канал синхронизирована до завершения соответствующего приёма из этого канала). То есть всё, что отправитель записал до отправки, получатель после приёма гарантированно увидит.

Цена — это парковка, а не «канал»

И прежде чем смотреть на числа — одно различение, без которого «горутина заблокировалась» звучит страшнее, чем есть.

Заблокированная горутина не означает заблокированный поток ОС. Парковка — операция планировщика внутри процесса: горутина снимается с P, на её место встаёт другая, поток продолжает работать. Ядро об этом не знает и не участвует. Именно поэтому «тысяча горутин ждёт на каналах» — нормальное состояние программы, а не тысяча простаивающих потоков.

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

Измерено на передаче тысячи значений между двумя горутинами:

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

И граница у этого числа названа тут же: «3,1» получены на одной машине, двух ядрах и одной версии Go. Кратность зависит от того, сколько горутин выполняется одновременно и попали ли отправитель с получателем на одно ядро, — то есть переносить отсюда нужно причину, а не число. Правило пишется так: цена канала растёт вместе с числом парковок, и мерить её нужно на своей нагрузке.

Как отвечать на собеседовании

Короткий ответ: канал — это связь двух горутин, в которой отправка и приём встречаются: пока получателя нет, отправитель ждёт, и наоборот. Буфер это ожидание не убирает, а отсрочивает ровно на свою вместимость. Из закрытого канала читать можно — сначала дочитываются положенные значения; писать в него и закрывать его повторно нельзя. А ветки select выбираются равномерно случайно, а не сверху вниз.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «что такое канал» отвечайте структурой. «Указатель на структуру с буфером, мьютексом и двумя очередями ожидающих». Дальше почти всё выводится отсюда, включая поведение nil-канала.

Про буфер говорите «отсрочка», а не «ускорение». «Буфер не убирает блокировку, а отсрочивает её на свою вместимость; цена небуферизованного — это парковки, у меня выходило втрое на тысяче значений». Второе предложение превращает заученное в проверенное.

Таблицу давайте двумя правилами. «Паникуют только запись и закрытие; чтение не паникует никогда, поэтому закрытие и работает как сигнал». Двенадцать клеток по памяти перечисляют немногие, а два правила восстанавливают их все.

Про select скажите «равномерно случайно». И добавьте, что порядок веток ничего не значит, а приоритет отмены делается отдельным select с default. Это распознаётся как опыт мгновенно.

Про утечку назовите и причину, и инструмент. «Заблокированная горутина не собирается; -race её не найдёт, ловится счётом горутин или профилем goroutine». Половина кандидатов отвечает «поймает race detector».

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

ch := make(chan int, 2)
ch <- 1
ch <- 2
close(ch)
a, ok1 := <-ch
b, ok2 := <-ch
c, ok3 := <-ch
fmt.Println(a, ok1)
fmt.Println(b, ok2)
fmt.Println(c, ok3)
fmt.Println(len(ch), cap(ch))

1 true
2 true
0 false
0 2

0 false
0 false
0 false
0 2

1 true
2 true
0 false
0 0

1 false
2 false
0 false
2 2

Проверка знаний