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

Для этого используется область видимости потоков через std::thread::scope. Она позволяет потокам заимствовать локальные данные, потому что гарантирует завершение всех дочерних потоков до выхода из области видимости.

В отличие от обычного thread::spawn, scoped-потоки не требуют, чтобы захваченные значения жили до конца программы: их время жизни ограничено временем работы scope.

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

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

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

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

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

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

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

std::thread::scope создаёт область, внутри которой можно запускать scoped-потоки. Замыкание потока может захватывать ссылки на данные внешней функции, но сам scope не возвращает управление наружу, пока все созданные потоки не завершатся.

use std::thread;

fn main() {
    let data = [10, 20, 30, 40];

    thread::scope(|scope| {
        for part in data.chunks(2) {
            scope.spawn(move || {
                println!("{}", part.iter().sum::<i32>());
            });
        }
    });
}

Здесь part — ссылка на часть локального массива. Она безопасна, потому что data живёт дольше всех потоков внутри scope, а выход из scope невозможен до их завершения.

Механизм не отменяет требования Send для данных, передаваемых в поток, и Sync для данных, доступных через общую ссылку. Scoped-потоки лишь ослабляют требование 'static; они не делают небезопасные совместные обращения допустимыми.

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

Компромисс состоит в том, что scope блокирует выход из своей области до завершения потоков. Это удобно для пакетной параллельной работы, но не подходит для фоновых задач, которые должны продолжать работу после возврата из функции. Для таких задач нужен обычный spawn и данные с подходящим временем жизни, например собственные значения или Arc.

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

Сервис обрабатывает большой буфер только в пределах одного запроса и хочет распределить независимые диапазоны между рабочими потоками.

Рассматриваются три варианта:

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

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

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

1. Почему обычный thread::spawn не может принять ссылку на локальную переменную, даже если сразу после запуска вызывается join?

Требование 'static проверяется в момент создания потока. Компилятор не выводит из последующего вызова join, что поток обязательно будет присоединён именно до уничтожения конкретной локальной переменной: дескриптор можно передать, забыть или сохранить другим способом. thread::scope встраивает это ограничение в API и потому может безопасно разрешить более короткое время жизни.

2. Делает ли область видимости потоков безопасным совместное изменение одного объекта без mutex?

Нет. Scope гарантирует время жизни и завершение потоков, но не устраняет гонки данных. Несколько потоков не могут получить конфликтующие &mut-заимствования одного объекта; если доступ идёт через общую ссылку, сам тип должен поддерживать безопасную синхронизацию, например через Mutex, атомарный тип или другой корректный примитив.

3. Что произойдёт, если scoped-поток запаникует?

Scope всё равно должен дождаться завершения созданных потоков, чтобы ссылки не вышли из области действия преждевременно. После этого паника обычно передаётся вызывающему коду через результат join или самим scope, если панику не обработать явно. Поэтому scoped-потоки ограничивают время жизни, но не превращают ошибки потоков в автоматически игнорируемые события.