# Async/Await w Rust: Tokio, Futures i asynchroniczna współbieżność w praktyce

> Kompletny przewodnik po programowaniu asynchronicznym w Rust. Artykuł wyjaśnia mechanizm futures, runtime Tokio, spawning zadań, kanały mpsc, obsługę błędów oraz wzorce produkcyjne z ograniczaniem współbieżności.

- Published: 2026-04-30
- Updated: 2026-04-30
- Author: SharpSkill
- Tags: rust, async, tokio, futures, concurrency
- Reading time: 12 min

---

Programowanie asynchroniczne w Rust opiera się na trzech filarach: składni async/await, leniwie ewaluowanych futures oraz zewnętrznym runtime. W przeciwieństwie do języków takich jak JavaScript czy Python, gdzie runtime asynchroniczny jest wbudowany w interpreter, Rust wymaga jawnego wyboru executora -- najczęściej jest nim Tokio. Ta decyzja projektowa nie jest przypadkowa: dzięki niej abstrakcja async/await w Rust jest tzw. zero-cost abstraction, co oznacza brak narzutu w czasie wykonania w porównaniu z ręcznie napisanym kodem opartym na callbackach.

Dla programistów przygotowujących się do rozmów kwalifikacyjnych (rust concurrency interview) zrozumienie tych mechanizmów jest niezbędne. Rust nie ukrywa złożoności współbieżności za magicznym API -- zamiast tego daje pełną kontrolę nad tym, jak i kiedy zadania asynchroniczne są wykonywane.

> Futures w Rust są leniwe -- samo wywołanie funkcji async nie rozpoczyna żadnej pracy. Dopiero .await lub przekazanie future do executora uruchamia faktyczne obliczenie. To fundamentalna różnica w stosunku do Promise w JavaScript, które startują natychmiast po utworzeniu.

## Jak działają Futures w Rust -- cecha Future pod lupą

W wielu językach programowania obietnice (promises) lub futures to obiekty, które natychmiast rozpoczynają wykonanie operacji asynchronicznej. W Rust mechanizm ten działa zupełnie inaczej. Cecha `Future` definiuje interfejs oparty na odpytywaniu (polling), gdzie runtime wielokrotnie wywołuje metodę `poll`, aż future zwróci gotowy wynik.

```rust
// core::future::Future
trait Future {
    type Output;
    fn poll(self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output>;
}
```

Metoda `poll` zwraca `Poll::Ready(value)` gdy wynik jest dostępny lub `Poll::Pending` gdy operacja jeszcze trwa. W tym drugim przypadku future rejestruje waker w kontekście `cx`, który powiadomi runtime o konieczności ponownego odpytania. Ten model pull-based daje kompilatorowi możliwość optymalizacji maszyn stanów generowanych z bloków async -- i właśnie dlatego rust futures explained w kontekście wydajności zawsze wraca do tego fundamentu.

## Konfiguracja Tokio jako runtime asynchronicznego

Tokio to najpopularniejszy runtime asynchroniczny w ekosystemie Rust. Zapewnia wielowątkowy executor, timer, operacje I/O oraz prymitywy synchronizacji. Każdy rust tokio tutorial zaczyna się od konfiguracji zależności w pliku `Cargo.toml`.

```toml
# Cargo.toml
[dependencies]
tokio = { version = "2", features = ["rt-multi-thread", "macros", "net", "time"] }
```

Makro `#[tokio::main]` przekształca asynchroniczną funkcję `main` w synchroniczny punkt wejścia, który uruchamia runtime Tokio i blokuje bieżący wątek do momentu zakończenia wszystkich zadań.

```rust
// main.rs
#[tokio::main]
async fn main() {
    let result = fetch_data().await;
    println!("Got: {result}");
}

async fn fetch_data() -> String {
    // Simulate async I/O
    tokio::time::sleep(std::time::Duration::from_millis(100)).await;
    String::from("data loaded")
}
```

Warto zwrócić uwagę, że `fetch_data()` bez `.await` zwróciłoby jedynie future -- żadna praca nie zostałaby wykonana. Dopiero operator `.await` uruchamia odpytywanie i oddaje kontrolę executorowi na czas oczekiwania.

