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

Если несколько ветвей select готовы одновременно, выбирается одна из них псевдослучайно. Порядок case не задаёт приоритет, поэтому полагаться на обработку первой ветви нельзя.

Если готовых ветвей нет, select блокируется, пока одна из операций не станет доступной. Наличие default меняет это поведение: при отсутствии готовой операции сразу выбирается default.

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

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

Такой механизм особенно полезен для объединения данных, тайм-аутов, сигналов отмены и завершения работы в одном цикле обработки.

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

Предположим, обработчик одновременно получает данные из рабочего канала и сигнал отмены. В момент выбора обе операции могут быть готовы.

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

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

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

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

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

Минимальный пример показывает, почему порядок ветвей не определяет результат:

package main

import "fmt"

func main() {
	left := make(chan int, 1)
	right := make(chan int, 1)
	left <- 1
	right <- 2

	select {
	case v := <-left:
		fmt.Println("left", v)
	case v := <-right:
		fmt.Println("right", v)
	}
}

Оба канала готовы до входа в select, поэтому программа может вывести любую из двух строк. Для приоритета одного события нужно явно строить дополнительную логику, а не менять порядок case.

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

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

В сервисе обработчик читает задания из канала и должен завершаться по context.Done(). После отмены контекста оба события иногда готовы: в очереди уже есть задание, а сигнал отмены уже закрыт.

Вариант с надеждой на порядок case плох: select не гарантирует приоритет отмены. Вариант с постоянным default тоже нежелателен: он усложняет цикл и может создать активное ожидание.

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

Такой подход явно фиксирует семантику завершения, не приписывает select несуществующий приоритет и предотвращает зависание воркеров.

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

Гарантирует ли select справедливое чередование готовых ветвей?

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

Что меняется при добавлении default?

Без default select блокируется при отсутствии готовых операций. С default он немедленно завершает выбор через эту ветвь, поэтому цикл может непрерывно проверять каналы, не блокируясь. Такой режим подходит для разовой неблокирующей проверки, но в цикле обычно требует паузы, таймера или другой стратегии ожидания, иначе возникает busy loop.

Зачем в select используют канал nil?

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