Kiedy wybrać threading, multiprocessing lub asyncio?

Question

Accepted Answer

Python oferuje trzy modele współbieżności, a prawidłowy wybór zależy głównie od tego, czy praca jest **I/O-bound** czy **CPU-bound** — decyzja silnie kształtowana przez GIL (który uniemożliwia wątkom równoległy kod Python).

## Trzy modele

```text
threading        → multiple threads, ONE process. GIL-limited for CPU.
multiprocessing  → multiple PROCESSES, each its own interpreter/GIL → true parallelism.
asyncio          → single thread, cooperative coroutines yielding at await points.
```

## threading — dla współbieżności I/O-bound

```python
from concurrent.futures import ThreadPoolExecutor

# ✅ good for I/O — the GIL is RELEASED during I/O waits, so waits overlap
with ThreadPoolExecutor(max_workers=10) as ex:
    results = list(ex.map(download_url, urls))   # many downloads concurrently
```

Wątki sprawdzają się dobrze w zadaniach I/O-bound (sieć, pliki, baza danych), ponieważ GIL jest zwalniany podczas czekania — wiele czekaczy przebiega jednocześnie. **Nie** przyspieszają pracy CPU-bound.

## multiprocessing — dla paralelizmu CPU-bound

```python
from concurrent.futures import ProcessPoolExecutor

# ✅ good for CPU — separate processes each have their own GIL → use all cores
with ProcessPoolExecutor(max_workers=4) as ex:
    results = list(ex.map(heavy_computation, data))   # genuine parallelism
```

Pracy wymagające dużej mocy obliczeniowej (przetwarzanie obrazów, matematyka, przetwarzanie danych) obchodzą pojedynczy GIL za pomocą oddzielnych procesów i działają w rzeczywistości równolegle na wielu rdzeniach. Koszt: wyższe obciążenie (start procesu) i dane muszą być **serializowane** między procesami (brak domyślnie wspólnej pamięci).

## asyncio — dla wysokiej współbieżności I/O

```python
import asyncio
# ✅ best for MANY concurrent I/O operations (thousands) — lightest weight
await asyncio.gather(*(fetch(url) for url in urls))
```

asyncio obsługuje ogromną liczbę współbieżnych operacji I/O na jednym wątku, bardziej efektywnie niż wątki (brak obciążenia na wątek) — idealne dla serwerów i kodu sieciowego o wysokiej współbieżności.

## Przewodnik decyzyjny

```text
CPU-bound (computation)              → multiprocessing
I/O-bound, moderate concurrency      → threading (simple, works with sync libraries)
I/O-bound, HIGH concurrency          → asyncio (thousands of connections, but needs
                                       async-compatible libraries)
Mixed CPU + I/O                       → combine (e.g. asyncio + a process pool for CPU)
```

## Dlaczego to ważne

Wybór odpowiedniego modelu współbieżności to jedna z najbardziej znaczących decyzji dotyczących wydajności w Pythonie, a błędny wybór (klasyczny błąd: wątki do pracy CPU-bound, którą GIL czyni bezużyteczną) prowadzi do kodu, który się nie skaluje.

Logika kierunkowa wynika z GIL: **wątki/asyncio dla I/O-bound** (GIL zwalniany podczas czekaczy — współbieżność działa) i **multiprocessing dla CPU-bound** (oddzielne GILy dla rzeczywistego paralelizmu), z asyncio preferowanym gdy współbieżność jest bardzo wysoka.

Zrozumienie mocnych stron każdego modelu, kosztów (obciążenie procesu/serializacja, wymagania bibliotek asyncio) i decyzji I/O-vs-CPU jest niezbędne do napisania współbieżnego Pythona, który faktycznie dostarcza wydajność.