Каналы: обмен данными

В прошлом уроке горутины научились работать параллельно, но обмениваться словами могли только через общий срез и общий счётчик — а это прямая дорога к гонкам данных. Каналы go решают проблему обмена честно: это типизированная труба, у которой есть один отправитель и один получатель, и значение проходит по ней строго по одному — как монетка в щели копилки. Никакая горутина не трогает чужую память: она просто кладёт значение в канал или достаёт из него. В англоязычных источниках это слово пишется латиницей — channel, и по запросу channels golang вы найдёте те же самые механизмы, что разберём ниже.

Канал типизирован: chan int возит только int, chan string — только строки. Смешать типы не выйдет, компилятор поймает на месте. И канал — это первое значение в курсе, которое можно не только создавать и читать, но и «закрывать», поэтому у него богатая жизнь: рождение через make, работа через отправку и приём, смерть через close.

По курсу продвинутых возможностей это центральный урок про конкурентность: WaitGroup говорил «дождись», канал говорит «передай». Дальше на select, мьютексах и пуле workers мы достроим остальное — но без каналов никуда.

Создаётся канал встроенной функцией make: ch := make(chan int) — и это единственный способ, нулевое значение var ch chan int даёт nil-канал, который пока только мешает (о нём ближе к концу урока). Над готовым каналом есть ровно четыре операции, и все записываются стрелкой <-, которая похожа на направление движения значения:

- ch <- v — отправка: значение v уезжает в канал; - v := <-ch — приём: значение приезжает из канала в переменную; - <-ch — приём и выбросить: если значение не нужно, а нужен только факт приёма; - close(ch) — закрыть: объявить, что новых значений не будет.

Стрелку удобно читать вслух «значение течёт в ту сторону»: в ch <- v оно течёт из v в ch, в v := <-ch — из ch в v. Синтаксис компактный, но под каждой из четырёх операций прячутся правила блокировки, и именно они делают каналы инструментом синхронизации, а не просто очередью. Начнём с самого строгого режима — незабуферизованного канала.

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

Из этого следует неожиданное на первый взгляд свойство: порядок печати в программе с каналами определяет принимающий, а не отправляющий. В прошлом уроке мы добивались детерминированного вывода через WaitGroup и обсуждали, что планировщик ничего не обещает; здесь гарантия получается бесплатно. Горутина, чья строка стоит после отправки, не напечатает ничего, пока main не заберёт мяч — значит, первым на экране всегда будет вывод принимающего. Именно поэтому пример выше — не «повезло с таймингом», а конструкция, которую можно повторять бесконечно.

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

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

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

Есть и удобные встроенные помощники: len(ch) — сколько значений в очереди сейчас, cap(ch) — сколько мест всего. Полезно помнить, что len меняется под ногами у конкурентных горутин: для отладки и логов он хорош, для управления логикой программы — уже рискован (это ближе к теме мьютексов и гонок).

Канал — не только труба, но и вешка: его можно закрыть встроенной функцией close(ch), объявив «новых значений не будет». Зачем? Чтобы принимающий узнал конец передачи. Представьте горутину, которая генерирует задачи: как потребителю понять, что задач больше не будет — их пять, пятьдесят или ноль? На этот вопрос отвечает close: после него любой приём из канала перестаёт блокировать.

Кто закрывает? Тот, кто отправляет: close — обещание владельца трубы, поэтому его берут в defer там же, где создаётся канал, — механика «при любом выходе» та же, что у wg.Done из прошлого урока.

Правила приёма из закрытого канала двухступенчатые. Сначала вычитывается всё, что осталось в буфере (и что «застряло» в рандеву), — обычные значения, как ни в чём не бывало. Когда буфер пуст, приём возвращает мгновенно нулевое значение типа: 0 для int, "" для string, nil для указателей. Вторая ступень потому и опасна: без проверки вы получите нули и примете их за настоящие данные.

Поэтому у приёма есть двухзначная форма: v, ok := <-ch — та же конструкция «значение и флаг», что у чтения из карт. ok — это true, пока канал открыт (или пока из буфера есть что вычитать), и false, когда канал закрыт и опустошён. Проверка ok — единственный способ отличить «настоящий ноль из канала» от «нуля, потому что данных больше нет».

Писать v, ok := <-ch в цикле вручную можно, но громоздко. Идиома лучше: for v := range ch — цикл range умеет читать каналы. Он принимает значения одно за другим и продолжается, пока канал открыт и данные идут; как только канал закрыт и опустошён, цикл корректно завершается. Это тот же range, что ходил по срезам и картам, но тут он превращается в «читай, пока есть что читать».

