Каналы

Channel — это типизированный канал передачи значений между горутинами. Небуферизированный синхронизирует: отправка блокируется, пока не готов получатель. Буферизированный (make(chan T, n)) хранит до n значений, и отправка блокируется только когда буфер заполнен.

Канал, созданный через make(chan T), — это типизированный канал передачи между горутинами. Отправка пишется как ch <- v, а приём — как v := <-ch; стрелка всегда указывает в направлении движения значения. На небуферизированном канале отправка блокируется, пока другая горутина не будет готова принять, а приём блокируется, пока значение не придёт, поэтому обе горутины встречаются и синхронизируются в этой точке. Тип элемента T фиксируется при создании.

Небуферизированный канал имеет ёмкость 0, поэтому каждая отправка блокируется, пока получатель не будет готов забрать значение — отправка и приём должны встретиться. Буферизированный канал из make(chan T, n) хранит до n значений, поэтому первые n отправок завершаются без ожидающего получателя и блокируются, только когда буфер заполнен. Это развязывает отправителя и получателя на n элементов: производитель может забегать вперёд, сглаживая всплески, но не получает неограниченного запаса.

select ждёт, пока одна из его channel-веток не станет готовой; если готовы несколько, он выбирает одну равновероятно случайно. С веткой default он никогда не блокируется — если ни одна ветка не готова, сразу выполняется default. Пустой select{} блокируется навсегда.

Используйте форму comma-ok v, ok := <-ch: ok равно false, когда channel закрыт и опустошён, а v — нулевое значение типа элемента. Идиоматичная альтернатива — цикл for range ch: он завершается автоматически при закрытии channel.

И отправка, и приём на nil channel блокируются навсегда — операция никогда не продолжается и не паникует. Channel-переменная с нулевым значением равна nil. Это иногда применяют намеренно в select, отключая ветку присваиванием её channel значения nil.

for v := range ch продолжает принимать значения одно за другим и завершается только когда канал закрыт и опустошён. close(ch) — это сигнал отправителя, что значений больше не будет; range по незакрытому каналу блокируется навсегда, как только тот опустеет. Приём из закрытого канала возвращает нулевое значение элемента с ok == false, что и останавливает цикл. Закрывать должен только отправитель, а повторное закрытие или отправка после закрытия вызывает панику.

Приём из закрытого channel возвращает нулевое значение с ok == false, поэтому (1) даёт v == 0, ok == false. Отправка в закрытый channel паникует с send on closed channel, поэтому (2) паникует. Повторное закрытие закрытого channel тоже паникует, поэтому (3) паникует. Правило — закрывает отправитель, никогда не получатель, и только один раз.

context.Context переносит сигналы отмены, дедлайны и значения уровня запроса через границы API. Вызов функции cancel или наступление дедлайна закрывает channel Done() контекста; это закрытие распространяется на каждый производный дочерний контекст, и все они видят отмену.

Channel — это указатель на runtime-структуру hchan: кольцевой буфер (buf с индексами sendx/recvx и счётчиками элементов), две очереди ожидания заблокированных горутин (sendq, recvq) и mutex. Каждая отправка/приём берёт лок; если операция не может пройти, горутина паркуется в очереди и позже будится своим партнёром. Закрытие выставляет флаг и будит обе очереди.

Будет deadlock: fatal error: all goroutines are asleep - deadlock!. Отправка в небуферизированный channel блокируется, пока не готов получатель, но единственная горутина заблокирована на этой отправке, поэтому приём не выполняется. Исправление: отправлять из отдельной горутины или make(chan int, 1).

Отправка в закрытый channel немедленно паникует с send on closed channel. Избегайте этого, назначив одного владельца ответственным за закрытие и никогда не закрывая из получателя или из нескольких отправителей. Закрытие решает отправитель, получатель лишь обнаруживает его через comma-ok.

for v := range ch принимает значения, пока channel не закрыт. Продьюсер отправляет 1 и 2, но никогда не вызывает close(ch), поэтому потребитель навсегда блокируется после их вычерпывания, wg.Done() не выполняется, и wg.Wait() тоже блокируется — deadlock. Исправление: close(ch) после последней отправки.

Печатает 02468. С ёмкостью 1 на одной goroutine ветки отправки и приёма чередуются: при пустом буфере готова лишь отправка (кладёт i, ничего не печатает); на следующей итерации буфер полон, поэтому готов лишь приём (печатает сохранённое чётное значение). С небуферизированным channel ни одна ветка никогда не готова на одной goroutine, поэтому это fatal error: all goroutines are asleep - deadlock.

Печатает 6. Go вычисляет выражение с двумя операндами слева направо: первый <-worker() вызывает worker() (запускает goroutine №1) и затем блокируется на 3с на приёме из него. Только после этого вообще стартует второй worker(), и блокируется ещё на 3с — они идут последовательно, всего ~6с. Чтобы совместить, сначала запустите обе: c1, c2 := worker(), worker(); <-c1; <-c2 → ~3с.

select по двум case: case <-ctx.Done(): return false и case <-timer.C: return true. Не используйте time.After, который течёт нижележащим таймером до срабатывания; вместо этого t := time.NewTimer(d); defer t.Stop(), чтобы при отмене таймер освобождался сразу.

Запустите unpredictableFunc в goroutine, которая шлёт результат в буферизированный channel ёмкости 1, затем select между этим channel и ctx.Done(). Буфер здесь несущий: с небуферизированным channel worker навсегда блокируется на отправке после таймаута, утекая. Если у ctx нет дедлайна, оберните его context.WithTimeout с defer cancel().

cancelCtx хранит лениво создаваемый channel Done и набор дочерних контекстов; cancel закрывает этот channel и рекурсивно отменяет детей. timerCtx оборачивает его time.Timer, который вызывает cancel по дедлайну. valueCtx — один узел ключ/значение, и поиск идёт вверх по цепочке родителей.

Две ошибки. Закрывающая goroutine записана как go func(){ wg.Wait(); close(out) } без завершающих (), поэтому она объявлена, но не запущена — out никогда не закрывается и range merge(...) уходит в deadlock. Вторая: замыкание worker захватывает переменную цикла c, поэтому до 1.22 все goroutine читают один и тот же последний channel. Исправление: вызвать закрытие через () и передать c аргументом (или переобъявить).

Горутина утекает, когда навсегда блокируется на отправке или приёме channel, который никто не удовлетворит — например, worker отправляет результат, когда вызвавший уже вернулся. Давайте каждой блокирующей операции выход: select по ctx.Done() или буферизированный channel результата.

Запустите по горутине на каждый входной канал, каждая range-ит свой канал и шлёт все значения в общий out. sync.WaitGroup считает пересыльщиков; отдельная горутина зовёт wg.Wait(), затем close(out), поэтому выход закрывается ровно один раз после опустошения всех входов. out верните сразу. range по входам и закрытие out только после Wait исключают и панику send-on-closed, и утечку горутины.