## Spawning zadań i strukturalna współbieżność

W aplikacjach produkcyjnych rzadko wystarcza sekwencyjne wykonywanie operacji asynchronicznych. `tokio::spawn` pozwala uruchomić niezależne zadanie, które będzie wykonywane współbieżnie z innymi zadaniami na puli wątków executora.

```rust
// concurrent_tasks.rs
use tokio::task::JoinHandle;

#[tokio::main]
async fn main() {
    // Spawn two independent tasks
    let handle_a: JoinHandle<u32> = tokio::spawn(async {
        expensive_computation("dataset_a").await
    });

    let handle_b: JoinHandle<u32> = tokio::spawn(async {
        expensive_computation("dataset_b").await
    });

    // Await both results
    let (result_a, result_b) = (
        handle_a.await.expect("task A panicked"),
        handle_b.await.expect("task B panicked"),
    );

    println!("Results: {result_a}, {result_b}");
}

async fn expensive_computation(name: &str) -> u32 {
    tokio::time::sleep(std::time::Duration::from_secs(1)).await;
    println!("{name} done");
    42
}
```

`JoinHandle` działa jak uchwyt do spawned task -- jego `.await` zwraca wynik zadania opakowany w `Result`, co pozwala obsłużyć sytuację, gdy zadanie spanikowało. Oba zadania wykonują się równolegle, więc łączny czas to ok. 1 sekunda, a nie 2.

## Łączenie futures: tokio::join! i tokio::select!

Gdy trzeba równocześnie wykonać kilka operacji i poczekać na wszystkie wyniki, makro `tokio::join!` jest idiomatycznym rozwiązaniem. W przeciwieństwie do sekwencyjnych `.await`, `join!` uruchamia wszystkie futures współbieżnie.

```rust
// join_example.rs
use tokio::time::{sleep, Duration};

#[tokio::main]
async fn main() {
    // All three run concurrently, total time ~200ms (not 600ms)
    let (users, orders, inventory) = tokio::join!(
        fetch_users(),
        fetch_orders(),
        fetch_inventory()
    );

    println!("Users: {}, Orders: {}, Stock: {}", users.len(), orders.len(), inventory);
}

async fn fetch_users() -> Vec<String> {
    sleep(Duration::from_millis(200)).await;
    vec!["Alice".into(), "Bob".into()]
}

async fn fetch_orders() -> Vec<String> {
    sleep(Duration::from_millis(150)).await;
    vec!["ORD-001".into()]
}

async fn fetch_inventory() -> u32 {
    sleep(Duration::from_millis(100)).await;
    84
}
```

Z kolei `tokio::select!` czeka na pierwsze future, które się zakończy, i anuluje pozostałe. Ten wzorzec jest nieoceniony przy implementacji timeoutów, fallbacków cache/baza danych czy nasłuchiwaniu na wielu kanałach jednocześnie.

```rust
// select_example.rs
use tokio::time::{sleep, Duration};

#[tokio::main]
async fn main() {
    tokio::select! {
        val = fetch_from_cache() => {
            println!("Cache hit: {val}");
        }
        val = fetch_from_database() => {
            println!("DB result: {val}");
        }
    }
}

async fn fetch_from_cache() -> String {
    sleep(Duration::from_millis(5)).await;
    "cached_value".into()
}

async fn fetch_from_database() -> String {
    sleep(Duration::from_millis(50)).await;
    "db_value".into()
}
```

W powyższym przykładzie cache odpowiada po 5 ms, więc gałąź bazodanowa zostanie anulowana. Jest to typowy wzorzec stosowany w systemach o niskich wymaganiach latencji.

## Obsługa błędów w asynchronicznym Rust

Kod asynchroniczny w Rust korzysta z tego samego systemu typów `Result<T, E>` co kod synchroniczny. Operator `?` działa bezproblemowo wewnątrz funkcji async, co pozwala na elegancką propagację błędów bez utraty kontekstu.

