Каналы в Go

С буфером и без

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

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

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

// Размер буфера - не «чем больше, тем лучше». Большой буфер прячет проблему: система работает, очередь растёт, задержка растёт, и всё это невидимо, пока память не кончится. Буфер на единицы или десятки сглаживает всплеск, буфер на миллион маскирует то, что потребитель просто не справляется.

небуферизованный канал

передача происходит только при встрече отправителя и получателя

Закрытие: правила без исключений

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

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

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

// Когда отправителей несколько, закрывать канал напрямую нельзя ни одному из них: любой рискует закрыть его раньше соседа. Стандартный приём - отдельная горутина ждёт WaitGroup всех отправителей и закрывает канал после того, как все завершились.

ch := make(chan int, 2)
ch <- 1
close(ch)

v, ok := <-ch   // 1, true   - данные из буфера
v, ok = <-ch    // 0, false  - канал закрыт и пуст
v, ok = <-ch    // 0, false  - и так сколько угодно раз

Каналы как элемент дизайна

Направление указывают в сигнатуре: chan<- int только для отправки, <-chan int только для приёма. Компилятор проследит, и читателю сразу видно, кто здесь производитель, а кто потребитель. Функция, возвращающая <-chan Result, честно говорит: закрывать буду я, ты только читай.

Канал пустых структур chan struct{} - идиома сигнала. Пустая структура занимает ноль байт, данных не передаётся, передаётся сам факт события: «начинай», «стоп», «готово». Закрытие такого канала работает как широковещательное оповещение - все, кто читает, разблокируются разом.

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

// Полезное правило выбора, которое любят на собеседовании: передаёшь данные между задачами - канал, защищаешь состояние от одновременного доступа - мьютекс. Каналы не заменяют sync, они решают другую задачу.

chan struct{}

канал-сигнал: данных нет, передаётся факт события; закрытие оповещает всех разом

Как отвечать: «Кто должен закрывать канал и что вернёт приём из закрытого?»

Закрывает отправитель, и только он: получатель не знает, будет ли ещё отправка, а отправитель знает. Плюс отправка в закрытый канал паникует, так что право закрытия обязано лежать у того, кто контролирует конец потока. Приём из закрытого канала при этом полностью безопасен: он не блокируется и не паникует, а сразу возвращает нулевое значение типа. Чтобы отличить настоящий ноль от закрытия, используют форму с двумя результатами: v, ok := <-ch, где ok равно false после закрытия. Я это проверял: если в буфере лежал элемент, первый приём отдаёт его с ok true, а все следующие - ноль и false. range по каналу на закрытии корректно завершается, и это основной способ читать поток. Отдельный случай - несколько отправителей: тогда закрывать не может ни один из них, потому что каждый рискует опередить остальных. Стандартный приём - отдельная горутина ждёт WaitGroup всех отправителей и закрывает канал после них.

Названо правило с причиной, точно описано поведение приёма с проверенными значениями, упомянут range и отдельно разобран случай нескольких отправителей - тот самый следующий вопрос.

На чём валят

• −Закрывают канал на стороне получателя - отправитель следом паникует.
• −Забывают закрыть канал, и range на другой стороне висит вечно.
• −Не различают ноль-значение и закрытие: без формы v, ok это одно и то же.
• −Дают нескольким отправителям закрывать один канал вместо горутины-закрывашки.
• −Ставят огромный буфер и прячут за ним то, что потребитель не справляется.
• −Городят каналы вокруг общего счётчика там, где нужен обычный мьютекс.