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

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

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

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

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

Нулевое значение типа может быть совершенно валидными данными: 0 для числа, false для логического типа, пустая строка для строки или нулевая структура. Если проверять только полученное значение, программа не сможет отличить отправленное нулевое значение от чтения из уже закрытого канала.

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

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

При получении из канала Go возвращает пару: значение и булев признак. Признак равен true, если значение действительно получено из канала, и false, если канал закрыт и опустошён.

package main

import "fmt"

func main() {
    ch := make(chan int, 2)
    ch <- 0
    close(ch)

    value, ok := <-ch
    fmt.Println(value, ok) // 0 true
    value, ok = <-ch
    fmt.Println(value, ok) // 0 false
}

Сначала получатель извлекает отправленное значение 0, поэтому ok равен true. После исчерпания буфера чтение из закрытого канала возвращает нулевое значение типа int и ok == false.

Удобный вариант для обработки всего потока — range по каналу: цикл автоматически завершается после закрытия канала и опустошения его буфера. Закрывать канал должен тот компонент, который владеет отправкой и знает, что новых значений больше не будет; получатель обычно лишь реагирует на закрытие.

Для nil-канала это правило не применяется: получение из него блокируется навсегда, поскольку такой канал не был инициализирован. Получение из закрытого канала, напротив, не блокируется; после исчерпания значений оно немедленно возвращает нулевое значение и false.

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

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

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

Можно было бы передавать отдельный специальный код завершения, но это усложняет контракт и требует гарантировать уникальность кода. Выбран двухзначный результат получения: реальные нулевые результаты обрабатываются при ok == true, а завершение потока — при ok == false. В результате сервис корректно принимает все результаты и предсказуемо завершает обработку после закрытия канала.

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

1. Что произойдёт при чтении из закрытого буферизованного канала, если в буфере ещё есть значения?

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

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

2. Можно ли определить закрытие канала, не извлекая из него значение?

У обычного канала нет отдельной неблокирующей операции «проверить, закрыт ли канал». Проверка через len или cap также не решает задачу: они не сообщают надёжно о закрытии и не дают корректного протокола синхронизации.

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

3. Что произойдёт, если продолжить получать значения из закрытого канала?

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

Именно по этой причине следует использовать ok или range. Отправка в закрытый канал имеет другое поведение: она приводит к панике, но это не меняет безопасного поведения операций получения.