Какие ошибки делают команды, когда используют Tokio (Rust) без понимания его модели выполнения или сборки?

Типичные ошибки команд без понимания модели выполнения

Ошибка 1: Blocking в async контексте

// ПЛОХО: блокирует весь worker-поток
async fn handle_request() {
    std::thread::sleep(Duration::from_secs(1)); // блокирует поток!
    let data = std::fs::read_to_string("file.txt").unwrap(); // блокирует!
}

// ХОРОШО
async fn handle_request() {
    tokio::time::sleep(Duration::from_secs(1)).await;
    let data = tokio::fs::read_to_string("file.txt").await.unwrap();
    // или для CPU-bound:
    let result = tokio::task::spawn_blocking(|| {
        expensive_computation()
    }).await.unwrap();
}

Ошибка 2: Бесконтрольный spawn без backpressure

// ПЛОХО: queue растёт бесконтрольно при burst
while let Some(job) = rx.recv().await {
    tokio::spawn(process(job)); // spawn без ограничения
}

// ХОРОШО: Semaphore ограничивает конкурентность
let sem = Arc::new(tokio::sync::Semaphore::new(100));
while let Some(job) = rx.recv().await {
    let permit = sem.clone().acquire_owned().await.unwrap();
    tokio::spawn(async move {
        let _permit = permit; // держим до завершения задачи
        process(job).await;
    });
}

Ошибка 3: Игнорирование cancellation

// ПЛОХО: при cancel ресурс не освобождается
async fn write_to_db(conn: &mut Conn, data: Data) {
    conn.begin_transaction().await.unwrap();
    conn.insert(data).await.unwrap();
    // если здесь task отменена, транзакция не закоммичена
    // НО и не откатана — соединение в сломанном состоянии
    conn.commit().await.unwrap();
}

// ХОРОШО: использовать RAII guard или явный rollback в Drop
struct Transaction<'a> { conn: &'a mut Conn, committed: bool }
impl Drop for Transaction<'_> {
    fn drop(&mut self) {
        if !self.committed {
            // rollback в Drop — синхронно, без .await
        }
    }
}

Ошибка 4: tokio::sync::Mutex везде

// ПЛОХО: async Mutex дорогой, если critical section синхронная
let data = tokio::sync::Mutex::new(HashMap::new());

// ХОРОШО: для синхронных операций — std::sync::Mutex
// Правило: если внутри lock нет .await — используй std::sync::Mutex
let data = std::sync::Mutex::new(HashMap::new());
// НЕ держать std::sync::Mutex через .await — deadlock!

Ошибка 5: Забытые JoinHandle

// ПЛОХО: паника внутри spawn незаметна
tokio::spawn(async { panic!("oops"); });

// ХОРОШО: сохраняем handle и обрабатываем результат
let handle = tokio::spawn(async { panic!("oops"); });
match handle.await {
    Ok(_) => {},
    Err(e) if e.is_panic() => eprintln!("Task panicked!"),
    Err(e) => eprintln!("Task cancelled: {e}"),
}

Ошибка 6: Неправильный выбор flavour runtime

// В тестах на CI создаём несколько #[tokio::test] — каждый создаёт свой runtime
// Если тест создаёт ещё один runtime внутри — паника
// Используйте Handle::try_current() для проверки

// Для Lambda/CLI — current_thread экономит потоки
#[tokio::main(flavor = "current_thread")]
async fn main() { /* ... */ }

Подводные камни

• rayon внутри tokio::spawn: Rayon блокирует при ожидании worker-потока — deadlock если tokio-потоки == rayon-потоки.
• tracing::subscriber не установлен: без tracing_subscriber::fmt::init() все span-ы молча теряются.
• Неправильный shutdown: без runtime.shutdown_timeout() задачи могут не завершиться корректно при остановке сервиса.
• select! без default ветки: tokio::select! при отмене одной ветки дропает все остальные futures — можно потерять данные из канала.
• broadcast::Receiver lag: если receiver медленный, он пропускает сообщения с ошибкой RecvError::Lagged — часто игнорируется командой.
• interval() первый tick немедленный: tokio::time::interval() срабатывает сразу при создании. Если нужна задержка — используйте interval_at(Instant::now() + period, period).
• async в trait не стабилизирован полностью: без async-trait макроса или nightly у вас boxing overhead на каждый вызов.

• Перечислять ошибки без объяснения причин
• Не отличать beginner mistakes от production failure modes
• Не предлагать процесс, который предотвращает повторение ошибок

• Знает типичные ошибки при работе с Tokio (Rust)
• Понимает причины ошибок
• Предлагает практики prevention и early detection