Kada odabirete threading, multiprocessing ili asyncio?

Question

Accepted Answer

Python nudi tri modela konkurentnosti, a ispravan izbor ovisi uglavnom o tome je li vaš rad **I/O-bound** ili **CPU-bound** — odluka koju se GIL uvelike utječe (koji sprječava niti da izvršavaju Python kod paralelno).

## Tri modela

```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 — za I/O-bound konkurentnost

```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
```

Niti dobro funkcioniraju za I/O-bound zadatke (mrežu, datoteke, DB) jer se GIL oslobađa tijekom čekanja — višestruki čekanja nastavljaju se konkurentno. Oni **nikad** ne ubrzavaju CPU-bound rad.

## multiprocessing — za CPU-bound paralelnost

```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
```

Za teške CPU operacije (obrada slike, matematika, obrada podataka), odvojeni procesi zaobilaze jednu GIL i zaista se izvršavaju paralelno na više jezgara. Trošak: veća režija (pokretanje procesa) i podaci moraju biti **serializirani** između procesa (nema dijeljene memorije prema zadanoj vrijednosti).

## asyncio — za visoku konkurentnost 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 upravlja ogromnim brojem konkurentnih I/O operacija na jednoj niti, učinkovitije nego niti (bez per-thread režije) — idealno za servere i kod s visokom konkurentnom mrežom.

## Vodič za odluku

```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)
```

## Zašto je to važno

Odabir ispravnog modela konkurentnosti jedno je od najvažnijih Python odluka za performanse, a krivi izbor (klasična greška: niti za CPU-bound rad, što GIL čini beskorisnim) vodi do koda koji se ne skalira.

Vodilica logika teče iz GIL-a: **niti/asyncio za I/O-bound** (GIL se oslobađa tijekom čekanja — konkurentnost radi) i **multiprocessing za CPU-bound** (odvojeni GIL-ovi za pravu paralelnost), s asyncio preferiranim kada je konkurentnost vrlo visoka.

Razumijevanje snaga svakog modela, troškova (režija procesa/serializacija, zahtjevi biblioteke asyncio) i odluka I/O-vs-CPU neophodno je za pisanje konkurentnog Python-a koji zapravo pruža performanse.