Ответ.

История вопроса: Каналы — одна из фундаментальных концепций CSP-модели в Go. Они предназначены для обмена данными между горутинами. Работа с каналами требует особой осторожности, чтобы избежать deadlock, утечек и паник при закрытии.

Проблема: Закрытие и дальнейшее использование каналов часто приводит к панике (panic: send on closed channel). Работа с nil-каналами или попытки читать из закрытого канала без проверки могут дать неожиданный результат. Разные горутины могут одновременно писать и читать в один канал, что требует четко описанной логики жизненного цикла.

Решение: Канал всегда должен закрываться только с той стороны, где в канал больше не будет писать никто (обычно продюсер). После закрытия из канала можно читать значения до истощения, но писать нельзя — будет panic. Проверять закрытие удобно через второй возвращаемый параметр из канала:

Пример кода:

ch := make(chan int)
go func() {
    for i := 0; i < 5; i++ {
        ch <- i
    }
    close(ch)
}()
for v := range ch {
    fmt.Println(v)
}

Ключевые особенности:

• Канал должен закрываться только там, где никто больше в него не пишет.
• Чтение из закрытого канала даёт zero value (0 для int, "" для string) и false во втором параметре.
• Писать в закрытый канал — panic.

Вопросы с подвохом.

1. Нужно ли закрывать канал, если его читает только одна горутина и больше никто не ожидает дополнительные значения?

Ответ: Закрывать канал не обязательно, если никто не ждёт его закрытия через range. Но если использован цикл for v : = range ch — да, канал закрыть нужно обязательно, иначе цикл не завершится.

2. Что будет, если читать из закрытого канала?

Ответ: Значения будут возвращаться, пока не опустошится буфер, потом — zero value и признак false. Канал безопасно читать до конца после закрытия.

ch := make(chan int, 1)
ch <- 42
close(ch)
v, ok := <-ch // v = 42, ok = true
v, ok = <-ch  // v = 0, ok = false

3. Кто должен закрывать канал: читатель или писатель?

Ответ: Всегда "писатель" (тот, кто отправляет значения и знает, когда работа закончена). "Читатель" не должен закрывать канал, чтобы не привести к race.

Типовые ошибки и анти-паттерны

• Закрытие канала не "отправителем", а "приёмником".
• Попытка писать в закрытый канал, что приводит к panic.
• Некорректная организация обработки конечных условий через range по незакрытому каналу.
• Забытие закрытия каналов, из-за чего циклы-читатели блокируются навсегда (deadlock).

Пример из жизни

Негативный кейс

В приложении несколько горутин пишут в один канал, одна читает. Кто-то закрыл канал в читателе, а другая горутина ещё пыталась отправить — panic.

Плюсы: Условно простая логика взаимодействия. Минусы: Невозможность предсказать момент закрытия, паники, race-condition.

Позитивный кейс

Писатель ведёт учёт всех горутин, использует sync.WaitGroup, закрывает канал только после завершения всех писателей. Читатель корректно завершает цикл range после закрытия канала, безопасно обрабатывает ошибки.

Плюсы: Корректная синхронизация, нет утечек и deadlock, предсказуемое поведение. Минусы: Чуть сложнее логика, необходимо явно завершать все работы.