Каналы: точки синхронизации, ограниченные очереди и дедлоки между ними

Небуферизованный — рандеву, буферизованный — очередь

У небуферизованного канала (make(chan T)) нет хранилища: отправка блокируется, пока получатель не будет готов, и значение передаётся напрямую из стека одной горутины в стек другой. Это делает его точкой синхронизации: когда ch <- v вернулся, вы знаете, что получатель забрал значение, и отправка гарантированно happens-before завершения приёма. Буферизованный канал (make(chan T, n)) — ограниченная FIFO-очередь: отправки завершаются мгновенно, пока есть ёмкость, и блокируются, когда она исчерпана; приёмы блокируются на пустом канале. Семантика различается качественно, а не количественно: небуферизованный канал передаёт и синхронизирует; буферизованный в основном лишь передаёт, ничего не говоря о том, когда выполнялась другая сторона.

Ёмкость — ручка настройки с острой гранью. Ёмкость 0 связывает продюсера и консьюмера такт в такт. Небольшой буфер (размером с реальный всплеск) гасит джиттер и расцепляет их расписания. «Бесконечный» буфер (make(chan T, 1_000_000)) — способ превратить видимый backpressure (давление обратной связи: продюсер блокируется, когда консьюмер не успевает) в невидимый рост памяти: продюсер не почувствует отставание консьюмера, пока процесс не словит OOM. Правило сениора: выбирайте 0, если не можете назвать измеренный всплеск, который буфер должен поглотить, и относитесь к заполненному буферу как к сигналу (консьюмер слишком медленный), а не как к препятствию, которое обходят числом побольше.

Аксиомы каналов

Четыре поведения определяют каждый канальный баг, который вы будете отлаживать:

1. Отправка в nil-канал блокируется навсегда. Приём — тоже. var ch chan int без make — или чтение из map, вернувшее нулевое значение, — даёт горутину, припаркованную навечно. Сознательно полезно внутри select: присвоив каналу кейса nil, вы отключаете этот кейс.
2. Приём из закрытого канала возвращается сразу с нулевым значением типа; двухзначная форма v, ok := <-ch сообщает ok == false. Цикл for range ch завершается, когда канал закрыт и вычерпан — поэтому range по каналу, который никто не закрывает, висит вечно.
3. Отправка в закрытый канал паникует. Всегда, немедленно, и по сути это нарушение протокола: две стороны считали, что владеют каналом.
4. Закрытие закрытого (или nil) канала паникует. Close — одноразовый broadcast, а не уборка, которую рассыпают на всякий случай.

Все четыре аксиомы вместе объясняют каждый загадочный дедлок или панику, с которыми вы столкнётесь: nil-канал молча поглощает, закрытый молча осушается, второй писатель молча портит — три разных режима отказа, все невидимые без знания аксиом. Закрывает отправитель, никогда не получатель, и закрывает ровно одна сторона. Close означает «значений больше не будет никогда» — это сообщение от продюсера. При нескольких продюсерах ни один из них не может закрыть безопасно; идиома — sync.WaitGroup по продюсерам и одна горутина-супервизор, вызывающая close после wg.Wait().

// Fan-out / fan-in с правильной дисциплиной close и отменой.
func process(ctx context.Context, rows <-chan Row) <-chan Result {
	out := make(chan Result)
	var wg sync.WaitGroup
	for i := 0; i < 8; i++ { // fan-out: 8 воркеров читают из одного входного канала
		wg.Add(1)
		go func() {
			defer wg.Done()
			for r := range rows { // выходит, когда rows закрыт и вычерпан
				select {
				case out <- transform(r):
				case <-ctx.Done(): // разблокирует отправку, если downstream исчез
					return
				}
			}
		}()
	}
	go func() { // ровно один закрывальщик, после того как ВСЕ отправители закончили
		wg.Wait()
		close(out)
	}()
	return out // fan-in: консьюмер читает из одного объединённого потока
}

select: композиция каналов и запасной выход default

select ждёт несколько канальных операций и выполняет одну из готовых, выбирая равномерно случайно среди готовых кейсов — случайность намеренная, она предотвращает голодание кейса, который «тоже всегда готов». С веткой default он становится неблокирующим: попробуй операцию, провались дальше, если она заблокировала бы. Это строительный блок паттернов try-send — сбрасывать нагрузку вместо того, чтобы её копить:

select {
case events <- e: // доставлено
default:
	droppedTotal.Inc() // буфер полон: сбрасываем и считаем, не блокируем горячий путь
}

Честный компромисс: default превращает блокировку в потерю данных, что правильно для метрик и неправильно для денег. Средний вариант — кейс с таймаутом (case <-time.After(d) — или переиспользуемый time.Timer в горячих циклах, поскольку time.After аллоцирует таймер, живущий до срабатывания).

Отмена течёт вниз по пайплайну

Пайплайн надёжен ровно настолько, насколько продумана его история выхода. Стандартный контракт: каждая стадия принимает context.Context, и каждая отправка сидит внутри select с веткой case <-ctx.Done(). Отмена течёт вниз от вызывающего; close течёт вперёд вместе с данными; и горутины разблокируются независимо от того, какая сторона исчезла. Пропустите select на отправке — и вы воспроизведёте историю из вступления: стадия ниже по течению, переставшая читать, оставляет каждого отправителя выше припаркованным навсегда — утечка из предыдущего урока, поставленная на поток. Рантайм объявляет deadlock! только когда припаркована каждая горутина; в реальном сервере с одним живым HTTP-листенером ваш дедлокнутый пайплайн просто молча стоит, неотличимый от простоя нигде, кроме goroutine-профиля.