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

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

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

Каналы в Go предназначены не только для передачи данных, но и для координации горутин. Закрытие канала отделяет состояние «значения ещё могут поступить» от состояния «производитель завершил отправку» без отдельного управляющего сообщения.

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

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

Если потребитель не различает нулевое значение элемента и признак закрытия, он может принять завершение канала за настоящий результат. Это особенно опасно для типов, у которых нулевое значение является допустимым рабочим значением: например, для int ноль может быть обычными данными.

Закрывать канал должен отправитель, который знает, что новых отправок не будет. Отправка в закрытый канал приводит к панике, а повторное закрытие также приводит к панике.

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

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

package main

import "fmt"

func main() {
    ch := make(chan int, 1)
    ch <- 7
    close(ch)

    v, ok := <-ch
    fmt.Println(v, ok)
    v, ok = <-ch
    fmt.Println(v, ok)
}

Программа напечатает сначала 7 true, затем 0 false. Цикл for range автоматически получает значения до опустошения закрытого канала и после этого завершается.

Закрытие не делает канал nil и не запрещает получать из него данные. Для незакрытого канала отсутствие значения обычно означает блокировку, а для закрытого и пустого канала получение завершается сразу с ok == false.

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

В пуле обработки задач одна горутина отправляет задания, а несколько рабочих горутин получают их из канала. После чтения всех входных данных производитель закрывает канал; рабочие завершают циклы range, когда обработают оставшиеся буферизованные задания.

Альтернатива — отправлять специальное значение «завершение». Она плохо масштабируется: нужно заранее согласовать такое значение, а при нескольких потребителях требуется дополнительная координация. Использование закрытия лучше выражает именно окончание потока, но требует гарантировать единственного ответственного за закрытие.

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

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

Можно ли получить значения из канала после его закрытия?

Да. Все значения, которые уже находятся в буфере, будут возвращены в обычном порядке. Только после опустошения канала получение начнёт возвращать нулевое значение и false.

Что произойдёт при отправке в закрытый канал?

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

Почему нельзя использовать только полученное значение вместо ok?

Потому что нулевое значение может быть настоящим элементом потока. Например, получение 0 из канала chan int не показывает, был ли отправлен ноль или канал уже закрыт и пуст. Второй результат ok однозначно различает эти случаи.