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

Ветка select, использующая nil-канал, навсегда считается неготовой и фактически отключается. Если все ветви связаны с nil-каналами и отсутствует default, select блокируется навсегда.

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

Каналы в Go имеют нулевое значение nil, что позволяет объявлять канал без немедленного создания внутреннего объекта канала. Это согласуется с общей моделью Go, где нулевые значения допустимы, но не всегда означают готовность объекта к работе.

Поведение nil-канала особенно полезно вместе с select: изменение переменной канала на nil позволяет динамически исключить соответствующую операцию из набора ожидаемых событий без отдельного флага.

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

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

Ошибочная замена рабочего канала на nil без понимания механизма приводит к вечной блокировке. Это особенно опасно, если nil-канал становится единственной возможной ветвью select и в программе отсутствует путь завершения.

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

Операция чтения из nil-канала и отправка в nil-канал блокируются навсегда. Закрыть nil-канал нельзя: попытка закрытия вызывает панику.

В select ветвь с чтением или отправкой через nil-канал не участвует в выборе. Поэтому присваивание каналу значения nil временно отключает конкретное направление обмена:

package main

import "fmt"

func main() {
    var ch chan int

    select {
    case v := <-ch:
        fmt.Println(v)
    default:
        fmt.Println("нет готовой операции")
    }
}

В примере чтение из ch не может стать готовым, поэтому выбирается default. Если убрать default, select заблокируется навсегда.

Важно отличать nil-канал от закрытого канала. Чтение из закрытого канала немедленно завершается, а чтение из nil-канала блокируется. Поэтому после обнаружения закрытия одного из каналов в цикле его часто присваивают nil, чтобы убрать эту ветвь из последующих выборов.

Такой приём удобен для динамического управления набором каналов, но требует явного контроля завершения. Нельзя рассчитывать, что select сам выйдет из ожидания, если все его рабочие каналы стали nil.

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

Сервис агрегирует результаты от нескольких источников. После завершения одного источника его канал закрывается, но оставлять ветвь чтения активной нельзя: чтение из закрытого канала будет немедленно возвращаться, и цикл начнёт потреблять процессор.

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

Выбранное решение — после обработки всех значений закрытого канала присвоить соответствующей переменной канала nil. Это исключает ветвь из select, позволяя продолжить работу с остальными источниками; цикл завершается, когда все каналы отключены или приходит сигнал отмены.

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

Дополнительный вопрос: Что произойдёт, если в select останутся только nil-каналы, но будет присутствовать default?

Ответ: Немедленно выберется default, потому что ни одна операция через nil-канал не готова. Такой select не блокируется, но при выполнении в tight loop может создать активное ожидание и загрузить процессор.

Дополнительный вопрос: Можно ли использовать nil-канал как безопасный способ завершить ожидающую операцию?

Ответ: Нет. Изменение переменной канала на nil отключает только будущие операции через эту переменную в конкретном select. Уже выполняющаяся горутина, заблокированная на прежнем канале, от этого не разблокируется; для её завершения нужен другой механизм, например канал отмены или контекст.

Дополнительный вопрос: Чем опасно присваивание nil каналу, который должен принимать данные от производителя?

Ответ: Приёмник перестанет выбирать соответствующую ветвь select, а производитель при отправке в этот канал может заблокироваться навсегда, если нет другого получателя или буфера, способного принять значение. Поэтому отключать канал можно только после гарантии, что производитель больше не будет отправлять данные либо имеет отдельный путь отмены.