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

spawn_blocking использует отдельный пул потоков с ограниченным числом одновременно выполняемых задач. Когда лимит достигнут, новые задачи обычно помещаются в очередь, поэтому их передача в spawn_blocking не гарантирует немедленный параллельный запуск каждой задачи. Кроме того, CPU-bound работа конкурирует за ограниченное число ядер и может ухудшить производительность всего процесса.

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

Асинхронные runtime рассчитаны на короткие неблокирующие операции: worker-поток должен быстро вернуть управление планировщику, чтобы обслуживать другие futures. Синхронный вызов, который блокирует поток, нарушает эту модель и может остановить прогресс множества async-задач.

spawn_blocking появился как адаптационный механизм: блокирующую работу выносят из async worker-потоков в отдельный пул. Это сохраняет отзывчивость основного executor, но не превращает пул в бесконечный источник вычислительных ресурсов.

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

Предположим, сервис получил много CPU-bound задач и отправил их все через spawn_blocking. Если runtime создавал бы неограниченное количество потоков, система быстро столкнулась бы с конкуренцией за CPU, расходом памяти, частыми переключениями контекста и ростом задержек.

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

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

spawn_blocking отделяет место выполнения от async worker-потоков, но не отменяет планирование ресурсов. Runtime решает, сколько blocking-потоков можно запустить одновременно; конкретный лимит и политика очереди зависят от runtime и его конфигурации.

Для I/O-bound блокирующих операций такой подход обычно эффективен: пока один поток ждёт файловую систему или синхронный клиент, другие задачи могут выполняться. Для CPU-bound работы ожидания нет, поэтому каждый занятый поток постоянно конкурирует за процессорное время.

use tokio::task::spawn_blocking;

#[tokio::main]
async fn main() {
    let mut handles = Vec::new();
    for input in 0..100 {
        handles.push(spawn_blocking(move || expensive_calculation(input)));
    }
    for handle in handles {
        let _ = handle.await;
    }
}

fn expensive_calculation(input: u32) -> u32 {
    (0..input * 1000).sum()
}

В примере все задачи могут быть поставлены в blocking-пул, но фактическое число одновременно исполняемых замыканий ограничено. Для большого количества CPU-bound задач обычно лучше использовать специализированный вычислительный пул, например пул с контролируемым числом рабочих потоков, соответствующим доступным ядрам. Это позволяет отделить вычислительную нагрузку от блокирующих операций и заранее управлять очередью.

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

Сервис обрабатывает HTTP-запросы и запускает тяжёлое сжатие данных. Первый вариант передаёт каждое сжатие в spawn_blocking. Плюс решения — async worker-потоки не блокируются; минус — при всплеске запросов blocking-пул и CPU насыщаются, а задержки запросов становятся непредсказуемыми.

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

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

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

Вопрос: Чем ограничение blocking-пула отличается от ограничения числа async-задач?

Ответ: Async-задача обычно является лёгким объектом состояния и может находиться в очереди runtime в большом количестве. Blocking-задача после запуска занимает настоящий поток, поэтому её количество ограничивает память, планировщик ОС и доступный CPU. Ограничение blocking-пула контролирует именно одновременно выполняющиеся блокирующие замыкания, а не общее число созданных futures.
Вопрос: Почему увеличение лимита blocking-пула может ухудшить результат для CPU-bound работы?

Ответ: Если рабочих потоков становится больше, чем эффективно поддерживаемое число CPU-ядер, потоки начинают конкурировать за процессор. Растут переключения контекста, давление на кэш и задержки других потоков, включая async worker-потоки. Увеличение лимита может повысить пропускную способность для блокирующего I/O, но для вычислений часто лишь усиливает перегрузку.
Вопрос: Почему конечная очередь перед вычислительным пулом важна даже при наличии ограничения числа рабочих потоков?

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