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

T: Sync означает, что общую ссылку типа &T можно безопасно передавать между потоками и использовать там одновременно. Формально тип T является Sync, если &T является Send. Это гарантирует, что параллельный доступ через неизменяемые ссылки не создаёт гонок данных или другого нарушения правил безопасной памяти.

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

Rust стремится проверять безопасность многопоточности во время компиляции, не требуя сборщика мусора и обязательной стоимостью синхронизации во время выполнения. Для этого язык разделяет две независимые гарантии: Send описывает безопасность передачи владения между потоками, а Sync — безопасность совместного доступа через ссылки.

Такой подход решает классическую проблему системных языков: объект может физически находиться в общей памяти, но безопасным является только тот способ доступа, который допускает его тип. Типы-сигналы Send и Sync позволяют библиотекам выражать это ограничение в системе типов.

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

Если несколько потоков получают &T, они могут читать один объект одновременно. Однако неизменяемая ссылка не гарантирует безопасность сама по себе: внутри T могут находиться изменяемые данные, небезопасные указатели или состояние, не защищённое синхронизацией.

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

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

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

Связь формулируется так: T: Sync тогда и только тогда, когда &T: Send. Передача &T между потоками означает, что один объект становится доступен через общие ссылки в разных потоках, поэтому тип обязан выдерживать такой параллельный доступ.

Send и Sync не являются взаимозаменяемыми. Тип может быть Send, но не Sync: его можно передать целиком в другой поток, но нельзя безопасно разделять между потоками через &T. Например, Cell<T> и RefCell<T> допускают локальную внутреннюю изменяемость без блокировок, поэтому не являются Sync.

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

Минимальный пример безопасного общего изменения состояния:

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

fn main() {
    let data = Arc::new(Mutex::new(Vec::<u8>::new()));
    let shared = Arc::clone(&data);

    let handle = thread::spawn(move || {
        shared.lock().unwrap().push(1);
    });

    handle.join().unwrap();
    assert_eq!(*data.lock().unwrap(), vec![1]);
}

Здесь Arc передаёт владение ссылочным счётчиком в поток, а Mutex не позволяет двум потокам одновременно изменять Vec. Само наличие Arc без Mutex не разрешило бы безопасную мутацию.

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

Допустим, несколько рабочих потоков используют общий кэш конфигурации. Если конфигурация полностью неизменяема после создания, подходящим вариантом будет Arc<Config> при условии, что Config: Send + Sync. Он не требует блокировки при чтении и имеет небольшие накладные расходы на подсчёт ссылок.

Вариант с Arc<RefCell<Config>> дешевле для однопоточной программы, но не компилируется для безопасного межпоточного использования: RefCell проверяет заимствования во время выполнения без межпоточной синхронизации. Применение Arc<Mutex<Config>> решает проблему, но добавляет блокировки и возможное ожидание конкурирующих потоков.

Выбор зависит от доступа: для неизменяемого кэша лучше разделяемое чтение через Arc<Config>, для редких записей — Arc<RwLock<Config>>, а для коротких критических секций с простым протоколом — Arc<Mutex<Config>>. Результат — компилятор не позволяет случайно заменить потокобезопасный контейнер на локальный тип с небезопасной внутренней изменяемостью.

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

Вопрос: Достаточно ли требования T: Send, чтобы безопасно передавать &T между потоками?

Ответ: Нет. Send означает безопасность передачи самого значения во владение другого потока. Для передачи общей ссылки требуется T: Sync, потому что именно это гарантирует &T: Send. Тип может быть перемещаемым между потоками, но не поддерживать одновременный доступ через несколько ссылок.
Вопрос: Делает ли Arc<T> тип T потокобезопасным?

Ответ: Нет. Arc безопасно управляет совместным владением и атомарным счётчиком ссылок, но не синхронизирует внутреннее состояние T. Поэтому свойства Send и Sync для Arc<T> зависят от T; для изменяемого общего состояния нужен, например, Mutex или RwLock.
Вопрос: Почему Mutex<T> может быть Sync, даже если T сам по себе не является Sync?

Ответ: Mutex не предоставляет одновременный доступ к T: получить &mut T или &T можно только через охраняемый блокировкой доступ. Для передачи защищённого значения между потоками обычно требуется T: Send, чтобы значение можно было безопасно перемещать между потоками под контролем блокировки. При этом конкретные ограничения реализации и комбинации трейтов определяются стандартной библиотекой, но принцип остаётся тем же: безопасность обеспечивается сериализацией доступа, а не свойствами T без оболочки.