Ключевое правило, которое экономит часы отладки: range останавливается только на close. Если отправитель забыл закрыть канал, потребитель вычитает все значения и застрянет в ожидании следующего — цикл не закончится никогда, main подвиснет. Поэтому в Go закреплено распределение ролей: канал закрывает тот, кто в него отправляет. Принимающий закрывать канал не имеет права — и даже range не спасёт, если отправитель в другой горутине не позвал close.

Обратная сторона: закрытый канал можно продолжать читать. После close и опустошения каждый приём мгновенно возвращает ноль и ok = false — range на этом и заканчивается. Никакой ошибки чтения из закрытого канала нет; ошибка (паника send on closed channel — из той же семьи, что разобрана в уроке про panic и recover) случается только при отправке в закрытый канал и при повторном close. Запомните таблицу асимметрий: читать закрытый — можно и нужно, писать в закрытый — нельзя никогда.

Канал — двусторонняя труба, но хорошая функция должна признаваться, какой стороной она пользуется. Для этого у типа канала есть направления: chan<- int — «только отправка» (send-only), <-chan int — «только приём» (receive-only). Стрелка смотрит в сторону канала — значит, можно отправлять; стрелка смотрит из канала — можно принимать. Внутри функции с таким параметром компилятор не даст сделать лишнее: из send-only канала не прочитать, в receive-only не записать и его не закрыть.

Направленные типы — это документация, которую проверяет компилятор. Сигнатура func producer(out chan<- int) сразу говорит: эта функция только пишет. func consume(in <-chan int) int — только читает. Если вы по ошибке попытаетесь принять в producer-е, программа не соберётся — ошибка найдена в момент компиляции, а не в трёх ночи в продакшене. Обычный двунаправленный канал chan int неявно превращается в направленный при передаче: отправить канал в функцию с параметром chan<- можно, обратно — нет.

Функция put в примере ниже объявлена send-only, take — receive-only, а main владеет двунаправленным каналом и раздаёт его сторонам. Это стандартный скелет конвейера: владелец канала делает make и close, посредники получают направления.

Все блокировки каналов добрые, пока есть вторая сторона. Уберите её — и блокировка станет навсегда: дедлоком. Классическая ошибка новичка — отправить значение в незабуферизованный канал из main и надеяться, что «значение где-то сохранится»: ch := make(chan int); ch <- 1; fmt.Println(<-ch). Первая же строка ch <- 1 блокирует main навсегда: принимающего нет, а до приёма в третьей строке main не дойдёт — он стоит во второй. Одна горутина не может одновременно отправлять и принимать из одного незабуферизованного канала: рандеву требует двоих.

Рантайм распознаёт ситуацию, когда все горутины спят, — и паникует с «fatal error: all goroutines are asleep - deadlock!». В песочнице вы увидите честное прерывание по лимиту времени: программа не ответила, потому что не должна была. Второй распространённый источник дедлока — обратный: приём из канала, в который никто никогда не отправит (например, отправитель уже завершился или забыл про канал). Симптом один: программа висит.

Лекарство простое, но дисциплинарное: на каждую отправку в незабуферизованный канал должен существовать приём в другой горутине (или буфер), а горутина-производитель в цикле обязана передавать переменную параметром, как учил разбор захвата в уроке про замыкания. Если вторая сторона не гарантирована — буферизуйте, выносите отправку в горутину или пересматривайте дизайн. И держите в голове старший брат этой ошибки — nil-канал, о нём ниже.

Нулевое значение канала — nil, и это не «пустой канал», а отсутствие канала как такового. И отправка ch <- v, и приём <-ch на nil-канале блокируются навсегда: горутина просто засыпает, ожидая, что кто-то когда-то подключится к трубе, которой нет. Отсюда практическое правило: забытый make — источник «зависшей» программы без единого сообщения об ошибке. Зато в конструкциях выбора (select, урок 06) nil-канал превращается в полезный инструмент: ветку с nil-каналом планировщик никогда не выбирает, и им «выключают» остывшие направления.

Как каналы соотносятся с мьютексами? Канал — «передай данные кому-то», мьютекс — «дай мне одного подойти к общим данным». Идиома языка говорит: не общайтесь, передавая право собственности, через общую память с блокировками — передавайте сами данные по каналам (do not communicate by sharing memory; share memory by communicating). Мьютекс честнее для защиты структур данных, к которым подходят многие; канал честнее для конвейеров, где данные текут от этапа к этапу. Полное сравнение и борьба с гонками — отдельный урок курса, а пока держите критерий: если вы собрались класть в канал указатель на общую структуру и править её у всех на глазах — вам нужен мьютекс, а не канал.

Дальше по курсу: select научит ждать сразу несколько каналов и строить таймауты (и спасать от утечек горутин на каналах), пул workers покажет fan-out/fan-in на каналах задач, мьютексы и sync-примитивы закроют тему общих данных. Всё это — надстройки над четырьмя операциями сегодняшнего урока.