Краткий ответ

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

При ёмкости канала C получение освобождает место для следующей отправки: получение k-го значения происходит до завершения отправки k+C-го значения. При этом каждая конкретная отправка всё равно синхронизируется с получением соответствующего значения.

Исторический контекст

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

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

Постановка проблемы

У небуферизованного канала отправка требует готового получателя. У буферизованного канала первые C отправок могут завершиться без получателя, поскольку значения помещаются в буфер.

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

Подробное решение

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

package main

import "fmt"

func main() {
	ch := make(chan int, 2)
	ch <- 1
	ch <- 2
	go func() {
		fmt.Println(<-ch)
	}()
	ch <- 3
}

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

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

Слишком маленький буфер чаще блокирует производителей и снижает пропускную способность при неравномерной нагрузке. Слишком большой буфер увеличивает задержку обнаружения перегрузки, потребление памяти и объём работы, который может оказаться устаревшим к моменту обработки.

Ситуация из практики

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

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

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

Что кандидаты часто упускают

Доказывает ли успешная отправка в буфер, что получатель уже выполнялся?

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

Что меняется для канала нулевой ёмкости?

При C, равном нулю, буфер отсутствует: отправитель и получатель должны встретиться в одной операции. Специальное правило сводится к тому, что получение k-го значения происходит до завершения отправки k-го значения, то есть передача не может завершиться независимо от готовности получателя.

Можно ли изменить ёмкость уже созданного канала?

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