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

Проверка len канала перед отправкой ненадёжна как способ гарантировать отсутствие блокировки. len возвращает только моментальный снимок состояния: другая горутина может изменить канал сразу после проверки. Для попытки отправки без блокировки применяйте select с веткой default, а не предварительную проверку len.

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

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

Такое разделение важно: канал отвечает за корректную передачу и блокировку операций, а не за предоставление транзакции вида «проверить свободное место и затем гарантированно отправить».

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

Условие len(ch) < cap(ch) может быть истинным в момент проверки, но другая горутина успеет занять свободное место до отправки. В результате отправитель всё равно заблокируется. Обратная ситуация также возможна: канал был заполнен при проверке, но место освободилось до попытки отправки.

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

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

len(ch) для буферизованного канала показывает число значений, находящихся в буфере на момент вызова, а cap(ch) — его вместимость. Эти значения можно использовать для диагностики, метрик и приблизительного наблюдения, но нельзя использовать как синхронизационный протокол между горутинами.

Для атомарной попытки отправки используется select: операции в его ветвях проверяются и выбираются как единая операция. Если отправка готова, выполняется её ветвь; если места нет и присутствует default, выполняется default без блокировки.

package main

func trySend(ch chan<- int, value int) bool {
	select {
	case ch <- value:
		return true
	default:
		return false
	}
}

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

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

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

Сервис собирает телеметрию и передаёт её в ограниченный буфер. Разработчик проверяет свободное место через len и при наличии места отправляет событие. Под нагрузкой несколько горутин проходят проверку одновременно, одна занимает последнее место, а другая блокируется, хотя логика должна была пропустить событие или сразу его отклонить.

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

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

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

Вопрос: Может ли len канала измениться между проверкой и последующей отправкой в одной и той же горутине?

Ответ: Да. Планировщик может переключить выполнение между этими операциями, а другие горутины могут отправить значение или получить его. Даже если переключения не произошло практически сразу, корректность программы не должна зависеть от такого предположения: проверка и отправка не образуют атомарную пару.
Вопрос: Что означает len небуферизованного канала в момент, когда другая горутина готова принять значение?

Ответ: Он всё равно равен нулю. У небуферизованного канала нет очереди значений, поэтому наличие ожидающего получателя не отражается через len. Готовность конкретной операции можно проверить только самой операцией, например отправкой в select с default.
Вопрос: Делает ли select с default отправку безопасной, если канал может быть закрыт другой горутиной?

Ответ: Нет. Если канал закрыт, отправка в него недопустима и приводит к панике; default не превращает закрытие в обычный отказ. Нужно организовать владение каналом так, чтобы отправители не конкурировали с его закрытием, либо передавать отмену отдельным механизмом и закрывать канал только после завершения всех отправителей.