Каналы — главный примитив коммуникации в Go, и каждая грань у него острая

Go строит конкурентность вокруг одного лозунга — «не делите память, общайтесь через каналы». Channel — это не просто очередь: это типизированная труба, которая синхронизирует горутины и устанавливает между ними отношение happens-before. Передали значение через channel — и компилятор с рантаймом гарантируют, что получатель видит всё, что отправитель записал до отправки. Именно поэтому каналы заменяют мьютексы в идиоматичном Go-коде.

Но за удобством прячется набор острых граней, и каждая из них — стандартный вопрос на собеседовании. Отправка в закрытый channel не «молча отбрасывается» — она роняет программу панкой. Операция на nil channel не паникует — она блокируется навсегда. Закрытие из получателя или из нескольких отправителей паникует на двойном закрытии. select без default блокируется, пустой select{} блокируется вечно, а горутина, навсегда заблокированная на channel, который никто не удовлетворит, — это утечка, которую сборщик мусора не уберёт. Эта тема разбирает channel по слоям — от устройства рантайм-структуры hchan до дерева узлов context.

Карта темы

• Механика каналов — что такое channel под капотом — структура hchan, рандеву небуферизированного канала, отношение happens-before.
• Буферизированные каналы — make(chan T, n), кольцевой буфер, когда именно блокируется отправка и приём.
• nil-каналы — почему отправка и приём на nil channel виснут навсегда и как этим пользуются в select.
• Поведение закрытого канала — comma-ok, range по каналу, паника при отправке и при повторном закрытии.
• Оператор select — равновероятный выбор готовой ветки, default как неблокирующий путь, пустой select{}.
• Утечки горутин — как заблокированная навсегда горутина тихо копится и почему GC её не уберёт.
• Отмена через context — как context.Context переносит сигнал отмены и распространяет его по дереву.
• Устройство context — cancelCtx, timerCtx, valueCtx, ленивый Done, цепочка значений.

Частые ошибки и ловушки

Значение для собеседований

Каналы — обязательная тема на любом Go-интервью, и спрашивают не синтаксис <-, а модель блокировки под ним. Интервьюер проверяет, есть ли у вас рабочая ментальная модель того, когда операция блокируется, когда паникует и когда виснет навсегда.

Что обычно проверяют:

• Чем буферизированный channel отличается от небуферизированного — где синхронное рандеву, а где кольцевой буфер.
• Когда именно блокируется отправка и приём — на пустом и на полном буфере.
• Что происходит при операции на nil channel — блокировка навсегда, и как это используют в select.
• Что делает отправка в закрытый channel — паника; что возвращает приём — нулевое значение и ok=false.
• Семантику select — равновероятный выбор, роль default, поведение пустого select{}.
• Как channel приводит к утечке горутины и чем её предотвращают — select по ctx.Done() или буферизированный channel результата.
• Как context.Context распространяет отмену и как он устроен внутри — дерево cancelCtx/timerCtx/valueCtx.

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