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

Ограниченный async-канал имеет фиксированную вместимость. Когда буфер заполнен, операция отправки не блокирует поток runtime, а приостанавливает текущую async-задачу до освобождения места; так скорость производителя связывается со скоростью потребителя.

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

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

В синхронных программах ожидание свободного места часто блокирует поток. В async-модели ожидание представляется как незавершённый future, поэтому runtime может выполнять на том же потоке другие готовые задачи.

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

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

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

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

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

Пока отправитель ожидает, поток runtime не обязан простаивать: он может переключиться на другие готовые futures. Когда потребитель извлекает сообщение, канал освобождает место и уведомляет ожидающую задачу; после повторного опроса future отправка может завершиться.

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

В Tokio отправка через send(...).await обычно ожидает свободного места, а try_send немедленно сообщает, что канал заполнен. Выбор между ними — это выбор политики: ждать, отклонять сообщение, повторять попытку с задержкой или применять деградацию сервиса.

use tokio::sync::mpsc;

#[tokio::main]
async fn main() {
    let (tx, mut rx) = mpsc::channel(2);
    let producer = tokio::spawn(async move {
        for value in 0..5 {
            tx.send(value).await.expect("receiver dropped");
        }
    });

    while let Some(value) = rx.recv().await {
        println!("{value}");
        tokio::time::sleep(std::time::Duration::from_millis(100)).await;
    }
    producer.await.unwrap();
}

После заполнения буфера на две позиции следующая отправка приостанавливает задачу производителя. Это не блокировка системного потока; отправитель продолжит работу после того, как потребитель извлечёт сообщение.

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

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

Сервис принимает события HTTP и передаёт их одному потребителю, который записывает данные во внешнее хранилище. Во время всплеска запросов потребитель становится узким местом.

Неограниченный канал сохраняет все события, но создаёт риск роста памяти и обработки устаревших данных. Немедленный try_send защищает память, однако приводит к потере событий при каждом кратком всплеске. Увеличение числа потребителей повышает пропускную способность, но может нарушить порядок обработки или превысить лимиты внешнего хранилища.

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

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

Чем ожидание в ограниченном async-канале отличается от блокировки потока?

При блокировке поток не может выполнять другую работу до освобождения ресурса. При send().await задача переходит в состояние ожидания, а runtime получает возможность запускать другие готовые задачи на этом потоке. Однако код до и после точки ожидания всё равно выполняется обычным образом, поэтому длительная синхронная работа внутри задачи по-прежнему может блокировать поток.
Почему нельзя безусловно заменить ожидание send().await на try_send?

try_send меняет семантику системы: заполненный канал становится немедленной ошибкой, а не сигналом замедлиться. Это подходит для телеметрии или устаревающих уведомлений, но опасно для платежей, команд и других обязательных событий. Простое повторение try_send в плотном цикле также создаёт активное ожидание и может перегрузить CPU; повторные попытки должны иметь паузу, лимит или другую стратегию.
Что происходит с ожидающей отправкой при закрытии канала?

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