```rust
// error_handling.rs
use std::io;

#[derive(Debug)]
enum AppError {
    Network(reqwest::Error),
    Parse(serde_json::Error),
    Io(io::Error),
}

async fn load_config(url: &str) -> Result<Config, AppError> {
    let response = reqwest::get(url)
        .await
        .map_err(AppError::Network)?;

    let text = response.text()
        .await
        .map_err(AppError::Network)?;

    let config: Config = serde_json::from_str(&text)
        .map_err(AppError::Parse)?;

    Ok(config)
}

#[derive(serde::Deserialize)]
struct Config {
    db_url: String,
    port: u16,
}
```

Wzorzec z dedykowanym enumem `AppError` mapującym różne typy błędów jest standardem w projektach produkcyjnych. Każdy wariant enuma otacza konkretny typ błędu z odpowiedniej biblioteki, co zachowuje pełną informację diagnostyczną.

## Kanały do komunikacji asynchronicznej

Gdy zadania asynchroniczne muszą wymieniać dane, kanały MPSC (multiple producer, single consumer) oferują bezpieczny i ergonomiczny mechanizm komunikacji. Tokio dostarcza zarówno kanały ograniczone (bounded), jak i nieograniczone (unbounded).

```rust
// channel_example.rs
use tokio::sync::mpsc;

#[tokio::main]
async fn main() {
    // Bounded channel with capacity 32
    let (tx, mut rx) = mpsc::channel::<String>(32);

    // Producer task
    let producer = tokio::spawn(async move {
        for i in 0..5 {
            tx.send(format!("message-{i}")).await.unwrap();
            tokio::time::sleep(std::time::Duration::from_millis(10)).await;
        }
        // tx dropped here, closing the channel
    });

    // Consumer reads until channel closes
    while let Some(msg) = rx.recv().await {
        println!("Received: {msg}");
    }

    producer.await.unwrap();
}
```

Kanał ograniczony o pojemności 32 oznacza, że producent zostanie wstrzymany (backpressure), jeśli konsument nie nadąża z przetwarzaniem wiadomości. To naturalne ograniczenie przepływu zapobiega niekontrolowanemu zużyciu pamięci. Po upuszczeniu nadajnika (`tx`) kanał zostaje zamknięty, a pętla `while let` w konsumencie kończy się w sposób kontrolowany.

## Wzorzec produkcyjny: współbieżne HTTP z ograniczaniem szybkości

W rzeczywistych aplikacjach rzadko można wysłać tysiące żądań HTTP jednocześnie bez ograniczeń. Semafor z `tokio::sync::Semaphore` pozwala kontrolować maksymalną liczbę jednocześnie wykonywanych operacji.

```rust
// rate_limited_fetcher.rs
use std::sync::Arc;
use tokio::sync::Semaphore;

async fn fetch_all(urls: Vec<String>, max_concurrent: usize) -> Vec<Result<String, String>> {
    let semaphore = Arc::new(Semaphore::new(max_concurrent));
    let mut handles = Vec::new();

    for url in urls {
        let sem = Arc::clone(&semaphore);
        let handle = tokio::spawn(async move {
            // Acquire permit before making request
            let _permit = sem.acquire().await.unwrap();
            reqwest::get(&url)
                .await
                .map(|r| r.status().to_string())
                .map_err(|e| e.to_string())
            // permit dropped here, allowing next task to proceed
        });
        handles.push(handle);
    }

    let mut results = Vec::new();
    for handle in handles {
        results.push(handle.await.unwrap());
    }
    results
}
```

Wszystkie zadania są spawnowane natychmiast, ale tylko `max_concurrent` z nich może jednocześnie posiadać permit semafora. Pozostałe czekają asynchronicznie, nie blokując wątku executora. Gdy zadanie kończy żądanie HTTP, permit jest automatycznie zwalniany (drop), co pozwala kolejnemu zadaniu kontynuować pracę.

## Pin i Unpin -- dlaczego to ma znaczenie

