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

Код отклоняется, потому что std::sync::mpsc::Receiver<T> реализует Send, но не Sync. Его можно передать целиком другому потоку, однако нельзя безопасно разделить один экземпляр между потоками через Arc.

Arc<T> можно передать между потоками только когда T: Sync, поскольку клонированные Arc одновременно предоставляют доступ к одному объекту. Для общего приёмника обычно используют Arc<Mutex<Receiver<T>>> либо многопотребительский канал с поддержкой клонирования приёмников.

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

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

Тип std::sync::mpsc означает «много отправителей, один получатель». Такая модель специально отделяет масштабирование отправителей от масштабирования потребителей: Sender можно клонировать, а Receiver — нет.

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

Arc защищает время жизни объекта и потокобезопасно подсчитывает число ссылок, но не делает сам объект безопасным для одновременного доступа. Поэтому Arc<Receiver<T>> не превращает приёмник в общий потокобезопасный ресурс.

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

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

Для Arc<T> действует важное условие: чтобы значение Arc<T> можно было отправить в другой поток, T должен быть Sync. Это необходимо, потому что разные копии Arc могут обращаться к одному T одновременно.

В данном коде Arc<Receiver<u32>> перемещается в замыкание thread::spawn. Компилятор проверяет, что замыкание можно безопасно отправить в новый поток, и обнаруживает: Receiver<u32> не реализует Sync, поэтому общий Arc недопустим.

Минимальный вариант с мьютексом выглядит так:

use std::{sync::{mpsc, Arc, Mutex}, thread};

fn main() {
    let (tx, rx) = mpsc::channel::<u32>();
    let shared_rx = Arc::new(Mutex::new(rx));

    for _ in 0..2 {
        let worker_rx = Arc::clone(&shared_rx);
        thread::spawn(move || loop {
            let job = worker_rx.lock().unwrap().recv();
            match job {
                Ok(job) => println!("{job}"),
                Err(_) => break,
            }
        });
    }
    drop(tx);
}

Мьютекс делает доступ к Receiver последовательным и тем самым добавляет требуемые Send/Sync-гарантии. Вызов recv выполняется под блокировкой, поэтому в каждый момент времени только один поток получает сообщение; обработку задачи лучше выполнять после освобождения мьютекса, иначе медленная работа одного обработчика задержит выдачу задач всем остальным.

У стандартного mpsc это компромисс: общий приёмник можно защитить мьютексом, но сама операция получения остаётся узким местом. Если нужна естественная модель «несколько потребителей», следует выбрать канал, в котором приёмник можно клонировать; тогда каждый поток получает собственный handle, а очередь распределяет сообщения между ними.

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

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

Второй вариант — общий Receiver под Mutex. Он прост и использует стандартную библиотеку, но выдача заданий сериализуется; при коротком получении задачи это обычно приемлемо, а при высокой частоте сообщений мьютекс становится заметным ограничением.

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

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

Почему Arc<Mutex<Receiver<T>>> допустим, хотя сам Receiver<T> не Sync?

Mutex<T> предоставляет синхронизированный доступ к T и реализует Sync, если доступ к T можно безопасно передавать между потоками. В данном случае Receiver<T> является Send, поэтому мьютекс может владеть им и выдавать временный эксклюзивный доступ только одному потоку.
Решает ли Arc<Mutex<Receiver<T>>> проблему параллельного выполнения задач?

Нет. Он параллелизует обработку после получения задания, но не саму операцию получения: рабочие потоки по очереди захватывают мьютекс. Поэтому нельзя держать блокировку во время обработки; нужно извлечь задание, освободить мьютекс и только затем выполнять работу.
Почему Arc<Sender<T>> обычно допустим, а Arc<Receiver<T>> — нет?

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