Sygnatura metody `poll` zawiera `Pin<&mut Self>`, co jest bezpośrednio związane z bezpieczeństwem pamięci w kontekście asynchronicznym. Gdy kompilator Rust przekształca blok `async` w maszynę stanów, ta maszyna może zawierać referencje wewnętrzne (self-referential struct). Przesunięcie takiej struktury w pamięci unieważniłoby te referencje.

`Pin` gwarantuje, że dana wartość nie zostanie przeniesiona w pamięci po jej przypięciu. Większość typów w Rust implementuje cechę `Unpin` automatycznie, co oznacza, że można je swobodnie przenosić nawet po przypięciu. Natomiast futures generowane przez bloki `async` zazwyczaj nie implementują `Unpin`, dlatego wymagają przypięcia.

W praktyce programiści rzadko muszą bezpośrednio operować na `Pin` -- rust async await ukrywa tę złożoność za składnią `.await`. Jednak zrozumienie tego mechanizmu jest kluczowe przy implementacji własnych futures lub pracy z bibliotekami niskopoziomowymi.

## Wydajność i spawn_blocking

Runtime Tokio wykorzystuje pulę wątków roboczych do obsługi zadań asynchronicznych. Domyślna konfiguracja `rt-multi-thread` tworzy tyle wątków, ile rdzeni procesora. Kluczowa zasada brzmi: nigdy nie wolno blokować wątku executora długotrwałą operacją synchroniczną.

Dla operacji intensywnie obciążających CPU -- takich jak haszowanie, kompresja czy parsowanie dużych zbiorów danych -- Tokio udostępnia `spawn_blocking`, które przenosi pracę na dedykowaną pulę wątków blokujących.

```rust
// spawn_blocking_example.rs
#[tokio::main]
async fn main() {
    let hash = tokio::task::spawn_blocking(|| {
        // CPU-intensive work runs on a blocking thread
        compute_hash(b"large dataset")
    })
    .await
    .unwrap();

    println!("Hash: {hash}");
}

fn compute_hash(data: &[u8]) -> String {
    use std::collections::hash_map::DefaultHasher;
    use std::hash::{Hash, Hasher};
    let mut hasher = DefaultHasher::new();
    data.hash(&mut hasher);
    format!("{:x}", hasher.finish())
}
```

Zablokowanie wątku executora operacją CPU na kilkaset milisekund może spowodować, że setki innych zadań asynchronicznych przestaną być obsługiwane. `spawn_blocking` eliminuje ten problem, izolując pracę blokującą od lekkiego executora async.

## Podsumowanie

Asynchroniczne programowanie w Rust oferuje unikalne połączenie wydajności i bezpieczeństwa, ale wymaga zrozumienia kilku fundamentalnych koncepcji:

- **Futures są leniwe** -- nie wykonują pracy dopóki nie zostaną jawnie odpytane przez runtime lub oczekiwane przez `.await`.
- **Tokio** to najdojrzalszy runtime asynchroniczny, zapewniający wielowątkowy executor, timery, kanały i prymitywy synchronizacji.
- **tokio::join!** wykonuje wiele futures współbieżnie i czeka na wszystkie, podczas gdy **tokio::select!** reaguje na pierwszą zakończoną operację.
- **Kanały mpsc** zapewniają bezpieczną komunikację między zadaniami z wbudowanym mechanizmem backpressure.
- **Semafory** pozwalają ograniczyć współbieżność w scenariuszach produkcyjnych, takich jak odpytywanie zewnętrznych API.
- **Pin** chroni self-referential futures przed przesunięciem w pamięci, gwarantując bezpieczeństwo referencji wewnętrznych.
- **spawn_blocking** izoluje operacje CPU-intensive od executora asynchronicznego, chroniąc responsywność aplikacji.

Opanowanie rust async await i ekosystemu Tokio jest dzisiaj niezbędnym elementem kompetencji każdego programisty Rust. Tematy te pojawiają się regularnie podczas rozmów kwalifikacyjnych i stanowią fundament budowy wydajnych, współbieżnych aplikacji sieciowych.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/pl/blog/rust/rust-async-await-tokio-futures-concurrency